PaX es un parche para el kernel de Linux que implementa protecciones de privilegios mínimos para las páginas de memoria . El enfoque de privilegios mínimos permite que los programas informáticos puedan restringir el conjunto de operaciones que pueden realizar; en el caso de PaX, la capacidad de ejecutar datos como código, que generalmente no es aplicable fuera de ciertos tipos de programas (como como compiladores just-in-time ) pero a menudo se utiliza para su explotación. PaX se lanzó por primera vez en 2000.
PaX marca la memoria de datos como no ejecutable y la memoria de programa como no grabable. Esto puede ayudar a prevenir algunas vulnerabilidades de seguridad , como las derivadas de ciertos tipos de desbordamientos de búfer , al evitar la ejecución de código no intencionado . PaX también presenta características de aleatorización del espacio de direcciones para hacer que los ataques de retorno a libc (ret2libc) sean estadísticamente difíciles de explotar. Sin embargo, estas funciones no protegen contra ataques que sobrescriban variables y punteros .
PaX es mantenido por The PaX Team , cuyo codificador principal es anónimo. El proyecto grsecurity incluye PaX, junto con otros parches del kernel de Linux exclusivos de grsecurity. Todas las versiones más nuevas de PaX a partir de 2014 solo se encuentran como parte del conjunto de parches de grsecurity.
Significado
Varios tipos de inseguridades informáticas son causadas por errores en los programas que hacen posible alterar su función, permitiendo efectivamente que se "reescriban" mientras se ejecutan. Los primeros 44 avisos de seguridad emitidos por Ubuntu se pueden clasificar [1] para mostrar que el 41% de las vulnerabilidades provienen de desbordamientos de búfer, el 11% de desbordamientos de enteros y el 16% de otro mal manejo de datos mal formados. Estos tipos de errores a menudo abren la posibilidad de inyectar y ejecutar código externo, o ejecutar código existente fuera de orden, y constituyen el 61% del grupo de muestra, descartando la superposición. (Este es un análisis burdo; un análisis más completo de las vulnerabilidades individuales probablemente arrojaría cifras muy diferentes). Muchos gusanos , virus e intentos de apoderarse de una máquina se basan en cambiar el contenido de la memoria para que se ejecute el código del malware. ; o al ejecutar contenidos de "datos" por desvío. Si se pudiera bloquear la ejecución de dicho malware, podría causar poco o ningún daño incluso después de haber sido instalado en una computadora; muchos, como el gusano Sasser , podrían evitarse en absoluto.
PaX fue diseñado para hacer precisamente eso para una gran cantidad de posibles ataques, y para hacerlo de una manera muy generalizada. Evita la ejecución de código incorrecto controlando el acceso a la memoria (acceso de lectura, escritura o ejecución; o combinaciones de los mismos) y está diseñado para hacerlo sin interferir con la ejecución del código adecuado. A costa de una pequeña cantidad de gastos generales, PaX reduce muchas vulnerabilidades de seguridad a una denegación de servicio (DoS) o un control de flujo de código remoto; exploits que normalmente darían a los atacantes acceso de root , permitirían el acceso a información importante en un disco duro o causarían otros daños que en su lugar causarían que el programa o proceso afectado se bloqueara con poco efecto en el resto del sistema.
Un ataque DoS (o su equivalente) es generalmente una molestia y, en algunas situaciones, puede causar pérdida de tiempo o recursos (por ejemplo, pérdida de ventas para una empresa cuyo sitio web se ve afectado); sin embargo, ningún dato debe verse comprometido cuando PaX interviene, ya que ninguna información se copiará incorrectamente en otro lugar. Sin embargo, el equivalente a un ataque DoS es inaceptable en algunos entornos; Algunas empresas tienen contratos de nivel de servicio u otras condiciones que hacen que la entrada exitosa de intrusos sea un problema menos costoso que la pérdida o reducción del servicio. Por tanto, el enfoque de PaX no se adapta bien a todas las circunstancias; sin embargo, en muchos casos, es un método aceptable para proteger la información confidencial al prevenir violaciones de seguridad exitosas.
Muchos, pero no todos, los errores de programación causan daños en la memoria. De los que lo hacen, y se pueden activar intencionalmente, algunos permitirán inducir al programa a hacer varias cosas para las que no estaba destinado, como producir un shell de privilegios elevados. El enfoque de PaX no está en la búsqueda y corrección de dichos errores, sino más bien en la prevención y contención de técnicas de explotación que pueden derivarse de dicho error del programador. Se reducirá la gravedad de un subconjunto de estos errores; los programas terminan, en lugar de proporcionar un servicio incorrecto.
PaX no previene directamente los desbordamientos del búfer; por el contrario, evita de forma eficaz que muchos de estos y otros errores de programación relacionados se utilicen para acceder sin autorización a un sistema informático. Otros sistemas, como Stack-Smashing Protector y StackGuard , intentan detectar directamente los desbordamientos del búfer y eliminan el programa infractor cuando se identifican; este enfoque se denomina protección contra la destrucción de pilas e intenta bloquear dichos ataques antes de que se puedan realizar. El enfoque más general de PaX, por otro lado, evita daños después de que comienza el intento. Aunque ambos enfoques pueden lograr algunos de los mismos objetivos, no son del todo redundantes. Por lo tanto, emplear ambos hará, en principio, un sistema operativo más seguro.
A mediados de 2004, PaX no se ha enviado al árbol del núcleo principal porque el equipo de PaX aún no lo considera apropiado; aunque PaX es completamente funcional en muchas arquitecturas de CPU , incluida la arquitectura x86 ampliamente utilizada , todavía permanece parcial o totalmente sin implementar en algunas arquitecturas. Aquellos en los que PaX es efectivo incluyen las arquitecturas IA-32 (x86), AMD64 , IA-64 , Alpha , PA-RISC y MIPS de 32 y 64 bits , PowerPC y SPARC .
Limitaciones
PaX no puede bloquear fallas de diseño fundamentales en programas ejecutables o en el kernel que permiten que un exploit abuse de los servicios suministrados, ya que en principio son indetectables. Por ejemplo, un motor de secuencias de comandos que permite el acceso a archivos y redes puede permitir que las secuencias de comandos maliciosas roben datos confidenciales a través de cuentas de usuarios privilegiados. PaX tampoco puede bloquear algunos ataques basados en errores de cadenas de formato , que pueden permitir la lectura y escritura arbitrarias de ubicaciones de datos en la memoria utilizando código ya existente; el atacante no necesita conocer ninguna dirección interna o inyectar ningún código en un programa para ejecutar este tipo de ataques.
La documentación de PaX, [2] mantenida en el sitio web de PaX, describe tres clases de ataques contra los cuales PaX intenta protegerse. La documentación analiza tanto los ataques para los que PaX será eficaz para proteger un sistema como aquellos para los que no lo hará. Todos asumen una base ejecutable completa e independiente de la posición con protecciones de espacio ejecutable completas y distribución aleatoria completa del diseño del espacio de direcciones. Entonces, brevemente, los ataques bloqueables son:
- Aquellos que introducen y ejecutan código arbitrario. Estos tipos de ataques con frecuencia involucran shellcode.
- Aquellos que intentan ejecutar código de programa existente fuera del orden original previsto por el (los) programador (es) de computadora. Esto se denomina comúnmente ataque de retorno a libc o ret2libc para abreviar.
- Aquellos que intentan ejecutar código de programa existente en el orden previsto con datos arbitrarios. Este problema existía en las versiones de zlib anteriores a la 1.1.4; una secuencia comprimida dañada podría causar un archivo double-free.
Debido a que PaX tiene como objetivo prevenir el daño de tipos de ataques específicos en lugar de encontrar y corregir los errores que los permiten, no puede proteger contra todo tipo de ataques; de hecho, prevenir todos los ataques es imposible .
La primera clase de ataques sigue siendo posible con un 100% de fiabilidad a pesar de utilizar PaX si el atacante no necesita un conocimiento previo de las direcciones en la tarea atacada.
La segunda y tercera clases de ataques también son posibles con un 100% de confiabilidad, si el atacante necesita un conocimiento avanzado del diseño del espacio de direcciones y puede obtener este conocimiento leyendo el espacio de direcciones de la tarea atacada. Esto es posible si el objetivo tiene un error que filtra información, por ejemplo, si el atacante tiene acceso a / proc / (pid) / maps. Hay un parche de oscuridad que anula los valores para los rangos de direcciones y los inodos en cada fuente de información accesible desde el área del usuario para cerrar la mayoría de estos agujeros; sin embargo, actualmente no está incluido en PaX.
La segunda y tercera clases de ataques son posibles con una pequeña probabilidad si el atacante necesita un conocimiento avanzado del diseño del espacio de direcciones, pero no puede obtener este conocimiento sin recurrir a adivinar o realizar una búsqueda por fuerza bruta. La documentación de ASLR [3] describe cómo se puede cuantificar aún más la "pequeña probabilidad" de éxito de estos ataques.
La primera clase de ataques es posible si el atacante puede hacer que la tarea atacada cree, escriba y mmap () un archivo. Esto, a su vez, requiere que sea posible el segundo método de ataque, por lo que un análisis de eso también se aplica aquí. Aunque no forma parte de PaX, se recomienda, entre otras cosas, que los sistemas de producción utilicen un sistema de control de acceso que evite este tipo de ataques.
Aún se requiere una administración responsable del sistema incluso en los sistemas PaXified. PaX previene o bloquea ataques que explotan errores de corrupción de memoria , como los que conducen a ataques shellcode y ret2libc. La mayoría de los ataques que PaX puede prevenir están relacionados con errores de desbordamiento de búfer. Este grupo incluye los esquemas más comunes que se utilizan para aprovechar los problemas de gestión de la memoria. Aún así, PaX no puede prevenir todos esos ataques.
Características
PaX ofrece protección de espacio ejecutable , usando (o emulando en el software del sistema operativo) la funcionalidad de un bit NX (es decir, CPU incorporada y soporte MMU para etiquetado de privilegios de ejecución de contenido de memoria). También proporciona aleatorización del diseño del espacio de direcciones para derrotar los ataques ret2libc y todos los demás ataques que se basan en la estructura conocida de la memoria virtual de un programa .
Protecciones de espacio ejecutables
La característica principal de PaX es la protección del espacio ejecutable que ofrece. Estas protecciones aprovechan el bit NX en ciertos procesadores para evitar la ejecución de código arbitrario. Esto evita los ataques que involucran inyección de código o shellcode. En las CPU IA-32 donde no hay un bit NX, PaX puede emular la funcionalidad de uno de varias formas.
Muchos sistemas operativos, incluido Linux, aprovechan la funcionalidad NX existente en el hardware para aplicar las restricciones adecuadas a la memoria. La figura 1 muestra un conjunto simple de segmentos de memoria en un programa con una biblioteca cargada; los segmentos verdes son datos y los azules son códigos. En casos normales, el espacio de direcciones en AMD64 y otros procesadores similares se parecerá por defecto a la Fig. 1 , con datos y código claramente definidos. Desafortunadamente, Linux de forma predeterminada no prohíbe que una aplicación cambie ninguna de sus protecciones de memoria; cualquier programa puede crear confusión en el código de datos , marcando áreas de código como escribibles y áreas de datos como ejecutables. PaX evita tales cambios, además de garantizar el conjunto predeterminado más restrictivo adecuado para el funcionamiento típico.
Cuando las Protecciones de espacio ejecutable están habilitadas, incluidas las restricciones mprotect (), PaX garantiza que no se marcarán asignaciones de memoria de ninguna manera en las que se puedan ejecutar como código de programa después de que haya sido posible alterarlas de su estado original. El efecto de esto es que se vuelve imposible ejecutar la memoria durante y después de que ha sido posible escribir en ella, hasta que esa memoria se destruye; y por lo tanto, ese código no se puede inyectar en la aplicación, malicioso o de otro tipo, desde una fuente interna o externa.
El hecho de que los programas no puedan ejecutar por sí mismos datos que originaron como código de programa plantea un problema infranqueable para las aplicaciones que necesitan generar código en tiempo de ejecución como función básica, como los compiladores just-in-time para Java ; sin embargo, la mayoría de los programas que tienen dificultades para funcionar correctamente bajo estas restricciones pueden ser depurados por el programador y corregidos para que no dependan de esta funcionalidad. Para aquellos que simplemente necesitan esta funcionalidad, o aquellos que aún no se han solucionado, el administrador del sistema puede marcar el archivo ejecutable del programa para que no se le apliquen estas restricciones.
El equipo de PaX tuvo que tomar algunas decisiones de diseño sobre cómo manejar la llamada al sistema mmap () . Esta función se utiliza para mapear la memoria compartida o para cargar bibliotecas compartidas. Debido a esto, necesita proporcionar RAM grabable o ejecutable, dependiendo de las condiciones en las que se utilice.
La implementación actual de PaX proporciona asignaciones de memoria anónimas grabables por defecto; las asignaciones de memoria respaldadas por archivos solo se pueden escribir si la llamada mmap () especifica el permiso de escritura. La función mmap () nunca devolverá asignaciones que sean tanto de escritura como ejecutables, incluso si esos permisos se solicitan explícitamente en la llamada.
Páginas no ejecutables forzadas
De forma predeterminada, Linux no proporciona el uso más seguro de páginas de memoria no ejecutables a través del bit NX. Además, algunas arquitecturas ni siquiera proporcionan explícitamente una forma de marcar las páginas de memoria como no ejecutables. PaX proporciona una política para aprovechar las páginas no ejecutables de la manera más segura posible.
Además, si la CPU no proporciona un bit NX explícito, PaX puede emular (suministrar) un bit NX mediante uno de varios métodos. Esto degrada el rendimiento del sistema, pero aumenta enormemente la seguridad. Además, la pérdida de rendimiento en algunos métodos puede ser lo suficientemente baja como para ignorarla.
PAGEEXEC
PAGEEXEC usa o emula un bit NX. En los procesadores que no admiten un NX de hardware, a cada página se le asigna un bit NX emulado. El método utilizado para hacer esto se basa en la arquitectura de la CPU. Si hay disponible un bit NX de hardware, PAGEEXEC lo usará en lugar de emular uno, sin incurrir en costos de rendimiento.
En las arquitecturas IA-32, la emulación de bits NX se realiza cambiando el nivel de permiso de las páginas no ejecutables. El bit Supervisor está sobrecargado para representar NX. Esto provoca un error de protección cuando se produce el acceso a la página y aún no está almacenada en caché en el búfer de búsqueda de traducción . En este caso, la unidad de gestión de memoria alerta al sistema operativo; en IA-32, la MMU generalmente tiene cachés TLB separados para ejecución (ITLB) y lectura / escritura (DTLB), por lo que esta falla también permite que Linux y PaX determinen si el programa estaba tratando de ejecutar la página como código. Si se detecta una falla de la ITLB, el proceso se termina [ aclarar ] ; de lo contrario, Linux obliga a que se permita una carga DTLB y la ejecución continúa con normalidad.
PAGEEXEC tiene la ventaja de no dividir el espacio de direcciones de memoria a la mitad; las tareas aún obtienen un espacio virtual de 3 GB en lugar de una división de 1,5 / 1,5. Sin embargo, para la emulación, es más lento que SEGMEXEC y causó un serio detrimento del rendimiento en algunos casos.
Desde mayo de 2004, el código PAGEEXEC más nuevo para IA-32 en PaX rastrea la página ejecutable más alta en la memoria virtual y marca todas las páginas más altas como páginas de usuario. Esto permite que las páginas de datos por encima de este límite, como la pila, se manejen con normalidad, sin pérdida de rendimiento. Todo lo que esté debajo de esta área todavía se maneja como antes. Este cambio es similar a la implementación de Exec Shield NX y la implementación de OpenBSD W ^ X ; excepto que PaX usa el método de sobrecarga de bits de Supervisor para manejar páginas NX en el segmento de código también.
SEGMEXEC
SEGMEXEC emula la funcionalidad de un bit NX en CPU IA-32 (x86) dividiendo el espacio de direcciones por la mitad y reflejando las asignaciones de código en el espacio de direcciones. Cuando hay una recuperación de instrucción , la recuperación se traduce a través de la división. Si el código no está mapeado allí, el programa se mata.
SEGMEXEC reduce a la mitad el espacio de memoria virtual de la tarea. En circunstancias normales, los programas obtienen un espacio de VM de 3GiB de ancho, que tiene una memoria física asignada. Bajo SEGMEXEC, esto se convierte en una división de 1,5 / 1,5 GiB, con la mitad superior utilizada para la duplicación. A pesar de esto, aumenta el rendimiento si la emulación debe realizarse en arquitecturas IA-32 (x86). El mapeo en la mitad superior e inferior del espacio de memoria es a la misma página de memoria física, por lo que no duplica el uso de RAM.
Mprotect restringido ()
Se supone que PaX garantiza que ninguna RAM sea tanto escribible como ejecutable. Una función, la función mprotect (), cambia los permisos en un área de memoria. La Especificación Única de UNIX define mprotect () con la siguiente nota en su descripción:
- Si una implementación no puede soportar la combinación de tipos de acceso especificados por prot, la llamada a mprotect () fallará.
La implementación de PaX no permite que una página de memoria tenga permisos PROT_WRITE y PROT_EXEC habilitados cuando las restricciones mprotect () están habilitadas para la tarea; cualquier llamada a mprotect () para establecer ambos (PROT_WRITE | PROT_EXEC) al mismo tiempo fallará debido a EACCESS (Permiso denegado). Esto garantiza que las páginas no se volverán tanto escribibles como ejecutables y, por lo tanto, un terreno fértil para ataques simples de inyección de código.
Se produce un error similar si mprotect (... | PROT_EXEC) se produce en una página que no tiene la restricción PROT_EXEC activada. El fracaso aquí está justificado; si una página PROT_WRITE tiene código inyectado en ella, y luego se convierte en PROT_EXEC, una activación posterior del exploit que permite la inyección de código permitirá que se ejecute el código. Sin esta restricción, es posible un exploit de tres pasos: inyectar código, ret2libc :: ret2mprotect (), ejecutar código.
Con las restricciones de mprotect () habilitadas, un programa ya no puede violar la política de páginas no ejecutables que PaX establece inicialmente en todas las asignaciones de memoria; por lo tanto, mprotect () restringido podría considerarse una aplicación estricta de la política de seguridad, mientras que las "páginas no ejecutables forzadas" sin estas restricciones podrían considerarse una forma más flexible de aplicación.
Emulación de trampolín
Los trampolines generalmente son implementados por gcc como pequeños fragmentos de código generados en tiempo de ejecución en la pila . Por lo tanto, requieren ejecutar memoria en la pila, lo que hace que PaX elimine el programa.
Debido a que los trampolines son códigos generados en tiempo de ejecución , activan PaX y provocan la muerte del programa que los usa. PaX es capaz de identificar la configuración de las camas elásticas y permitir su ejecución. Sin embargo, se considera que esto produce una situación de seguridad debilitada.
Aleatorización del diseño del espacio de direcciones
La aleatorización del diseño del espacio de direcciones, o ASLR, es una técnica para contrarrestar la ejecución arbitraria de código o ataques ret2libc. Estos ataques implican ejecutar código ya existente fuera del orden previsto por el programador .
ASLR, como se proporciona en PaX, mezcla la base de la pila y la base del montón en la memoria virtual cuando está habilitado. También, opcionalmente, aleatoriza la base mmap () y la base ejecutable de los programas. Esto reduce sustancialmente la probabilidad de un ataque exitoso al requerir que el código de ataque adivine la ubicación de estas áreas.
La Fig. 2 muestra vistas cualitativas de los espacios de direcciones del proceso con distribución aleatoria del diseño del espacio de direcciones. Las flechas de media cabeza indican un espacio aleatorio entre varias áreas de la memoria virtual. En cualquier momento en el que el núcleo inicializa el proceso, se puede considerar que la longitud de estas flechas aumenta o se acorta a partir de esta plantilla de forma independiente entre sí.
Durante el curso de la vida de un programa, el montón, también llamado segmento de datos o .bss, crecerá; el montón se expande hacia la dirección de memoria más alta disponible. Por el contrario, la pila crece hacia abajo, hacia la dirección de memoria más baja, 0.
Es muy poco común que un programa requiera un gran porcentaje del espacio de direcciones para cualquiera de estos. Cuando las bibliotecas de programas se cargan dinámicamente al inicio de un programa por el sistema operativo, se colocan antes del montón; sin embargo, hay casos en los que el programa cargará otras bibliotecas, como las comúnmente denominadas complementos , durante la ejecución. El sistema operativo o programa debe elegir un desplazamiento aceptable para colocar estas bibliotecas.
PaX deja una parte de las direcciones, los MSB , fuera de los cálculos de aleatorización. Esto ayuda a asegurar que la pila y el montón se coloquen de modo que no choquen entre sí, y que las bibliotecas se coloquen de manera que la pila y el montón no choquen con ellos.
El efecto de la aleatorización depende de la CPU. Las CPU de 32 bits tendrán 32 bits de espacio de direcciones virtuales, lo que permitirá el acceso a 4 GiB de memoria. Debido a que Linux usa el 1 GB superior para el kernel, esto se reduce a 3GiB. SEGMEXEC proporciona una división a la mitad de este espacio de direcciones 3GiB, restringiendo la aleatorización a 1.5GiB. Las páginas tienen un tamaño de 4 KB y las aleatorizaciones están alineadas con las páginas. Los cuatro MSB superiores se descartan en la aleatorización, de modo que el montón existe al principio y la pila al final del programa. Esto se reduce a que la pila y el montón existan en uno de varios millones de posiciones (aleatorización de 23 y 24 bits), y todas las bibliotecas existan en cualquiera de las aproximadamente 65.000 posiciones.
En las CPU de 64 bits, el espacio de direcciones virtuales proporcionado por la MMU puede ser mayor, lo que permite el acceso a más memoria. La aleatorización será más entrópica en tales situaciones, reduciendo aún más la probabilidad de un ataque exitoso en ausencia de una fuga de información.
Base de pila aleatoria
PaX compensa aleatoriamente la base de la pila en incrementos de 16 bytes, combinando la ubicación aleatoria del segmento de memoria virtual real con un espacio de pila de subpágina. La magnitud total de la aleatorización depende del tamaño del espacio de memoria virtual; por ejemplo, la base de la pila está en algún lugar en un rango de 256MiB en arquitecturas de 32 bits, lo que da 16 millones de posiciones posibles o 24 bits de entropía.
La aleatorización de la base de la pila tiene un efecto en la entrega de la carga útil durante los ataques shellcode y return-to-libc . Ese tipo de ataques modifican el campo del puntero de retorno a la dirección de la carga útil. Siempre que la dirección de la pila no se filtre y, por lo tanto, sea desconocida para el adversario, la probabilidad de éxito se reduce significativamente; la posición de la pila es impredecible y perder la carga útil probablemente hace que el programa se bloquee.
En el caso de shellcode, se puede anteponer a la carga útil una serie de instrucciones denominadas diapositiva NOP o trineo NOP. Esto agregará un caso de éxito más por cada 16 bytes de diapositiva NOP. 16 bytes de diapositiva NOP aumentan la tasa de éxito de 1 / 16M a 2 / 16M; 128 bytes de diapositiva NOP aumentan esto a 9 / 16M. El aumento en la tasa de éxito es directamente proporcional al tamaño de la diapositiva NOP; duplicar la longitud de cualquier deslizamiento NOP dado duplica las posibilidades de un ataque exitoso.
Los ataques de retorno a libc no utilizan código, sino que inyectan marcos de pila de ancho fijo. Debido a esto, los marcos de pila deben repetirse exactamente alineados a 16 bytes. A menudo, un marco de pila será más grande que esto, dando cargas útiles de marco de pila repetidas de la misma longitud que un trineo NOP dado con un impacto menor en la tasa de éxito de los ataques.
Base mmap () aleatorizada
En los sistemas POSIX , la llamada al sistema mmap () permite que la memoria se asigne en las compensaciones especificadas por el proceso o seleccionadas por el kernel. Puede ser un recuerdo anónimo sin nada; o mapeos de memoria respaldados por archivos, que simulan una parte de un archivo o una copia de dicha parte para estar en la memoria en ese punto. Las bibliotecas de programas se cargan utilizando mmap () para asignar su código y datos privados; los archivos se copian en la memoria si se modifican, en lugar de reescribirlos en el disco.
Cualquier llamada a mmap () puede o no especificar un desplazamiento en la memoria virtual para asignar el mapeo. Si no se especifica un desplazamiento, es el sistema operativo quien debe seleccionar uno. Linux hace esto calculando un desplazamiento de una manera predecible, comenzando desde una dirección virtual predefinida llamada base mmap () . Debido a esto, cada ejecución de un proceso carga bibliotecas iniciales como la biblioteca estándar de C o libc en el mismo lugar.
Cuando la base aleatoria de mmap () está habilitada, PaX cambia aleatoriamente la base de mmap (), lo que afecta el posicionamiento de todas las bibliotecas y otras llamadas a mmap () no específicas. Esto hace que todo el código vinculado dinámicamente, es decir, los objetos compartidos, se mapeen en un desplazamiento diferente, seleccionado aleatoriamente cada vez. Los atacantes que requieran una función en una biblioteca determinada deben adivinar dónde se carga esa biblioteca en el espacio de memoria virtual para llamarla. Esto dificulta los ataques de retorno a libc; aunque las inyecciones de shellcode aún pueden buscar la dirección de cualquier función en la tabla de compensación global .
PaX no cambia el orden de carga de las bibliotecas. Esto significa que si un atacante conoce la dirección de una biblioteca, puede derivar las ubicaciones de todas las demás bibliotecas; sin embargo, es notable que hay problemas más serios si el atacante puede derivar la ubicación de una biblioteca en primer lugar, y la aleatorización adicional probablemente no ayudará a eso. Además, los ataques típicos solo requieren encontrar una biblioteca o función; otros elementos interesantes como el montón y la pila se aleatorizan por separado y no se pueden derivar de la base mmap ().
Cuando se cargan los ejecutables ET_DYN, es decir, los ejecutables compilados con código independiente de la posición de la misma manera que las bibliotecas compartidas, su base también se elige aleatoriamente, ya que se mmap () en la RAM al igual que los objetos compartidos normales.
Cuando se combina una pila no ejecutable con la aleatorización base mmap (), la dificultad para explotar los errores protegidos por PaX aumenta enormemente debido al uso forzado de los ataques return-to-libc. En sistemas de 32 bits, esto equivale a 16 órdenes de magnitud ; es decir, las posibilidades de éxito se reducen recursivamente a la mitad 16 veces. Combinado con la aleatorización de la pila, el efecto puede ser bastante asombroso; si cada persona en el mundo (asumiendo un total de 6 mil millones) ataca el sistema una vez, aproximadamente 1 o 2 deberían tener éxito en un sistema de 32 bits. Los sistemas de 64 bits, por supuesto, se benefician de una mayor aleatorización.
Base ET_EXEC aleatoria
PaX puede mapear código no independiente de la posición de forma aleatoria en la RAM; sin embargo, esto plantea algunos problemas. Primero, incurre en una sobrecarga de rendimiento adicional. En segundo lugar, en raras ocasiones provoca falsas alarmas, lo que hace que PaX detenga el proceso sin ningún motivo. Se recomienda encarecidamente que los ejecutables se compilen ET_DYN, de modo que sean un código 100% independiente de la posición.
La aleatorización de la base de carga ejecutable para los ejecutables de posición fija ET_EXEC se vio afectada por una falla de seguridad en el código de duplicación de VM en PaX. Para aquellos que no se han actualizado, la falla podría solucionarse desactivando la emulación de bits SEGMEXEC NX y la aleatorización RANDEXEC de la base ejecutable.
Marcas binarias
PaX permite que los archivos ejecutables en formato ejecutable y enlazable se marquen con restricciones reducidas a través de las herramientas chpax y paxctl . Estas marcas existen en el encabezado ELF y, por lo tanto, son independientes del sistema de archivos y forman parte del objeto de archivo en sí. Esto significa que las marcas se conservan mediante el empaquetado, la copia, el archivo, el cifrado y el movimiento de los objetos. La herramienta chpax está obsoleta en favor de paxctl.
PaX permite marcas individuales tanto para PAGEEXEC como para SEGMEXEC; aleatorizar el mmap (), la pila y la base del montón; aleatorizar la base ejecutable para los binarios ET_EXEC; restringir mprotect (); y emulando trampolines.
En el caso de chpax, ciertas herramientas como la tira pueden perder las marcas; usar paxctl para configurar PT_PAX_FLAGS es el único método confiable. La herramienta paxctl utiliza un nuevo encabezado de programa ELF creado específicamente para las banderas PaX. Estas marcas pueden estar explícitamente activadas, desactivadas o desactivadas. Cuando no se configura, la decisión sobre qué configuración utilizar la toma el código PaX en el kernel y está influenciada por la configuración del modo suave PaX en todo el sistema.
Historia
Este es un historial incompleto de PaX que se actualizará a medida que se encuentre más información.
- Octubre de 2000: PaX se lanzó por primera vez con el método básico PAGEEXEC
- Noviembre de 2000: se lanza la primera encarnación de MPROTECT
- Junio de 2001: ASLR (aleatorización de mmap) implementado, no publicado
- Julio de 2001: lanzamiento de ASLR
- Agosto de 2001: lanzamiento de ASLR con pila adicional y aleatorización de PIE
- Julio de 2002: lanzamiento de VMA Mirroring y RANDEXEC
- Octubre de 2002: lanzamiento de SEGMEXEC
- Octubre de 2002: lanzamiento de ASLR con aleatorización de pila de kernel adicional
- Febrero de 2003: se introduce el método de marcado EI_PAX ELF
- Abril de 2003: Lanzamiento de KERNEXEC (páginas de kernel no ejecutables)
- Julio de 2003: ASLR con aleatorización adicional de brk lanzada
- Febrero de 2004: se introduce el método de marcado PT_PAX_FLAGS ELF
- Mayo de 2004: PAGEEXEC aumentado con seguimiento de límite de segmento de código para un rendimiento mejorado
- 4 de marzo de 2005: se anuncia la vulnerabilidad VMA Mirroring, se lanzan nuevas versiones de PaX y grsecurity, todas las versiones anteriores que utilizan SEGMEXEC y RANDEXEC tienen una vulnerabilidad de escalamiento de privilegios
- 1 de abril de 2005: debido a esa vulnerabilidad, se programó que el proyecto PaX fuera asumido por un nuevo desarrollador, pero, como no apareció ningún candidato, el antiguo desarrollador ha continuado con el mantenimiento desde entonces.
Ver también
- Escudo ejecutivo
- Endurecimiento (informática)
- Sistema de detección de intrusos
- Sistema de Prevención de Intrusión
- Linux con seguridad mejorada
- RSBAC
Referencias
- ^ "USNAnalysis - Wiki de Ubuntu" . Consultado el 2 de junio de 2016 .[ fuente autoeditada ]
- ^ "pax.txt" . Consultado el 2 de junio de 2016 .
- ^ "aslr.txt" . Consultado el 2 de junio de 2016 .
Otras lecturas
- Documentación de PaX
enlaces externos
- Página de inicio de PaX
- Futuro de PaX 2003
- Presentación sobre PaX 2003-10-14
- Camas elásticas para funciones anidadas
- Técnicas de mitigación de explotación 2004
- Análisis de Ubuntu Linux USN
- Error de seguridad de elevación de privilegios de PaX 9 de marzo de 2005
- Código de prueba de concepto de elevación de privilegios de PaX 2005