¿Por qué algunas DLL no son aleatorias? ¿Por qué es difícil implementar ASLR completo para todas las DLL?

Question

¿Por qué algunas DLL no son aleatorias? ¿Por qué es difícil implementar ASLR completo para todas las DLL?

#1 de Thomas Pornin (8 votos)

11

Uno de los desafíos con la implementación de ASLR para todo es que, al menos en Windows, algunas DLL (bibliotecas) no se compilan de una manera que sea compatible con ASLR. (No se compilan como código independiente de la posición y, por lo tanto, el lugar donde se cargan en la memoria no se puede aleatorizar).

Esto es problemático, porque si una aplicación carga incluso una sola DLL no aleatoria, entonces efectivamente no es aleatoria. Para detener los ataques estándar (por ejemplo, ataques de ROP), todo el código debe ser aleatorio : incluso una sola DLL no aleatoria es un punto de apoyo suficiente para que los ataques de ROP puedan ser posibles. Por lo tanto, para una aproximación de primer orden, ASLR solo es útil para proteger una aplicación en particular si todos de sus DLL están aleatorizados. Las aplicaciones a menudo cargan muchas DLL, y como solo se necesita una DLL no aleatoria, esto hace que sea especialmente importante asegurarse de que todas las DLL estén aleatorizadas.

En general, la industria se está moviendo hacia un mayor uso de la aleatorización, pero slow : Supongo que se necesita tiempo para llevar esto a cada DLL que cualquier programa utilizará. Por ejemplo, recientemente se reveló que la DLL de Dropbox no usa la aleatorización , por lo que cualquier programa que use la DLL de Dropbox no está protegido contra los ataques de ROP (cualquier programa que use la DLL de Dropbox pierde el beneficio de ASLR).

Mi pregunta: ¿Cuáles son las razones típicas por las que algunas DLL no son aleatorias? ¿Es típicamente algún tipo de barrera técnica o problema técnico lo que dificulta o imposibilita compilar la DLL como código independiente de la posición? ¿Es la falta de conciencia / atención a la seguridad, por parte de los desarrolladores que construyen el DLL? ¿Son las DLL heredadas que son muy antiguas y no se han vuelto a compilar para aprovechar la aleatorización? ¿Microsoft Visual C ++ no hace lo correcto de forma predeterminada (no puede compilar DLL como código independiente de la posición de manera predeterminada)? ¿Es algo completamente distinto?

¿Existen avances técnicos o herramientas que ayuden a facilitar una mayor implementación de ASLR / randomización para DLL que actualmente no admiten la aleatorización?

Recursos relacionados: SlopFinder es una herramienta para analizar archivos DLL que no admiten ASLR.

hardening memory aslr

pregunta D.W. 11.09.2013 - 21:51

fuente

1 respuesta

Lea otras preguntas en las etiquetas hardening memory aslr

¿Cómo cumple Square Reader con los requisitos de entrada de pines EMV? Distinguir entre el portal Wi-Fi cautivo y el ataque MitM

score 8 · Answer 1

Hay una buena información aquí . Aparentemente, una DLL puede estar sujeta a ASLR solo si está etiquetada como tal, debido a "problemas de compatibilidad con versiones anteriores". Aunque una DLL es, por naturaleza, destinada a ser reubicada, puedo imaginar que algún software escrito (mal) puede hacer algunos trucos que se basan en que la DLL termine en un rango relativamente pequeño del espacio de direcciones (un posible candidato sería algunos Recolector de basura que debe distinguir entre "punteros a datos" y "punteros a código". Lo sé que tales problemas ocurrieron con algunas versiones del interpretador de Javascript de Chrome cuando se lanzaron en OpenBSD con emulación de Linux).

Si Microsoft se tomó la molestia de implementar un indicador adicional, es plausible, si no es probable, que haya encontrado al menos un caso de software que no puedan ignorar (la compatibilidad con versiones anteriores es muy importante en el mundo de Windows) .

Entonces, DLL permitirá que ASLR suceda si el enlazador estático lo dice, cuando se construyó la DLL por última vez. Esto es una cuestión de usar la bandera /DYNAMICBASE . La documentación indica que:

De forma predeterminada, / DYNAMICBASE está activado.

Las documentaciones para Visual Studio 2010 y 2012 contienen esta oración, pero NO la documentación para Visual Studio 2008. Entonces, uno tiene que asumir que la mayoría de las personas que usan Visual Studio 2010+ producen DLL compatibles con ASLR, pero la mayoría de las personas que usan Visual Studio 2008 o una versión anterior producen DLL que no están sujetos a ASLR.

En la página que primero vinculo arriba, uno de los comentarios dice:

Aún puedes usar el enlazador de Microsoft para hacer eso, después de que se construya tu imagen PE. Utilice link / edit / dynamicbase (o editbin / dynamicbase).

Por lo tanto, puede "arreglar" una DLL, pero eso es suponiendo que la DLL no se romperá con ASLR, es decir, la falta de marca se debió simplemente a la configuración predeterminada de Visual Studio, como la utiliza el proveedor de DLL.