Memory Tagging Extension (MTE)

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Informações Básicas

Memory Tagging Extension (MTE) foi projetada para aumentar a confiabilidade e a segurança do software, detectando e prevenindo erros relacionados à memória, como buffer overflows e vulnerabilidades use-after-free. O MTE, como parte da arquitetura ARM, fornece um mecanismo para anexar uma pequena tag a cada alocação de memória e uma tag correspondente a cada ponteiro que referencia essa memória. Essa abordagem permite a detecção de acessos ilegais à memória em tempo de execução, reduzindo significativamente o risco de exploração dessas vulnerabilidades para execução de código arbitrário.

Como o Memory Tagging Extension Funciona

O MTE opera dividindo a memória em pequenos blocos de tamanho fixo, com cada bloco recebendo uma tag, tipicamente de poucos bits.

Quando um ponteiro é criado para apontar para essa memória, ele recebe a mesma tag. Essa tag é armazenada nos bits não utilizados de um ponteiro de memória, vinculando efetivamente o ponteiro ao bloco de memória correspondente.

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

Quando um programa acessa a memória através de um ponteiro, o hardware do MTE verifica se a tag do ponteiro corresponde à tag do bloco de memória. Se as tags não corresponderem, isso indica um acesso ilegal à memória.

MTE Pointer Tags

As tags dentro de um ponteiro são armazenadas em 4 bits dentro do byte superior:

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

Portanto, isso permite até 16 valores de tag diferentes.

MTE Memory Tags

A cada 16B de memória física corresponde uma tag de memória.

As tags de memória são armazenadas em uma região de RAM dedicada (não acessível para uso normal). Ter tags de 4 bits para cada 16B de memória consome até 3% da RAM.

ARM introduces the following instructions to manipulate these tags in the dedicated RAM memory:

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
...

Modos de Verificação

Sync

A CPU verifica as tags durante a execução da instrução, se houver um mismatch, ela lança uma exceção (SIGSEGV com SEGV_MTESERR) e você sabe imediatamente a instrução e o endereço exatos.
Este é o mais lento e o mais seguro porque a load/store ofensiva é bloqueada.

Async

A CPU verifica as tags assíncronamente, e quando um mismatch é encontrado ela seta um bit de exceção em um dos registradores do sistema. É mais rápido que o anterior mas é incapaz de apontar a instrução exata que causou o mismatch e não dispara a exceção imediatamente (SIGSEGV com SEGV_MTEAERR), dando algum tempo para o atacante completar seu ataque.

Mixed

Preferências por core (por exemplo escrevendo sync, async ou asymm em /sys/devices/system/cpu/cpu*/mte_tcf_preferred) permitem que kernels silenciosamente façam upgrade ou downgrade de requisições por processo, então builds de produção geralmente requicam ASYNC enquanto cores privilegiadas forçam SYNC quando a carga de trabalho permite.

Implementation & Detection Examples

Chamado Hardware Tag-Based KASAN, MTE-based KASAN ou in-kernel MTE.
Os kernel allocators (como kmalloc) vão chamar este módulo que preparará a tag a usar (aleatoriamente), a anexará ao espaço de memória do kernel alocado e ao ponteiro retornado.

Note que ele marcará apenas granules de memória suficientes (16B cada) para o tamanho solicitado. Então se o tamanho solicitado foi 35 e um slab de 60B foi dado, ele marcará os primeiros 16*3 = 48B com essa tag e o restante será marcado com a chamada invalid tag (0xE).

A tag 0xF é o match all pointer. Uma memória com este pointer permite que qualquer tag seja usada para acessar sua memória (sem mismatches). Isso pode impedir que MTE detecte um ataque se essa tag estiver sendo usada na memória atacada.

Portanto existem apenas 14 valores que podem ser usados para gerar tags já que 0xE e 0xF são reservados, dando uma probabilidade de reusar tags de 1/17 -> cerca de 7%.

Se o kernel acessar o invalid tag granule, o mismatch será detectado. Se acessar outra localização de memória e a memória tiver uma tag diferente (ou a invalid tag) o mismatch também será detectado. Se o atacante tiver sorte e a memória estiver usando a mesma tag, isso não será detectado. As chances são em torno de 7%.

Outro bug ocorre no último granule da memória alocada. Se a aplicação requisitou 35B, foi dado o granule de 32 a 48. Portanto, os bytes de 36 a 47 estão usando a mesma tag mas não foram requisitados. Se o atacante acessar esses bytes extras, isso não é detectado.

Quando kfree() é executado, a memória é retagged com a invalid memory tag, então em um use-after-free, quando a memória é acessada novamente, o mismatch é detectado.

Porém, em um use-after-free, se o mesmo chunk for realocado novamente com a MESMA tag que antes, um atacante será capaz de usar esse acesso e isso não será detectado (cerca de 7% de chance).

Além disso, apenas slab e page_alloc usam memória com tags mas no futuro isso também será usado em vmalloc, stack e globals (no momento do vídeo estes ainda podem ser abusados).

Quando um mismatch é detectado o kernel fará panic para prevenir exploração adicional e tentativas repetidas do exploit (MTE não tem falsos positivos).

Speculative Tag Leakage (TikTag)

TikTag (2024) demonstrou dois gadgets de execução especulativa (TIKTAG-v1/v2) capazes de leakar a tag de alocação de 4 bits de qualquer endereço em <4 segundos com >95% de sucesso. Ao tocar especulativamente linhas de cache escolhidas pelo atacante e observando timing induzido por prefetch, um atacante pode derandomizar a tag atribuída a processos do Chrome, serviços do sistema Android, ou o kernel Linux e então construir pointers carregando o valor leakado. Uma vez que o espaço de tags é bruto-forçado, as suposições probabilísticas de reuse de granule (≈7% taxa de falso-negativo) colapsam e exploits clássicos de heap (UAF, OOB) recuperam confiabilidade próxima de 100% mesmo quando MTE está habilitado. O paper também fornece proof-of-concept exploits que pivotam de tags leakadas para retagging de fake slabs, ilustrando que canais laterais especulativos continuam sendo um caminho viável de bypass para esquemas de tagging por hardware.

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks