Memory Tagging Extension (MTE)

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Información básica

Memory Tagging Extension (MTE) está diseñada para mejorar la fiabilidad y la seguridad del software al detectar y prevenir errores relacionados con la memoria, como buffer overflows y use-after-free vulnerabilities. MTE, como parte de la arquitectura ARM, proporciona un mecanismo para adjuntar un tag pequeño a cada asignación de memoria y un tag correspondiente a cada pointer que referencia esa memoria. Este enfoque permite la detección de accesos ilegales a memoria en tiempo de ejecución, reduciendo significativamente el riesgo de explotar dichas vulnerabilidades para ejecutar código arbitrario.

Cómo funciona Memory Tagging Extension

MTE opera dividiendo la memoria en bloques pequeños de tamaño fijo, a cada uno de los cuales se le asigna un tag, típicamente de unos pocos bits.

Cuando se crea un pointer que apunta a esa memoria, obtiene el mismo tag. Este tag se almacena en los unused bits of a memory pointer, vinculando efectivamente el pointer con su bloque de memoria correspondiente.

https://www.youtube.com/watch?v=UwMt0e_dC_Q

Cuando un programa accede a la memoria a través de un pointer, el hardware MTE verifica que el tag del pointer coincida con el tag del bloque de memoria. Si los tags no coinciden, esto indica un acceso ilegal a memoria.

MTE Pointer Tags

Los tags dentro de un pointer se almacenan en 4 bits dentro del byte superior:

https://www.youtube.com/watch?v=UwMt0e_dC_Q

Por lo tanto, esto permite hasta 16 valores de tag diferentes.

MTE Memory Tags

Cada 16B of physical memory tiene un memory tag correspondiente.

Los memory tags se almacenan en una región de RAM dedicada (no accesible para uso normal). Tener tags de 4 bits por cada 16B de memoria supone hasta un 3% de la RAM.

ARM introduce las siguientes instrucciones para manipular estos tags en la memoria RAM dedicada:

STG [<Xn/SP>], #<simm>    Store Allocation (memory) Tag
LDG <Xt>, [<Xn/SP>]       Load Allocatoin (memory) Tag
IRG <Xd/SP>, <Xn/SP>      Insert Random [pointer] Tag
...

Checking Modes

Sync

La CPU comprueba las etiquetas durante la ejecución de la instrucción, si hay un desajuste genera una excepción (SIGSEGV con SEGV_MTESERR) y se conoce inmediatamente la instrucción y dirección exactas.
Esto es lo más lento y lo más seguro porque la carga/store ofensiva queda bloqueada.

Async

La CPU comprueba las etiquetas de forma asíncrona, y cuando se detecta un desajuste pone un bit de excepción en uno de los registros del sistema. Es más rápido que el anterior pero no puede señalar la instrucción exacta que causó el desajuste y no lanza la excepción inmediatamente (SIGSEGV con SEGV_MTEAERR), dando algo de tiempo al atacante para completar su ataque.

Mixed

Las preferencias por núcleo (por ejemplo escribir sync, async o asymm en /sys/devices/system/cpu/cpu*/mte_tcf_preferred) permiten que los kernels silenciosamente mejoren o degraden las peticiones por proceso, así que las compilaciones de producción suelen solicitar ASYNC mientras núcleos privilegiados fuerzan SYNC cuando la carga de trabajo lo permite.

Implementation & Detection Examples

Llamado Hardware Tag-Based KASAN, MTE-based KASAN o in-kernel MTE.
Los allocators del kernel (como kmalloc) llamarán a este módulo que preparará la tag a usar (aleatoriamente), la asociará al espacio de kernel asignado y al puntero devuelto.

Ten en cuenta que solo marcará suficientes granules de memoria (16B cada uno) para el tamaño solicitado. Así que si el tamaño solicitado fue 35 y se entregó un slab de 60B, marcará los primeros 16*3 = 48B con esta tag y el resto será marcado con la llamada invalid tag (0xE).

La tag 0xF es el match all pointer. Una memoria con este pointer permite que cualquier tag sea usada para acceder a su memoria (sin mismatches). Esto podría impedir que MTE detecte un ataque si esa tag está siendo usada en la memoria atacada.

Por lo tanto solo hay 14 valores que se pueden usar para generar tags ya que 0xE y 0xF están reservadas, dando una probabilidad de reutilizar tags de 1/17 -> alrededor del 7%.

Si el kernel accede al granule con la invalid tag, el mismatch será detectado. Si accede a otra ubicación de memoria y la memoria tiene una tag diferente (o la invalid tag) el mismatch también será detectado. Si el atacante tiene suerte y la memoria usa la misma tag, no será detectado. Las probabilidades son alrededor del 7%.

Otro bug ocurre en el último granule de la memoria asignada. Si la aplicación solicitó 35B, se le dio el granule de 32 a 48. Por lo tanto, los bytes de 36 a 47 usan la misma tag pero no fueron solicitados. Si el atacante accede a estos bytes extra, esto no se detecta.

Cuando se ejecuta kfree(), la memoria es retaggeada con la invalid memory tag, por lo que en un use-after-free, cuando la memoria es accedida de nuevo, el mismatch es detectado.

Sin embargo, en un use-after-free, si el mismo chunk es reasignado nuevamente con la misma tag que antes, un atacante podrá usar ese acceso y esto no será detectado (alrededor del 7% de probabilidad).

Además, sólo slab and page_alloc usan memoria etiquetada pero en el futuro esto también se usará en vmalloc, stack y globals (en el momento del video estos aún pueden ser abusados).

Cuando se detecta un mismatch el kernel hará panic para prevenir mayor explotación e intentos repetidos del exploit (MTE no tiene falsos positivos).

Speculative Tag Leakage (TikTag)

TikTag (2024) demostró dos gadgets de ejecución especulativa (TIKTAG-v1/v2) capaces de leak la etiqueta de asignación de 4 bits de cualquier dirección en <4 segundos con >95% de éxito. Al tocar especulativamente líneas de caché elegidas por el atacante y observar timings inducidos por prefetch, un atacante puede desaleatorizar la tag asignada a procesos de Chrome, servicios del sistema Android o el Linux kernel y luego construir pointers que lleven el leaked value. Una vez que el espacio de tags es brute-forceado, las suposiciones probabilísticas de reutilización de granules (≈7% tasa de falso negativo) colapsan y los exploits clásicos de heap (UAF, OOB) recuperan una fiabilidad cercana al 100% incluso con MTE habilitado. El paper también incluye proof-of-concept exploits que pivotan desde los leaked tags hacia retagging de fake slabs, ilustrando que los canales laterales especulativos siguen siendo una vía viable de bypass para los esquemas de hardware tagging.

References

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks