MTE फीचर सक्षम Pixel 8 पर kernel code execution अधिकार हासिल करना

 (github.blog)
1 पॉइंट द्वारा GN⁺ 2024-03-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CVE-2023-6241 Arm Mali GPU memory management unit में एक logic bug है, जिससे malicious Android app kernel MTE चालू Pixel 8 पर भी arbitrary kernel code execution और root privileges हासिल कर सकता है
  • प्रभावित डिवाइस वे latest Arm Mali GPU devices हैं जो Command Stream Frontend(CSF) का उपयोग करते हैं, जिनमें Google Pixel 7 और Pixel 8 शामिल हैं
  • vulnerability JIT memory विस्तार के दौरान lock खुलने वाली छोटी अवधि का फायदा उठाकर GPU mapping और backing page array के बीच inconsistency बनाने के तरीके से काम करती है
  • exploit freed backing page में बचे GPU mapping का उपयोग करता है, उस page को GPU context के PGD के रूप में reuse करवाता है, फिर kernel memory और kernel code को map करता है
  • MTE pointer और memory tag mismatch पकड़ता है, लेकिन यह attack flow GPU द्वारा physical address को सीधे access करने के कारण MTE protection scope के बाहर आगे बढ़ता है

vulnerability scope और patch status

  • CVE-2023-6241 Arm Mali GPU vulnerability है, जिससे malicious Android app device पर arbitrary kernel code execution और root privileges पा सकता है
  • इसे 15 नवंबर 2023 को Arm को report किया गया था, और 14 दिसंबर 2023 को publicly released Arm Mali driver r47p0 में fix किया गया
  • Android fixes मार्च 2024 security update में शामिल हैं
  • प्रभावित डिवाइस latest Arm Mali GPU devices हैं जो CSF(Command Stream Frontend) feature का उपयोग करते हैं, और Google Pixel 7 व Pixel 8 उदाहरण के रूप में दिए गए हैं
  • Pixel 8 पर kernel MTE enabled होने की स्थिति में भी exploit का काम करना verify किया गया

Arm64 MTE का defense model

  • MTE(Memory Tagging Extension) latest Arm processors का hardware feature है, जो memory corruption detect करने के लिए pointer और memory block के tags की तुलना करता है
  • Arm64 pointer 64-bit होते हैं, लेकिन actual application address space आमतौर पर 52-bit या उससे कम होता है, इसलिए upper bits का कुछ हिस्सा tag storage के लिए इस्तेमाल किया जा सकता है
  • linear overflow में adjacent memory block का tag pointer tag से अलग हो सकता है, और use-after-free में free व reallocation process के दौरान tag change से mismatch हो सकता है
  • kCFI जैसे later-stage mitigations के विपरीत, MTE एक early-stage mitigation है जो memory corruption पहली बार होने के समय ही पकड़ने की कोशिश करता है
  • tag bits की संख्या सीमित होने के कारण collision टाला नहीं जा सकता, और केवल 4-bit tag इस्तेमाल करने पर भी random success rate 1/16 तक घट जाता है
  • Spectre जैसे side-channel attacks से pointer और memory block values leak कर दी जाएं तो सही tag मिलाकर MTE bypass किया जा सकता है, लेकिन ऐसे leaks मुख्यतः local attacker के लिए संभव होते हैं
  • फिलहाल केवल Google Pixel 8 developer options में MTE enable करने की अनुमति देता है, और MTE default रूप से disabled है
  • kernel में MTE enable करने के लिए अतिरिक्त procedure की जरूरत होती है

Mali JIT memory में होने वाली race

  • Mali GPU driver का उपयोग करने वाला user app driver file खोलता है और ioctl calls से kbase_context kernel object बनाकर initialize करता है
  • kbase_context GPU device और user-space application के बीच shared कई प्रकार की memory manage करता है
  • Mali GPU का memory region kbase_va_region से represent होता है, जहां nr_pages virtual size और gpu_alloc->nents actual backing pages की संख्या दर्शाता है
  • JIT memory kernel driver द्वारा lifecycle managed native memory है, और app GPU commands से JIT memory allocate या free करता है
  • CSF GPU में software commands और hardware commands अलग-अलग queues में रखे जाते हैं
    • KBASE_IOCTL_KCPU_QUEUE_CREATE से kbase_kcpu_command_queue बनाया जा सकता है
    • KBASE_IOCTL_KCPU_QUEUE_ENQUEUE से commands queue में डाले जाते हैं
    • BASE_KCPU_COMMAND_TYPE_JIT_ALLOC और BASE_KCPU_COMMAND_TYPE_JIT_FREE JIT allocation/free के लिए इस्तेमाल होते हैं
  • kbase_jit_allocate freed JIT memory pool में reusable region खोजता है, और physical size कम होने पर kbase_jit_grow से backing pages बढ़ाता है
  • kbase_jit_grow, kbase_mem_pool_grow call के दौरान kctx->reg_lock और kctx->mem_partials_lock को temporary रूप से release कर सकता है
  • kctx->reg_lock memory region की concurrent access से सुरक्षा करता है, इसलिए lock release होने वाला हिस्सा race window बन जाता है

CVE-2023-6241 trigger flow

  • जब GPU किसी ऐसे memory region address को access करता है जो physical pages से backed नहीं है, तो GPU memory access fault होता है
  • kbase_mmu_page_fault_worker जांचता है कि region growable है या नहीं, फिर जरूरी backing pages को तुरंत allocate और map कर सकता है
  • JIT region creation के समय KBASE_REG_PF_GROW और KBASE_REG_GPU_WR शामिल करने वाली GROWABLE_FLAGS_REQUIRED condition पूरी करता है
  • JIT region free होते समय लगने वाला KBASE_REG_DONT_NEED flag kbase_jit_grow की शुरुआत में kbase_mem_evictable_unmake में हटा दिया जाता है
  • परिणामस्वरूप, kbase_mem_pool_grow execution के दौरान race window में उसी JIT region पर GPU page fault बनाया जाए, तो fault handler उस region को expand कर सकता है
  • fault handler अगर reg->gpu_alloc->nents बदल देता है, तो kbase_jit_grow द्वारा पहले store किए गए old_size और delta values actual state से अलग हो जाते हैं
  • इसके बाद kbase_alloc_phy_pages_helper_locked और kbase_mem_grow_gpu_mapping stale values से backing page allocation और GPU mapping करते हैं, जिससे GPU mapping और pages array के बीच inconsistency बनती है
  • यह race आसानी से जीती जा सकती है क्योंकि kbase_mem_pool_grow में large memory allocation शामिल होता है

GHSL-2023-005 patch के बाद बदला attack method

  • पिछली vulnerability GHSL-2023-005 में दूसरा thread KBASE_IOCTL_MEM_COMMIT से JIT region को shrink कर old_size और delta को invalidate कर सकता था
  • GHSL-2023-005 patch के बाद KBASE_IOCTL_MEM_COMMIT ioctl से JIT memory size बदलना संभव नहीं रहा
  • CVE-2023-6241 में race window में region को shrink नहीं किया जा सकता, केवल बढ़ाया जा सकता है
  • केवल बढ़ाने की स्थिति में आखिरी कुछ backing pages GPU में map नहीं होते, लेकिन शुरुआत से contiguous mapped form बना रहता है, इसलिए तुरंत समस्या नहीं बनती
  • exploit अतिरिक्त GPU fault से unmapped gap के बाद नई mapping बनाता है, और बाद में JIT free के जरिए shrink point को उस gap के भीतर align कर exploitable state बनाता है

GPU mapping teardown की कमजोर assumption

  • kbase_mmu_teardown_pgd_pages GPU page table को traverse करते हुए entries को invalid mark कर GPU address mapping हटाता है
  • यह function अगर higher-level PTE invalid हो, तो मानता है कि उस entry द्वारा cover किया गया बड़ा address range पहले से unmapped है और उसे skip कर देता है
  • एक level 2 PTE 512 pages का range cover करता है
  • normal kbase_va_region में mapped virtual addresses हमेशा region start से contiguous होते हैं और बीच में gap नहीं होता, इसलिए यह skip behavior safe है
  • CVE-2023-6241 exploit mappings के बीच unmapped gap बनाता है और shrink start point को gap के अंदर रखता है
  • kbase_mmu_teardown_pgd_pages invalid level 2 PTE देखकर 512 pages skip कर देता है, लेकिन उसके बाद के कुछ addresses वास्तव में mapped हो सकते हैं
  • गलत तरीके से skipped GPU addresses backing pages free होने के बाद भी उन physical pages तक access बनाए रखते हैं

kernel code execution तक पहुंचने की प्रक्रिया

  • JIT region free करने पर backing pages return हो जाते हैं, लेकिन गलत तरीके से बची GPU mapping freed pages को access करती रह सकती है
  • freed backing pages बाद में दूसरे kernel pages के रूप में reuse हो सकते हैं
  • इस्तेमाल की गई techniques में से एक freed backing page को GPU kbase_context के PGD(page table global directory) के रूप में reuse करवाने की है
  • Mali driver का backing page allocation hierarchical तरीके से होता है
    • पहले current kbase_context के kbase_mem_pool से pages लिए जाते हैं
    • कम पड़ने पर pool->next_pool इस्तेमाल होता है
    • फिर भी कम हो तो kernel buddy allocator के जरिए pages सीधे allocate किए जाते हैं
  • pool->next_pool Mali driver द्वारा managed और सभी kbase_context द्वारा shared memory pool है, और GPU context के PGD allocation में भी इस्तेमाल होता है
  • freed page PGD के रूप में reuse हो जाए, तो बचा हुआ GPU address उस PGD को GPU से फिर से लिख सकता है
  • PGD को दोबारा लिखने पर arbitrary kernel memory और kernel code को GPU में map किया जा सकता है
  • इस स्थिति में kernel code को rewrite कर arbitrary kernel code execution संभव होता है, और kernel data को read/write कर process credentials बदलना व SELinux disable करना भी संभव है
  • Pixel 8 के exploit और setup notes GitHub Security Lab repository में public किए गए हैं

MTE bypass क्यों संभव है

  • इस exploit flow में MTE-specific bypass step अलग से जरूरी नहीं है
  • MTE pointer जिस memory block को point करता है, उसके tag के match होने की जांच कर incorrect dereference पकड़ने वाला feature है
  • CVE-2023-6241 trigger के समय pages array और GPU mapping के बीच inconsistency बनती है, लेकिन दोनों को अलग-अलग देखें तो invalid entry नहीं है
  • kbase_mmu_teardown_pgd_pages जब GPU mapping removal skip करता है, तो freed memory page का physical address GPU page table में बचा रहता है
  • GPU जब इस freed page को access करता है, तो वह physical address को सीधे access करता है, इसलिए pointer dereference check से नहीं गुजरता
  • GPU memory access पर MTE का असर भी निश्चित नहीं है
  • नतीजतन यह bug coprocessor GPU द्वारा physical memory को सीधे access करने वाले path का उपयोग कर MTE protection bypass करता है

MTE के बाद भी बचा attack surface

  • CVE-2023-6241 दिखाता है कि kernel MTE enabled Pixel 8 पर भी single bug से arbitrary kernel code execution तक पहुंचा जा सकता है
  • MTE memory corruption mitigation में महत्वपूर्ण प्रगति है और कई memory corruption vulnerabilities को exploit करना असंभव बना सकता है, लेकिन यह universal defense नहीं है
  • इस case में GPU ने physical memory को सीधे access करने के तरीके से MTE bypass किया
  • CPU-side hardware और software mitigations बढ़ने के साथ, coprocessors और उनके kernel drivers लगातार मजबूत attack surface बने रह सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-20
Hacker News टिप्पणियाँ

  • यहाँ मुख्य बात यह है कि GPU लंबे समय से Android के लिए सिरदर्द रहा है
    GPU के पास AP तक बहुत मजबूत access permissions होते हैं, इसलिए यह आगे लगाए गए mitigations को लगभग bypass कर सकता है। Driver के mapping code में bug ताकतवर attack primitives तक ले जाता है, और वास्तविक in-the-wild exploits में भी बार-बार इसका दुरुपयोग हुआ है। आखिरकार, architecture को फिर से design किए बिना बहुत कुछ बदलना मुश्किल लगता है

    • मुझे लगता है कि आधे-अधूरे बने mobile GPUs को अपना MMU डालना बंद करके standard I/O MMU इस्तेमाल करना चाहिए
    • यहाँ AP का क्या मतलब है?

  • इस vulnerability में दिलचस्प बात यह है कि यह Arm Mali GPU के memory management unit में मौजूद logical bug है, और Memory Tagging Extension को bypass कर सकता है
    लेकिन लेख का बाकी हिस्सा ऐसा बताता दिखता है कि असली कारण race condition है, और use-after-free उसका परिणाम है

  • क्या March update से पहले की GrapheneOS installs भी प्रभावित थीं?

    • GrapheneOS के मुख्य लक्ष्यों में से एक security updates को जितनी जल्दी हो सके deploy करना है, इसलिए अगर upstream में patch हो गया था तो GrapheneOS में लगभग निश्चित रूप से शामिल रहा होगा
      कभी-कभी यह release से पहले AOSP security patch level अपनाता है, या अभी public न हुए AOSP या kernel source के security fixes भी backport करता है
    • यह GPU के अंदर hardware के करीब की समस्या, शायद firmware issue से जुड़ी लगती थी, इसलिए मुझे लगा कि March update के बाद भी असर रहेगा। क्योंकि वह update Bluetooth stack से संबंधित था
      सुधार: नज़रअंदाज़ करें। मैं हाल की GrapheneOS blog की उस post से confuse हो गया था जिसमें लिखा था “हमें एक समस्या मिली जिसमें MTE सभी system apps पर भी apply हो रहा था।” GrapheneOS ने 2024030600 release में “पूरा 2024-03-05 security patch level” लिया था, इसलिए लगता है यह patch भी शामिल है

  • संभाव्य Arm MTE memory safety, deterministic CHERI hardware की ओर एक stepping stone है, https://saaramar.github.io/memory_safety_blogpost_2022/ और https://news.ycombinator.com/item?id=39668053
    सही mitigation को पहले attack primitive, यानी bug के root cause को निशाना बनाना चाहिए। Hardware solutions में CHERI(Morello, CheriIoT), MTE हैं, और software mitigations में kalloc_type+dataPAC, AUTOSLAB, Firebloom, GuardedMemcpy, CastGuard, attack surface reduction हैं; safe programming languages में Rust और Swift हैं। MTE और CHERI एक-दूसरे के साथ अच्छी तरह fit होते हैं और इस क्षेत्र के bugs को root cause पर हटाने में मदद करते हैं। MSR, MSRC, Azure Silicon ने CHERI को सबसे छोटे RISC-V core spec, RISC-V32E, तक shrink करने की दिशा को आगे बढ़ाया
    Microsoft Research ने IoT devices के लिए CHERI hardware/software stack को open source किया, https://msrc.microsoft.com/blog/2023/02/first-steps-in-cheri...
    CHERI-आधारित microcontroller का लक्ष्य instruction set architecture (ISA), application binary interface (ABI), isolation model, और software stack के core को साथ में design करके बहुत strong security guarantees पाना है। यह microcontroller CHERI-ISA features के जरिए spatial safety की deterministic mitigation, load barriers·zeroing·revocation·1-bit information flow control के जरिए heap और compartments के बीच stack temporal safety की deterministic mitigation, और अतिरिक्त CHERI-ISA features व छोटे monitor के जरिए fine-grained compartmentalization हासिल करता है
    David Chisnall, U of Cambridge, https://lobste.rs/s/gnjx2n/c_can_be_memory_safe#c_9ohzku via https://eclypsium.com/blog/a-faster-path-to-memory-safety-ch...
    “कई trusted computing bases में शामिल open source C/C++ code करीब 13 billion lines है, और proprietary code जोड़ें तो यह और बड़ा हो जाता है। अगर आज सभी लोग C/C++ लिखना बंद कर दें और सभी software engineers legacy code को safe languages में फिर से लिखने पर focus करें, तब भी सब कुछ replace करने में 5~10 साल लगेंगे, और लंबे समय से verified code को safe language के allowed idioms के हिसाब से अलग algorithms और data structures चाहिए होने वाले नए code से बदलते समय बहुत सारे logic bugs बनने की संभावना भी ज्यादा है।”
    “अगर rewrite किए बिना सिर्फ C/C++ code लिखना बंद करें, तो सामान्य code replacement rate पर trusted computing base को पूरी तरह safe होने में करीब 50 साल लगेंगे। अगर सभी C/C++ रोकने पर सहमत नहीं होते, तो कम से कम 100 साल।”
    “इसके उलट, अगर प्रमुख CPU manufacturers 5 साल के भीतर CHERI CPU release करते हैं, तो programmers के behavior बदले बिना भी आज से 15 साल के भीतर ज्यादातर machines, खासकर high-value machines, memory safety पा लेंगी।”

    • अगर embedded/IoT जैसे use cases के लिए CHERI में रुचि है, तो lowRISC CHERIoT के लिए कुछ FPGA-आधारित evaluation platforms बना रहा है: https://www.sunburst-project.org/
      पहला Sonata system है: https://github.com/lowRISC/sonata-system. इसमें FPGA और कई peripherals व headers वाला dedicated PCB शामिल है। PCB design पूरा हो चुका है और Mouser के जरिए उपलब्ध होगा; board layout तक open source है, इसलिए चाहें तो खुद assemble भी कर सकते हैं। फिलहाल FPGA के लिए RTL पर काम चल रहा है। पूरा होने पर documentation और tools के साथ CHERIoT-आधारित microcontroller-टाइप system मिलेगा
      इसके अलावा Sonata और OpenTitan Earl Grey trust root को जोड़ने वाला Symphony system भी बनाया जा रहा है: https://github.com/lowRISC/symphony-system
    • Solaris SPARC ADI भी है। Oracle और Solaris SPARC की मौजूदा स्थिति की वजह से ज्यादातर लोग इसे भूल चुके हैं, लेकिन यह अफसोस की बात है
    • यह CPU के बाहर का hardware bug है, इसलिए CHERI कैसे मदद करेगा, पता नहीं
      ऊपर से, आखिरी बार जब देखा था तब CHERI sound नहीं था। उस पर भी memory bugs लिखे जा सकते थे; क्या अब वह ठीक हो गया है?
    • “सब कुछ replace करने में 5~10 साल” अगर सचमुच सालों में है, तो यह बहुत optimistic लगता है
      सिर्फ bikeshedding में ही शायद इतना समय लग जाएगा
    • मूल समस्या यह लगती है कि user malicious code चलाता है और किसी MMU hash collision का exploit करता है
      यह exploit Rust समेत ज्यादातर languages में लिखा जा सकता लगता है

  • Hardware इतना खराब है? हे भगवान...

    • GPU hardware bugs से भरा पड़ा है। Hardware को दोबारा tape-out तभी करते हैं जब acceptable cost पर driver में workaround संभव न हो
      यह तरीका इसलिए संभव है क्योंकि GPU, CPU की तरह relatively direct hardware access allow नहीं करता
    • यह CPU पर चलने वाला driver bug है

  • शानदार रिसर्च और लेख है, लेकिन इसका GitHub ब्लॉग पर आना थोड़ा अप्रत्याशित होने के साथ-साथ अच्छा भी लगा
    क्या किसी को पता है कि इस तरह की रिसर्च करने के पीछे GitHub की “बिज़नेस वजह” क्या है? मेरा मतलब यह नहीं कि बिज़नेस वजह होना ज़रूरी है, लेकिन इसे यहाँ देखकर थोड़ा आश्चर्य हुआ

    • Man Yue Mo GitHub द्वारा अधिग्रहित किए जाने से पहले Semmle में काम करते थे (https://blog.sonatype.com/steps-to-responsible-disclosure, https://github.blog/2019-09-18-github-welcomes-semmle/)
      वह रिसर्च फ़ंक्शन आगे चलकर GitHub Security Lab बना। Semmle ने CodeQL बनाया था, जिसे अब GitHub उपलब्ध कराता है (https://docs.github.com/en/code-security/code-scanning/intro...). GitHub और Microsoft CodeQL को “गहरी security insights” से जोड़ना चाहते हैं (https://www.microsoft.com/en-us/security/blog/2023/11/02/ann...)
      इसलिए वे ऐसी नई और रोचक security research को लगातार funding दे रहे हैं, और industry के security practitioners इसके लिए आभारी हैं
    • यह काम GitHub के Security Lab से आया है: https://securitylab.github.com/
    • Microsoft द्वारा अधिग्रहण के बाद इस तरह की रिसर्च को support करने के संसाधन मिल गए
      GitHub ऐप भी है, और उस ऐप की security GitHub के दायरे से बाहर नहीं है। अगर कोई attacker फ़ोन में छिपकर रहने वाला ऐप install कर सकता है, तो वह user बनकर कई काम कर सकता है। अगर वह व्यक्ति GitHub पर प्रभावशाली है, तो नुकसान काफ़ी बड़ा हो सकता है, इसलिए ऐसी vulnerabilities ढूँढना GitHub के हित में भी है
    • GitHub के पास Arm के लिए hosted Actions runners भी हैं
      इसलिए MTE का उपयोग करके sandboxing के लिए Arm hardware की security features की जाँच और validation करने में उसकी रुचि हो सकती है
    • मुझे यह असल में basic research के करीब लगता है [0]
      सीधे तौर पर देखें तो GitHub नाम के product को Android security experts की अनिवार्य ज़रूरत नहीं है। लेकिन long term में संभावित लाभ हैं
      [0]: https://en.wikipedia.org/wiki/Basic_research

  • यह हैरानी की बात है कि अब तक किसी ने लगभग बिना GPU या बिल्कुल बिना GPU वाले CPU और फ़ोन बनाकर उन्हें business phone नहीं कहा
    security, cost और power consumption के लिहाज़ से फायदे स्पष्ट लगते हैं

    • स्पष्ट नुकसान यह है कि high-resolution touchscreen नहीं होगा, जिससे हम Blackberry या Palm Treo के दौर में लौट जाएँगे। सच में वे चीज़ें business phone के रूप में बेची गई थीं