El infierno de las DLL

Una versión específica de una biblioteca puede ser compatible con algunos programas que la utilizan e incompatible con otros. Windows ha sido particularmente vulnerable a esto debido a su énfasis en el enlace dinámico de bibliotecas C++ y objetos OLE ( Object Linking and Embedding ). Las clases C++ exportan muchos métodos, y un solo cambio en la clase, como un nuevo método virtual, puede hacerla incompatible con programas compilados con una versión anterior. OLE tiene reglas muy estrictas para evitar esto: las interfaces deben ser estables y los administradores de memoria no se comparten. Sin embargo, esto es insuficiente, ya que la semántica de una clase puede cambiar. Una corrección de errores para una aplicación puede resultar en la eliminación de una característica de otra. Antes de Windows 2000 , Windows era vulnerable a esto porque la tabla de clases COM se compartía entre todos los usuarios y procesos. Solo un objeto COM en una DLL/EXE podía declararse con un ID de clase COM global específico en un sistema. Si algún programa necesitaba crear una instancia de esa clase, obtenía la implementación registrada centralmente en ese momento. Como resultado, la instalación de un programa que instala una nueva versión de un objeto común podría, sin querer, dañar otros programas que se hayan instalado previamente.

Un problema común y molesto ocurre cuando un programa recién instalado sobrescribe una DLL del sistema que funciona correctamente con una versión anterior e incompatible. Ejemplos tempranos de esto fueron las ctl3d.dllbibliotecas ctl3dv2.dllpara Windows 3.1 : bibliotecas creadas por Microsoft que los editores externos distribuían con su software, pero cada uno distribuía la versión con la que lo desarrollaron en lugar de la versión más reciente. ^{[ 2 ]} La sobrescritura de DLL ocurre porque:

• En el pasado, Microsoft distribuía las DLL de tiempo de ejecución como componentes de sistema compartidos ^{[ 3 ]} (originalmente C:\WINDOWS y C:\WINDOWS\SYSTEM), como una forma de compartir código de manera eficiente en un sistema operativo de memoria compartida con RAM y espacio en disco limitados. En consecuencia, los desarrolladores externos también las distribuían de esta manera.
• Los instaladores de aplicaciones suelen ejecutarse en un entorno de seguridad privilegiado que permite instalar archivos DLL en los directorios del sistema y editar el registro del sistema para registrar nuevos archivos DLL como objetos COM . Por lo tanto, un instalador mal escrito o mal configurado puede degradar una biblioteca del sistema en versiones antiguas de Windows, donde la Protección de archivos de Windows o la Protección de recursos de Windows no revierten el cambio. En Windows Vista y versiones posteriores, solo la cuenta de "instalador de confianza" puede modificar las bibliotecas principales del sistema operativo.
• Las aplicaciones de Windows podían incluir actualizaciones del sistema operativo en sus propios programas de instalación. Es decir, muchas DLL de Microsoft son redistribuibles , lo que significa que las aplicaciones pueden incluirlas si necesitan los servicios de dichas bibliotecas.
• Antes de Windows Installer , los instaladores de Windows eran históricamente productos comerciales; muchas personas intentaban escribir sus propios instaladores, pasando por alto o gestionando incorrectamente los problemas de versiones en el proceso.
• Algunos entornos de desarrollo no añadían automáticamente un recurso de versión a sus bibliotecas compiladas, por lo que muchos desarrolladores pasaban por alto este aspecto. Comprobar las fechas de los archivos, sobrescribir los archivos existentes u omitir la operación de copia si la DLL ya estaba instalada eran las únicas opciones disponibles en lugar de un correcto control de versiones.
• En ocasiones, el propio sistema operativo eliminaba o reemplazaba las DLL con versiones más antiguas u obsoletas. Por ejemplo, Windows 2000 instalaba las DLL de impresoras en blanco y negro sobre las DLL compatibles con color, si la impresora en blanco y negro se instalaba después de la impresora a color. ^{[ 4 ]}

En COM y otras partes de Windows, antes de la introducción de los ensamblados sin registro en paralelo , ^{[ 5 ]} el Registro se utilizaba para determinar qué DLL subyacente usar. Si se registraba una versión diferente de un módulo, se cargaba esta DLL en lugar de la esperada. Esta situación podía deberse a instalaciones conflictivas que registraban versiones diferentes de las mismas bibliotecas, en cuyo caso prevalecía la última instalación.

Las versiones de 16 bits de Windows (y Windows on Windows ) cargan solo una instancia de cada DLL; todas las aplicaciones hacen referencia a la misma copia en memoria hasta que ninguna aplicación la utiliza y se descarga de la memoria. (En las versiones de 32 y 64 bits de Windows, el uso compartido entre procesos solo ocurre cuando diferentes ejecutables cargan un módulo desde el mismo directorio; el código, pero no la pila, se comparte entre procesos mediante un proceso llamado "mapeo de memoria"). Por lo tanto, incluso cuando la DLL deseada se encuentra en un directorio donde se espera que esté, como en el directorio del sistema o el directorio de la aplicación, ninguna de estas instancias se utilizará si otra aplicación se ha iniciado con una versión incompatible desde un tercer directorio. Este problema puede manifestarse como un error de aplicación de 16 bits que solo ocurre cuando las aplicaciones se inician en un orden específico.

En conflicto directo con el problema de la sobreexposición de DLL: si las actualizaciones de una DLL no afectan a todas las aplicaciones que la utilizan, resulta mucho más difícil "darle mantenimiento", es decir, eliminar los problemas existentes en las versiones actuales de la DLL. (Las correcciones de seguridad son un caso particularmente complejo y problemático). En lugar de corregir solo la última versión de la DLL, lo ideal es que el desarrollador aplique las correcciones y las pruebe para comprobar su compatibilidad con todas las versiones publicadas de la DLL.

Windows busca en varias ubicaciones DLL ambiguas, es decir, aquellas que no están completamente calificadas. El malware puede explotar este comportamiento de varias maneras, en un proceso conocido como secuestro del orden de búsqueda de DLL . Un método es la precarga de DLL o un ataque de inserción de binarios . Este método coloca archivos DLL con el mismo nombre en una ubicación que se buscó anteriormente, como el directorio de trabajo actual . Cuando el programa vulnerable intenta cargar la DLL, se ejecuta la versión maliciosa, posiblemente con altos privilegios si el programa se ejecuta a ese nivel. ^{[ 6 ]}

Otro método es el secuestro de DLL mediante ruta relativa , que mueve el programa vulnerable a una ubicación junto con la DLL maliciosa. La DLL se carga porque el directorio de la aplicación se busca al principio. Según CrowdStrike , este método es el más común. ^{[ 7 ]} La ​​carga lateral de DLL entrega tanto el programa legítimo como la biblioteca maliciosa. Puede evitar la detección porque la ejecución parece la de un programa legítimo. ^{[ 8 ]}

Otros métodos incluyen el secuestro de DLL fantasma , donde se crea un archivo DLL malicioso a partir de referencias a una biblioteca inexistente, y la modificación de los valores del registro para abusar de la redirección de DLL , lo que cambia el orden de búsqueda de DLL. ^{[ 6 ]}

El secuestro de DLL fue utilizado por grupos patrocinados por el estado, incluidos Lazarus Group y Tropic Trooper . ^{[ 8 ]}

Una solución simple al problema de las DLL en una aplicación es enlazar estáticamente todas las bibliotecas, es decir, incluir la versión de la biblioteca requerida en el programa, en lugar de seleccionar una biblioteca del sistema con un nombre específico. ^{[ 9 ]} Esto es común en aplicaciones C/C++, donde, en lugar de tener que preocuparse por qué versión MFC42.DLLestá instalada, la aplicación se compila para enlazarse estáticamente con las mismas bibliotecas. Esto elimina por completo las DLL y es posible en aplicaciones independientes que solo utilizan bibliotecas que ofrecen una opción estática, como Microsoft Foundation Class Library . Sin embargo, se sacrifica el propósito principal de las DLL: compartir bibliotecas en tiempo de ejecución entre programas para reducir la sobrecarga de memoria; duplicar el código de la biblioteca en varios programas crea un exceso de software y complica la implementación de correcciones de seguridad o versiones más recientes del software dependiente.

El problema de sobrescritura de DLL (conocido como DLL stomping por Microsoft) se redujo en cierta medida con la Protección de archivos de Windows (WFP), ^{[ 10 ]} que se introdujo en Windows 2000. ^{[ 11 ]} Esto impide que las aplicaciones no autorizadas sobrescriban las DLL del sistema, a menos que utilicen las API específicas de Windows que lo permiten. Aún puede existir el riesgo de que las actualizaciones de Microsoft sean incompatibles con las aplicaciones existentes, pero este riesgo generalmente se reduce en las versiones actuales de Windows mediante el uso de ensamblados en paralelo .

Las aplicaciones de terceros no pueden sobrescribir archivos del sistema operativo a menos que incluyan actualizaciones legítimas de Windows en su instalador, o que deshabiliten el servicio de Protección de archivos de Windows durante la instalación. En Windows Vista o versiones posteriores, además, deben tomar posesión de los archivos del sistema y otorgarse acceso a ellos. La utilidad SFC puede revertir estos cambios en cualquier momento.

Las soluciones propuestas consisten en tener copias diferentes de las mismas DLL para cada aplicación, tanto en el disco como en la memoria.

Una solución manual sencilla para los conflictos consistía en colocar las distintas versiones de la DLL problemática en las carpetas de las aplicaciones, en lugar de en una carpeta común del sistema. Esto funciona en general siempre que la aplicación sea de 32 o 64 bits y que la DLL no utilice memoria compartida. En el caso de aplicaciones de 16 bits, las dos aplicaciones no pueden ejecutarse simultáneamente en una plataforma de 16 bits ni en la misma máquina virtual de 16 bits bajo un sistema operativo de 32 bits. OLE lo impedía antes de Windows 98 SE/2000, ya que las versiones anteriores de Windows tenían un único registro de objetos COM para todas las aplicaciones.

Windows 98 SE/2000 introdujo una solución llamada ensamblaje en paralelo , ^{[ 12 ]} que carga copias separadas de DLL para cada aplicación que las requiere (y por lo tanto permite que las aplicaciones que requieren DLL conflictivas se ejecuten simultáneamente). Este enfoque elimina los conflictos al permitir que las aplicaciones carguen versiones únicas de un módulo en su espacio de direcciones, mientras que preserva el beneficio principal de compartir DLL entre aplicaciones (es decir, reducir el uso de memoria) mediante el uso de técnicas de asignación de memoria para compartir código común entre diferentes procesos que aún usan el mismo módulo. Sin embargo, las DLL que usan datos compartidos entre múltiples procesos no pueden usar este enfoque. ^{[ 13 ]} Un efecto secundario negativo es que las instancias huérfanas de DLL pueden no actualizarse durante los procesos automatizados.

Dependiendo de la arquitectura de la aplicación y el entorno de ejecución, las aplicaciones portátiles pueden ser una forma eficaz de reducir algunos problemas con las DLL, ya que cada programa incluye sus propias copias privadas de las DLL que necesita. ^{[ 11 ]} El mecanismo se basa en que las aplicaciones no califiquen completamente las rutas a las DLL dependientes al cargarlas, y en que el sistema operativo busque en el directorio ejecutable antes que en cualquier ubicación compartida. ^{[ 14 ]} Sin embargo, esta técnica también puede ser explotada por malware, ^{[ 15 ]} y la mayor flexibilidad también puede ir en detrimento de la seguridad si las DLL privadas no se mantienen actualizadas con parches de seguridad de la misma manera que las compartidas.

La virtualización de aplicaciones también permite que estas se ejecuten en un entorno aislado, lo que evita la instalación de archivos DLL directamente en el sistema operativo.

Existen otras contramedidas para evitar el infierno de las DLL, algunas de las cuales pueden tener que utilizarse simultáneamente; otras características que ayudan a mitigar el problema son:

• Las herramientas de instalación ahora vienen integradas en Microsoft Visual Studio , uno de los principales entornos para el desarrollo de Windows. Estas herramientas realizan comprobaciones de versión antes de la instalación de DLL y pueden incluir paquetes de instalación predefinidos en una instalación .MSI. Esto permite que las aplicaciones de terceros integren actualizaciones de componentes del sistema operativo sin tener que escribir sus propios instaladores para dichos componentes.
• La función Restaurar sistema puede recuperar un sistema tras una instalación defectuosa, incluso si el daño se ha producido en el registro. Si bien esto no evita el problema, facilita la recuperación.
• El directorio WinSxS ( Windows Side-by-Side ) permite que coexistan varias versiones de las mismas bibliotecas.
• Ejecute aplicaciones de 16 bits en un espacio de memoria separado en una versión de Windows de 32 bits para permitir que dos aplicaciones utilicen versiones conflictivas de la misma DLL al mismo tiempo.
• Utilice una versión de Windows que incluya la Protección de archivos de Windows . Windows Me y Windows 2000 , ambos lanzados en el año 2000, son compatibles con esta forma de protección de archivos del sistema, al igual que Windows XP y Windows Server 2003. Su sustituto, la Protección de recursos de Windows , se introdujo en Windows Vista y Windows Server 2008 , y utiliza un método diferente para proteger los archivos del sistema contra modificaciones.
• COM sin registro: Windows XP introdujo un nuevo modo de registro de objetos COM llamado " COM sin registro ". Esta característica permite que las aplicaciones que necesitan instalar objetos COM almacenen toda la información de registro COM necesaria en el directorio de la propia aplicación, en lugar de en el registro global del sistema. De este modo, proporciona un mecanismo para que varias aplicaciones registren simultáneamente múltiples versiones de la misma DLL (Microsoft lo denomina " Ensamblaje en paralelo " ^{[ 16 ]} ). El infierno de las DLL se puede evitar en gran medida utilizando COM sin registro; la única limitación es que requiere al menos Windows XP o versiones posteriores de Windows y que no debe utilizarse para servidores COM EXE ni componentes de todo el sistema como MDAC , MSXML , DirectX o Internet Explorer .
• El sistema operativo incluye un sistema de gestión de paquetes capaz de rastrear las dependencias de las DLL, lo que fomenta el uso del gestor de paquetes y desalienta la instalación manual de las DLL. Windows Installer , incluido en Windows Me , Windows 2000 y todas las versiones posteriores, ofrece esta funcionalidad.
• Disponer de una base de datos central o autoridad para la resolución de conflictos de DLL y la distribución de software. Los cambios en una biblioteca pueden enviarse a esta autoridad, lo que garantiza la compatibilidad en las ramas desarrolladas. Si algún software antiguo es incompatible con la biblioteca actual, la autoridad puede proporcionar una interfaz de compatibilidad o incluir la versión anterior como un paquete independiente.
• Si los desarrolladores de software necesitan personalizar una biblioteca y es improbable que la versión principal de la biblioteca incorpore los cambios que necesitan, pueden distribuir la DLL personalizada para uso privado del programa (normalmente colocándola en el directorio privado del programa) o enlazar estáticamente el programa con la biblioteca personalizada.
• Si bien las DLL son ideales para modularizar aplicaciones y componentes del sistema, así como para funcionar como bibliotecas de terceros, su uso no es imprescindible en todos los casos en sistemas modernos donde la memoria ya no es un factor limitante. Por ejemplo, si una aplicación necesita una biblioteca que no se utilizará en ningún otro lugar, se puede enlazar estáticamente, sin penalización de espacio y con una mejora en el rendimiento.
• Windows Vista y versiones posteriores utilizan un servicio especial llamado TrustedInstaller para instalar los archivos del sistema operativo. Otras cuentas de usuario, incluida la del sistema, no tienen acceso para sobrescribir los archivos binarios principales del sistema. Windows 7 amplía esta funcionalidad a algunas partes críticas del Registro.