Apple M5 पर पहला सार्वजनिक macOS kernel memory corruption exploit

• Calif के इंजीनियरों ने Apple M5 पर काम करने वाला macOS kernel memory corruption exploit बनाया और vulnerability research report Apple को सौंप दी
• exploit chain MIE enabled bare-metal M5 hardware को target करती है, और Apple के fix जारी करने के बाद पूरे technical details प्रकाशित किए जाएंगे
• target macOS 26.4.1 (25E253) है, और बिना privilege वाले local user से केवल सामान्य system calls का उपयोग करके root shell तक पहुंचा जाता है
• implementation में दो vulnerabilities और कई techniques का उपयोग किया गया, और Calif के अनुसार यह MIE hardware पर सार्वजनिक रूप से सामने आया पहला macOS kernel exploit है
• Mythos Preview ने bug identification और exploit development में मदद की, लेकिन MIE जैसी नई mitigations को bypass करने के लिए अब भी human experts की जरूरत है

---

M5 की MIE को पार करने वाला macOS kernel exploit

• Calif के इंजीनियरों ने Mythos Preview के साथ मिलकर Apple M5 silicon पर काम करने वाला macOS kernel memory corruption exploit बनाया, और Apple Park में Apple को vulnerability research report सीधे सौंप दी
• यह chain MIE(Memory Integrity Enforcement) enabled bare-metal M5 hardware को target करती है
• target macOS 26.4.1 (25E253) है, और यह बिना privilege वाले local user से शुरू होकर केवल सामान्य system calls का उपयोग करते हुए root shell पर समाप्त होने वाली data-only kernel local privilege escalation chain है
• implementation में दो vulnerabilities और कई techniques शामिल थीं, और Apple द्वारा vulnerability और attack path को fix करने के बाद 55-page report और पूरे technical details प्रकाशित किए जाएंगे
• timeline तेज़ी से आगे बढ़ी
  • Bruce Dang ने 25 अप्रैल को bug खोजा
  • Dion Blazakis 27 अप्रैल को Calif से जुड़े
  • Josh Maine ने tools बनाए, और 1 मई को काम करने वाला exploit पूरा हो गया

MIE और Mythos Preview का महत्व

• memory corruption iOS और macOS सहित अब भी सबसे आम vulnerability type है, और यदि इसे पूरी तरह रोका नहीं जा सकता तो ऐसी mitigations की जरूरत होती है जो attack cost बढ़ाएं
• Apple ने performance और security दोनों को ध्यान में रखते हुए कई defense features को hardware में शामिल किया, और पूरे stack को control करने के तरीके से bypass की कठिनाई बढ़ाई
• MIE ARM की MTE(Memory Tagging Extension) पर आधारित hardware-assisted memory safety system है, और इसे Apple M5 और A19 के प्रमुख security feature के रूप में पेश किया गया
• Apple के research के अनुसार MIE ने हाल में लीक हुए Coruna और Darksword exploit kits सहित modern iOS के खिलाफ सभी public exploit chains को बाधित किया
• Calif यह खोजता रहा है कि MTE environment में काम करने वाले exploits बनाने में AI कैसे योगदान दे सकता है, और Apple की iOS-केंद्रित MIE के latest MacBook के M5 पर लागू होने से macOS attack path संभव हुआ
• Mythos Preview ने bug identification और exploit development के पूरे process में मदद की, और जिन problem types पर यह पहले से train हो चुका है, उनमें यह लगभग उसी तरह की समस्याओं तक generalize कर सकता है
• Mythos ने bugs को तेजी से इसलिए खोजा क्योंकि वे bugs ज्ञात प्रकारों में आते थे, जबकि MIE जैसी नई state-of-the-art mitigations को autonomously bypass करना अब भी human experts का क्षेत्र है
• Calif ने यह परखा कि top-tier models और experts के संयोजन से क्या संभव है, और यह संयोजन top-level protections के खिलाफ एक हफ्ते के भीतर kernel memory corruption exploit पूरा कर सका
• MIE hackers को पूरी तरह रोकने के लिए बना तंत्र नहीं है, और यदि उपयुक्त vulnerability हो तो इसे evade किया जा सकता है
• MAD Bugs series में कहा गया है कि AI systems लगातार अधिक vulnerabilities खोज रहे हैं, और उनमें से कुछ MIE जैसी advanced mitigations को पार करने लायक पर्याप्त शक्तिशाली हो सकते हैं
• जब Apple ने MIE बनाया था तब Mythos Preview जैसा environment मौजूद नहीं था, और यह काम AI-based bug discovery से advanced mitigation technologies पर पड़ने वाले दबाव का शुरुआती उदाहरण दिखाता है

[GN⁺]

Hacker News की राय

• सिर्फ़ डेमो को देखें तो Apple bug bounty platform पर यह $100,000 की vulnerability लगती है, लेकिन अगर इसे अच्छी तरह पैकेज किया जाए तो यह $1.5 million की vulnerability भी बन सकती है
  इसे macOS beta version पर reproduce करना होगा, इसे unauthorized access के रूप में वर्गीकृत करना होगा, और संभव हो तो Lockdown Mode में भी दिखाना होगा

  • यह local privilege escalation (LPE) जैसा दिखता है, जबकि ऊपर कही गई बात no-click remote code execution (RCE) के ज़्यादा क़रीब है

• ऐसा लगता है कि दुनिया security issue पर LLM के असर के लिए बिल्कुल तैयार नहीं थी
  अगर यह सच है, तो Calif टीम को बधाई, और भले ही details इतने technical हैं कि सब समझना मुश्किल है, फिर भी 55-पेज की report का इंतज़ार है

  • मैं भी सहमत हूँ, लेकिन मुझे लोगों की चिंता है
    हर जगह से यह सुनने को मिल रहा है कि developers बिना ठीक से समझे कि वे क्या deploy कर रहे हैं, LLM-generated code changes को production में push कर रहे हैं
    जैसे-जैसे changes जमा होते जाते हैं, codebase की समझ घटती जाती है और व्यवहार ज़्यादा जोखिमभरा होता जाता है
    इससे भी बुरा यह है कि ऐसे व्यवहार को leadership सीधे या परोक्ष रूप से बढ़ावा दे रही है। जैसे अवास्तविक speed targets, अस्पष्ट "AI use" initiatives पर promotion, layoffs के बाद बचे developers पर overload डालना, और inexperienced developers को senior roles में बिठाना
    ऐसा लग रहा है कि industry का बड़ा हिस्सा security की बुनियादी बातें मुश्किल से फिर से सीखने पर मजबूर हो रहा है, और दुनिया पागल हो गई है
  • मानो यह मान लिया गया हो कि blue teams और engineers कुछ भी नहीं कर रहे और बस हाथ पर हाथ धरे बैठे हैं

• अगले कुछ सालों में LLM Rube Goldberg-style vulnerabilities की भरमार पैदा करेंगे
  यह शुरू हो चुका है, और भले ही यह मामला वैसा न हो, लेकिन यह सच में हो रहा है

  • सैद्धांतिक रूप से सुरक्षित system बनाना ही शायद भौतिक रूप से असंभव हो
    जैसे यह मानना कि कोई ऐसी cell नहीं होती जो किसी भी virus से पूरी तरह अछूती हो
    हो सकता है अब तक हम एक तरह की security through obscurity पर टिके रहे हों, और उस obscurity का मतलब बस इतना हो कि किसी के पास code को सच में analyze करने के लिए समय और एकाग्रता नहीं थी
  • जिज्ञासा है कि इसका मतलब kernel में vibe coding से ऐसी vulnerabilities डालना है, या उन्हें ढूँढ निकालना

• अफ़सोस है कि details थोड़ी कम हैं
  यह जानने की बहुत उत्सुकता है कि bug ने MTE को कैसे bypass किया

  • Memory Tagging Extension
    Arm ने 2019 में Memory Tagging Extension (MTE) spec जारी की थी, ताकि hardware memory corruption bugs को ढूँढने में मदद कर सके
    MTE एक memory tagging और tag-checking system है, जो हर memory allocation पर एक secret value को tag के रूप में जोड़ता है
    बाद में hardware सिर्फ़ तभी memory access की अनुमति देता है जब access request में वही सही secret value शामिल हो
    अगर secret value मेल न खाए, तो app crash हो जाती है, event log हो जाता है, और developers memory corruption bug को उसी समय पहचान सकते हैं
    https://support.apple.com/guide/security/operating-system-in...
  • data-only attacks के बारे में और पढ़ने पर बात समझ में आती है
    (https://www.usenix.org/publications/loginonline/data-only-at...)
    program वास्तव में बदलता नहीं, बल्कि वह ऐसा behavior force करता है जहाँ MTE को दख़ल देना चाहिए, इसलिए MTE trigger नहीं होता
    एक और सवाल यह है कि Apple ने यहाँ fbounds checks का इस्तेमाल क्यों नहीं किया
    क्योंकि दूसरी जगहों पर वह इन्हें काफ़ी आक्रामक तरीके से लागू करता रहा है
    MTE और व्यापक fbounds checks को साथ इस्तेमाल किया जाए तो operating system बेहद मज़बूत हो सकता है
  • GPU memory, shaders आदि MTE या PAC से सुरक्षित नहीं हैं
    क्योंकि इसे "data-only" कहा गया है, संभव है कि GPU commands यहाँ फिट बैठती हों
  • मेरे मन में भी यही सवाल आया, और अगर यह data-only attack है, तो शायद सबक यह है कि MIE कई attack paths को कम तो करता है, लेकिन सभी उपयोगी corruption primitives को पूरी तरह ख़त्म नहीं करता
  • यह पहली बार नहीं है कि bug ने MTE को bypass किया हो
    पिछले साल Google Pixel में भी ऐसा ही कुछ हुआ था
    https://github.blog/security/vulnerability-research/bypassin...

• यह हैरानी की बात है कि Apple अब भी कथित रूप से सुरक्षित भाषा Swift का अंदरूनी तौर पर ठीक से इस्तेमाल नहीं कर रहा
  लगता है Swift 6 का ज़्यादातर हिस्सा लगभग marketing ही था

  • वे निश्चित रूप से इसका इस्तेमाल कर रहे हैं
    Embedded Swift आने का एक कारण यह भी है कि मौजूदा iBoot firmware, जो Fil-C जैसी सोच वाली C dialect में लिखा गया है, उसे किसी बेहतर चीज़ से बदला जाए
    हालाँकि इसमें Linux kernel से कोई ख़ास फ़र्क नहीं है
    सिर्फ़ इसलिए कि Rust की अनुमति मिल गई, इसका मतलब यह नहीं कि पूरी दुनिया दोबारा लिख दी गई, और कोई समझदार इंसान Claude से kernel rewrite करवाने की कोशिश नहीं करेगा
  • Apple में Swift का इस्तेमाल स्पष्ट रूप से हो रहा है
    हाल में इसे Safari के CSS parser में जोड़ा गया है, और Secure Enclave के कुछ हिस्सों में यह embedded रूप में चलता है
    मेरी जानकारी में Strangeloop के समय से इसे kernel में डालने पर चर्चा थी, लेकिन यह कितनी आगे बढ़ी, यह नहीं पता
    इसके अलावा Apple clang के fbounds checks को काफ़ी ज़ोर से आगे बढ़ा रहा है, और इससे memory-safe languages जो देती हैं उसका छोटा लेकिन महत्वपूर्ण हिस्सा हासिल किया जा सकता है
    Swift या अन्य वैकल्पिक भाषाओं को और अपनाते देखना अच्छा होगा, और safe language क्षेत्र में ज़्यादा competition हमेशा स्वागतयोग्य है
  • आपको Strict Memory Safety option में दिलचस्पी हो सकती है
    https://docs.swift.org/compiler/documentation/diagnostics/st...

• मैंने MIE की वजह से जानबूझकर M5 खरीदा था, और अब थोड़ा बेवकूफ़ जैसा महसूस हो रहा है

  • ऐसी ज़रूरत नहीं है
    MTE vulnerabilities के बड़े वर्ग को रोकता है, और ROP तथा JOP जैसी techniques को अब बहुत मुश्किल या लगभग असंभव बना देता है
  • memory corruption bugs से ज़्यादा npm/PyPI malware की चिंता करनी चाहिए

• क्या लेख edit हुआ था? on-site visit के बारे में ज़्यादा जानकारी नहीं है

• यह Mythos के लिए एक और बढ़ा-चढ़ाकर की गई marketing जैसा लगता है
  curl report काफ़ी ज़्यादा संयत थी
  https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

  • ये लोग Apple या Anthropic में काम नहीं करते