Memory Tagging Extension (MTE)

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese Inligting

Memory Tagging Extension (MTE) is ontwerp om sagtewarebetroubaarheid en sekuriteit te verbeter deur geheueverwante foute op te spoor en te voorkom, soos buffer overflows en use-after-free vulnerabilities. MTE, as deel van die ARM-argitektuur, bied ’n meganisme om ’n klein tag aan elke geheue-allokasie te heg en ’n ooreenstemmende tag aan elke pointer wat na daardie geheue verwys. Hierdie benadering stel in staat om onwettige geheue-toegange tydens uitvoering op te spoor en verminder die risiko om sulke kwetsbaarhede te misbruik vir die uitvoering van arbitrary code aansienlik.

Hoe Memory Tagging Extension Werk

MTE werk deur die geheue te verdeel in klein, vaste-grootte blokke, waarbij elke blok ’n tag toegeken kry, gewoonlik ’n paar bits groot.

Wanneer ’n pointer geskep word wat na daardie geheue verwys, kry dit dieselfde tag. Hierdie tag word in die ongebruikte bits van ’n memory pointer gestoor, wat die pointer effektief aan sy ooreenstemmende geheueblok koppel.

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

Wanneer ’n program geheue deur ’n pointer benader, kontroleer die MTE-hardware dat die pointer’s tag ooreenstem met die memory block’s tag. As die tags nie ooreenstem nie, dui dit op ’n onwettige geheue-toegang.

MTE Pointer Tags

Tags binne ’n pointer word in 4 bits gestoor binne die top byte:

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

Daarom laat dit toe om tot 16 verskillende tagwaardes te hê.

MTE Memory Tags

Elke 16B van fisiese geheue het ’n ooreenstemmende memory tag.

Die memory tags word in ’n toegewyde RAM-gebied gestoor (nie toeganklik vir normale gebruik nie). Met 4bits tags vir elke 16B geheue neem dit tot 3% van die RAM in beslag.

ARM stel die volgende instruksies bekend om hierdie tags in die toegewyde RAM-geheue te manipuleer:

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

Kontrolemodusse

Sync

Die CPU kontroleer die tags terwyl die instruksie uitgevoer word, indien daar ’n wanpasser is, sal dit ’n uitsondering gooi (SIGSEGV met SEGV_MTESERR) en jy weet onmiddellik die presiese instruksie en adres.
Dit is die stadigste en die veiligste omdat die oortredende load/store geblokkeer word.

Async

Die CPU kontroleer die tags asynchroon, en wanneer ’n wanpasser gevind word, stel dit ’n uitsonderingsbit in een van die stelselregisters. Dit is vurder as die vorige, maar dit is nie in staat om die presiese instruksie aan te dui wat die wanpasser veroorsaak het nie en dit gooi nie onmiddellik die uitsondering nie (SIGSEGV met SEGV_MTEAERR), wat vir die aanvaller tyd gee om sy aanval te voltooi.

Mixed

Per-kern voorkeure (byvoorbeeld om sync, async of asymm na /sys/devices/system/cpu/cpu*/mte_tcf_preferred te skryf) laat kernels stilweg per-proses versoeke op- of afgradeer, so produksieboues versoek gewoonlik ASYNC terwyl bevoorregte kerne SYNC afdwing wanneer die werklading dit toelaat.

Implementering & Opsporingsvoorbeelde

Noem dit Hardware Tag-Based KASAN, MTE-based KASAN of in-kernel MTE.
Die kernel-allocators (soos kmalloc) sal hierdie module aanroep wat die tag sal voorberei om te gebruik (lukraak), dit aan die toegekende kernel-ruimte en aan die teruggegewe pointer heg.

Neem kennis dat dit slegs genoeg geheue-granules sal merk (16B elk) vir die versoekte grootte. Dus as die versoek 35 was en ’n slab van 60B gegee is, sal dit die eerste 16*3 = 48B met hierdie tag merk en die res sal met ’n sogenaamde invalid tag (0xE) gemerk word.

Die tag 0xF is die match all pointer. Geheue met hierdie pointer laat toe dat enige tag gebruik kan word om daardie geheue te benader (geen wanpassers nie). Dit kan verhoed dat MTE ’n aanval opspoor as daardie tag in die geteikende geheue gebruik word.

Daar is dus slegs 14 waardes wat gebruik kan word om tags te genereer aangesien 0xE en 0xF gereserveer is, wat ’n waarskynlikheid van hergebruik van tags gee van 1/17 -> ongeveer 7%.

As die kernel die invalid tag granule benader, sal die wanpasser gedetekteer word. As dit ’n ander geheue-ligging benader en die geheue ’n ander tag het (of die invalid tag), sal die wanpasser ook gedetekteer word. As die aanvaller gelukkig is en die geheue gebruik dieselfde tag, sal dit nie gedetekteer word nie. Kans is rondom 7%.

Nog ’n fout gebeur in die laaste granule van die toegekende geheue. As die aansoek 35B versoek het, is dit die granule van 32 tot 48 gegee. Dus gebruik die bytes van 36 tot 47 dieselfde tag maar hulle was nie versoek nie. As die aanvaller hierdie ekstra bytes benader, word dit nie gedetekteer nie.

Wanneer kfree() uitgevoer word, word die geheue hergetag met die invalid memory tag, so in ’n use-after-free, wanneer die geheue weer benader word, word die wanpasser gedetekteer.

Echter, in ’n use-after-free, as dieselfde chunk weer heralloceer word met dieselfde tag as voorheen, sal ’n aanvaller hierdie toegang kan gebruik en dit sal nie gedetekteer word nie (ongeveer 7% kans).

Verder gebruik slegs slab en page_alloc getagde geheue, maar in die toekoms sal dit ook in vmalloc, stack en globals gebruik word (op die tyd van die video kan hierdie steeds misbruik word).

Wanneer ’n wanpasser gedetekteer word, sal die kernel panic om verdere eksploitasie en nuwe poging tot die exploit te voorkom (MTE het geen vals positiewe nie).

Speculative Tag Leakage (TikTag)

TikTag (2024) het twee speculative execution gadgets (TIKTAG-v1/v2) gedemonstreer wat in staat is om die 4-bit toewysingstag van enige adres in <4 sekondes te leak met >95% sukses. Deur spekulatief aanvaller-gekose cache-lyne aan te raak en prefetch-induced timing te observeer, kan ’n aanvaller die tag wat aan Chrome-processes, Android system services, of die Linux kernel toegekend is derandomize en dan pointers bou wat die leaked waarde dra. Sodra die tag-ruimte deur brute-force uitgeput is, stort die probabilistiese granule-hergebruik-veronderstelling (≈7% vals-negatiewe koers) in en klassieke heap exploits (UAF, OOB) herwin byna 100% betroubaarheid selfs wanneer MTE geaktiveer is. Die artikel bevat ook proof-of-concept exploits wat van leaked tags na retagging fake slabs skuif, wat illustreer dat speculative side channels steeds ’n lewensvatbare omseilpad vir hardware tagging skemas bly.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks