La programación orientada al retorno ( ROP ) es una técnica de explotación de seguridad informática que permite a un atacante ejecutar código en presencia de defensas de seguridad [1] [2] como la protección del espacio ejecutable y la firma de código . [3]
En esta técnica, un atacante obtiene el control de la pila de llamadas para secuestrar el flujo de control del programa y luego ejecuta secuencias de instrucciones de máquina cuidadosamente elegidas que ya están presentes en la memoria de la máquina, llamadas "gadgets". [4] [nb 1] Cada gadget generalmente termina en una instrucción de retorno y se encuentra en una subrutina dentro del programa existente y/o código de biblioteca compartida. [nb 1] Encadenados, estos gadgets permiten a un atacante realizar operaciones arbitrarias en una máquina empleando defensas que frustran ataques más simples.
DrawLineha sido llamada por DrawSquare. Observe que la pila crece hacia arriba en este diagrama.La programación orientada al retorno es una versión avanzada de un ataque de destrucción de pila . Generalmente, este tipo de ataques surgen cuando un adversario manipula la pila de llamadas aprovechando un error en el programa, a menudo un desbordamiento de búfer . En un desbordamiento de búfer, una función que no realiza una comprobación de límites adecuada antes de almacenar los datos proporcionados por el usuario en la memoria aceptará más datos de entrada de los que puede almacenar correctamente. Si los datos se escriben en la pila, el exceso de datos puede desbordar el espacio asignado a las variables de la función (por ejemplo, "locales" en el diagrama de pila a la derecha) y sobrescribir la dirección de retorno. Esta dirección será utilizada más tarde por la función para redirigir el flujo de control de vuelta al llamador . Si se ha sobrescrito, el flujo de control se desviará a la ubicación especificada por la nueva dirección de retorno.
En un ataque de desbordamiento de búfer estándar, el atacante simplemente escribiría el código de ataque (la "carga útil") en la pila y luego sobrescribiría la dirección de retorno con la ubicación de estas instrucciones recién escritas. Hasta fines de la década de 1990, los principales sistemas operativos no ofrecían ninguna protección contra estos ataques; Microsoft Windows no proporcionó protecciones contra desbordamientos de búfer hasta 2004. [5] Finalmente, los sistemas operativos comenzaron a combatir la explotación de errores de desbordamiento de búfer marcando la memoria donde se escriben los datos como no ejecutable, una técnica conocida como protección del espacio ejecutable . Con esto habilitado, la máquina se negaría a ejecutar cualquier código ubicado en áreas de memoria escribibles por el usuario, lo que evitaría que el atacante colocara la carga útil en la pila y saltara a ella mediante una sobrescritura de la dirección de retorno. Más tarde, se puso a disposición soporte de hardware para fortalecer esta protección.
Con la prevención de ejecución de datos, un adversario no puede ejecutar directamente las instrucciones escritas en un búfer porque la sección de memoria del búfer está marcada como no ejecutable. Para vencer esta protección, un ataque de programación orientada al retorno no inyecta instrucciones maliciosas, sino que utiliza secuencias de instrucciones ya presentes en la memoria ejecutable, llamadas "gadgets", manipulando las direcciones de retorno. Una implementación típica de prevención de ejecución de datos no puede defenderse contra este ataque porque el adversario no ejecuta directamente el código malicioso, sino que combina secuencias de instrucciones "buenas" modificando las direcciones de retorno almacenadas; por lo tanto, el código utilizado se marcaría como ejecutable.
La implementación generalizada de la prevención de ejecución de datos hizo que las vulnerabilidades tradicionales de desbordamiento de búfer fueran difíciles o imposibles de explotar de la manera descrita anteriormente. En cambio, un atacante estaba restringido al código que ya estaba en la memoria marcado como ejecutable, como el código del programa en sí y cualquier biblioteca compartida vinculada . Dado que las bibliotecas compartidas, como libc , a menudo contienen subrutinas para realizar llamadas al sistema y otras funciones potencialmente útiles para un atacante, son las candidatas más probables para encontrar código para ensamblar un ataque.
En un ataque de retorno a la biblioteca, un atacante secuestra el flujo de control del programa explotando una vulnerabilidad de desbordamiento de búfer, exactamente como se explicó anteriormente. En lugar de intentar escribir una carga útil de ataque en la pila, el atacante elige una función de biblioteca disponible y sobrescribe la dirección de retorno con su ubicación de entrada. Luego, se sobrescriben otras ubicaciones de la pila, obedeciendo las convenciones de llamada aplicables , para pasar cuidadosamente los parámetros adecuados a la función para que realice una funcionalidad útil para el atacante. Esta técnica fue presentada por primera vez por Solar Designer en 1997, [6] y luego se extendió al encadenamiento ilimitado de llamadas de función. [7]
La aparición de procesadores x86 de 64 bits trajo consigo un cambio en la convención de llamada de subrutinas que requería que los primeros argumentos de una función se pasaran en registros en lugar de en la pila. Esto significaba que un atacante ya no podía configurar una llamada a una función de biblioteca con los argumentos deseados simplemente manipulando la pila de llamadas a través de un exploit de desbordamiento de búfer. Los desarrolladores de bibliotecas compartidas también comenzaron a eliminar o restringir las funciones de biblioteca que realizaban acciones particularmente útiles para un atacante, como los envoltorios de llamadas del sistema . Como resultado, los ataques de retorno a la biblioteca se volvieron mucho más difíciles de realizar con éxito.
La siguiente evolución se produjo en forma de un ataque que utilizaba fragmentos de funciones de biblioteca, en lugar de funciones completas, para explotar vulnerabilidades de desbordamiento de búfer en máquinas con defensas contra ataques más simples. [8] Esta técnica busca funciones que contengan secuencias de instrucciones que extraigan valores de la pila y los introduzcan en registros. La selección cuidadosa de estas secuencias de código permite a un atacante colocar valores adecuados en los registros apropiados para realizar una llamada de función según la nueva convención de llamada. El resto del ataque se desarrolla como un ataque de retorno a la biblioteca.
La programación orientada al retorno se basa en el enfoque de fragmentos de código prestados y lo extiende para proporcionar una funcionalidad Turing-completa al atacante, incluidos bucles y ramas condicionales . [9] [10] Dicho de otra manera, la programación orientada al retorno proporciona un "lenguaje" completamente funcional que un atacante puede usar para hacer que una máquina comprometida realice cualquier operación deseada. Hovav Shacham publicó la técnica en 2007 [11] y demostró cómo se pueden simular todas las construcciones de programación importantes utilizando programación orientada al retorno contra una aplicación de destino vinculada con la biblioteca estándar de C y que contiene una vulnerabilidad de desbordamiento de búfer explotable.
Un ataque de programación orientada al retorno es superior a los otros tipos de ataque analizados, tanto en potencia expresiva como en resistencia a las medidas defensivas. Ninguna de las técnicas de contraexplotación mencionadas anteriormente, incluida la eliminación total de funciones potencialmente peligrosas de las bibliotecas compartidas, es eficaz contra un ataque de programación orientada al retorno.
Aunque los ataques de programación orientada al retorno se pueden realizar en una variedad de arquitecturas, [11] el artículo de Shacham y la mayoría del trabajo posterior se centran en la arquitectura x86 de Intel. La arquitectura x86 es un conjunto de instrucciones CISC de longitud variable . La programación orientada al retorno en x86 aprovecha el hecho de que el conjunto de instrucciones es muy "denso", es decir, es probable que cualquier secuencia aleatoria de bytes sea interpretable como un conjunto válido de instrucciones x86.
Por lo tanto, es posible buscar un código de operación que altere el flujo de control, en particular la instrucción de retorno (0xC3) y luego mirar hacia atrás en el binario para encontrar bytes anteriores que formen instrucciones posiblemente útiles. Estos conjuntos de "dispositivos" de instrucciones pueden encadenarse sobrescribiendo la dirección de retorno, mediante un exploit de desbordamiento de búfer, con la dirección de la primera instrucción del primer dispositivo. La primera dirección de los dispositivos posteriores se escribe entonces sucesivamente en la pila. Al finalizar el primer dispositivo, se ejecutará una instrucción de retorno, que sacará la dirección del siguiente dispositivo de la pila y saltará a él. Al finalizar ese dispositivo, la cadena continúa con el tercero, y así sucesivamente. Al encadenar las pequeñas secuencias de instrucciones, un atacante puede producir un comportamiento de programa arbitrario a partir de código de biblioteca preexistente. Shacham afirma que, dada cualquier cantidad suficientemente grande de código (incluida, entre otras, la biblioteca estándar de C), existirán suficientes dispositivos para la funcionalidad Turing-completa. [11]
Se ha desarrollado una herramienta automatizada para ayudar a automatizar el proceso de localización de dispositivos y la construcción de un ataque contra un binario. [12] Esta herramienta, conocida como ROPgadget, busca en un binario dispositivos potencialmente útiles e intenta ensamblarlos en una carga útil de ataque que genera un shell para aceptar comandos arbitrarios del atacante.
La aleatorización del diseño del espacio de direcciones también tiene vulnerabilidades. Según el artículo de Shacham et al., [13] el ASLR en arquitecturas de 32 bits está limitado por la cantidad de bits disponibles para la aleatorización de direcciones. Solo 16 de los 32 bits de dirección están disponibles para la aleatorización, y 16 bits de aleatorización de direcciones pueden ser derrotados por un ataque de fuerza bruta en minutos. Las arquitecturas de 64 bits son más robustas, con 40 de los 64 bits disponibles para la aleatorización. El ataque de fuerza bruta para la aleatorización de 40 bits es posible, pero es poco probable que pase desapercibido. [ cita requerida ] Además de los ataques de fuerza bruta, existen técnicas para eliminar la aleatorización .
Incluso con una aleatorización perfecta, si hay alguna fuga de información del contenido de la memoria, sería útil calcular la dirección base de, por ejemplo, una biblioteca compartida en tiempo de ejecución. [14]
Según el artículo de Checkoway et al., [15] es posible realizar programación orientada al retorno en arquitecturas x86 y ARM sin utilizar una instrucción de retorno (0xC3 en x86). En su lugar, utilizaron secuencias de instrucciones cuidadosamente diseñadas que ya existen en la memoria de la máquina para comportarse como una instrucción de retorno. Una instrucción de retorno tiene dos efectos: en primer lugar, lee el valor de cuatro bytes en la parte superior de la pila y establece el puntero de instrucción en ese valor, y en segundo lugar, aumenta el valor del puntero de pila en cuatro (equivalente a una operación pop). En la arquitectura x86, las secuencias de instrucciones jmp y pop pueden actuar como una instrucción de retorno. En ARM, las secuencias de instrucciones de carga y bifurcación pueden actuar como una instrucción de retorno.
Dado que este nuevo enfoque no utiliza una instrucción de retorno, tiene implicaciones negativas para la defensa. Cuando un programa de defensa no solo verifica varios retornos sino también varias instrucciones de salto, este ataque puede detectarse.
La técnica G-Free fue desarrollada por Kaan Onarlioglu, Leyla Bilge, Andrea Lanzi, Davide Balzarotti y Engin Kirda. Es una solución práctica contra cualquier forma posible de programación orientada al retorno. La solución elimina todas las instrucciones de rama libre no alineadas (instrucciones como RET o CALL que los atacantes pueden usar para cambiar el flujo de control) dentro de un ejecutable binario y protege las instrucciones de rama libre para que no sean utilizadas por un atacante. La forma en que G-Free protege la dirección de retorno es similar al canario XOR implementado por StackGuard. Además, verifica la autenticidad de las llamadas de función agregando un bloque de validación. Si no se encuentra el resultado esperado, G-Free hace que la aplicación se bloquee. [16]
Se han propuesto varias técnicas para subvertir los ataques basados en la programación orientada al retorno. [17] La mayoría se basan en aleatorizar la ubicación del código del programa y de la biblioteca, de modo que un atacante no pueda predecir con precisión la ubicación de las instrucciones que podrían ser útiles en los gadgets y, por lo tanto, no pueda montar una cadena de ataque de programación orientada al retorno exitosa. Una implementación bastante común de esta técnica, la aleatorización del diseño del espacio de direcciones (ASLR), carga bibliotecas compartidas en una ubicación de memoria diferente en cada carga de programa. Aunque se implementa ampliamente en los sistemas operativos modernos, la ASLR es vulnerable a los ataques de fuga de información y otros enfoques para determinar la dirección de cualquier función de biblioteca conocida en la memoria. Si un atacante puede determinar con éxito la ubicación de una instrucción conocida, se puede inferir la posición de todas las demás y se puede construir un ataque de programación orientada al retorno.
Este enfoque de aleatorización se puede llevar más lejos al reubicar todas las instrucciones y/o otros estados del programa (registros y objetos de pila) del programa por separado, en lugar de solo las ubicaciones de la biblioteca. [18] [19] [20] Esto requiere un amplio soporte en tiempo de ejecución, como un traductor dinámico de software, para volver a unir las instrucciones aleatorias en tiempo de ejecución. Esta técnica es exitosa para hacer que los gadgets sean difíciles de encontrar y utilizar, pero conlleva una sobrecarga significativa.
Otro enfoque, adoptado por kBouncer, modifica el sistema operativo para verificar que las instrucciones de retorno realmente desvían el flujo de control a una ubicación inmediatamente posterior a una instrucción de llamada. Esto evita el encadenamiento de gadgets, pero conlleva una gran penalización de rendimiento [ aclaración necesaria ] y no es eficaz contra ataques de programación orientada a saltos que alteran los saltos y otras instrucciones que modifican el flujo de control en lugar de los retornos. [21]
Algunos sistemas modernos, como Cloud Lambda (FaaS) y las actualizaciones remotas de IoT, utilizan la infraestructura de la nube para realizar una compilación sobre la marcha antes de la implementación del software. Una técnica que introduce variaciones en cada instancia de un programa de software en ejecución puede aumentar drásticamente la inmunidad del software a los ataques ROP. La fuerza bruta de Cloud Lambda puede provocar un ataque a varias instancias del software aleatorio, lo que reduce la eficacia del ataque. Asaf Shelly publicó la técnica en 2017 [22] y demostró el uso de la aleatorización binaria en un sistema de actualización de software. Para cada dispositivo actualizado, el servicio basado en la nube introdujo variaciones en el código, realizó una compilación en línea y envió el binario. Esta técnica es muy eficaz porque los ataques ROP se basan en el conocimiento de la estructura interna del software. El inconveniente de la técnica es que el software nunca se prueba por completo antes de su implementación porque no es posible probar todas las variaciones del software aleatorio. Esto significa que muchas técnicas de aleatorización binaria son aplicables para interfaces de red y programación de sistemas y son menos recomendadas para algoritmos complejos.
La protección de sobrescritura del controlador de excepciones estructurado es una característica de Windows que protege contra los ataques de desbordamiento de pila más comunes, especialmente contra ataques a un controlador de excepciones estructurado.
A medida que los sistemas integrados pequeños proliferan debido a la expansión de la Internet de las cosas , también aumenta la necesidad de protección de dichos sistemas integrados. Mediante el uso del control de acceso a memoria basado en instrucciones (IB-MAC) implementado en hardware, es posible proteger sistemas integrados de bajo costo contra ataques maliciosos de flujo de control y desbordamiento de pila. La protección se puede proporcionar separando la pila de datos y la pila de retorno. Sin embargo, debido a la falta de una unidad de gestión de memoria en algunos sistemas integrados, la solución de hardware no se puede aplicar a todos los sistemas integrados. [23]
En 2010, Jinku Li et al. propusieron [24] que un compilador modificado adecuadamente podría eliminar los "gadgets" orientados al retorno reemplazando cada uno con la secuencia de instrucciones y cada uno con la secuencia de instrucciones , donde representa una tabulación inmutable de todas las direcciones de retorno "legítimas" en el programa y representa un índice específico en esa tabla. [24] : 5–6 Esto evita la creación de un gadget orientado al retorno que regresa directamente desde el final de una función a una dirección arbitraria en el medio de otra función; en cambio, los gadgets solo pueden regresar a direcciones de retorno "legítimas", lo que aumenta drásticamente la dificultad de crear gadgets útiles. Li et al. afirmaron que "nuestra técnica de indirección de retorno esencialmente desgeneraliza la programación orientada al retorno al viejo estilo de retorno a libc". [24] Su compilador de prueba de concepto incluyó una fase de optimización de mirilla para lidiar con "ciertas instrucciones de máquina que contienen el código de operación de retorno en sus códigos de operación u operandos inmediatos", [24] como .call fpushl $index; jmp fretpopl %reg; jmp table(%reg)tableindexmovl $0xC3, %eax
La arquitectura ARMv8.3-A introduce una nueva característica a nivel de hardware que aprovecha los bits no utilizados en el espacio de direcciones del puntero para firmar criptográficamente las direcciones del puntero utilizando un cifrado de bloque ajustable especialmente diseñado [25] [26] que firma el valor deseado (normalmente, una dirección de retorno) combinado con un valor de "contexto local" (por ejemplo, el puntero de pila).
Antes de realizar una operación sensible (es decir, regresar al puntero guardado), se puede verificar la firma para detectar alteraciones o usos en un contexto incorrecto (por ejemplo, aprovechar una dirección de retorno guardada de un contexto de trampolín de explotación).
Cabe destacar que los chips Apple A12 utilizados en los iPhones se han actualizado a ARMv8.3 y utilizan PAC. Linux obtuvo soporte para la autenticación de puntero dentro del kernel en la versión 5.7 lanzada en 2020; el soporte para aplicaciones de espacio de usuario se agregó en 2018. [27]
En 2022, investigadores del MIT publicaron un ataque de canal lateral contra los PAC denominado PACMAN. [28]
La arquitectura ARMv8.5-A introduce otra característica nueva a nivel de hardware que identifica explícitamente los destinos válidos de las instrucciones de bifurcación. El compilador inserta una instrucción especial, un código de operación denominado "BTI", en cada punto de destino previsto de las instrucciones de bifurcación indirecta. Estos destinos de bifurcación identificados suelen incluir puntos de entrada de funciones y bloques de código de conmutación/caso.
Las instrucciones BTI se utilizan en páginas de memoria de código que están marcadas como "protegidas" por el compilador y el enlazador. Cualquier instrucción de bifurcación indirecta que llegue, en una página protegida, a cualquier instrucción que no sea una BTI genera un error.
Los destinos identificados donde se inserta una instrucción BTI representan aproximadamente el 1% de todas las instrucciones en el código de aplicación promedio. Por lo tanto, el uso de BTI aumenta el tamaño del código en la misma cantidad. [29]
Los gadgets que se utilizan en un ataque ROP se encuentran en cualquier parte del código de la aplicación. Por lo tanto, en promedio, el 99% de los gadgets comienzan con una instrucción que no es una BTI. La ramificación a estos gadgets, en consecuencia, da como resultado un error. Teniendo en cuenta que un ataque ROP está compuesto por una cadena de múltiples gadgets, la probabilidad de que todos los gadgets de una cadena formen parte del 1% que comienza con una BTI es muy baja.
PAC y BTI son mecanismos complementarios para prevenir inyecciones de código malicioso mediante ataques de programación orientados al retorno y al salto. Mientras que PAC se centra en el origen de una operación de bifurcación (un puntero con signo), BTI se centra en el destino de la bifurcación. [30]
Por ello, diseñamos QARMA, una nueva familia de cifrados de bloques ligeros y modificables.