Aleatorización del diseño del espacio de direcciones

Técnica de seguridad informática

La aleatorización del diseño del espacio de direcciones ( ASLR ) es una técnica de seguridad informática implicada en la prevención de la explotación de vulnerabilidades de corrupción de memoria . ^[1] Para evitar que un atacante redirija de manera confiable la ejecución del código a, por ejemplo, una función explotada particular en la memoria, ASLR organiza aleatoriamente las posiciones del espacio de direcciones de las áreas de datos clave de un proceso , incluida la base del ejecutable y las posiciones de la pila , el montón y las bibliotecas .

Historia

El proyecto Linux PaX fue el primero en acuñar el término "ASLR" y publicó el primer diseño e implementación de ASLR en julio de 2001 como un parche para el núcleo de Linux. Se lo considera una implementación completa, que proporciona un parche para la aleatorización de la pila del núcleo desde octubre de 2002. ^[2]

El primer sistema operativo convencional que admitió ASLR de forma predeterminada fue OpenBSD versión 3.4 en 2003, ^{[3] [4]} seguido por Linux en 2005.

Beneficios

La aleatorización del espacio de direcciones dificulta algunos tipos de ataques de seguridad al hacer que sea más difícil para un atacante predecir las direcciones de destino. Por ejemplo, los atacantes que intentan ejecutar ataques de retorno a libc deben localizar el código que se va a ejecutar, mientras que otros atacantes que intentan ejecutar el código shell inyectado en la pila deben encontrar la pila primero. En ambos casos, el sistema hace que las direcciones de memoria relacionadas sean impredecibles desde el punto de vista de los atacantes. Estos valores deben adivinarse y, por lo general, una suposición errónea no se puede recuperar debido a que la aplicación se bloquea.

Eficacia

La aleatorización del diseño del espacio de direcciones se basa en la baja probabilidad de que un atacante adivine las ubicaciones de áreas ubicadas aleatoriamente. La seguridad aumenta al aumentar el espacio de búsqueda. Por lo tanto, la aleatorización del espacio de direcciones es más efectiva cuando hay más entropía presente en los desplazamientos aleatorios. La entropía aumenta ya sea aumentando la cantidad de espacio del área de memoria virtual sobre la que se produce la aleatorización o reduciendo el período durante el cual se produce la aleatorización. 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 VMA.

Para vencer la aleatorización, los atacantes deben adivinar con éxito las posiciones de todas las áreas que desean atacar. En el caso de á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 mediante el uso de diapositivas 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 exactitud. A menudo, estas áreas están mezcladas, por ejemplo, se inyectan marcos de pila en la pila y se devuelve una biblioteca a ella.

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 suponer una cantidad de intentos α realizados sin ser interrumpidos por un IPS basado en firmas, la aplicación de la ley u otro factor; en el caso de fuerza bruta, el demonio no se puede reiniciar. También se debe calcular la cantidad de bits relevantes y cuántos se atacan en cada intento, dejando la cantidad de bits que el atacante tenga que derrotar.

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{ if }}0\leq \,\alpha \,}$(conjetura aislada; el espacio de direcciones se vuelve a aleatorizar después de cada intento)
• ${\displaystyle b\left(\alpha \,\right)={\frac {\alpha \,}{2^{N}}}\,{\text{ if }}0\leq \,\alpha \,\leq \,{2^{N}}}$(fuerza bruta sistemática sobre copias del programa con el mismo espacio de direcciones)

En muchos sistemas, puede ser de miles o millones. En sistemas de 32 bits, una cantidad típica de entropía N es de 8 bits. ^[5] Para las velocidades de las computadoras de 2004, Shacham y sus colaboradores afirman que "... 16 bits de aleatorización de direcciones pueden ser derrotados por un ataque de fuerza bruta en cuestión de minutos". ^[6] (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 implica evitar que un ejecutable se ejecute durante una cantidad de tiempo configurable si se ha bloqueado una cierta cantidad de veces). En los sistemas modernos de 64 bits , estas cifras suelen alcanzar los millones al menos. ^{[ cita requerida ]} ${\displaystyle 2^{N}}$^[update]

Android, ^{[7] [ se necesita una fuente no primaria ]} y posiblemente otros sistemas, ^{[¿ cuáles? ]} implementan la aleatorización del orden de carga de bibliotecas , una forma de ASLR que aleatoriza el orden en el que se cargan las bibliotecas. Esto proporciona muy poca entropía. A continuación, se muestra una aproximación de la cantidad de bits de entropía suministrados por biblioteca necesaria; esto aún no tiene en cuenta los distintos tamaños de biblioteca, por lo que la entropía real obtenida es realmente algo mayor. Los atacantes generalmente necesitan solo 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{ if }}\beta \,=1,l\geq \,1\\\sum _{i=l}^{l-\left(\beta \,-1\right)}\log _{2}\left(i\right)&{\text{ if }}\beta \,\geq \,1,l\geq \,1\end{cases}}}$

Estos valores tienden a ser bajos incluso para valores grandes de l , lo que es más importante porque los atacantes normalmente solo pueden usar la biblioteca estándar de C y, por lo tanto, a menudo se puede asumir que . Sin embargo, incluso para una pequeña cantidad de bibliotecas, aquí se ganan algunos bits de entropía; por lo tanto, es potencialmente interesante combinar la aleatorización del orden de carga de la biblioteca con la aleatorización de la dirección VMA para ganar algunos bits adicionales de entropía. Estos bits adicionales de entropía no se aplicarán a otros segmentos mmap(), solo a las bibliotecas. ${\displaystyle \beta \,=1}$

Reducción de la entropía

Los atacantes pueden utilizar varios métodos para reducir la entropía presente en un espacio de direcciones aleatorio, desde simples fugas de información hasta atacar múltiples bits de entropía por ataque (por ejemplo, mediante pulverización de heap ). No hay mucho que se pueda hacer al respecto.

Es posible filtrar información sobre la distribución de la memoria mediante vulnerabilidades de cadenas de formato . Las funciones de cadenas de formato como printf utilizan una lista de argumentos variable para hacer su trabajo; los especificadores de formato describen cómo se ve la lista de argumentos. Debido a la forma en que se pasan normalmente los argumentos, cada especificador de formato se acerca a la parte superior del marco de la pila. Finalmente, se pueden extraer el puntero de retorno y el puntero del marco de la pila, lo que revela la dirección de una biblioteca vulnerable y la dirección de un marco de pila conocido; esto puede eliminar la aleatorización de la biblioteca y la pila como un obstáculo para un atacante.

También se puede disminuir la entropía en la pila o montón. La pila normalmente debe estar alineada a 16 bytes, por lo que este es el intervalo de aleatorización más pequeño posible; mientras que el montón debe estar alineado a la página, normalmente 4096 bytes. Al intentar un ataque, es posible alinear ataques duplicados con estos intervalos; se puede usar un deslizamiento NOP/bin/sh con inyección de código shell, y la cadena ' ' se puede reemplazar con ' ////////bin/sh' para una cantidad arbitraria de barras al intentar regresar al sistema . La cantidad de bits eliminados es exactamente para n intervalos atacados. ${\displaystyle \log _{2}\!\left(n\right)}$

Estas disminuciones están limitadas debido a la cantidad de datos en la pila o montón. La pila, por ejemplo, normalmente está limitada a8  MB ^[8] y crece hasta mucho menos; esto permite como máximo19 bits , aunque una estimación más conservadora sería de alrededor de 8–10 bits correspondientes a 4–16  KB ^[8] de relleno de pila. El montón, por otro lado, está limitado por el comportamiento del asignador de memoria; en el caso de glibc , las asignaciones superiores a 128 KB se crean utilizando mmap , lo que limita a los atacantes a 5 bits de reducción. Esto también es un factor limitante cuando se realiza un ataque de fuerza bruta; aunque se puede reducir la cantidad de ataques a realizar, el tamaño de los ataques aumenta lo suficiente como para que el comportamiento pueda, en algunas circunstancias, volverse evidente para los sistemas de detección de intrusiones .

Limitaciones

Las direcciones protegidas por ASLR pueden filtrarse a través de varios canales secundarios, lo que elimina la utilidad de mitigación. Los ataques recientes han utilizado información filtrada por el búfer predictor de destino de ramificación de CPU (BTB) o las tablas de páginas móviles de la unidad de administración de memoria (MMU). No está claro si esta clase de ataque ASLR se puede mitigar. Si no se puede, el beneficio de ASLR se reduce o se elimina.

Análisis empírico

En agosto de 2024 se publicó un artículo ^[9] con un análisis empírico de las principales plataformas de escritorio, incluidas Linux, MacOS y Windows, en el que se examinaba la variabilidad en la colocación de objetos de memoria en varios procesos, subprocesos y reinicios del sistema. Los resultados muestran que, si bien algunos sistemas a partir de 2024, como las distribuciones de Linux, proporcionan una aleatorización robusta, 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 de la entropía en la entropía de las bibliotecas después de la versión Linux 5.18 e identificaron rutas de correlación que un atacante podría aprovechar para reducir significativamente la complejidad de la explotación.

Implementaciones

Varios sistemas operativos generales y convencionales implementan ASLR.

Androide

Android 4.0 Ice Cream Sandwich ofrece aleatorización del diseño del espacio de direcciones (ASLR) para ayudar a proteger el sistema y las aplicaciones de terceros de vulnerabilidades de seguridad debido a problemas de gestión de memoria. En Android 4.1 se agregó compatibilidad con ejecutables independientes de la posición. ^[10] Android 5.0 abandonó la compatibilidad con archivos no PIE y requiere que todos los archivos binarios vinculados dinámicamente sean independientes de la posición. ^{[11] [12]} La aleatorización del orden de carga de la biblioteca se aceptó en el proyecto de código abierto de Android el 26 de octubre de 2015, ^{[7] [ se necesita una fuente no primaria ]} y se incluyó en la versión Android 7.0.

Libélula BSD

DragonFly BSD tiene una implementación de ASLR basada en el modelo de OpenBSD, agregada en 2010. ^[13] Está desactivada de manera predeterminada y se puede habilitar configurando sysctl vm.randomize_mmap en 1.

BSD libre

El soporte para ASLR apareció en FreeBSD 13.0. ^{[14] [15]} Está habilitado de forma predeterminada desde 13.2. ^[16]

iOS (iPhone, iPod touch, iPad)

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

KASLR se introdujo en iOS 6. ^[18] La base del kernel aleatorizada 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). ^[19]

Linux

El núcleo Linux habilitó una forma débil de ASLR de manera predeterminada desde la versión 2.6.12 del núcleo, lanzada en junio de 2005. ^[20] Los parches PaX y Exec Shield para el núcleo 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 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.

El ASLR se puede desactivar para un proceso específico cambiando su dominio de ejecución, utilizando personality(2). ^[21] Varias opciones de sysctl controlan el comportamiento del ASLR principal. Por ejemplo, kernel.randomize_va_spacecontrola qué aleatorizar; la opción más fuerte es 2. vm.mmap_rnd_bitscontrola cuántos bits aleatorizar para mmap . ^[22]

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 la misma aleatoriedad de dirección al ejecutable principal que la que se utiliza para las bibliotecas compartidas. La función PIE no se puede utilizar junto con la función de preenlace para el mismo ejecutable. La herramienta de preenlace implementa la aleatorización en el momento de preenlace en lugar de en el momento de ejecución, porque por diseño, el preenlace tiene como objetivo gestionar la reubicación de las bibliotecas antes de que lo haga el enlazador dinámico, lo que permite que la reubicación se produzca una vez para muchas ejecuciones del programa. Como resultado, la aleatorización del espacio de direcciones real 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, hay un desplazamiento fijo entre el ejecutable y las funciones de la biblioteca. Si un atacante encuentra una manera de encontrar 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 en relación con la biblioteca, ^[5] pero aún no se ha incorporado al upstream a partir de 2024. ^[23]

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 thp_get_unmapped_areapara responder a un mmap respaldado por archivo . Con un cambio en 5.18, los archivos mayores a 2 MiB deben 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 para superar este umbral de 2 MiB, por lo que en lugar de estar alineada con un límite de página (normalmente) 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 mmap_rnd_bitsconfiguración. ^[24] Martin Doucha agregó un caso de prueba del Proyecto de prueba de Linux para detectar este problema. ^[25]

Aleatorización del diseño del espacio de direcciones del núcleo

La aleatorización del diseño del espacio de direcciones del núcleo (KASLR) permite la aleatorización del espacio de direcciones para la imagen del núcleo de Linux al aleatorizar la ubicación del código del núcleo en el momento del arranque. ^[26] KASLR se fusionó con la línea principal del núcleo de Linux en la versión 3.14 del núcleo, lanzada el 30 de marzo de 2014. ^[27] Cuando se compila, se puede desactivar en el momento del arranque especificando nokaslr como uno de los parámetros de arranque del núcleo. ^[28]

Existen varios ataques de canal lateral en procesadores x86 que podrían filtrar direcciones del núcleo. ^{[29] [30]} A fines de 2017, se desarrolló el aislamiento de la tabla de páginas del núcleo (KPTI, también conocido como KAISER) para derrotar estos ataques. ^{[31] [32]} Sin embargo, este método no puede proteger contra ataques de canal lateral que utilizan colisiones en estructuras de predictores de bifurcación . ^[33]

A partir de 2021 ^[update], la aleatorización del diseño del espacio de direcciones del kernel de grano más fino (o KASLR granular de función, FGKASLR) es una extensión planificada de KASLR para aleatorizar hasta el nivel de función. ^[34]

Microsoft Windows

Los sistemas operativos Windows Vista (lanzado en enero de 2007) y posteriores de Microsoft tienen ASLR habilitado solo para ejecutables y bibliotecas de vínculos dinámicos que están específicamente vinculados para ser habilitados con ASLR. ^[35] Por razones de compatibilidad, no está habilitado de manera predeterminada para otras aplicaciones. Por lo general, solo el software más antiguo es incompatible y ASLR se puede habilitar por completo editando una entrada de registro HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages, ^[36] o instalando el kit de herramientas Enhanced Mitigation Experience de Microsoft .

Las ubicaciones de los bloques heap , stack , Process Environment Block y Thread Environment Block también son aleatorias. Un informe técnico de seguridad de Symantec señaló que ASLR en Windows Vista de 32 bits puede no ser tan robusto como se esperaba, y Microsoft ha reconocido una debilidad en su implementación. ^[37]

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

^{En febrero de 2012 [42]} se observó que la eficacia de ASLR en sistemas Windows de 32 bits anteriores a Windows 8 puede verse reducida en situaciones de poca memoria. En la misma investigación también se había logrado un efecto similar en Linux. El código de prueba provocó que el sistema Mac OS X 10.7.3 entrara en pánico del núcleo , por lo que no quedó claro su comportamiento ASLR en este escenario.

NetBSD

El soporte para ASLR en el espacio de usuario apareció en NetBSD 5.0 ​​(lanzado en abril de 2009), ^[43] y se habilitó de manera predeterminada en NetBSD-current en abril de 2016. ^[44]

El soporte de ASLR del kernel en amd64 se agregó en NetBSD-current en octubre de 2017, convirtiendo a NetBSD en el primer sistema BSD en soportar KASLR. ^[45]

OpenBSD

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

macOS

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

En Mac OS X Lion 10.7 (lanzado en julio de 2011), Apple amplió su implementación para cubrir todas las aplicaciones, afirmando 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 de montón), lo que hace que las aplicaciones de 64 y 32 bits sean más resistentes a los ataques". ^[49]

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

Solaris

La ASLR se ha introducido en Solaris a partir de Solaris 11.1 (lanzada en octubre de 2012). La ASLR en Solaris 11.1 se puede configurar en todo el sistema, por zona o por binario. ^[51]

Explotación

Se demostró que un ataque de canal lateral que utiliza un búfer de destino de rama evita la protección ASLR. ^[33] En 2017, se demostró un ataque llamado "ASLR⊕Cache" que podía derrotar a ASLR en un navegador web usando JavaScript. ^[52]

Véase también

• Desbordamiento de búfer
• Desbordamiento del búfer de pila
• Protección contra la destrucción de pilas
• Broca NX

Referencias

1. Marco-Gisbert, Hector; Ripoll Ripoll, Ismael (22 de julio de 2019). "Aleatorización del diseño del espacio de direcciones de próxima generación". Applied Sciences . 9 (14): 2928. doi : 10.3390/app9142928 . hdl : 10251/144813 . ISSN  2076-3417.
2. Brad Spengler (octubre de 2003). "PaX: el fin garantizado de la ejecución arbitraria de código" (PDF) . grsecurity.net . Diapositivas 22 a 35. Archivado (PDF) desde el original el 25 de octubre de 2020 . Consultado el 20 de agosto de 2015 .
3. Theo De Raadt (2005). "Técnicas de mitigación de exploits (actualizadas para incluir malloc y mmap aleatorios) en OpenCON 2005". Archivado desde el original el 16 de julio de 2012. Consultado el 26 de agosto de 2009 .
4. "Innovaciones de OpenBSD". El proyecto OpenBSD. Archivado desde el original el 9 de septiembre de 2016. Consultado el 12 de septiembre de 2016 .
5. Marco-Gisbert, Hector; Ripoll, Ismael (2014-11-20). "Sobre la efectividad de ASLR completo en Linux de 64 bits" (PDF) . Archivado desde el original (PDF) el 2015-05-08 . Consultado el 2016-03-29 .
6. Shacham, H.; Page, M.; Pfaff, B.; Goh, EJ; Modadugu, N.; Boneh, D (2004). Sobre la eficacia de la aleatorización del espacio de direcciones . 11.ª conferencia de la ACM sobre seguridad informática y de las comunicaciones. págs. 298–307.
7. "Implementar la aleatorización del orden de carga de la biblioteca". Archivado desde el original el 2023-08-11 . Consultado el 2017-06-26 .
8. Los tamaños de memoria transistorizada, como RAM, ROM, flash y caché, así como los tamaños de archivo, se especifican utilizando significados binarios para K (1024 ¹ ), M (1024 ² ), G (1024 ³ ), etc.
9. Binosi, Lorenzo; Barzasi, Gregorio; Carminati, Michele; Zanero, Stefano; Polino, Mario (2024). "La ilusión de aleatoriedad: un análisis empírico de las implementaciones de aleatorización del diseño del espacio de direcciones". arXiv : 2408.15107 [cs.CR].
10. "Seguridad de Android". Desarrolladores de Android. Archivado desde el original el 12 de octubre de 2011. Consultado el 7 de julio de 2012 .
11. "oss-security". Archivado desde el original el 5 de octubre de 2015. Consultado el 4 de octubre de 2015 .
12. "Revertir "Volver a habilitar el soporte para ejecutables que no sean PIE"". Archivado desde el original el 2023-08-11 . Consultado el 2017-06-26 .
13. mmap - agregar aleatorización de desplazamiento mmap Archivado el 1 de febrero de 2014 en Wayback Machine , DragonFly Gitweb, 25 de noviembre de 2010.
14. "Implementar la aleatorización del diseño del espacio de direcciones (ASLR)". Archivado desde el original el 7 de mayo de 2019. Consultado el 10 de febrero de 2019 .
15. "ASLR - Wiki de FreeBSD". Archivado desde el original el 17 de mayo de 2021. Consultado el 17 de mayo de 2021 .
16. "Notas de la versión de FreeBSD 13.2-RELEASE". Archivado desde el original el 2023-04-11 . Consultado el 2023-04-11 .
17. Día 2 de Pwn2Own: iPhone y BlackBerry vencidos; Chrome y Firefox no aparecen Archivado el 2 de mayo de 2012 en Wayback Machine , Ars Technica , 11 de marzo de 2011
18. Stefan Esser (7 de marzo de 2013). "Explotación de iOS 6 280 días después". Diapositiva 19, "iOS 6 presenta KASLR". Archivado desde el original el 7 de mayo de 2019. Consultado el 25 de abril de 2018 .
19. Tarjei Mandt. "Ataque al núcleo de iOS: una mirada a 'evasi0n'" (PDF) . Archivado (PDF) del original el 13 de diciembre de 2020. Consultado el 23 de julio de 2023 .
20. Dang, Alan; Miller, Charlie (25 de marzo de 2009). "El bit NX y ASLR". Tom's Hardware . Archivado desde el original el 11 de agosto de 2023. Consultado el 20 de marzo de 2010 .
21. personality(2)  –  Manual del programador de Linux – Llamadas al sistema
22. • "Documentación para /proc/sys/kernel/ — La documentación del kernel de Linux". www.kernel.org .
    • "Documentación para /proc/sys/vm/ — La documentación del kernel de Linux". www.kernel.org .
23. "[PARCHE] ASLRv3: randomize_va_space=3 previene el ataque offset2lib". lore.kernel.org .
24. Miller, Justin (8 de enero de 2024). "ASLRn't: Cómo la alineación de memoria rompió la biblioteca ASLR". Blog de zolutal . Consultado el 13 de enero de 2024 .
25. "[LTP] [PARCHE 2/2] Agregar prueba para el error ASLRn't - Martin Doucha". lore.kernel.org .
26. Jake Edge (9 de octubre de 2013). «Aleatorización del diseño del espacio de direcciones del núcleo». LWN.net . Archivado desde el original el 4 de abril de 2014. Consultado el 2 de abril de 2014 .
27. "Núcleo Linux 3.14, Sección 1.7. Aleatorización del espacio de direcciones del núcleo". kernelnewbies.org . 2014-03-30. Archivado desde el original el 2021-01-15 . Consultado el 2014-04-02 .
28. "kernel/git/torvalds/linux.git: x86, kaslr: Ubicación de retorno de decompress_kernel (árbol de código fuente del kernel de Linux)". kernel.org . 2013-10-13. Archivado desde el original el 2023-08-11 . Consultado el 2014-04-02 .
29. KASLR ha muerto: larga vida a KASLR (PDF) . Ingeniería de software y sistemas seguros 2017. 2017-06-24.
30. Jang, Yeongjin; Lee, Sangho; Kim, Taesoo (2016). "Rompiendo la aleatorización del diseño del espacio de direcciones del núcleo con Intel TSX" (PDF) . Actas de la Conferencia ACM SIGSAC de 2016 sobre seguridad informática y de las comunicaciones . CCS '16. Nueva York: Association for Computing Machinery. págs. 380–392. doi : 10.1145/2976749.2978321 . ISBN . 9781450341394. S2CID  6293725. Archivado (PDF) del original el 21 de septiembre de 2020. Consultado el 29 de diciembre de 2017 .
31. Corbet, Jonathan (2017-12-20). "El estado actual del aislamiento de la tabla de páginas del núcleo". Linux Weekly News . Archivado desde el original el 2018-01-04 . Consultado el 2018-01-04 .
32. Corbet, Jonathan (15 de noviembre de 2017). «KAISER: ocultando el núcleo al espacio de usuario». Linux Weekly News . Archivado desde el original el 8 de diciembre de 2020. Consultado el 29 de diciembre de 2017 .
33. Evtyushkin, Dmitry; Ponomarev, Dmitry; Abu-Ghazaleh, Nael (2016). Saltar sobre ASLR: Ataque a los predictores de bifurcación para eludir ASLR (PDF) . 2016 49.° Simposio internacional anual IEEE/ACM sobre microarquitectura (MICRO). págs. 1–13. doi :10.1109/MICRO.2016.7783743. ISBN 978-1-5090-3508-3. Número de identificación del sujeto  3801142.
34. "Linux 5.16 tiene preparativos preliminares para soportar FGKASLR - Phoronix". www.phoronix.com . Archivado desde el original el 2021-11-10 . Consultado el 2021-11-10 .
35. "Defensas de seguridad del software ISV de Windows". Msdn.microsoft.com. 2010-12-06. Archivado desde el original el 2012-04-18 . Consultado el 2012-04-10 .
36. Componentes internos de Windows: incluye Windows Server 2008 y Windows Vista, quinta edición (PRO-Developer) ISBN 978-0-7356-2530-3 
37. Ollie Whitehouse (febrero de 2007). "An Analysis of Address Space Layout Randomization on Windows Vista" (PDF) . Archivado desde el original (PDF) el 2019-07-15 . Consultado el 2009-01-18 .
38. "WehnTrust". Codeplex.com. Archivado desde el original el 25 de diciembre de 2009. Consultado el 10 de abril de 2012 .
39. "Ozone de los arquitectos de seguridad". Arquitectos de seguridad. Archivado desde el original el 4 de marzo de 2016. Consultado el 10 de abril de 2012 .
40. "Código fuente de WehnTrust". Archivado desde el original el 28 de noviembre de 2013. Consultado el 15 de noviembre de 2013 .
41. "Aleatorización del espacio de direcciones para sistemas Windows" (PDF) . Archivado (PDF) desde el original el 2010-08-05 . Consultado el 2012-04-10 .
42. Ollie (2 de marzo de 2012). "Investigar, desarrollar, evaluar, consultar y educar | Recx: una técnica parcial contra ASLR: múltiples O/S". Recxltd.blogspot.co.uk. Archivado desde el original el 23 de marzo de 2013. Consultado el 10 de abril de 2012 .
43. "Anuncio de NetBSD 5.0". Archivado desde el original el 21 de abril de 2016. Consultado el 25 de abril de 2016 .
44. Christos Zoulas (2016). "Los binarios de PIE y ASLR están activados en la compilación predeterminada para amd64". Archivado desde el original el 22 de abril de 2016. Consultado el 25 de abril de 2016 .
45. "Kernel ASLR en amd64". 2017. Archivado desde el original el 16 de octubre de 2017. Consultado el 16 de octubre de 2017 .
46. Kurt Miller (2008). "Implementación de ejecutables independientes de la posición (PIE) de OpenBSD". Archivado desde el original el 12 de junio de 2011. Consultado el 22 de julio de 2011 .
47. "libc/stdlib/malloc.c". Referencia cruzada de BSD, OpenBSD src/lib/ . Archivado desde el original el 26 de diciembre de 2014 . Consultado el 12 de septiembre de 2016 .
48. "Mac OS X – Seguridad – Protege contra virus y malware". Apple. Archivado desde el original el 25 de mayo de 2011. Consultado el 10 de abril de 2012 .
49. "Seguridad". Apple Inc. Archivado desde el original el 6 de junio de 2011. Consultado el 6 de junio de 2011 .
50. "OS X Mountain Lion Core Technologies Overview" (PDF) . Junio ​​de 2012. Archivado (PDF) desde el original el 10 de julio de 2012 . Consultado el 25 de julio de 2012 .
51. Control de acceso a recursos de la máquina Archivado el 20 de junio de 2013 en Wayback Machine , Oracle Information Library, 26 de octubre de 2012.
52. AnC Archivado el 16 de marzo de 2017 en Wayback Machine VUSec, 2017

Enlaces externos

• Técnicas de mitigación de exploits: una actualización después de 10 años Archivado el 20 de febrero de 2014 en Wayback Machine en OpenBSD
• Documentación de PaX sobre ASLR
• Comparación de PaX con Exec Shield y W^X
• Aleatorización del diseño del espacio de direcciones en Windows Vista - Blog de Michael Howard
• ASLR para Windows 2000/XP/2003 (WehnTrust)
• Cómo eludir la protección ASLR de PaX
• Sobre la eficacia de la aleatorización del diseño del espacio de direcciones
• Pruebe aplicaciones (o bibliotecas) para comprobar su compatibilidad con ASLR y DEP
• Referencia de ASLR para Smack & Laugh