Apple का Memory Integrity Enforcement (MIE)

• Apple ने Memory Integrity Enforcement(MIE) पेश किया है, जो अपने सिलिकॉन हार्डवेयर और उन्नत operating system security को मिलाकर एक अभिनव memory safety framework पूरा करता है
• MIE हमेशा सक्रिय रहता है, मुख्य attack surface की सुरक्षा करता है, और बिना performance गिरावट के सभी iPhone 17 और iPhone Air डिवाइसों पर लागू होता है
• Enhanced Memory Tagging Extension(EMTE), secure memory allocator, और tag confidentiality policy के संयोजन से malicious attacks के खिलाफ resilience काफी बढ़ जाती है
• synchronous tag checking और operating system-hardware के परिष्कृत integration के कारण, buffer overflow और use-after-free vulnerabilities को रोकना अधिकतम स्तर तक बढ़ जाता है
• कई वर्षों के आक्रामक research और internal evaluation के माध्यम से attacker freedom को सीमित किया गया है, और मौजूदा मानकों के अनुसार सबसे मजबूत memory safety हासिल की गई है

---

परिचय

• Apple का Memory Integrity Enforcement(MIE) एक हमेशा-सक्रिय memory safety protection technology है, जो Apple Silicon hardware और उन्नत operating system security को एकीकृत करती है
• इसे अतिरिक्त performance गिरावट के बिना विभिन्न Apple डिवाइसों पर industry-first व्यापक memory safety framework देने के लक्ष्य से विकसित किया गया है
• Apple के अनुसार, यह consumer operating system memory safety के इतिहास में सबसे महत्वपूर्ण प्रगति में से एक है

सुरक्षा खतरे की पृष्ठभूमि और memory safety का विकास

• iPhone पर बड़े पैमाने के malware attacks के सफल उदाहरण न होने की वजह यह है कि वास्तविक खतरे के रूप में केवल mercenary spyware केंद्रित जटिल attack chains ही देखी गई हैं
• ऐसे उन्नत हमले, जो लाखों डॉलर खर्च वाले और सीमित targets के लिए होते हैं, सामान्य रूप से memory safety vulnerabilities का दुरुपयोग करते हैं
• Apple ने Swift जैसी safe languages के विकास, secure memory allocator की शुरुआत, और पूरे system में बड़े पैमाने की mitigations के जरिए लगातार memory safety बेहतर की है
• Pointer Authentication Code(PAC) को दुनिया में पहली बार A12 Bionic में लाकर Apple ने hardware-software integrated security को मुख्यधारा में स्थापित किया

hardware-based memory tagging technology (MTE/EMTE) और सीमाओं पर काबू

• Arm द्वारा प्रस्तावित Memory Tagging Extension(MTE) हर memory allocation को एक secret tag देता है, और केवल सही tag के साथ access की अनुमति देता है
• Apple ने MTE के मूल design की कमियां, जैसे asynchronous behavior, पहचानीं और Arm के साथ मिलकर इसे Enhanced Memory Tagging Extension(EMTE) के रूप में बेहतर बनाया
• इसे इस तरह डिज़ाइन किया गया कि tag checking हमेशा synchronous तरीके से काम करे; लगातार सुरक्षा देना इसका मुख्य आधार है

MIE की layered architecture और प्रमुख protection mechanisms

• MIE तीन घटकों से बना है: kalloc_type, xzone malloc, WebKit का libpas जैसे type-aware secure allocators, EMTE, और Tag Confidentiality Enforcement policy
• allocators अलग-अलग types के बीच memory page-level protection देते हैं, जबकि EMTE उसी type bucket के भीतर छोटे memory allocations की कमजोरियों तक का मुकाबला करता है
• buffer overflow, use-after-free जैसी सामान्य memory corruption attacks के खिलाफ, tagging और re-tagging का उपयोग कर hardware और operating system तुरंत पता लगाते और रोकते हैं

tag confidentiality और side-channel attacks के खिलाफ रणनीति

• attackers allocator storage और tag exposure को निशाना न बना सकें, इसके लिए Secure Page Table Monitor जैसे मजबूत protection mechanisms जोड़े गए हैं
• speculative execution का दुरुपयोग करने वाले side-channel attacks के खिलाफ, Apple Silicon को इस तरह डिज़ाइन किया गया है कि tag information के कारण speculative execution पर प्रभाव ही मूल रूप से न हो
• Spectre V1 vulnerability को भी प्रभावी तरीके से रोका गया है, जिससे अधिकतर मामलों में वास्तविक attack chain की कड़ियां टूट जाती हैं

software-hardware integrated response और व्यापक लागूकरण

• नए A19/A19 Pro chip design में tag storage और verification के लिए अतिरिक्त hardware resources बड़े पैमाने पर जोड़े गए
• MIE पहले secure allocators का उपयोग करके software के स्तर पर सुरक्षित किए जा सकने वाले हिस्सों को कवर करता है, जबकि EMTE उन क्षेत्रों पर सटीक रूप से लागू होता है जिन्हें software से सुरक्षित नहीं किया जा सकता
• deployment strategy को इस तरह परिष्कृत किया गया कि पुराने iPhone डिवाइस भी यथासंभव memory safety improvements का लाभ ले सकें

वास्तविक सुरक्षा मूल्यांकन और प्रभावशीलता विश्लेषण

• Apple की attack research team ने 2020~2025 के MIE plan चरण से ही विभिन्न attack scenarios बनाए और hardware prototypes तक पर बार-बार वास्तविक intrusion attempts किए
• नए और पुराने दोनों exploit chains में यह पुष्टि हुई कि MIE लागू होने पर हमले के अधिकांश चरण मूल रूप से अवरुद्ध हो जाते हैं
• जो कुछ कमजोरियां बचीं भी, वे स्थिर हमले के लिए उपयोगी नहीं रहीं, जिससे वास्तविक नुकसान की संभावना बहुत घट गई

निष्कर्ष

• iPhone की industry-leading security अधिकांश उपयोगकर्ताओं के लिए system-level attacks के exposure को ही सीमित कर देती है
• MIE वास्तविक mercenary spyware की सबसे जटिल और महंगी attack strategies को निष्क्रिय करते हुए, kernel सहित लगभग 70 प्रमुख user-space processes को हमेशा सुरक्षित रखता है
• मूल्यांकन के अनुसार, इसने memory corruption vulnerabilities के exploit cost और कठिनाई को बहुत बढ़ा दिया है, और पिछले 25 वर्षों की प्रमुख attack techniques को मजबूती से रोकने का प्रभाव दिखाया है
• MIE, iOS और Apple devices में consumer operating system memory safety के इतिहास का सबसे बड़ा बदलाव बनकर उभरता है

[GN⁺]

Hacker News राय

• दोनों approaches एक ही निष्कर्ष पर पहुँचे। Memory Integrity Enforcement(MIE) मूल रूप से उन अधिकांश exploit strategies को बंद कर देता है जिनका attackers उपयोग कर सकते हैं। memory corruption bugs आम तौर पर एक-दूसरे के बदले इस्तेमाल किए जा सकते हैं, लेकिन MIE बहुत ही बुनियादी स्तर पर इतने exploit paths रोक देता है कि नए bugs से बदलने पर भी chain को फिर से बहाल नहीं किया जा सका। बहुत कोशिश के बाद भी bypass chain दोबारा नहीं बनाई जा सकी। जो कुछ असर बचे भी हैं, वे भरोसेमंद नहीं हैं, इसलिए attackers के लिए सफल exploitation के लिए पर्याप्त नहीं हैं। यह बहुत अच्छी खबर है, और देखने में छोटी लग सकती है लेकिन महत्वपूर्ण बात है। mercenary spyware economy का एक हिस्सा interchangeable chains पर निर्भर करता है, इसलिए इस गुण को सीधे निशाना बनाने वाली defenses खास तौर पर दिलचस्प हैं
  • यह जानने की जिज्ञासा है कि Apple की रणनीति क्या CHERI(संदर्भ: Capability Hardware Enhanced RISC Instructions) जैसी पूरी capability-based memory safety की ओर एक कदम है, या इसे इस संकेत के रूप में देखना चाहिए कि Apple ने तय कर लिया है कि ऐसे system के बिना भी पर्याप्त सुरक्षा मिल सकती है
  • मैं Apple के मामले के जवाब में Google के memory safety approach का भी उल्लेख करना चाहूँगा। Google Chrome/Android के शुरुआती दिनों से memory safety को गंभीरता से लेता रहा है, और ASAN, syzkaller, Hardware MTE को अपनाने में भी अग्रणी रहा है। मैंने ऐसे team की जिम्मेदारी संभाली थी, इसलिए इसके कई फायदे-नुकसान सीधे देखे हैं। Google का लक्ष्य यह था कि ASAN-स्तर का verification जरूरत के हिसाब से on/off किया जा सके। सुरक्षा mitigation के रूप में इसे हमेशा on रखना, memory overhead के अलावा भी कई समस्याएँ लाता है। उदाहरण के लिए, सभी devices पर असंगत तरीके से users को दिखाई देने वाले बहुत सारे crashes होने लगते हैं। developers के लिए भी यह निराशाजनक होता है, क्योंकि उन्हें ठीक से testing केवल लगभग 10 लाख MTE-supported devices पर ही करनी पड़ती है। MTE कुछ security exploits पकड़ता है, लेकिन बहुत से harmless bugs भी पकड़ लेता है। हालांकि, runtime mitigation के लिए यह हमेशा सबसे अच्छा विकल्प है या नहीं, यह स्पष्ट नहीं है। Google Security, Project Zero आदि ने CSVs के खिलाफ बहुत मेहनत की है, लेकिन MTE को productize करने में कंपनी मुख्यालय कमज़ोर रहा, ऐसा मुझे लगता है (लिंक)
  • Vigilant Labs के लिए यह अच्छी खबर न हो, लेकिन वास्तव में उस पर कितना बड़ा प्रभाव पड़ा है, यह निश्चित नहीं है
• मुझे लगता है कि Apple का यह दावा कि "memory safety protections हमेशा synchronous, default-on, और लगातार सक्रिय होनी चाहिए" किसी कट्टर सिद्धांत से नहीं बल्कि अनुभव से आया है। यह शुरुआती kernel protections से अलग था। 2015 में iOS 9 में आए Kernel Patch Protection(KPP) में kernel में बदलाव हुआ है या नहीं, यह हर कुछ मिनट में, जब device idle हो, asynchronous तरीके से जाँचा जाता था। यह तरीका सुरक्षा की दृष्टि से बहुत भरोसेमंद नहीं था, और इसमें design flaws थे जिनके कारण इसे पूरी तरह bypass करने वाले hacks प्रकाशित हुए थे। KPP kernel patching को मूल रूप से रोकता नहीं था, बल्कि detect होने पर केवल panic कराता था। यानी अगर attacker अपना काम काफी तेजी से पूरा करके बदलाव वापस कर दे, तो KPP उसे detect नहीं कर पाता था (writeup देखें)
  • अंदरूनी जानकारी के आधार पर, KPP को A11 के KTRR आने के समय <A11 SoCs पर समान security level कृत्रिम रूप से मिलाने के लिए जल्दबाज़ी में बनाया गया था। इतने छोटे timeline में इसे सबसे अच्छे संभव तरीके से लागू किया गया, और बाद में इस तरह का तरीका दोहराया नहीं गया
  • यह शुरुआत से कोई सिद्धांतगत तैयारी कम, और MTE को लाने की शुरुआती planning के समय निकला निष्कर्ष ज़्यादा लगता है। Apple की security लगातार बेहतर हुई है, और इसके पीछे jailbreak जैसी चीज़ों से मजबूरन मिली सीख भी बड़ी वजह है
  • मैं इस बात से सहमत हूँ कि ऐसे systems को शुरुआत से ही perfectly implement करना कठिन होता है
• Apple ने कहा कि “iPhone पर सफल और व्यापक malware attacks नहीं हुए”, लेकिन मुझे लगता है कि मौजूदा spyware code में थोड़ा-सा बदलाव करके ही उसे बड़े पैमाने के attack में बदला जा सकता है। वास्तव में यह distinction इतना स्पष्ट नहीं है
  • वास्तविकता यह है कि Apple और Google, दोनों ही actual attack scale को पूरी तरह नहीं जान सकते। GrapheneOS द्वारा जारी leak materials के अनुसार, exploit developers device attacks और updates के प्रति लोगों की सोच से कहीं अधिक सक्षम हैं। उनके पास अतिरिक्त unpublished materials भी हैं, और कई independent sources से verify न होने पर leak path उजागर होने से बचाने के लिए वे केवल कुछ हिस्से ही साझा करते हैं। ऐसे exploit tools व्यापक रूप से उपलब्ध हैं, और यह अलग करना भी आसान नहीं कि कोई चीज़ routine data extraction है या remote exploitation। वास्तविक दुनिया में exploits का detect होना दुर्लभ है, और अधिकांश मामलों में वे detection के बिना बड़े पैमाने पर इस्तेमाल किए जा सकते हैं, इसलिए एक single chain भी लंबे समय तक मूल्यवान रहती है। दुनिया भर की law enforcement agencies Cellebrite Premium जैसे tools का उपयोग कर रही हैं और borders, protest sites आदि पर बहुत से लोगों के खिलाफ इन्हें लागू कर रही हैं। यह पहले से ही large-scale use है। remote exploits के मामले में, व्यापक उपयोग के लिए उनका व्यापक distribution होना भी जरूरी नहीं है
  • XcodeGhost iPhone पर बड़े पैमाने के malware attack का प्रमुख उदाहरण है। उस समय WeChat आदि संक्रमित हुए थे। संदर्भ: XcodeGhost Wikipedia
  • यह निश्चित नहीं कि यह वास्तव में बड़े पैमाने के attack में इस्तेमाल हो सकता था या नहीं, लेकिन अगर इसकी exposure Windows जैसी होती तो ऐसे मामले बहुत अधिक होते
  • संभव है कि उस वाक्य का उद्देश्य मुख्यतः Android से तुलना करते हुए अपने control model के फायदे को उभारना हो
  • भाषा कुछ वकीलों जैसी ज़रूर है, लेकिन MIE जैसी नई तकनीकों पर Apple ने इस बार बहुत विस्तृत सामग्री और आत्मविश्वास भरा संदेश जारी किया है, जो हम सबके लिए सकारात्मक है
• यह system निश्चित रूप से प्रभावशाली है। लेकिन जहाँ attacker बार-बार retry कर सकता ho, वहाँ defense पर्याप्त न हो सकती है। उदाहरण के लिए, अगर non-adjacent objects तक out-of-bounds access संभव हो, या बहुत सारे memory allocation manipulation के बाद संयोग से tag match हो जाए, तो bypass संभव है। tag match होने की संभावना 1/16 है। हालांकि, मुख्य लेख में विस्तृत विवरण नहीं है, इसलिए मेरी यह भविष्यवाणी सही है या नहीं, यह निश्चित नहीं। अगर इसे सफलतापूर्वक लागू किया गया, तो बचे हुए exploits को logic bugs पर निर्भर होना पड़ेगा, जो attackers के लिए कहीं अधिक कठिन होगा
  • Android MTE में भी इसी तरह छोटे tag size को निशाना बनाने वाले probabilistic attacks (कई बार retry) संभव थे। लेकिन यहाँ मुख्य अंतर consistent synchronous enforcement है। यानी हर memory write manipulation पर तुरंत trap होता है, context switch के समय नहीं
  • 1/16 की सफलता संभावना के अलावा बाकी 15/16 प्रयास crash पैदा करेंगे। इतने अस्थिर bugs user या diagnostic systems के सामने जल्दी उजागर हो जाते हैं, और अगर कई चरणों को लगातार सफल होना हो, तो संभाव्यता के हिसाब से वास्तविक exploitation लगभग असंभव के करीब पहुँच जाती है
  • supply chain attacks जैसे लंबे समय लेकर घुसपैठ करने वाले nation-state attacks पर ऐसी defenses लागू न भी हों
• Apple/ARM का model कहीं अधिक परिष्कृत होगा, लेकिन इससे Burroughs large system की memory tagging architecture याद आती है (संदर्भ)
• “attacker को system द्वारा चुनी गई tag value का अनुमान नहीं लगा पाना चाहिए। इसके लिए नए tags बनाने हेतु PRNG को बार-बार reseed किया जाता है” इस विवरण को देखकर लगता है कि मूल समस्या tag की कम entropy है (सिर्फ 4 bits)। attacker अगर random guess करे तो सफलता की संभावना 1/16 है, और PRNG reseed करने से यह संभावना बदलती नहीं। इस पर और स्पष्टीकरण चाहिए
  • attacker को केवल एक बार guess करने का मौका मिलता है। अगर guess गलत हुआ, तो process terminate हो जाती है या kernel panic हो जाता है। अगली बार कोशिश करने पर नया tag होगा, इसलिए फिर से नया guess करना पड़ेगा और continuous attempts संभव नहीं होते
  • 4 bits का मतलब है कि संभावित combinations बहुत कम हैं। memory allocations प्रति second लाखों बार होते हैं, इसलिए reseed बार-बार होने पर भी collisions की संभावना बहुत तेज़ी से बढ़ती है
• इस device series की सबसे बड़ी ताकत यही नई feature है
• अगर EU की chat control जैसी policies लागू हो गईं, तो राज्य मेरे device पर अपनी इच्छा की हर चीज़ तक पहुँच सकता है, और अगर Google WEI को enforce करे तो पूरा web बंद हो सकता है। Secure boot और MIE आने के बाद users के लिए अपनी पुरानी आज़ादी वापस पाना मुश्किल हो सकता है
  • यानी, ऐसी आज़ादी बचाए रखने के लिए systems और services को थोड़ा और अलग-अलग (बाल्कनाइज़) करना पड़ सकता है
  • क्या इसमें यह शिकायत शामिल है कि MIE को मजबूत करना jailbreak जैसी user freedom को सीमित करता है, यह जानने की जिज्ञासा है
  • WEI क्या है, यह भी जानना चाहता हूँ
• पिछले साल Google ने MTE को opt-in के रूप में दिया, यह एक अच्छा पहला कदम था, लेकिन पूर्ण integration की कमी के कारण यह Apple द्वारा ज़ोर दिए गए EMTE-आधारित MIE जैसा नहीं है। Apple के iPhone 17 और Air के साथ industry का पहला व्यापक always-on memory safety system आना प्रभावशाली है। हालांकि GrapheneOS के अग्रणी प्रयासों (release example, awareness raising) को पर्याप्त पहचान नहीं मिली, यह अफसोस की बात है, लेकिन उम्मीद है कि Apple की गंभीर कोशिश जल्दी ही Google, Pixel OS, और दूसरे security OS तक फैलेगी। इससे फिर पुष्टि होती है कि GrapheneOS अज्ञात खतरों तक से बचाव करने वाले systems में अग्रणी है
  • Apple इस क्षेत्र में लंबे समय से तैयारी कर रहा था। यह GrapheneOS द्वारा इसे enable करने के बाद शुरू नहीं हुआ
• इसमें कहा गया है कि “2018 के A12 Bionic chip में Pointer Authentication Codes(PAC) को industry-first के रूप में लागू कर code-flow integrity protection शुरू की गई”, लेकिन PAC आने के बाद भी कई full-chain attacks देखे गए। PAC कोई meaningful attack deterrent नहीं था। attackers लगातार PAC bypass ढूँढते रहे हैं। MIE की प्रभावशीलता का आकलन करते समय इसे ध्यान में रखना चाहिए
  • वास्तव में Apple ने PAC को attack deterrent नहीं कहा था, बल्कि “exploit complexity increase” को उपलब्धि बताया था। वाक्य कुछ अस्पष्ट ज़रूर है, लेकिन मेरी reading में इसका मतलब यह है कि केवल PAC पर्याप्त नहीं था और SW/HW combined approach की जरूरत को स्वीकार किया गया था। PAC भी software changes माँगने वाला hardware feature है, लेकिन EMTE उससे कहीं अधिक व्यापक स्तर और समन्वय माँगने वाली तकनीक है
  • PAC का मतलब यह नहीं कि वह बेकार है, बल्कि यह attackers को मजबूर करता है कि वे PAC bypass ज़रूर खोजें। PAC bypasses की संख्या अनंत नहीं है
  • PAC कई बार bypass हुआ है, इससे वह निष्प्रभावी साबित नहीं होता; उलटे इसका मतलब है कि वह उतनी प्रभावी तरह से काम कर रहा है