Aleatorización del diseño del espacio de direcciones

La aleatorización del espacio de direcciones se basa en la baja probabilidad de que un atacante adivine la ubicación de las áreas distribuidas aleatoriamente. La seguridad aumenta al incrementar el espacio de búsqueda. Por lo tanto, la aleatorización del espacio de direcciones es más efectiva cuando hay mayor entropía en los desplazamientos aleatorios. La entropía se incrementa aumentando la cantidad de espacio de memoria virtual sobre el cual se realiza la aleatorización o reduciendo el período durante el cual se realiza. El período generalmente se implementa lo más pequeño posible, por lo que la mayoría de los sistemas deben aumentar la aleatorización del espacio de memoria virtual.

Para burlar la aleatorización, los atacantes deben adivinar correctamente las posiciones de todas las áreas que desean atacar. En áreas de datos como la pila y el montón, donde se puede cargar código personalizado o datos útiles, se puede atacar más de un estado utilizando deslizamientos NOP para el código o copias repetidas de datos. Esto permite que un ataque tenga éxito si el área se aleatoriza a uno de un puñado de valores. Por el contrario, las áreas de código como la base de la biblioteca y el ejecutable principal deben descubrirse con precisión. A menudo, estas áreas están mezcladas; por ejemplo, se inyectan marcos de pila en la pila y se devuelve una biblioteca.

Se pueden declarar las siguientes variables:

• ${\displaystyle E_{s}}$(bits de entropía de la parte superior de la pila)
• ${\displaystyle E_{m}}$(bits de entropía de mmap()la base)
• ${\displaystyle E_{x}}$(bits de entropía de la base ejecutable principal)
• ${\displaystyle E_{h}}$(bits de entropía de la base del montón)
• ${\displaystyle A_{s}}$(bits atacados por intento de entropía de pila)
• ${\displaystyle A_{m}}$(bits atacados por intento de mmap()entropía base)
• ${\displaystyle A_{x}}$(bits atacados por intento de entropía del ejecutable principal)
• ${\displaystyle A_{h}}$(bits atacados por intento de entropía base del montón)
• ${\displaystyle \alpha }$(intentos realizados)
• ${\displaystyle N}$(cantidad total de entropía:${\displaystyle N=(E_{s}-A_{s})+(E_{m}-A_{m})+(E_{x}-A_{x})+(E_{h}-A_{h})\,}$)

Para calcular la probabilidad de éxito de un atacante, se debe asumir un número α de intentos realizados sin interrupciones por parte de un sistema de prevención de intrusiones (IPS) basado en firmas, las fuerzas del orden u otro factor; en el caso de un ataque de fuerza bruta, el demonio no puede reiniciarse. También se debe calcular el número de bits relevantes y cuántos se atacan en cada intento, lo que deja como resultado la cantidad de bits que el atacante debe superar.

Las siguientes fórmulas representan la probabilidad de éxito para un conjunto dado de α intentos en N bits de entropía.

• ${\displaystyle g\left(\alpha \,\right)=1-{\left(1-{2^{-N}}\right)^{\alpha }\,}\,{\text{ si }}0\leq \,\alpha \,}$(Adivinación aislada; el espacio de direcciones se vuelve a generar aleatoriamente después de cada intento)
• ${\displaystyle b\left(\alpha \,\right)={\frac {\alpha \,}{2^{N}}}\,{\text{ si }}0\leq \,\alpha \,\leq \,{2^{N}}}$(ataque sistemático de fuerza bruta en copias del programa con el mismo espacio de direcciones)

En muchos sistemas,${\displaystyle 2^{N}}$pueden ser miles o millones. En sistemas de 32 bits, una cantidad típica de entropía N es de 8 bits. ^{[ 6 ]} Para velocidades de computadoras de 2004, Shacham y sus colaboradores afirman que "... 16 bits de aleatorización de direcciones pueden ser superados por un ataque de fuerza bruta en cuestión de minutos." ^{[ 7 ]} (La afirmación de los autores depende de la capacidad de atacar la misma aplicación varias veces sin demora. Las implementaciones adecuadas de ASLR, como la incluida en grsecurity, proporcionan varios métodos para hacer que tales ataques de fuerza bruta sean inviables. Un método consiste en impedir que un ejecutable se ejecute durante un tiempo configurable si ha fallado un cierto número de veces). En sistemas modernosEn los sistemas de 64 bits , estas cifras suelen alcanzar al menos los millones.

Android, ^{[ 8 ]} y posiblemente otros sistemas, implementan la aleatorización del orden de carga de bibliotecas , una forma de ASLR que aleatoriza el orden en que se cargan las bibliotecas. Esto proporciona muy poca entropía. Una aproximación del número de bits de entropía proporcionados por biblioteca necesaria aparece a continuación; esto aún no tiene en cuenta los diferentes tamaños de biblioteca, por lo que la entropía real obtenida es en realidad algo mayor. Los atacantes generalmente solo necesitan una biblioteca; las matemáticas son más complejas con varias bibliotecas, y también se muestran a continuación. El caso de un atacante que usa solo una biblioteca es una simplificación de la fórmula más compleja para${\displaystyle l=1}$.

• l (número de bibliotecas cargadas)
• β (número de bibliotecas utilizadas por el atacante)
• ${\displaystyle E_{m}={\begin{cases}\log _{2}\left(l\right)&{\text{ si }}\beta \,=1,l\geq \,1\\\sum _{i=l}^{l-\left(\beta \,-1\right)}\log _{2}\left(i\right)&{\text{ si }}\beta \,\geq \,1,l\geq \,1\end{cases}}}$

Estos valores tienden a ser bajos incluso para valores grandes de l , lo más importante es que los atacantes normalmente solo pueden usar la biblioteca estándar de C y, por lo tanto, a menudo se puede suponer que${\displaystyle \beta \,=1}$Sin embargo, incluso para un número reducido de bibliotecas, se obtiene cierta entropía adicional; por lo tanto, resulta potencialmente interesante combinar la aleatorización del orden de carga de las bibliotecas con la aleatorización de la dirección VMA para obtener una entropía adicional. Esta entropía adicional no se aplicará a otros segmentos mmap(), solo a las bibliotecas.

Las direcciones protegidas por ASLR pueden filtrarse a través de diversos canales laterales, lo que anula su utilidad de mitigación. Ataques recientes han utilizado información filtrada por el búfer predictor de destino de bifurcación (BTB) de la CPU o por las tablas de páginas de la unidad de gestión de memoria (MMU). No está claro si este tipo de ataque ASLR puede mitigarse. De no ser así, la eficacia de ASLR se reduce o se elimina.

En agosto de 2024 se publicó un artículo ^{[ 10 ]} con un análisis empírico de las principales plataformas de escritorio, incluidas Linux, macOS y Windows, examinando la variabilidad en la ubicación de los objetos de memoria en diversos procesos, subprocesos y reinicios del sistema. Los resultados muestran que, si bien algunos sistemas, como las distribuciones de Linux, ofrecen una aleatorización robusta en 2024, otros, como Windows y macOS, a menudo no logran aleatorizar adecuadamente áreas clave como el código ejecutable y las bibliotecas. Además, encontraron una reducción significativa en la entropía de las bibliotecas después de la versión 5.18 de Linux e identificaron rutas de correlación que un atacante podría aprovechar para reducir significativamente la complejidad de la explotación.

Android 4.0 Ice Cream Sandwich proporciona aleatorización del diseño del espacio de direcciones (ASLR) para ayudar a proteger las aplicaciones del sistema y de terceros de exploits debido a problemas de administración de memoria. El soporte para ejecutables independientes de la posición se agregó en Android 4.1. ^{[ 11 ]} Android 5.0 eliminó el soporte para no PIE y requiere que todos los binarios vinculados dinámicamente sean independientes de la posición. ^{[ 12 ] [ 13 ]} La aleatorización del orden de carga de bibliotecas fue aceptada en el proyecto de código abierto de Android el 26 de octubre de 2015, ^{[ 8 ]} y se incluyó en la versión de Android 7.0.

DragonFly BSD tiene una implementación de ASLR basada en el modelo de OpenBSD, añadida en 2010. ^{[ 14 ]} Está desactivada por defecto y se puede habilitar configurando sysctl vm.randomize_mmap a 1.

El soporte para ASLR apareció en FreeBSD 13.0. ^{[ 15 ] [ 16 ]} Está habilitado por defecto desde 13.2. ^{[ 17 ]}

Apple introdujo ASLR en iOS 4.3 (lanzado en marzo de 2011). ^{[ 18 ]}

KASLR se introdujo en iOS 6. ^{[ 19 ]} La base del kernel aleatorio es 0x01000000 + ((1+0xRR) * 0x00200000), donde 0xRRes un byte aleatorio de SHA1 (datos aleatorios) generado por iBoot (el cargador de arranque de iOS de segunda etapa). ^{[ 20 ]}

El kernel de Linux habilitó una forma débil de ASLR por defecto desde la versión 2.6.12, publicada en junio de 2005. ^{[ 21 ]} Los parches PaX y Exec Shield para el kernel de Linux proporcionan implementaciones más completas. El parche Exec Shield para Linux proporciona 19 bits de entropía de pila en un período de 16 bytes y 8 bits de aleatorización de la base mmap en un período de 1 página de 4096 bytes. Esto coloca la base de la pila en un área de 8  MB de ancho que contiene 524 288 posiciones posibles, y la base mmap en un área de 1  MB de ancho que contiene 256 posiciones posibles.

ASLR se puede deshabilitar para un proceso específico cambiando su dominio de ejecución, usando personality(2). ^{[ 22 ]} Varias opciones de sysctlkernel.randomize_va_space controlan el comportamiento de ASLR principal. Por ejemplo, controla qué aleatorizar; la opción más fuerte es 2. vm.mmap_rnd_bitscontrola cuántos bits aleatorizar para mmap . ^{[ 23 ]}

El ejecutable independiente de la posición (PIE) implementa una dirección base aleatoria para el binario ejecutable principal y está en funcionamiento desde el 18 de abril de 2004. Proporciona al ejecutable principal la misma aleatoriedad de direcciones que se utiliza para las bibliotecas compartidas. La función PIE no se puede usar junto con la función de preenlace para el mismo ejecutable. La herramienta de preenlace implementa la aleatorización en tiempo de preenlace en lugar de en tiempo de ejecución, ya que, por diseño, el preenlace tiene como objetivo gestionar la reubicación de bibliotecas antes de que tenga que hacerlo el enlazador dinámico , lo que permite que la reubicación ocurra una sola vez para muchas ejecuciones del programa. Como resultado, la aleatorización real del espacio de direcciones anularía el propósito del preenlace.

En 2014, Marco-Gisbert y Ripoll revelaron la técnica offset2lib , que debilita el ASLR de Linux para los ejecutables PIE. Los núcleos de Linux cargan los ejecutables PIE justo después de sus bibliotecas; como resultado, existe un desplazamiento fijo entre el ejecutable y las funciones de la biblioteca. Si un atacante encuentra la dirección de una función en el ejecutable, también se conocen las direcciones de la biblioteca. Demostraron un ataque que encuentra la dirección en menos de 400 intentos. Propusieron una nueva randomize_va_space=3opción para aleatorizar la ubicación del ejecutable con respecto a la biblioteca, ^{[ 6 ]} pero aún no se ha incorporado al código fuente principal a fecha de 2024. ^{[ 24 ]}

El kernel de Linux 5.18, lanzado en mayo de 2022, redujo la efectividad de las implementaciones de 32 y 64 bits. Los sistemas de archivos de Linux llaman para responder a un mmapthp_get_unmapped_area respaldado por archivos . Con un cambio en 5.18, los archivos mayores de 2 MiB se hacen devolver direcciones alineadas a 2 MiB, por lo que potencialmente pueden estar respaldados por páginas enormes . (Anteriormente, la alineación aumentada solo se aplicaba a las asignaciones de Acceso Directo (DAX)). Mientras tanto, la biblioteca C (libc) ha crecido con el tiempo en tamaño hasta superar este umbral de 2 MiB, por lo que en lugar de estar alineada a un límite de página (típicamente) de 4 KiB como antes, estas bibliotecas ahora están alineadas a 2 MiB: una pérdida de 9 bits de entropía. Para Linux de 32 bits, muchas distribuciones no muestran ninguna aleatorización en la ubicación de libc. Para Linux de 64 bits, los 28 bits de entropía se reducen a 19 bits. En respuesta, Ubuntu ha aumentado su configuración. ^{[ 25 ]} Martin Doucha agregó un caso de prueba del Proyecto de Pruebas de Linux para detectar este problema. ^{[ 26 ]}     mmap_rnd_bits

Windows Vista de Microsoft ( lanzado para fabricación en noviembre de 2006, disponible generalmente en enero de 2007) y versiones posteriores tienen ASLR habilitado solo para ejecutables y bibliotecas de vínculos dinámicos que están específicamente vinculadas para ser habilitadas para ASLR. ^{[ 36 ]} Por compatibilidad, no está habilitado de forma predeterminada para otras aplicaciones. Por lo general, solo el software antiguo es incompatible y ASLR se puede habilitar completamente editando una entrada del registro HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages, ^{[ 37 ]} o instalando el Kit de herramientas de experiencia de mitigación mejorada de Microsoft .

Las ubicaciones del montón , la pila , el bloque de entorno del proceso y el bloque de entorno del hilo también se generan aleatoriamente. Un documento técnico sobre seguridad de Symantec señaló que ASLR en Windows Vista de 32 bits podría no ser tan robusto como se esperaba, y Microsoft ha reconocido una debilidad en su implementación. ^{[ 38 ]}

Los sistemas de prevención de intrusiones basados ​​en el host , como WehnTrust ^{[ 39 ]} y Ozone ^{[ 40 ],} también ofrecen ASLR para los sistemas operativos Windows XP y Windows Server 2003. WehnTrust es de código abierto. ^{[ 41 ]} No se dispone de detalles completos sobre la implementación de Ozone. ^{[ 42 ]}

^{En febrero de 2012 [ 43 ]} se observó que la eficacia de ASLR en sistemas Windows de 32 bits anteriores a Windows 8 podía verse reducida en situaciones de poca memoria. En la misma investigación se había observado un efecto similar en Linux. El código de prueba provocó un fallo del kernel en el sistema Mac OS X 10.7.3 , por lo que no quedó claro su comportamiento respecto a ASLR en este escenario.

El soporte para ASLR en el espacio de usuario apareció en NetBSD 5.0 ​​(lanzado en abril de 2009), ^{[ 44 ]} y se habilitó por defecto en NetBSD-current en abril de 2016. ^{[ 45 ]}

El soporte para ASLR del kernel en amd64 se agregó en NetBSD-current en octubre de 2017, lo que convirtió a NetBSD en el primer sistema BSD en soportar KASLR. ^{[ 46 ]}

En 2003, OpenBSD se convirtió en el primer sistema operativo popular en admitir una forma fuerte de ASLR y activarla por defecto. ^{[ 4 ]} OpenBSD completó su soporte de ASLR en 2008 cuando agregó soporte para binarios PIE . ^{[ 47 ]} El malloc(3) de OpenBSD 4.4 fue diseñado para mejorar la seguridad aprovechando las características de ASLR y gap page implementadas como parte de mmapla llamada al sistema de OpenBSD , y para detectar errores de uso después de la liberación. ^{[ 48 ]} Lanzado en 2013, OpenBSD 5.3 fue el primer sistema operativo popular en habilitar ejecutables independientes de la posición por defecto en múltiples plataformas de hardware , y OpenBSD 5.7 activó los binarios estáticos independientes de la posición (Static-PIE) por defecto. ^{[ 47 ]}

En Mac OS X Leopard 10.5 (lanzado en octubre de 2007), Apple introdujo la aleatorización para las bibliotecas del sistema. ^{[ 49 ]}

En Mac OS X Lion 10.7 (lanzado en julio de 2011), Apple amplió su implementación para abarcar todas las aplicaciones, declarando que "la aleatorización del diseño del espacio de direcciones (ASLR) se ha mejorado para todas las aplicaciones. Ahora está disponible para aplicaciones de 32 bits (al igual que las protecciones de memoria del montón), lo que hace que las aplicaciones de 64 bits y 32 bits sean más resistentes a los ataques". ^{[ 50 ]}

A partir de OS X Mountain Lion 10.8 (lanzado en julio de 2012) y versiones posteriores, todo el sistema, incluido el kernel, así como los kexts y las zonas, se reubican aleatoriamente durante el arranque del sistema. ^{[ 51 ]}

ASLR se introdujo en Solaris a partir de Solaris 11.1 (lanzado en octubre de 2012). ASLR en Solaris 11.1 se puede configurar para todo el sistema, por zona o por binario. ^{[ 52 ]}