Los sistemas Windows 95/98 y NT soportan nombres de ficheros largos,
así mismo mantienen la compatibilidad con los sistemas (8.3). El que
en los nuevos sistemas 32bits de Microsoft se puedan hacer llamadas
utilizando cualquiera de los dos métodos está provocando problemas
de seguridad.
En las anteriores versiones de DOS y Windows 16bits los nombres de
fichero podían estar compuestos por un máximo de 8 caracteres, seguidos
de un punto, y 3 caracteres más para la extensión (“fichero.exe”). Los
nuevos sistemas permiten el uso de nombres de ficheros largos, de hasta
255 caracteres. En los Windows 32bits, y para guardar compatibilidad
con versiones anteriores, es posible invocar a los ficheros por el
nombre largo o por una entrada corta truncada. Por ejemplo, el fichero
“nombreunpocolargo” de 17 caracteres puede ser también llamado como
“nombre~1” respetando el máximo de 8 caracteres de versiones anteriores.
El problema se presenta en diversos programas que no respetan las
politicas de seguridad impuestas a determinados ficheros o directorios
cuando son invocados por el método corto de truncar el nombre largo.
Por ejemplo, en Internet Information Server 4.0 (SP3) se pueden
configurar los directorios para que no listen sus contenidos a través
de la web. Si desactivamos el listado de directorio en
C:\inetpub\wwwroot\directoriolargo\ podremos comprobar que funciona
correctamente con el nombre largo, denegando el visualizar su contenido
a través del navegador mediante la dirección http://servidor/directoriolargo.
Sin embargo, si introducimos la dirección con el nombre del directorio
truncado, http://servidor/direct~1, obtendremos el listado.
La misma vulnerabilidad se presenta en los servidores vqServer 1.9,
Xitami 2.4d2, Cat Soft Serv-U 2.5, Netscape Enterprise Server 3.0
y Netscape FastTrack Server versiones 2.01 y 3.0.1. Donde las
restricciones aplicadas a los directorios con nombres largos son
ignoradas al llamarlos con la versión truncada.
En el caso del IIS 4.0 la solución pasa por tener actualizado Windows NT
con el SP4 o SP5. En muchos casos ocurre que, aun teniendo el pertinente
Service Pack instalado, el servidor continue manteniendo la vulnerabilidad,
ésto es debido a que la instalación posterior de paquetes de software
pueden hacer que partes de los parches sean sobreescritos con versiones
anteriores. Para evitar estas sorpresas es aconsejable reinstalar los
Service Pack después de cualquier instalación de software adicional en
el servidor.
En el caso de los servidores de Netscape ya existen parches disponibles.
Como medidas más generales, lo más cómodo a priori resulta utilizar
siempre nombres de ficheros cortos, con lo que desaparecen los problemas
de raíz. Algo similar puede lograrse al contrario, es decir, forzando
a Windows NT a que no pueda crear nombres de fichero truncados mediante
la siguiente entrada en el registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem
Variable: NtfsDisable8dot3NameCreation
Tipo: REG_DWORD
Valor: 1
Esta solución será válida en Windows NT que utilicen el sistema de
archivos NTFS, como contrapartida hay que indicar que no tiene caracter
retroactivo, no funcionará en volúmenes FAT, y dará problemas si se
utilizan aplicaciones de 16bits.
Más información:
Bugtraq
Deja un comentario