Más sobre las vulnerabilidades de rutas de DLL en aplicaciones sobre Windows

No para de aumentar la lista de programas informáticos -algunos de ellos muy populares- que sufren vulnerabilidadas con métodos públicos de aprovechamiento ("exploits") ya públicamente disponibles -algunos de uso sencillo al ser incluidos en la conocida herramienta Metasploit- donde las vulnerabilidades están relacionadas con el problema del orden de búsqueda de librerías (o ficheros de biblioteca) dinámicas (DLL) en Windows, en especial con que el "directorio actual" esté incluido en el orden de búsqueda de Windows (el directorio actual de una aplicación suele ir cambiando, por ejemplo, cuando se va explorando con la respectiva ventana de "abrir ficheros" de la aplicación) y la aplicación contenga fallos -lamentablemente muy habituales- como del tipo de intentar cargar una librería propia que ya no necesita realmente y ya no existe o no instala.

Los exploits y mecanismos de ataques son tan simples como depositar un fichero DLL normal (con la funcionalidad maliciosa deseada, generalmente instalar malware) en un recurso externo (disco USB, recurso de red ,etc) que tenga el nombre de una de las librerías mal programadas para ser cargadas en una de las aplicaciones vulnerables y esperar a que desde dicha aplicación se abra o "vaya" a ese directorio. Nótese que en especial no se requiere construir ningún fichero con contenido complejo hábilmente preparado como suele ser habitual en exploits de otras vulnerabilidades.

Ante la explosión de exploits disponibles de cada vez más aplicaciones muy conocidas y para mitigar la proliferación de instalación de malware vía esta familia de vulnerabilidades, Microsoft ha publicado una actualización cuya instalación define un nuevo parámetro de configuración de Windows que permite eliminar el directorio actual del camino de búsqueda o restringir su uso, si bien , esta contramedida está suponiendo problemas colaterales en muchas aplicaciones, algunas de Microsoft, tal y como podemos leer en los siguientes extractos traducidos de la noticia de ISC de SANS y comentarios de lectores:


'Las DLLs más importantes se especifican en una rama del registro (HKLM/System/CurrentControlSet/Control/Session Manager/KnownDLLs). Aquí la situación es sencila – si una aplicación necesita cargarla, el sistema sabe que tiene que ser desde el directorio especificado en la clave de registro DllDirectory, que suele valer %SystemRoot%/system32.

Sin embargo, en otros casos, el sistema intenta dinámicamente buscar la DLL. Al principio, Microsoft cometió un error al colocar el directorio actual en el primer lugar de búsqueda (algunos de los antiguos conocedores de Unix recordarán los tiempos cuando "." estaba en el primer lugar de la variable PATH). Microsoft corrigió esto con la introducción del valor del registro SafeDllSearchMode setting (registry value) que espeficica el orden en que una DLL debe buscarse. Por ejemplo, tal y como se especifica en http://msdn.microsoft.com/en-us/library/ms682586%28v=VS.85%29.aspx el orden de búsqueda con SafeDllSearchMode habilitado:

1. El directorio desde el que se abre la aplicación
2. El directorio de sistema.' [...]
3. 'El directorio de sistema de 16-bit ' [...]
4. 'El directorio de Windows' [...]
5. 'El directorio actual
6. Los directorios especificados en la variable de ambiente PATH. ' [...]

Si varios directorios contiene una DLL con el mismo nombre, el primer ajuste según el order anterior gana. Este ajuste viene establecido por defecto ya en Windows XP SP2.

El problema aparece, por ejemplo, cuando una aplicación intenta cargar una DLL que no existe en el sistema' [..]

'Microsoft ha publicado varios artículos describiendo los detalles de esta vulnrabilidad a la par que describiendo varias contramedidas ["workarounds"]. El boletín principal de seguridad está disponible aquí (2269637).' [..]' También ha publicaod una herramienta que permite crear listas negras de directorios para que no sean utilizados en la carga de librerías. Más información aquí y sobre la herramienta en sí aquí. La herramienta añade un nuevo valor de registro denominado CWDIllegailInDllSearch. '


'[...] si [CWDIllegailInDllSearch] se establece a 0xFFFFFFFF, el directorio actual de ejecuón ya no está en los caminos de búsqueda'

'Hemos establecido CWDIllegalInDllSearchValue=ffffffff en CurrentControlSet y Outlook ya no nos funciona. Tampoco Sendto en Word, Excel, Powerpoint,' [...] 'Añadiendo el path "C:\Program Files\Common Files\System\Mapi33 " a
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\winword.exe", ...excel.exe", ...
ya funcionan'


El valor , menos radical que la supresión completa del directorio actual de la ruta en todas las circunstancias, que se está recomendando para el nuevo parámetro CWDIllegailInDllSearch es 0x00000002 ya que bloquea la búsqueda de librerías dinámicas en recursos remotos para las aplicaciones que se han iniciado desde las unidades de disco locales, sirviendo por tanto en principio de protección si se combina esta medida con la de nunca iniciar una aplicación cuyo ejecutable esté en recurso remoto, pero establecer este valor parece que también está generando problemas para ciertas aplicaciones.


Entradas relacionadas:

• [25/08/2010] Microsoft confirma un grave problema de seguridad "compartido" con cientos de aplicaciones de terceros (Hispasec)