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 de 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 .
El proyecto Linux PaX acuñó por primera vez el término "ASLR" y publicó el primer diseño e implementación de ASLR en julio de 2001 como un parche para el kernel de Linux. Se considera una implementación completa y proporciona también un parche para la aleatorización de la pila del kernel 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 de Linux en 2005.
La aleatorización del espacio de direcciones obstaculiza algunos tipos de ataques de seguridad al hacer que a un atacante le resulte más difícil 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 falla.
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 colocadas 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 aumentando la cantidad de espacio del área de memoria virtual sobre la cual se produce la aleatorización o reduciendo el período durante el cual se produce la aleatorización. El período normalmente se implementa lo más pequeño posible, por lo que la mayoría de los sistemas deben aumentar la aleatorización del espacio VMA.
Para derrotar la aleatorización, los atacantes deben adivinar con éxito las posiciones de todas las áreas que desean atacar. Para áreas de datos como pila y montón, donde se puede cargar código personalizado o datos útiles, se puede atacar más de un estado utilizando diapositivas NOP para código o copias repetidas de datos. Esto permite que un ataque tenga éxito si el área se asigna aleatoriamente a uno de varios valores. Por el contrario, las áreas de código como la base de la biblioteca y el ejecutable principal deben descubrirse exactamente. A menudo, estas áreas se mezclan; por ejemplo, se inyectan marcos de pila en la pila y se devuelve una biblioteca.
Se pueden declarar las siguientes variables:
mmap()base)
mmap()entropía base)Para calcular la probabilidad de que un atacante tenga éxito, se debe asumir una cantidad de intentos α realizados sin ser interrumpidos por un IPS basado en firmas, 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 el número de bits relevantes y cuántos están siendo atacados en cada intento, dejando tantos bits que el atacante tenga que derrotar.
Las siguientes fórmulas representan la probabilidad de éxito de un conjunto dado de α intentos en N bits de entropía.
En muchos sistemas, pueden ser miles o millones. En sistemas de 32 bits, una cantidad típica de entropía N es de 8 bits. [5] Para velocidades de computadora de 2004, Shacham y sus compañeros de trabajo afirman "... 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 dichos ataques de fuerza bruta sean inviables. Un método implica prevenir un ejecutable se ejecute durante un período de tiempo configurable si se ha bloqueado una cierta cantidad de veces). En los sistemas modernos de 64 bits , estos números generalmente alcanzan al menos millones. [ cita necesaria ][update]
Android, [7] [ se necesita fuente no primaria ] y posiblemente otros sistemas, [ ¿cuáles? ] implementar 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 del número 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 algo mayor. Los atacantes normalmente necesitan sólo 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 utiliza sólo una biblioteca es una simplificación de la fórmula más compleja para .
Estos valores tienden a ser bajos incluso para valores grandes de l , lo más importante es que los atacantes normalmente sólo pueden usar la biblioteca estándar de C y, por lo tanto, a menudo se puede suponer que . Sin embargo, incluso para un pequeño número de bibliotecas, aquí se ganan algunas cantidades 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 direcciones VMA para obtener algunos bits adicionales de entropía. Estos bits adicionales de entropía no se aplicarán a otros segmentos mmap(), solo a las bibliotecas.
Los atacantes pueden hacer uso de varios métodos para reducir la entropía presente en un espacio de direcciones aleatorio, que van desde simples fugas de información hasta atacar múltiples bits de entropía por ataque (como mediante dispersión de montón ). Es poco lo que se puede hacer al respecto.
Es posible filtrar información sobre el diseño de la memoria utilizando vulnerabilidades de cadenas de formato . Las funciones de cadena de formato como printf utilizan una lista de argumentos variables para hacer su trabajo; Los especificadores de formato describen cómo se ve la lista de argumentos. Debido a la forma en que normalmente se pasan los argumentos, cada especificador de formato se acerca a la parte superior del marco de la pila. Con el tiempo, se pueden extraer el puntero de retorno y el puntero del marco de 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 bibliotecas y pilas como obstáculo para un atacante.
También se puede disminuir la entropía en la pila o el montón. Normalmente, la pila debe estar alineada en 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 con las páginas, normalmente 4096 bytes. Al intentar un ataque, es posible alinear ataques duplicados con estos intervalos; se puede usar una diapositiva NOP/bin/sh con inyección de código shell, y la cadena ' ' se puede reemplazar con ' ////////bin/sh' para un número arbitrario de barras al intentar regresar al sistema . El número de bits eliminados es exactamente para n intervalos de ataque.
Estas disminuciones están limitadas debido a la cantidad de datos en la pila o montón. La pila, por ejemplo, normalmente se limita a8 MB [8] y crece a 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. Por otro lado, el montón 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. Este también es un factor limitante cuando se aplica la fuerza bruta; Aunque se puede reducir el número de ataques a realizar, el tamaño de los ataques se aumenta lo suficiente como para que, en algunas circunstancias, el comportamiento pueda resultar evidente para los sistemas de detección de intrusiones .
Las direcciones protegidas por ASLR pueden filtrarse a través de varios canales laterales, lo que elimina la utilidad de mitigación. Los ataques recientes han utilizado información filtrada por el búfer de predicción de destino de la rama de la CPU (BTB) o las tablas de páginas móviles de la unidad de administración de memoria (MMU). No está claro si este tipo de ataque ASLR puede mitigarse. Si no pueden, el beneficio de ASLR se reduce o elimina.
Varios sistemas operativos convencionales de propósito general implementan ASLR.
Android 4.0 Ice Cream Sandwich proporciona aleatorización del diseño del espacio de direcciones (ASLR) para ayudar a proteger el sistema y las aplicaciones de terceros contra vulnerabilidades debido a problemas de administración de memoria. En Android 4.1 se agregó soporte para ejecutables independientes de la posición. [9] Android 5.0 eliminó el soporte que no es PIE y requiere que todos los archivos binarios vinculados dinámicamente sean independientes de su posición. [10] [11] 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 fuente no primaria ] 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, agregada en 2010. [12] Está desactivada de forma predeterminada y se puede habilitar configurando sysctl vm.randomize_mmap en 1.
El soporte para ASLR apareció en FreeBSD 13.0. [13] [14] Está habilitado de forma predeterminada desde 13.2. [15]
Apple introdujo ASLR en iOS 4.3 (lanzado en marzo de 2011). [dieciséis]
KASLR se introdujo en iOS 6. [17] La base del kernel aleatoria es 0x01000000 + ((1+0xRR) * 0x00200000), donde 0xRRhay un byte aleatorio de SHA1 (datos aleatorios) generado por iBoot (el cargador de arranque de iOS de segunda etapa). [18]
El kernel de Linux habilitó una forma débil de ASLR de forma predeterminada desde la versión 2.6.12 del kernel, lanzada en junio de 2005. [19] Los conjuntos de 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 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). [20] Varias opciones de sysctl controlan el comportamiento de 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 . [21]
El ejecutable independiente de la posición (PIE) implementa una dirección base aleatoria para el binario ejecutable principal y ha estado en funcionamiento desde el 18 de abril de 2004. Proporciona la misma aleatoriedad de dirección al ejecutable principal que se utiliza para las bibliotecas compartidas. La función PIE no se puede utilizar junto con la función de vínculo previo para el mismo ejecutable. La herramienta de prevínculo implementa la aleatorización en el momento del prevínculo en lugar del tiempo de ejecución, porque por diseño el prevínculo tiene como objetivo manejar la reubicación de bibliotecas antes de que el vinculador dinámico tenga que hacerlo, lo que permite que la reubicación ocurra una vez para muchas ejecuciones del programa. Como resultado, la aleatorización del espacio de direcciones real anularía el propósito del enlace previo.
En 2014, Marco-Gisbert y Ripoll revelaron la técnica offset2lib que debilita Linux ASLR para los ejecutables PIE. Los kernels de Linux cargan 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 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. [22]
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 de más de 2 MiB deben devolver direcciones alineadas con 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), con el tiempo, ha crecido en tamaño hasta superar este umbral de 2 MiB, por lo que en lugar de estar alineada con un ( normalmente) límite de página de 4 KiB como antes, estas bibliotecas ahora están alineadas con 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 la 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. [23] Martin Doucha agregó un caso de prueba del proyecto de prueba de Linux para detectar este problema. [24]mmap_rnd_bits
La aleatorización del diseño del espacio de direcciones del kernel (KASLR) permite la aleatorización del espacio de direcciones para la imagen del kernel de Linux al aleatorizar dónde se coloca el código del kernel en el momento del arranque. [25] KASLR se fusionó con la línea principal del kernel de Linux en la versión 3.14 del kernel, lanzada el 30 de marzo de 2014. [26] Cuando se compila, se puede desactivar en el momento del arranque especificando nokaslr como uno de los parámetros de arranque del kernel. [27]
Existen varios ataques de canal lateral en procesadores x86 que podrían filtrar direcciones del kernel. [28] [29] A finales de 2017, se desarrolló el aislamiento de la tabla de páginas del kernel (KPTI, también conocido como KAISER) para derrotar estos ataques. [30] [31] Sin embargo, este método no puede proteger contra ataques de canal lateral que utilizan colisiones en estructuras de predictor de rama . [32]
A partir de 2021 [update], la aleatorización del diseño del espacio de direcciones del kernel más detallada (o función granular KASLR, FGKASLR) es una extensión planificada de KASLR para aleatorizar hasta el nivel de función. [33]
Windows Vista de Microsoft (lanzado 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 vinculados para estar habilitados para ASLR. [34] Por compatibilidad, no está habilitado de forma predeterminada para otras aplicaciones. Normalmente, sólo 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, [35] 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 de proceso y el bloque de entorno de subproceso también son aleatorias. Un documento técnico de seguridad de Symantec señaló que ASLR en Windows Vista de 32 bits puede no ser tan sólido como se esperaba, y Microsoft ha reconocido una debilidad en su implementación. [36]
Los sistemas de prevención de intrusiones basados en host como WehnTrust [37] y Ozone [38] también ofrecen ASLR para los sistemas operativos Windows XP y Windows Server 2003 . WehnTrust es de código abierto. [39] Los detalles completos de la implementación de Ozone no están disponibles. [40]
En febrero de 2012 [41] se observó que ASLR en sistemas Windows de 32 bits anteriores a Windows 8 puede ver reducida su efectividad en situaciones de poca memoria. En la misma investigación también se logró un efecto similar en Linux. El código de prueba provocó que el sistema Mac OS X 10.7.3 entrara en pánico en el kernel , por lo que no quedó claro su comportamiento ASLR en este escenario.
La compatibilidad con ASLR en el espacio de usuario apareció en NetBSD 5.0 (lanzado en abril de 2009), [42] y se habilitó de forma predeterminada en NetBSD actual en abril de 2016. [43]
La compatibilidad con Kernel ASLR en amd64 se agregó en NetBSD-current en octubre de 2017, lo que convierte a NetBSD en el primer sistema BSD que admite KASLR. [44]
En 2003, OpenBSD se convirtió en el primer sistema operativo convencional que admitía una forma potente de ASLR y lo activaba de forma predeterminada. [3]
OpenBSD completó su soporte ASLR en 2008 cuando agregó soporte para binarios PIE . [45] Malloc(3) de OpenBSD 4.4 fue diseñado para mejorar la seguridad aprovechando las funciones ASLR y de página de brecha implementadas como parte de la mmap llamada al sistema de OpenBSD , y para detectar errores de uso después de la liberación. [46] Lanzado en 2013, OpenBSD 5.3 fue el primer sistema operativo convencional que permitió ejecutables independientes de la posición de forma predeterminada en múltiples plataformas de hardware , y OpenBSD 5.7 activó los binarios estáticos independientes de la posición (Static-PIE) de forma predeterminada. [45]
En Mac OS X Leopard 10.5 (lanzado en octubre de 2007), Apple introdujo la aleatorización para las bibliotecas del sistema. [47]
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 el montón). protecciones de memoria), haciendo que las aplicaciones de 64 y 32 bits sean más resistentes a los ataques". [48]
A partir de OS X Mountain Lion 10.8 (lanzado en julio de 2012) y posteriores, todo el sistema, incluido el kernel, así como los kexts y las zonas, se reubican aleatoriamente durante el inicio del sistema. [49]
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. [50]
Se demostró que un ataque de canal lateral que utiliza un búfer de destino de rama evita la protección ASLR. [32] En 2017, se demostró un ataque llamado "ASLR⊕Cache" que podría derrotar a ASLR en un navegador web usando JavaScript. [51]
