Memory Tagging Extension (MTE)

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

बुनियादी जानकारी

Memory Tagging Extension (MTE) सॉफ़्टवेयर की विश्वसनीयता और सुरक्षा बढ़ाने के लिए डिज़ाइन किया गया है, विशेष रूप से memory-related errors का पता लगाने और उन्हें रोकने के लिए, जैसे buffer overflows और use-after-free vulnerabilities. MTE, ARM आर्किटेक्चर का हिस्सा होने के नाते, एक ऐसी व्यवस्था प्रदान करता है जिसका उपयोग हर memory allocation पर छोटा टैग लगाने और उस मेमोरी को संदर्भित करने वाले हर pointer में संगत टैग जोड़ने के लिए किया जाता है। यह तरीका रनटाइम पर अवैध मेमोरी एक्सेस का पता लगाने की अनुमति देता है, जिससे ऐसे vulnerabilities का दुरुपयोग करके arbitrary code निष्पादित करने के जोखिम में काफी कमी आती है।

Memory Tagging Extension कैसे काम करता है

MTE काम करता है मेमोरी को छोटे, निश्चित-आकार के ब्लॉक्स में विभाजित करके, और प्रत्येक ब्लॉक को एक टैग असाइन करके, जो सामान्यतः कुछ bits का होता है।

जब उस मेमोरी को point करने के लिए एक pointer बनाया जाता है, तो उसे वही टैग मिलता है। यह टैग एक memory pointer के unused bits में स्टोर किया जाता है, जिससे pointer प्रभावी रूप से उसके संबंधित मेमोरी ब्लॉक से जुड़ जाता है।

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

जब कोई प्रोग्राम pointer के माध्यम से मेमोरी तक पहुँचता है, तो MTE हार्डवेयर जाँच करता है कि pointer का टैग मेमोरी ब्लॉक के टैग से मेल खाता है। यदि टैग्स मेल नहीं खाते, तो यह एक अवैध मेमोरी एक्सेस का संकेत होता है।

MTE Pointer Tags

Pointer के अंदर टैग्स ऊपरी बाइट में मौजूद 4 bits में स्टोर होते हैं:

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

इसलिए, यह अधिकतम 16 अलग-अलग टैग मानों की अनुमति देता है।

MTE मेमोरी टैग्स

प्रत्येक 16B of physical memory के लिए एक संबंधित memory tag होता है।

Memory tags को एक dedicated RAM region में स्टोर किया जाता है (सामान्य उपयोग के लिए पहुँच योग्य नहीं)। हर 16B के लिए 4-bit टैग होने के कारण यह RAM का लगभग 3% तक उपयोग कर सकता है।

ARM निम्नलिखित निर्देश प्रस्तुत करता है ताकि इन टैग्स को 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
...

Checking Modes

Sync

CPU टैग्स को instruction executing के दौरान चेक करता है, अगर mismatch होता है तो यह exception (SIGSEGV with SEGV_MTESERR) उठाता है और आप तुरंत सही instruction और address जान जाते हैं।
यह सबसे धीमा और सबसे सुरक्षित मोड है क्योंकि offending load/store ब्लॉक कर दिया जाता है।

Async

CPU टैग्स को asynchronously चेक करता है, और जब mismatch मिलता है तो यह system registers में से एक में एक exception bit सेट कर देता है। यह पिछले वाले की तुलना में तेज़ है पर यह ठीक उस instruction को इंगित नहीं कर पाता जिसने mismatch पैदा किया और यह तुरंत exception (SIGSEGV with SEGV_MTEAERR) नहीं उठाता, जिससे attacker को अपना attack पूरा करने के लिए कुछ समय मिल जाता है।

Mixed

Per-core preferences (उदाहरण के लिए /sys/devices/system/cpu/cpu*/mte_tcf_preferred में sync, async या asymm लिखने से) kernels per-process requests को silently upgrade या downgrade कर सकते हैं, इसलिए production builds आमतौर पर ASYNC request करते हैं जबकि privileged cores workload अनुमति देने पर SYNC मजबूर कर देते हैं।

Implementation & Detection Examples

Called Hardware Tag-Based KASAN, MTE-based KASAN or in-kernel MTE.
kernel allocators (जैसे kmalloc) इस module को call करेंगे जो उपयोग के लिए tag तैयार करेगा (randomly), उसे kernel space में allocated memory और returned pointer के साथ attach करेगा।

ध्यान दें कि यह केवल requested size के लिए पर्याप्त memory granules (प्रत्येक 16B) ही mark करेगा। इसलिए अगर requested size 35 था और 60B का slab दिया गया, तो यह पहले 16*3 = 48B को इस tag से mark करेगा और बाकी को invalid tag (0xE) से marked किया जाएगा।

tag 0xF वह match all pointer है। इस pointer वाले memory में किसी भी tag का उपयोग करके उसकी memory तक पहुँच संभव होती है (कोई mismatches नहीं)। अगर उस tag का उपयोग attacked memory में हो रहा हो तो यह MTE को attack detect करने से रोक सकता है।

इसलिए tag के जनरेट करने के लिए केवल 14 values ही उपयोग किए जा सकते हैं क्योंकि 0xE और 0xF reserved हैं, जिससे tags के reuse होने की probability 1/17 -> लगभग 7% रहती है।

अगर kernel invalid tag granule को access करता है तो mismatch detect हो जाएगा। अगर वह किसी अन्य memory location को access करता है और उस memory का tag अलग है (या invalid tag है) तो mismatch भी detect होगा। अगर attacker के पास किस्मत है और memory उसी tag का उपयोग कर रही है तो यह detect नहीं होगा। संभावना लगभग 7% है।

एक और बग allocated memory के last granule में होता है। अगर application ने 35B request किया, तो उसे 32 से 48 तक का granule दिया गया। इसलिए, bytes 36 से 47 तक वही tag उपयोग कर रहे हैं पर उन्हें request नहीं किया गया था। अगर attacker इन extra bytes को access करता है, तो यह detect नहीं होता।

जब kfree() execute किया जाता है, memory को invalid memory tag से retag किया जाता है, इसलिए एक use-after-free में जब memory फिर से access की जाती है तो mismatch detect हो जाएगा।

हालाँकि, use-after-free में अगर वही chunk फिर से SAME tag के साथ reallocated हो जाता है जैसा पहले था, तो attacker इस access का उपयोग कर पाएगा और यह detect नहीं होगा (लगभग 7% संभावना)।

इसके अलावा, केवल slab और page_alloc अभी tagged memory का उपयोग करते हैं पर भविष्य में यह vmalloc, stack और globals में भी उपयोग होगा (video के समय ये अभी भी abused किए जा सकते हैं)।

जब mismatch detect होता है kernel panic कर देगा ताकि आगे की exploitation और exploit के retries रोके जा सकें (MTE के false positives नहीं होते)।

Speculative Tag Leakage (TikTag)

TikTag (2024) ने दो speculative execution gadgets (TIKTAG-v1/v2) दिखाए जो किसी भी address का 4-bit allocation tag <4 seconds में >95% success के साथ leak करने में सक्षम थे। attacker चुनी हुई cache lines को speculatively touch करके और prefetch-induced timing को observe करके Chrome processes, Android system services, या Linux kernel को assigned tag को derandomize कर सकता है और फिर leaked value लेकर pointers craft कर सकता है। एक बार tag space brute-force होकर निकल जाए, probabilistic granule reuse assumptions (≈7% false-negative rate) collapse हो जाती हैं और classic heap exploits (UAF, OOB) MTE enabled होने पर भी लगभग 100% reliability के साथ काम करने लगते हैं। पेपर proof-of-concept exploits भी देता है जो leaked tags से fake slabs को retag करने तक pivot करते हैं, यह दर्शाते हुए कि speculative side channels hardware tagging schemes के लिए अभी भी viable bypass path बने हुए हैं।

References

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें