Estudio Detalla Ataques Prácticos Que Eluden las Protecciones MTE en Chrome y Linux

Tabla de Enlaces

Resumen

1. Introducción

2. Antecedentes

• Extensión de Etiquetado de Memoria
• Ataque de Ejecución Especulativa

3. Modelo de Amenaza

4. Encontrar Gadgets de Fuga de Etiquetas

• Plantilla de Fuga de Etiquetas
• Fuzzing de Fuga de Etiquetas

5. Gadgets TIKTAG

• TIKTAG-v1: Explotación de Reducción de Especulación
• TIKTAG-v2: Explotación de Reenvío de Almacenamiento a Carga

6. Ataques del Mundo Real

6.1. Atacando Chrome

7. Evaluación

8. Trabajo Relacionado

9. Conclusión y Referencias

\

Ataques del Mundo Real

Para demostrar la explotabilidad de los gadgets TIKTAG en mitigación basada en MTE, esta sección desarrolla dos ataques del mundo real contra Chrome y el kernel de Linux (Figura 9). Existen varios desafíos al lanzar ataques del mundo real utilizando gadgets TIKTAG. Primero, los gadgets TIKTAG deben ejecutarse en el espacio de direcciones objetivo, lo que requiere que el atacante construya o encuentre gadgets del sistema objetivo. Segundo, el atacante debe controlar y observar el estado de caché para filtrar los resultados de verificación de etiquetas. A continuación, demostramos los ataques del mundo real utilizando gadgets TIKTAG en dos sistemas del mundo real: el navegador Google Chrome (§6.1) y el kernel de Linux (§6.2), y discutimos las estrategias de mitigación.

\ 6.1. Atacando Chrome

Navegador Un navegador web es una superficie de ataque principal para ataques basados en web, ya que procesa contenido web no confiable, como JavaScript y HTML. Primero revisamos el modelo de amenaza (§6.1.1) y proporcionamos un gadget TIKTAG construido en el motor JavaScript V8 (§6.1.2). Luego, demostramos la efectividad de los gadgets TIKTAG en la explotación del navegador (§6.1.3) y discutimos las estrategias de mitigación (§6.1.4).

\ ==6.1.1. Modelo de Amenaza.== Seguimos el modelo de amenaza típico de ataques al navegador Chrome, donde el atacante tiene como objetivo explotar vulnerabilidades de corrupción de memoria en el proceso renderizador. Asumimos que el usuario víctima visita el sitio web controlado por el atacante, que sirve una página web maliciosa. La página web incluye HTML y JavaScript elaborados, que explotan vulnerabilidades de corrupción de memoria en el proceso renderizador de la víctima. Asumimos que todas las técnicas de mitigación de vanguardia de Chrome están en su lugar, incluyendo ASLR [18], CFI [15], aislamiento de sitios [53] y sandbox V8 [56]. Además, como defensa ortogonal, asumimos que el proceso renderizador habilita etiquetado MTE aleatorio en PartitionAlloc [2].

\ ==6.1.2. Construyendo Gadget TIKTAG.== En el entorno JavaScript V8, TIKTAG-v2 se construyó con éxito y filtró las etiquetas MTE de cualquier dirección de memoria. Sin embargo, no encontramos un gadget TIKTAG-v1 construible, ya que la restricción de tiempo estrecha entre BR y CHECK no era factible en nuestra técnica de escape especulativo del sandbox V8 (§A).

Gadget V8 TikTag-v2. La Figura 8 es el gadget TIKTAG-v2 construido en el motor JavaScript V8 y su pseudocódigo C después de la compilación JIT. Con este gadget, el atacante puede saber si la etiqueta adivinada Tg coincide con la etiqueta Tm asignada a target_addr. El atacante prepara tres arrays, slow, victim, probe, y un valor idx. slow es un Unit8Array con una longitud de 64 y se accede en BR para activar la predicción de rama incorrecta. victim es un Float64Array con longitud 64, al que se accede para activar el reenvío de almacenamiento a carga. probe es un Uint8Array con longitud 512, y se accede en

\ TEST para filtrar el resultado de verificación de etiqueta. Un valor idx de tipo Number se utiliza en el acceso fuera de límites de victim. El valor idx se elige de manera que victim[idx] apunte a targetaddr con una etiqueta adivinada Tg (es decir, (Tg«56)|targetaddr). Para acceder especulativamente a target_addr fuera del sandbox V8, aprovechamos la técnica de escape especulativo del sandbox V8 que descubrimos durante nuestra investigación, que detallamos en §A. La línea 8 de la Figura 8a es el bloque BR del gadget TIKTAG-v2, activando la predicción de rama incorrecta con slow[0].

\ La línea 12-13 es el bloque CHECK, que realiza el reenvío de almacenamiento a carga con victim[idx], accediendo a target_addr con una etiqueta adivinada Tg. Cuando este código se compila JIT (Figura 8b), se realiza una verificación de límites, comparando idx contra victim.length. Si idx es un índice fuera de límites, el código devuelve undefined, pero si el campo victim.length tarda mucho en cargarse, la CPU ejecuta especulativamente las siguientes instrucciones de almacenamiento y carga.

\ Después de eso, la línea 17 implementa el bloque TEST, que accede a probe con el valor reenviado val como índice. Nuevamente, una verificación de límites en val contra la longitud de probe precede, pero esta verificación tiene éxito ya que PROBEOFFSET es menor que la longitud del array probe. Como resultado, probe[PROBEOFFSET] se almacena en caché solo cuando el reenvío de almacenamiento a carga tiene éxito, que es el caso cuando Tg coincide con Tm.

\ ==6.1.3. Ataque de bypass MTE a Chrome.== La Figura 9a ilustra el ataque general de bypass MTE en el navegador Chrome con primitiva arbitraria de fuga de etiquetas de gadgets TIKTAG. Asumimos una vulnerabilidad de desbordamiento de búfer en el proceso renderizador, donde explotar una vulnerabilidad temporal (por ejemplo, use-after-free) es en gran medida lo mismo. La vulnerabilidad desborda un puntero (es decir, vuln_ptr) a un objeto vulnerable (es decir, objvuln), corrompiendo el objeto adyacente (es decir, objtarget).

\ Con la aplicación de MTE de PartitionAlloc, dos objetos tienen etiquetas diferentes con una probabilidad de 14/15. Para evitar generar una excepción, el atacante necesita asegurar que las etiquetas de objvuln y objtarget sean las mismas. TIKTAG-v2 puede utilizarse para filtrar la etiqueta de objvuln ( 1 ) y objtarget ( 2 ). Si ambas etiquetas filtradas son iguales, el atacante explota la vulnerabilidad, que no generaría un fallo de verificación de etiqueta ( 3 ). De lo contrario, el atacante libera y reasigna objtarget y vuelve al primer paso hasta que las etiquetas coincidan.

\ ==Activación de Canal Lateral de Caché.== Para explotar con éxito un gadget TIKTAG, el atacante necesita satisfacer los siguientes requisitos:

i) entrenamiento de rama,

ii) control de caché, y

iii) medición de caché. Los tres requisitos pueden cumplirse en JavaScript.

Primero, el atacante puede entrenar el predictor de rama ejecutando el gadget con slow[0] distinto de cero e idx dentro de límites, y activar la predicción de rama incorrecta en BR con valor cero en slow[0] e idx fuera de límites.

Segundo, el atacante puede desalojar las líneas de caché de slow[0], victim.length y probe[PROBE_OFFSET] con técnicas de desalojo de caché de JavaScript [8, 21, 70].

Tercero, el atacante puede medir el estado de caché de probe[PROBE_OFFSET] con un temporizador de alta resolución basado en SharedArrayBuffer [16, 58].

\ ==Explotación de Vulnerabilidades de Corrupción de Memoria.== Dadas las etiquetas MTE filtradas, el atacante puede explotar vulnerabilidades de corrupción de memoria espaciales y temporales en el renderizador. La estrategia de ataque es en gran medida la misma que los ataques tradicionales de corrupción de memoria, pero debe asegurar que la vulnerabilidad no genere un fallo de verificación de etiqueta utilizando las etiquetas filtradas. Detallamos más la estrategia de ataque en §C.

\ ==6.1.4. Mitigación.== Para mitigar los ataques de bypass MTE basados en gadgets TIKTAG en el proceso renderizador del navegador, se pueden emplear las siguientes mitigaciones:

i) Sandbox consciente de ejecución especulativa: Para evitar que los atacantes lancen ataques basados en TIKTAG desde un entorno en sandbox como el sandbox V8, el sandbox puede fortificarse previniendo cualquier acceso especulativo a memoria más allá de la región de memoria del sandbox. Mientras que los navegadores web modernos emplean un sandbox para aislar contenidos web no confiables del renderizador, a menudo pasan por alto las rutas especulativas.

\ Por ejemplo, el sandbox Chrome V8 [56] y el sandbox Safari Webkit [1] no median completamente las rutas especulativas [27]. Basándose en las técnicas actuales de compresión de punteros [64], las rutas especulativas pueden restringirse a la región del sandbox enmascarando los bits altos de los punteros.

\ ii) Barrera de especulación: Como se sugiere en §5, colocar una barrera de especulación después de BR para posibles gadgets TIKTAG puede prevenir ataques de fuga especulativa de etiquetas. Sin embargo, esta mitigación puede no ser aplicable en el entorno crítico de rendimiento del navegador, ya que puede introducir una sobrecarga de rendimiento significativa.

\ iii) Prevención de construcción de gadget: Como se sugiere en §5.2, el gadget TIKTAG-v2 puede mitigarse rellenando instrucciones entre instrucciones de almacenamiento y carga. Un gadget TIKTAGv1, aunque no hemos encontrado uno explotable, puede mitigarse rellenando instrucciones entre una rama y accesos a memoria, como se describe en §5.1.

\ 6.2. Atacando el Kernel de Linux

El kernel de Linux en ARM se utiliza ampliamente para dispositivos móviles, servidores y dispositivos IoT, convirtiéndolo en un objetivo de ataque atractivo. Explotar una vulnerabilidad de corrupción de memoria en el kernel puede escalar el privilegio del usuario, y por lo tanto MTE es un mecanismo de protección prometedor para el kernel de Linux. Los ataques basados en TIKTAG contra el kernel de Linux presentan desafíos únicos diferentes del ataque al navegador (§6.1).

\ Esto se debe a que el espacio de direcciones del atacante está aislado del espacio de direcciones del kernel donde se ejecutará el gadget. A continuación, primero revisamos el modelo de amenaza del kernel de Linux (§6.2.1) y proporcionamos un gadget TIKTAG de prueba de concepto que descubrimos en el kernel de Linux (§6.2.2). Finalmente, demostramos la efectividad de los gadgets TIKTAG en la explotación de vulnerabilidades del kernel de Linux (§6.2.3).

\ ==6.2.1. Modelo de Amenaza.== El modelo de amenaza aquí es en gran medida el mismo que el de los ataques típicos de escalada de privilegios contra el kernel. Específicamente, nos enfocamos en el kernel Linux Android basado en ARM, reforzado con protecciones de kernel predeterminadas (por ejemplo, KASLR, SMEP, SMAP y CFI). Además, asumimos que el kernel está reforzado con una solución de etiquetado aleatorio MTE, similar a las soluciones MTE listas para producción, Scudo [3].

\ Para ser específico, cada objeto de memoria está etiquetado aleatoriamente, y se asigna una etiqueta aleatoria cuando se libera un objeto, previniendo así tanto corrupciones de memoria espaciales como temporales. El atacante es capaz de ejecutar un proceso sin privilegios y tiene como objetivo escalar su privilegio explotando vulnerabilidades de corrupción de memoria en el kernel. Se asume que el atacante conoce vulnerabilidades de corrupción de memoria del kernel pero no conoce ninguna etiqueta MTE de la memoria del kernel. Activar corrupción de memoria entre objetos del kernel con

\ etiquetas no coincidentes generaría un fallo de verificación de etiqueta, lo cual es indeseable para exploits del mundo real. Un desafío crítico en este ataque es que el gadget debe construirse reutilizando el código del kernel existente y ejecutarse mediante las llamadas al sistema que el atacante puede invocar. Como la arquitectura ARMv8 separa las tablas de páginas de usuario y kernel, los gadgets del espacio de usuario no pueden acceder especulativamente a la memoria del kernel. Esta configuración es muy diferente del modelo de amenaza de atacar el navegador (§6.1), que aprovechó el código proporcionado por el atacante para construir el gadget. También excluimos la construcción de gadgets basada en eBPF [17, 28], porque eBPF no está disponible para el proceso Android sin privilegios [33].

\ ==6.2.2. Gadget TikTag del Kernel==. Como se describe en §4.1, los gadgets TIKTAG deben cumplir varios requisitos, y cada requisito conlleva desafíos en el entorno del kernel.

Primero, en BR, debe activarse una predicción de rama incorrecta con cond_ptr, que debe ser controlable desde el espacio de usuario. Dado que los procesadores AArch64 recientes aíslan el entrenamiento de predicción de rama entre el usuario y el kernel [33], el entrenamiento de rama debe realizarse desde el espacio del kernel.

Segundo, en CHECK, guessptr debe desreferenciarse. guessptr debe elaborarse desde el espacio de usuario de manera que incruste una etiqueta de suposición (Tg) y apunte a la dirección del kernel (es decir, target_addr) para filtrar la etiqueta (Tm). A diferencia del entorno JavaScript del navegador (§6.1), los datos proporcionados por el usuario están fuertemente sanitizados en las llamadas al sistema, por lo que es difícil crear un puntero de kernel arbitrario.

\ Por ejemplo, accessok() asegura que el puntero proporcionado por el usuario apunte al espacio de usuario, y la macro arrayindexnospec previene el acceso especulativo fuera de límites con el índice proporcionado por el usuario. Por lo tanto, guessptr debe ser un puntero de kernel existente, específicamente el puntero vulnerable que causa corrupción de memoria. Por ejemplo, puede usarse un puntero colgante en use-after-free (UAF) o un puntero fuera de límites en desbordamiento de búfer. Por último, en TEST, testptr debe desreferenciarse, y testptr debe ser accesible desde el espacio de usuario. Para facilitar la medición del estado de caché, test_ptr debe ser un puntero del espacio de usuario proporcionado a través de un argumento de llamada al sistema.

\ ==Gadgets Descubiertos.== Analizamos manualmente el código fuente del kernel de Linux para encontrar el gadget TIKTAG que cumple con los requisitos mencionados. Como resultado, encontramos un gadget TIKTAG-v1 potencialmente explotable en sndtimeruserread() (Figura 10). Este gadget cumple con los requisitos de TIKTAG-v1 (§5.1). En la línea 10 (es decir, BR), la declaración switch activa la predicción de rama incorrecta con un valor controlable por el usuario tu->tread (es decir, condptr). En las líneas 14-17 (es decir, CHECK), tread (es decir, guessptr) se desreferencia mediante cuatro instrucciones de carga. tread apunta a un objeto struct sndtimer_tread64 que el atacante puede asignar y liberar arbitrariamente.

\ Si una vulnerabilidad temporal transforma tread en un puntero colgante, puede usarse como guessptr. En la línea 20, (es decir, TEST), un puntero de espacio de usuario buffer (es decir, testptr) se desreferencia en copytouser. Como este gadget no es directamente alcanzable desde el espacio de usuario, hicimos una ligera modificación al código del kernel; eliminamos el retorno anticipado para el caso predeterminado en la línea 6. Esto asegura que solo se acceda al búfer en la ruta especulativa para observar la diferencia de estado de caché debido a la ejecución especulativa.

\ Aunque esta modificación no es realista en un escenario del mundo real, demuestra la explotabilidad potencial del gadget si se realizan cambios de código similares. Descubrimos varios gadgets más potencialmente explotables, pero no pudimos observar la diferencia de estado de caché entre la coincidencia y no coincidencia de etiquetas. Aún así, pensamos que hay un fuerte potencial para explotar esos gadgets. Lanzar ataques basados en TIKTAG implica ingeniería compleja y sensible, y por lo tanto no pudimos experimentar con todos los casos posibles.

\ Especialmente, TIKTAG-v1 depende de la reducción de especulación en eventos de ruta incorrecta, que también pueden incluir fallos de traducción de direcciones u otras excepciones en la ruta de predicción de rama incorrecta. Como las llamadas al sistema implican flujos de control complejos, la reducción de especulación puede no activarse como se espera. Además, varios gadgets pueden volverse explotables cuando cambia el código del kernel. Por ejemplo, un gadget TIKTAG-v1 en ip6mr_ioctl() no exhibió un comportamiento de fuga de etiqueta MTE cuando se llamó desde su ruta de llamada al sistema (es decir, ioctl). Sin embargo, el gadget tuvo fuga de etiqueta cuando se portó a otras syscalls (por ejemplo, write) con un flujo de control simple.

\ ==6.2.3. Ataque de bypass MTE del Kernel.== La Figura 9b ilustra los ataques de bypass MTE en el kernel de Linux. Tomando una vulnerabilidad use-afterfree como ejemplo, asumimos que el atacante ha identificado un gadget TIKTAG correspondiente, SysTikTagUAF(), capaz de filtrar el resultado de verificación de etiqueta del puntero colgante creado por la vulnerabilidad. Por ejemplo, el gadget TIKTAG-v1 en sndtimeruser_read() (Figura 10) puede filtrar el resultado de verificación de etiqueta de tread, que puede convertirse en un puntero colgante por una vulnerabilidad use-after-free o double-free.

\ El ataque procede de la siguiente manera: Primero, el atacante libera un objeto del kernel (es decir, objvuln) y deja su puntero (es decir, vuln_ptr) como un puntero colgante ( 1 ). A continuación, el atacante asigna otro objeto del kernel (es decir, objtarget) en la dirección de objvuln con SysAllocTarget() ( 2 ). Luego, el atacante invoca SysTikTag() con un búfer del espacio de usuario (es decir, ubuf) ( 3 ), y filtra el resultado de verificación de etiqueta (es decir, Tm == Tg) midiendo la latencia de acceso de ubuf ( 4 ). Si las etiquetas coinciden, el atacante activa SysExploitUAF(), una llamada al sistema que explota la vulnerabilidad use-after-free ( 5 ). De lo contrario, el atacante reasigna objtarget hasta que las etiquetas coincidan.

\ ==Activación de Canal Lateral de Caché.== Como en §6.1.3, una explotación exitosa del gadget TIKTAG requiere i) entrenamiento de rama, ii) control de caché, y iii) medición de caché. Para el entrenamiento de rama, el atacante puede entrenar el predictor de rama y activar la especulación con condiciones de rama controladas por el usuario desde el espacio de usuario. Para el control de caché, el atacante puede vaciar el búfer del espacio de usuario (es decir, ubuf), mientras que la dirección de memoria del kernel puede desalojarse mediante rebote de línea de caché [25]. Para la medición de caché, la latencia de acceso de ubuf puede medirse con el contador virtual (es decir, CNTVCT_EL0) o un temporizador basado en contador de memoria (es decir, resolución cercana al ciclo de CPU).

\ ==Explotación de Vulnerabilidades de Corrupción de Memoria.== Los gadgets TIKTAG permiten omitir MTE y explotar vulnerabilidades de corrupción de memoria del kernel. El atacante puede invocar el gadget TIKTAG en el kernel para activar especulativamente la corrupción de memoria y obtener el resultado de verificación de etiqueta. Luego, el atacante puede obtener el resultado de verificación de etiqueta, y activar la corrupción de memoria solo si las etiquetas coinciden. Detallamos el proceso de ataque de bypass MTE del kernel Linux en §D.

\ ==6.2.4. Mitigación.== Para mitigar el gadget TIKTAG en el kernel de Linux, los desarrolladores del kernel deben considerar las siguientes mitigaciones:

i) Barrera de especulación: Las barreras de especulación pueden mitigar efectivamente el gadget TIKTAG-v1 en el kernel de Linux. Para evitar que los atacantes filtren el resultado de verificación de etiqueta a través del búfer del espacio de usuario, las funciones del kernel que acceden a direcciones del espacio de usuario, como copytouser y copyfromuser, pueden reforzarse con barreras de especulación. Como se describe en §5.1, la filtración de resultados de verificación de etiqueta con acceso de almacenamiento puede mitigarse colocando una barrera de especulación antes del acceso de almacenamiento (es decir, TEST).

\ Por ejemplo, para mitigar los gadgets que aprovechan copytouser, puede insertarse una barrera de especulación antes de la invocación de copytouser. Para gadgets que utilizan acceso de carga al búfer del espacio de usuario, las barreras mitigan los gadgets si se insertan entre la rama y el acceso a memoria del kernel (es decir, CHECK). Por ejemplo, para mitigar los gadgets que aprovechan copyfromuser, los desarrolladores del kernel deben analizar cuidadosamente la base de código del kernel para encontrar el patrón de la rama condicional, el acceso a memoria del kernel y copyfromuser(), e insertar una barrera de especulación entre la rama y el acceso a memoria del kernel.

\ ii) Prevención de construcción de gadget: Para eliminar posibles gadgets TIKTAG en el kernel de Linux, el código fuente del kernel puede analizarse y parchearse. Como los gadgets TIKTAG también pueden construirse mediante optimizaciones del compilador, puede realizarse un análisis binario. Para cada gadget descubierto, las instrucciones pueden reordenarse o pueden insertarse instrucciones adicionales para prevenir la construcción del gadget, siguiendo las estrategias de mitigación en §5.1 y §5.2.

:::info Autores:

1. Juhee Kim
2. Jinbum Park
3. Sihyeon Roh
4. Jaeyoung Chung
5. Youngjoo Lee
6. Taesoo Kim
7. Byoungyoung Lee

:::

:::info Este documento está disponible en arxiv bajo licencia CC 4.0.

:::

\