Memory Tagging Extension (MTE)

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Basiese Inligting

Memory Tagging Extension (MTE) is ontwerp om sagteware-betroubaarheid en -veiligheid te verbeter deur geheuger-verwante foute op te spoor en te voorkom, soos buffer-oorvloei en gebruik-na-vry kwesbaarhede. MTE, as deel van die ARM-argitektuur, bied 'n meganisme om 'n klein etiket aan elke geheue-toewysing te heg en 'n ooreenstemmende etiket aan elke wyser wat na daardie geheue verwys. Hierdie benadering maak die opsporing van onwettige geheugentoegange tydens uitvoering moontlik, wat die risiko om sulke kwesbaarhede te benut vir die uitvoering van willekeurige kode aansienlik verminder.

Hoe Memory Tagging Extension Werk

MTE werk deur geheue in klein, vasgestelde blokke te verdeel, met elke blok wat 'n etiket toegewys kry, tipies 'n paar bietjies groot.

Wanneer 'n wyser geskep word om na daardie geheue te wys, kry dit dieselfde etiket. Hierdie etiket word gestoor in die ongebruikte bietjies van 'n geheue-wyser, wat die wyser effektief koppel aan sy ooreenstemmende geheueblok.

Wanneer 'n program geheue deur 'n wyser toegang, kontroleer die MTE-hardeware of die etiket van die wyser ooreenstem met die etiket van die geheueblok. As die etikette nie ooreenstem nie, dui dit op 'n onwettige geheue-toegang.

MTE Wysertekens

Tekens binne 'n wyser word gestoor in 4 bietjies binne die boonste byte:

Dit maak dus tot 16 verskillende etiketwaardes moontlik.

MTE Geheue-etikette

Elke 16B van fisiese geheue het 'n ooreenstemmende geheue-etiket.

Die geheue-etikette word gestoor in 'n toegewyde RAM-gebied (nie toeganklik vir normale gebruik nie). Met 4 bietjies etikette vir elke 16B geheue-etikette tot 3% van RAM.

ARM introduceer die volgende instruksies om hierdie etikette 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
...

Kontroleermodusse

Sync

Die CPU kontroleer die etikette tydens die instruksie-uitvoering, as daar 'n wanpassing is, veroorsaak dit 'n uitsondering. Dit is die stadigste en mees veilige.

Async

Die CPU kontroleer die etikette asinkroon, en wanneer 'n wanpassing gevind word, stel dit 'n uitsonderingsbit in een van die stelselregisters in. Dit is vinniger as die vorige een, maar dit is nie in staat om die presiese instruksie aan te dui wat die wanpassing veroorsaak nie en dit veroorsaak nie onmiddellik 'n uitsondering nie, wat die aanvaller tyd gee om sy aanval te voltooi.

Gemeng

???

Implementering & Opmerkingsvoorbeelde

Geroep Hardeware Etiket-Gebaseerde KASAN, MTE-gebaseerde KASAN of in-kernel MTE. Die kernel-allocators (soos kmalloc) sal hierdie module aanroep wat die etiket gereed maak om te gebruik (willekeurig) dit aan die toegewysde kernel-spasie heg en aan die teruggekeerde wyser.

Let daarop dat dit slegs genoeg geheuegranules sal merk (elk 16B) vir die gevraagde grootte. Dus as die gevraagde grootte 35 was en 'n slob van 60B gegee is, sal dit die eerste 16*3 = 48B met hierdie etiket merk en die res sal gemerk word met 'n sogenaamde ongeldige etiket (0xE).

Die etiket 0xF is die pas alle wyser. 'n Geheue met hierdie wyser laat toe dat enige etiket gebruik word om toegang tot sy geheue te verkry (geen wanpassings). Dit kan voorkom dat MET 'n aanval opspoor as hierdie etikette in die aangevalle geheue gebruik word.

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

As die kernel toegang tot die ongeldige etiket granule verkry, sal die wanpassing opgespoor word. As dit toegang tot 'n ander geheueplek verkry, as die geheue 'n ander etiket (of die ongeldige etiket) het, sal die wanpassing opgespoor word. As die aanvaller gelukkig is en die geheue dieselfde etiket gebruik, sal dit nie opgespoor word nie. Die kanse is ongeveer 7%.

'n Ander fout kom voor in die laaste granule van die toegewysde geheue. As die aansoek 35B versoek het, is die granule van 32 tot 48 gegee. Daarom gebruik die byte vanaf 36 tot 47 dieselfde etiket maar dit is nie aangevra nie. As die aanvaller toegang tot hierdie ekstra byte verkry, word dit nie opgespoor nie.

Wanneer kfree() uitgevoer word, word die geheue heretiketteer met die ongeldige geheue-etiket, sodat in 'n gebruik-na-vry, wanneer die geheue weer benader word, die wanpassing opgespoor word.

Tog, in 'n gebruik-na-vry, as dieselfde blok weer met dieselfde etiket toegewys word as voorheen, sal 'n aanvaller hierdie toegang kan gebruik en dit sal nie opgespoor word nie (ongeveer 7% kans).

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

Wanneer 'n wanpassing opgespoor word, sal die kernel paniek veroorsaak om verdere uitbuiting en herpogings van die aanval te voorkom (MTE het nie vals positiewe nie).

Verwysings

Last updated