आख़िरी 0day जेलब्रेक: Tachy0n

• tachy0n iOS 13.0~13.5 के लिए आख़िरी सार्वजनिक 0day जेलब्रेक exploit का एक उदाहरण है
• यह बग Lightspeed कहलाने वाले lio_listio system call की race condition पर आधारित kernel LPE (privilege escalation) vulnerability exploitation है
• Spice और unc0ver सहित कई जेलब्रेक प्रोजेक्ट्स ने इस vulnerability का वास्तविक उपयोग किया, और यह exploit तरीके तथा memory management issues को हैक करने की तकनीकों को समझाता है
• इस exploit के सार्वजनिक होने के बाद Apple ने patches और regression tests लागू किए, और अधिक मज़बूत kernel object isolation (Zone, kheap आदि) तथा pointer protection features को काफ़ी मज़बूत किया
• इसके बाद iOS 14 से जेलब्रेक और kernel exploit का परिदृश्य मूल रूप से बदल गया, और अब कोई सार्वजनिक kernel exploit मौजूद नहीं है

---

0. परिचय

• tachy0n एक पुराना exploit है जो iOS 13.0 से 13.5 तक लागू होता है
• 23 मई 2020 को unc0ver v5.0.0 में इसे 0day के रूप में सार्वजनिक किया गया, और सिर्फ़ 1 हफ़्ते में Apple ने emergency patch जारी कर दिया
• इस vulnerability का पहले भी 1day के रूप में उपयोग हो चुका था, इसलिए exploit techniques के नज़रिए से इसे एक महत्वपूर्ण उदाहरण माना जाता है
• यह लेख vulnerability के source और उसके discovery process को विस्तार से समझाता है

1. Lightspeed

• यह vulnerability Synacktiv द्वारा प्रकाशित Lightspeed bug (CVE-2020-9859 आदि) है, जिसमें lio_listio syscall के asynchronous I/O context memory free होने के दौरान race condition की समस्या होती है
• memory double free condition बनाने के लिए I/O operation timing को नियंत्रित किया जाता है, और दो बार object free कराके एक ही memory region में कई objects को overlap कर exploit किया जा सकता है
  • kernel के kalloc.16 zone में dynamic memory allocation structure को exploit में इस्तेमाल किया जाता है
  • मूल रूप से यह race को कई बार दोहराकर success probability बढ़ाने का तरीका है

2. Spice

• इस exploit का उपयोग पहले team Jake Blair द्वारा बनाए गए Spice jailbreak में किया गया था
• racoon और app में exploit के अलग-अलग variants लागू किए गए, और मुख्य लक्ष्य mach port forgery था
• iOS 11.x के समय PAN (Protection Against Null dereference) bypass करना आसान था, और kernel infoleak तथा sandbox escape के साथ कई तरह की hacking techniques आज़माई गईं
• racoon के मामले में IOKit access restrictions के कारण OSUnserializeXML का उपयोग कर kernel के उस zone के लिए spray target objects बनाए गए
• sysctl_procargsx, kernel uninitialized memory leak, sandbox policies जैसी बारीक भिन्नताएँ और बाद की तकनीकी प्रगति का भी वर्णन किया गया है

3. unc0ver

• unc0ver में लागू करते समय exploit structure को इस तरह डिज़ाइन किया गया कि यह A8~A13 सहित व्यापक SoC range पर काम करे
• OSData objects की nesting और overlapping को track किया जाता है, और सही समय पर इच्छित objects को free/allocate करके memory region को नियंत्रित किया जाता है
• IOMemoryDescriptor जैसे kernel objects का उपयोग कर user-controlled data buffer address को expose किया जाता है और kernel से direct read/write लागू किया जाता है
• iOS 13 kernel allocator policies की कमज़ोरियों, जैसे zone_require bypass, का उचित उपयोग किया गया
• पूरे exploit structure का detailed implementation सार्वजनिक GitHub repository (tachy0n) में देखा जा सकता है

4. बाद का प्रभाव

• इस 0day exploit के सार्वजनिक होने से security community और Apple दोनों पर बड़ा असर पड़ा
  • वास्तविक exploit के सार्वजनिक होने के 4 घंटे के भीतर ही Project Zero और Synacktiv ने detailed analysis और response शुरू कर दिया
• patch के बाद Apple ने इस vulnerability के लिए XNU में औपचारिक regression test जोड़ दिए, यानी मूलभूत security strategy को मज़बूत करने की दिशा में बदलाव किया
• iOS 14 से allocation region separation, object secure guards, PAC (Pointer Authentication Code), kheap structure आदि जैसे बड़े बदलाव लागू किए गए, जिन्होंने exploit बनाना काफ़ी कठिन बना दिया
• अब exploit strategy ख़ुद ज़्यादा महत्वपूर्ण हो गई है, और public information तथा private research के बीच का अंतर बढ़ गया है; iOS 17~18 के लिए तो कोई सार्वजनिक kernel exploit है ही नहीं

5. निष्कर्ष

• यह मामला साफ़ दिखाता है कि iOS security और jailbreak क्षेत्र 5 साल में नाटकीय रूप से बदल चुका है
• यह jailbreak/exploit community, researchers और Apple की तकनीकी दिशा कैसे बदली, इस पर महत्वपूर्ण insight देता है
• IL साझा करने और खुली चुनौती देने का दौर अब अतीत बन चुका है, और iOS 14 के बाद exploit information sharing काफ़ी कम हो गई है

संदर्भ और संपर्क

• संबंधित source code और विस्तृत जानकारी Siguza की व्यक्तिगत वेबसाइट और सार्वजनिक GitHub repository पर देखी जा सकती है

[ndrgrd]

Apple का hardware बेहतरीन है, लेकिन उसका software उपयोगकर्ताओं को बाँधकर रखने की मंशा से भरा हुआ है.
आप अपनी बनाई और build की हुई app को सिर्फ अपने ही device पर चलाना चाहें, तब भी 100 डॉलर का subscription चाहिए.

अगर आप छोटे या मध्यम स्तर के open source apps इस्तेमाल करते हैं और उन्हें खुद build करके चलाने वाले developer हैं,
तो Apple के device पर vulnerability का फायदा उठाकर jailbreak करके sideload करने से बेहतर है कि बस Android इस्तेमाल करें.

[GN⁺]

Hacker News राय

• मेरे हिसाब से उसने Apple जैसी विशाल कंपनी को हराने का असली तरीका कोई जादुई चीज़ नहीं, बल्कि उबाऊ और बार-बार किया जाने वाला काम था: regression testing पर जोर SockPuppet पहले भी iOS 12 के दौर में jailbreak के लिए इस्तेमाल हुआ था, और Project Zero के Ned Williamson ने Apple को इसकी सूचना दी थी। iOS 12.3 में patch होने के बाद भी यह iOS 12.4 में फिर से दिखा शायद Apple ने XNU को अलग branch में fork करते समय उस patch को छोड़ दिया, और मूल समस्या यह थी कि ऐसे नए/पुराने vulnerabilities के लिए regression testing लगभग थी ही नहीं मैंने खुद कुछ known 1-day vulnerabilities को regression tests के रूप में automate करके चलाया, और तुरंत सफलतापूर्वक vulnerabilities ढूंढ लीं सोचता हूं कि Linux, FreeBSD, OpenWRT, OpenSSH जैसे अलग-अलग open source projects भी क्या नए versions पर पुरानी vulnerabilities के regression tests चलाते हैं अगर हर vulnerability को automated रूप में लिखा जाए और CI में resources लगाकर चलाया जा सके, तो इसका फायदा काफी बड़ा हो सकता है
• regression testing, यानी यह जांचना कि ठीक किया गया bug दोबारा न आए, QA की standard procedure है, इस पर जोर 20 साल पहले यूनिवर्सिटी के दिनों में Mozilla में volunteer QA करते समय सैकड़ों regression test cases देखे थे ज़्यादातर rendering/layout और JS engine bugs होते थे, और अगर minimized test case बना लिया जाए तो उसे सीधे CI pipeline में जोड़ा जा सकता था bugs तो किसी हद तक अपरिहार्य हैं, लेकिन जो bug पहले ही ठीक हो चुका हो उसका फिर लौट आना समय और लागत की सबसे बुरी बर्बादी है; जो संगठन quality की परवाह करते हैं वे regression testing में ज़रूर भारी निवेश करते हैं अफसोस की बात है कि बहुत-से संगठन QA को नज़रअंदाज़ करते हैं या सिर्फ outsourcing से निपटाना चाहते हैं और गंभीरता से ध्यान नहीं देते Apple के पास jailbreak-संबंधित regression tests नहीं थे, यह समझ से बाहर है Mozilla वगैरह में बहुत पहले से Tinderbox, Bugzilla जैसे tools के जरिए शानदार QA और CI/CD environment बना लिया गया था, और मुझे लगा था कि DevOps शब्द लोकप्रिय होने से पहले भी यह तरीका आम था, लेकिन बाद में पता चला कि असलियत ऐसी नहीं थी
• नाम याद नहीं, लेकिन एक open source project का उदाहरण दिया गया जिसमें हर issue के लिए test case था हजारों test cases थे; शायद वह Sqlite था यह भी जोड़ा कि अगर patch backport नहीं किया जाता, तो उसके साथ जुड़े tests भी backport न होने की संभावना काफी रहती है
• कई संगठनों में security issues को अलग workflow और अलग तरह के bugs की तरह अलग कर देना ही मूल समस्या है आखिरकार Conway's law security और feature development के बीच भी वैसा ही लागू होता है इसलिए भले ही किसी संगठन के build/release process में regression testing अच्छी तरह मौजूद हो, उसकी internal structure की वजह से security-related issues छूट जाने की संभावना बढ़ जाती है
• “क्या दूसरे projects भी ऐसे regression tests चलाते हैं?” इस सवाल पर, राय दी गई कि intelligence agencies (G10, रूस, चीन, उत्तर कोरिया आदि) और कई private groups तो निश्चित रूप से vulnerabilities के regression tests इसी तरह चलाते होंगे
• मैं security researcher नहीं हूं, लेकिन यह मामला व्यक्तिगत रूप से भी बहुत relatable लगा
• “heap isolation से जुड़ी जानकारी, तरह-तरह की mitigations सब भूल जाओ” जैसी बात पर, इसे उस स्थिति से तुलना की गई जहां आप किसी दोस्त से विदेशी भाषा में बात कर रहे हों और अगले ही पल बातचीत brain surgery या nuclear physics जैसे बेहद विशेषज्ञ विषय पर पहुंच जाए और दिमाग सुन्न हो जाए मुझे पुराने समय की याद आई जब मैंने steel mill repairs से जुड़ी बातचीत का दुभाषिया बनने की कोशिश की थी jailbreak का लगभग गायब हो जाना खलता है; jailbreak किया हुआ iPad मैंने कोई खास उपयोगी काम में नहीं लगाया था, लेकिन वह अपने-आप में मजेदार था आज होता तो tethering app, UTM, या JIT solution install करना चाहता SideStore promising लग रहा है और उसे आजमाना चाहता हूं, लेकिन मेरा Apple account पहले paid developer account था और 10 app IDs अभी तक expire नहीं हुए हैं, इसलिए ऐसे apps install करने पर restrictions हैं या तो नया account बनाना पड़ेगा या फिर दोबारा पैसे देने पड़ेंगे
• मैंने अपना पुराना iPhone 4 jailbreak करके इस्तेमाल किया था jailbreak के बिना iPhone को main phone की तरह इस्तेमाल करने की मेरे लिए कोई वजह नहीं थी, और आखिरकार मैं Android पर चला गया उसी समय तक Android basic features के मामले में काफी हद तक बराबरी पर आ चुका था
• सुना है कि Apple अब jailbreak के लिए एक million dollars तक reward देता है, और यही market में बनती हुई minimum price है
• असल में यह price ceiling 2015 में ही टूट गई थी, और 1 million dollars वाले मामले का लेख साझा किया गया
• जिज्ञासा जताई गई कि jailbreak में सफलता मिलने पर Apple से कई million dollars का reward पाने के लिए संपर्क कैसे किया जाए क्या किसी broker के जरिए जाना पड़ता है, कोई official email या channel है, और क्या यह जोखिम नहीं कि मामला first-line support में ही दब जाए
• यही तो market price है, और संबंधित लेख का लिंक साझा किया गया: Zerodium का zero-day bounty
• अगर Apple की strategy सही मानी जाए, तो root privileges पाने के सभी रास्ते बंद करके Apple ऐसा ढांचा बना लेता है जिसमें jailbreak developers जो vulnerabilities मुफ्त में ढूंढते हैं, उनका फायदा भी Apple को मिल जाता है
• लेकिन हकीकत ऐसी नहीं है जैसा लेख में कहा गया, private communities में अभी भी vulnerabilities मौजूद हैं और Apple लगातार patch करता रहता है बस public को दिखने वाले jailbreak कम हो गए हैं
• एक राय यह भी थी कि भले ही context में उस शब्द का मतलब थोड़ा अलग हो, फिर भी समझा जा सकता है कि वह slang किस ओर इशारा कर रहा है
• शायद किसी ने सोचा हो कि उसने वह शब्द खुद गढ़ा है, लेकिन वास्तव में उसका slang के रूप में पहले से इस्तेमाल मौजूद था