Programación orientada al retorno de señal

Si se emplean mecanismos como la prevención de ejecución de datos , el atacante no podrá simplemente colocar un shellcode en la pila y provocar su ejecución sobrescribiendo la dirección de retorno. Con estas protecciones, la máquina no ejecutará ningún código presente en las áreas de memoria marcadas como modificables y no ejecutables. Por lo tanto, el atacante deberá reutilizar código que ya se encuentre en la memoria.

La mayoría de los programas no contienen funciones que permitan al atacante llevar a cabo directamente la acción deseada (por ejemplo, obtener acceso a un intérprete de comandos ), pero las instrucciones necesarias suelen estar dispersas por la memoria. ^{[ 6 ]}

La programación orientada a retornos requiere que estas secuencias de instrucciones, llamadas gadgets, terminen con una RETinstrucción. De esta forma, el atacante puede escribir una secuencia de direcciones para estos gadgets en la pila, y tan pronto como RETse ejecute una instrucción en un gadget, el flujo de control pasará al siguiente gadget de la lista.

Este ataque es posible gracias a cómo se manejan las señales en la mayoría de los sistemas tipo POSIX . Cada vez que se entrega una señal, el núcleo necesita cambiar de contexto al manejador de señales instalado. Para ello, el núcleo guarda el contexto de ejecución actual en un marco en la pila. ^{[ 5 ] [ 6 ]} La estructura que se inserta en la pila es una variante específica de la arquitectura de la estructura sigcontext , que contiene varios datos que comprenden el contenido de los registros en el momento del cambio de contexto. Cuando finaliza la ejecución del manejador de señales, sigreturn()se llama al sistema.

Llamar a la llamada al sistema sigreturn significa poder establecer fácilmente el contenido de los registros usando un solo gadget que se puede encontrar fácilmente en la mayoría de los sistemas. ^{[ 1 ]}

Existen varios factores que caracterizan un exploit SROP y lo distinguen de un exploit de programación orientada a retornos clásico. ^{[ 7 ]}

En primer lugar, ROP depende de los gadgets disponibles, que pueden ser muy diferentes en distintos binarios , lo que hace que las cadenas de gadgets no sean portátiles. La aleatorización del espacio de direcciones (ASLR) dificulta el uso de gadgets sin fugas de información para obtener sus posiciones exactas en la memoria.

Aunque existen compiladores ROP Turing-completos , ^{[ 8 ]} crear una cadena ROP suele ser no trivial. ^{[ 7 ]}

Los exploits SROP suelen ser portables entre diferentes binarios con un esfuerzo mínimo o nulo y permiten establecer fácilmente el contenido de los registros, lo que podría ser no trivial o inviable para los exploits ROP si no están presentes los gadgets necesarios. ^{[ 6 ]} Además, SROP requiere un número mínimo de gadgets y permite construir shellcodes efectivos encadenando llamadas al sistema. Estos gadgets siempre están presentes en la memoria y, en algunos casos, siempre están en ubicaciones fijas: ^{[ 7 ]}

Un ejemplo del tipo de dispositivo necesario para los exploits SROP siempre se puede encontrar en el área de memoria de objeto compartido dinámico virtual (VDSO) en sistemas Linux x86 :

__kernel_sigreturn proc cerca de : pop eax mov eax , 77h int 80h ; LINUX - sys_sigreturn nop lea esi , [ esi + 0 ] __kernel_sigreturn endp

En algunas versiones del kernel de Linux , ASLR se puede deshabilitar estableciendo el límite del tamaño de la pila en ilimitado, ^{[ 9 ]} evitando efectivamente ASLR y permitiendo un fácil acceso al gadget presente en un VDSO.

Para los núcleos de Linux anteriores a la versión 3.3, también es posible encontrar un gadget adecuado dentro de la página vsyscall, que es un mecanismo para acelerar el acceso a ciertas llamadas al sistema que suelen usar los programas antiguos y que siempre reside en una ubicación fija.

Es posible utilizar dispositivos para escribir en el contenido de los marcos de pila, construyendo así un programa automodificable . Mediante esta técnica, se puede diseñar una máquina virtual simple , que puede utilizarse como objetivo de compilación para un lenguaje Turing-completo . Un ejemplo de este enfoque se encuentra en el artículo de Bosman, que demuestra la construcción de un intérprete para un lenguaje similar al lenguaje de programación Brainfuck . El lenguaje proporciona un contador de programa PC, un puntero de memoria Py un registro temporal utilizado para la suma de 8 bits A. Esto significa que también se pueden diseñar puertas traseras complejas o ataques ofuscados. ^{[ 1 ]}

La aleatorización de la distribución del espacio de direcciones dificulta el uso de dispositivos adecuados, ya que hace que sus ubicaciones sean impredecibles.

Se ha propuesto una solución para SROP denominada cookies de señal . Consiste en verificar que la estructura sigcontext no ha sido alterada mediante una cookie aleatoria combinada con la dirección de la ubicación de la pila donde se almacenará. De esta forma, la llamada al sistema sigreturn solo necesita verificar la existencia de la cookie en la ubicación esperada, mitigando así SROP con un impacto mínimo en el rendimiento. ^{[ 1 ] [ 10 ]}

En versiones del kernel de Linux superiores a 3.3, se emula la interfaz vsyscall, y cualquier intento de ejecutar directamente gadgets en la página dará como resultado una excepción. ^{[ 11 ] [ 12 ]}

Grsecurity es un conjunto de parches para el kernel de Linux para fortalecer y mejorar la seguridad del sistema. ^{[ 13 ]} Incluye la denominada protección de dirección de retorno (RAP) para ayudar a proteger contra ataques de reutilización de código. ^{[ 14 ]}

A partir de 2016, Intel está desarrollando una tecnología de control de flujo ( CET ) para ayudar a mitigar y prevenir las vulnerabilidades de salto de pila. CET funciona implementando una pila en la memoria RAM que solo contendrá direcciones de retorno, protegida por la unidad de gestión de memoria de la CPU . ^{[ 15 ] [ 16 ]}