Aleatorización del diseño del espacio de direcciones - Address space layout randomization

La aleatorización del diseño del espacio de direcciones ( ASLR ) es una técnica de seguridad informática involucrada en la prevención de la explotación de vulnerabilidades de corrupción de memoria . Para evitar que un atacante salte de manera confiable, por ejemplo, a una función explotada en 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 , montón y bibliotecas .

Historia

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, que también proporciona un parche para la aleatorización de la pila del kernel desde octubre de 2002.

El primer sistema operativo convencional que admite ASLR de forma predeterminada fue OpenBSD versión 3.4 en 2003, seguido de Linux en 2005.

Beneficios

La aleatorización del espacio de direcciones obstaculiza algunos tipos de ataques de seguridad al hacer 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 shellcode inyectado en la pila deben encontrar la pila primero. En ambos casos, el sistema oculta las direcciones de memoria relacionadas 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.

Eficacia

La aleatorización del diseño del espacio de direcciones se basa en la baja probabilidad de que un atacante adivine la ubicación de las áreas colocadas al azar. 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 las compensaciones aleatorias. La entropía aumenta ya sea aumentando la cantidad de espacio del área de memoria virtual sobre la cual ocurre la aleatorización o reduciendo el período durante el cual ocurre 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 VMA.

Para vencer 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 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 asigna aleatoriamente a uno de los pocos 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:

${\ Displaystyle E_ {s}}$ (trozos de entropía de la parte superior de la pila)
${\ Displaystyle E_ {m}}$ (trozos de entropía de mmap()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 ejecutable principal)
${\ Displaystyle A_ {h}}$ (bits atacados por intento de entropía de la 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 que un atacante tenga éxito, tenemos que asumir una cantidad de intentos $α$ llevados a cabo 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 tenemos que averiguar cuántos bits son relevantes y cuántos están siendo atacados en cada intento, dejando cuantos bits tenga que vencer el atacante.

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 \,}$ (suposición aislada; el espacio de direcciones se vuelve a asignar al azar 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 en copias del programa con el mismo espacio de direcciones)

En muchos sistemas, puede ser de miles o millones; en los sistemas modernos de 64 bits , estos números generalmente alcanzan los millones al menos, Hector Marco-Gisbert e Ismael Ripoll mostraron en 2014 cómo omitir el ASLR en sistemas de 64 bits en menos de un segundo bajo ciertas circunstancias. Para sistemas de 32 bits a velocidades de computadora de 2004 que tienen 16 bits para la aleatorización de direcciones, 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". La declaració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 que se incluye en grsecurity, proporcionan varios métodos para hacer inviables estos ataques de fuerza bruta. Un método implica evitar que un ejecutable se ejecute durante un período de tiempo configurable si se ha bloqueado un cierto número de veces. ${\ Displaystyle 2 ^ {N}}$

Android, y posiblemente otros sistemas, implementan la distribución aleatoria del orden de carga de la biblioteca , una forma de ASLR que aleatoriza el orden en 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 tamaños de biblioteca variados, por lo que la entropía real obtenida es algo mayor. Tenga en cuenta que, por lo general, los atacantes solo necesitan una biblioteca; las matemáticas son más complejas con múltiples bibliotecas, y también se muestran a continuación. Tenga en cuenta que el caso de un atacante que utiliza 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 {casos}}}$

Estos valores tienden a ser bajos incluso para valores grandes de $l$ , lo que es más importante ya que los atacantes generalmente pueden usar solo la biblioteca estándar de C y, por lo tanto, a menudo se puede suponer eso . Sin embargo, incluso para un pequeño número de bibliotecas, aquí se obtienen 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 obtener algunos bits adicionales de entropía. Tenga en cuenta que estos bits adicionales de entropía no se aplicarán a otros segmentos de mmap (), solo a las bibliotecas. ${\ Displaystyle \ beta \, = 1}$

Reducir la entropía

Los atacantes pueden hacer uso de varios métodos para reducir la entropía presente en un espacio de direcciones aleatorias, que van desde simples filtraciones de información hasta atacar múltiples bits de entropía por ataque (como por ejemplo, mediante la pulverización de pilas ). 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 usan una lista de argumentos de variable 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. Eventualmente, el puntero de retorno y el puntero del marco de pila se pueden extraer, revelando la dirección de una biblioteca vulnerable y la dirección de un marco de pila conocido; esto puede eliminar por completo 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. Normalmente, la pila 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 con la página, normalmente 4096 bytes. Al intentar un ataque, es posible alinear ataques duplicados con estos intervalos; se puede usar una diapositiva NOP con inyección de shellcode , y la cadena " /bin/sh" se puede reemplazar por " ////////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 atacados. ${\ Displaystyle \ log _ {2} \! \ left (n \ right)}$

Estas disminuciones están limitadas debido a la cantidad de datos en la pila o el montón. La pila, por ejemplo, normalmente se limita a8 MB 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 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. Este también es un factor limitante cuando se utiliza la fuerza bruta; aunque se puede reducir el número de ataques a realizar, el tamaño de los ataques aumenta lo suficiente como para que, en algunas circunstancias, el comportamiento se vuelva evidente para los sistemas de detección de intrusos .

Limitaciones

Las direcciones protegidas por ASLR se pueden filtrar por varios canales laterales, eliminando la utilidad de mitigación. Los ataques recientes han utilizado información filtrada por el búfer predictor 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 esta clase de ataque ASLR puede mitigarse. Si no pueden, el beneficio de ASLR se reduce o se elimina.

Implementaciones

Varios sistemas operativos convencionales de propósito general implementan ASLR.

Androide

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. Se agregó compatibilidad con ejecutables independientes de la posición en Android 4.1. Android 5.0 eliminó el soporte no PIE y requiere que todos los binarios vinculados dinámicamente sean independientes de la posición. 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 y se incluyó en la versión de Android 7.0.

DragonFly BSD

DragonFly BSD tiene una implementación de ASLR basada en el modelo de OpenBSD, agregado en 2010. Está desactivado de forma predeterminada y se puede habilitar configurando sysctl vm.randomize_mmap en 1.

FreeBSD

El soporte para ASLR apareció en FreeBSD 13.0. Está deshabilitado por defecto.

iOS (iPhone, iPod touch, iPad)

Apple introdujo ASLR en iOS 4.3 (lanzado en marzo de 2011).

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

Linux

El kernel de Linux habilitó una forma débil de ASLR por defecto desde la versión 2.6.12 del kernel, lanzada en junio de 2005. 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 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 de mmap en un área de 1 MB de ancho que contiene 256 posiciones posibles.

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 2003. Proporciona la misma aleatoriedad de direcciones al ejecutable principal que se utiliza para las bibliotecas compartidas. La función PIE está en uso solo para los demonios conectados a la red; la función PIE no se puede usar junto con la función de preenlace para el mismo ejecutable. La herramienta de prevínculo implementa la aleatorización en el tiempo de prevínculo en lugar de en tiempo de ejecución, porque por diseño prelink tiene como objetivo manejar la reubicación de bibliotecas antes de que el enlazador 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 frustraría el propósito de la vinculación previa.

La aleatorización se puede desactivar para un proceso específico cambiando su dominio de ejecución, utilizando personality(2).

Aleatorización del diseño del espacio de direcciones del kernel

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. KASLR se fusionó con la línea principal del kernel de Linux en la versión del kernel 3.14, lanzada el 30 de marzo de 2014. Cuando se compila, se puede deshabilitar en el momento del arranque especificando nokaslr como uno de los parámetros de arranque del kernel.

Hay varios ataques de canal lateral en procesadores x86 que podrían filtrar direcciones del kernel. A fines de 2017, se desarrolló el aislamiento de tablas de páginas del kernel (KPTI también conocido como KAISER) para derrotar estos ataques. Sin embargo, este método no puede proteger contra ataques de canal lateral utilizando colisiones en estructuras de predicción de ramas .

Microsoft Windows

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. Por compatibilidad, no está habilitado de forma 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\MoveImageso 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 subprocesos también son aleatorias. Un informe 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.

Los sistemas de prevención de intrusiones basados en host , como WehnTrust y Ozone, también ofrecen ASLR para los sistemas operativos Windows XP y Windows Server 2003 . WehnTrust es de código abierto. Los detalles completos de la implementación de Ozone no están disponibles.

En febrero de 2012 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. También se logró un efecto similar en Linux en la misma investigación. 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.

NetBSD

El soporte para ASLR en el área de usuario apareció en NetBSD 5.0 (publicado en abril de 2009) y se habilitó de forma predeterminada en NetBSD-current en abril de 2016.

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.

OpenBSD

En 2003, OpenBSD se convirtió en el primer sistema operativo convencional en admitir una forma sólida de ASLR y en activarlo de forma predeterminada. OpenBSD completó su soporte ASLR en 2008 cuando agregó soporte para binarios PIE . Malloc (3) de OpenBSD 4.4 fue diseñado para mejorar la seguridad aprovechando las funciones de ASLR y de página de brechas implementadas como parte de la mmap llamada al sistema de OpenBSD , y para detectar errores de uso después de la liberación. Lanzado en 2013, OpenBSD 5.3 fue el primer sistema operativo convencional en habilitar ejecutables independientes de la posición de forma predeterminada en múltiples plataformas de hardware , y OpenBSD 5.7 activó binarios estáticos independientes de la posición (Static-PIE) de forma predeterminada.

Mac OS

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

En Mac OS X Lion 10.7 (lanzado en julio de 2011), Apple amplió su implementación para cubrir todas las aplicaciones, indicando que "la distribución aleatoria 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 heap protecciones de memoria), lo que hace que las aplicaciones de 64 y 32 bits sean más resistentes a los ataques ".

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.

Solaris

ASLR se ha introducido en Solaris a partir de Solaris 11.1 (publicado en octubre de 2012). ASLR en Solaris 11.1 se puede configurar para todo el sistema, por zona o por binario.

Explotación

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

Languages

In other projects