Programación orientada al retorno

La implementación generalizada de la prevención de ejecución de datos dificultó o imposibilitó la explotación de las vulnerabilidades tradicionales de desbordamiento de búfer de la manera descrita anteriormente. En cambio, un atacante se vio limitado al código ya presente en la memoria y marcado como ejecutable, como el propio código del programa y las bibliotecas compartidas vinculadas . Dado que las bibliotecas compartidas, como libc , suelen contener subrutinas para realizar llamadas al sistema y otras funcionalidades potencialmente útiles para un atacante, son las candidatas más probables para encontrar código con el que 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, tal como se describió 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. Posteriormente, se sobrescriben otras ubicaciones de la pila, respetando las convenciones de llamada aplicables , para pasar cuidadosamente los parámetros adecuados a la función y que esta realice una funcionalidad útil para el atacante. Esta técnica fue presentada por primera vez por Solar Designer en 1997 ^{[ 6 ]} y posteriormente se extendió al encadenamiento ilimitado de llamadas a funciones ^{[ 7 ] .}

El auge de los procesadores x86 de 64 bits trajo consigo un cambio en la convención de llamada a 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 mediante una vulnerabilidad 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 al sistema . Como resultado, los ataques de retorno a la biblioteca se volvieron mucho más difíciles de ejecutar con éxito.

La siguiente evolución se presentó 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 extraen valores de la pila y los almacenan en registros. Una selección cuidadosa de estas secuencias de código permite al atacante colocar valores adecuados en los registros correspondientes para realizar una llamada a la función bajo la nueva convención de llamada. El resto del ataque se desarrolla como un ataque de retorno a la biblioteca.

Aunque los ataques de programación orientada a retorno pueden realizarse en diversas arquitecturas, ^{[ 11 ]} el artículo de Shacham y la mayoría de los trabajos posteriores se centran en la arquitectura Intel x86 . La arquitectura x86 es un conjunto de instrucciones CISC de longitud variable . La programación orientada a retorno en x86 aprovecha el hecho de que el conjunto de instrucciones es muy "denso", es decir, cualquier secuencia aleatoria de bytes puede interpretarse 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, especialmente la instrucción de retorno (0xC3), y luego buscar en el binario los bytes precedentes que formen instrucciones potencialmente útiles. Estos conjuntos de instrucciones, a modo de "dispositivos", pueden encadenarse sobrescribiendo la dirección de retorno, mediante una vulnerabilidad de desbordamiento de búfer, con la dirección de la primera instrucción del primer dispositivo. La primera dirección de los dispositivos subsiguientes se escribe sucesivamente en la pila. Al finalizar el primer dispositivo, se ejecuta una instrucción de retorno que extrae la dirección del siguiente dispositivo de la pila y salta 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 arbitrario del programa a partir de código de biblioteca preexistente. Shacham afirma que, con una cantidad suficientemente grande de código (incluida, entre otras, la biblioteca estándar de C), existirán suficientes dispositivos para lograr una funcionalidad Turing-completa. ^{[ 11 ]}

Se ha desarrollado una herramienta automatizada para ayudar a automatizar el proceso de localización de gadgets y la construcción de un ataque contra un binario. ^{[ 12 ]} Esta herramienta, conocida como ROPgadget, busca en un binario gadgets potencialmente útiles e intenta ensamblarlos en una carga útil de ataque que genere una shell para aceptar comandos arbitrarios del atacante.

La aleatorización del espacio de direcciones también presenta 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 estos 16 bits pueden ser vulnerados mediante 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. Un ataque de fuerza bruta contra la aleatorización de 40 bits es posible, pero es improbable que pase desapercibido. Además de los ataques de fuerza bruta, existen técnicas para eliminar la aleatorización .

Incluso con una aleatorización perfecta, cualquier fuga de información del contenido de la memoria ayudaría a 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 a retorno en arquitecturas x86 y ARM sin usar 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: primero, lee el valor de cuatro bytes en la parte superior de la pila y establece el puntero de instrucción a ese valor; y segundo, incrementa 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 load y branch 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 comprueba no solo varias instrucciones de retorno, sino también varias instrucciones de salto, este ataque puede ser detectado.

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 a retorno. La solución elimina todas las instrucciones de salto 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 dichas instrucciones 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 a funciones agregando un bloque de validación. Si no se encuentra el resultado esperado, G-Free provoca que la aplicación falle. ^{[ 16 ]}

Se han propuesto varias técnicas para contrarrestar los ataques basados ​​en la programación orientada a retornos. ^{[ 17 ]} La mayoría se basa 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 llevar a cabo una cadena de ataque de programación orientada a retornos exitosa. Una implementación bastante común de esta técnica, la aleatorización del espacio de direcciones (ASLR), carga las bibliotecas compartidas en una ubicación de memoria diferente en cada carga del programa. Aunque está ampliamente implementada por los sistemas operativos modernos, ASLR es vulnerable a 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, puede inferir la posición de todas las demás y construir un ataque de programación orientada a retornos.

Este enfoque de aleatorización puede ampliarse reubicando todas las instrucciones y/o demás estado del programa (registros y objetos de pila) 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 reconstruir las instrucciones aleatorizadas durante la ejecución. Esta técnica logra 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íen el flujo de control a una ubicación inmediatamente posterior a una instrucción de llamada. Esto evita el encadenamiento de gadgets, pero no es efectivo contra ataques de programación orientados 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 infraestructura en la nube para realizar compilaciones 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. El ataque de fuerza bruta a Cloud Lambda puede resultar en el ataque a varias instancias del software aleatorizado, lo que reduce la efectividad 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ó la compilación en línea y distribuyó el binario. Esta técnica es muy efectiva porque los ataques ROP se basan en el conocimiento de la estructura interna del software. La desventaja de la técnica es que el software nunca se prueba completamente antes de su implementación, ya que no es factible probar todas las variaciones del software aleatorizado. Esto significa que muchas técnicas de aleatorización binaria son aplicables a interfaces de red y programación de sistemas, y se recomiendan menos para algoritmos complejos.

La protección contra la sobrescritura del controlador de excepciones estructuradas es una función de Windows que protege contra los ataques de desbordamiento de pila más comunes, especialmente contra los ataques a un controlador de excepciones estructuradas.

A medida que proliferan los sistemas embebidos pequeños debido a la expansión del Internet de las Cosas , también aumenta la necesidad de protegerlos. Mediante el control de acceso a memoria basado en instrucciones (IB-MAC) implementado en hardware, es posible proteger los sistemas embebidos de bajo costo contra ataques maliciosos de flujo de control y desbordamiento de pila. Esta protección se logra separando la pila de datos de la pila de retorno. Sin embargo, debido a la falta de una unidad de gestión de memoria en algunos sistemas embebidos, la solución de hardware no se puede aplicar a todos ellos. ^{[ 23 ]}

En 2010, Jinku Li et al. propusieron ^{[ 24 ]} que un compilador adecuadamente modificado 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 del final de una función a una dirección arbitraria en 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 estilo antiguo de retorno a libc". ^{[ 24 ]} Su compilador de prueba de concepto incluyó una fase de optimización de mirilla para tratar 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 .callfpushl$index; jmpfretpopl%reg; jmptable(%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 de puntero para firmar criptográficamente las direcciones de puntero utilizando un cifrado de bloques ajustable especialmente diseñado ^{[ 25 ] [ 26 ]} que firma el valor deseado (típicamente, una dirección de retorno) combinado con un valor de "contexto local" (por ejemplo, el puntero de pila).

Antes de realizar una operación delicada (es decir, volver al puntero guardado), se puede comprobar la firma para detectar manipulaciones o usos en un contexto incorrecto (por ejemplo, aprovechar una dirección de retorno guardada desde un contexto de trampolín de explotación).

Los procesadores Apple Silicon desde el A12 se han actualizado a ARMv8.3 y utilizan PAC. Linux obtuvo soporte para la autenticación de punteros 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 ]}

ARMv8.5-A introdujo características a nivel de hardware para identificar explícitamente los destinos válidos de las instrucciones de salto. El compilador inserta una instrucción especial, con el código de operación "BTI", en cada punto de destino previsto de las instrucciones de salto indirecto . Estos destinos de salto identificados suelen incluir puntos de entrada de funciones y bloques de código switch/case.

Las instrucciones BTI se utilizan en páginas de memoria de código que el compilador y el enlazador marcan como "protegidas". Cualquier instrucción de salto indirecto que aterrice en una página protegida, en cualquier instrucción que no sea una BTI, genera un fallo.

Los destinos identificados donde se inserta una instrucción BTI representan aproximadamente el 1% de todas las instrucciones en el código de una aplicación promedio. Por lo tanto, el uso de BTI aumenta el tamaño del código en la misma cantidad. ^{[ 29 ]}

Los gadgets utilizados 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. En consecuencia, saltar a estos gadgets provoca un fallo. Dado que un ataque ROP se compone de 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 a retornos y saltos. Mientras que PAC se centra en el origen de una operación de salto (un puntero con signo), BTI se centra en el destino del salto. ^{[ 30 ]}