iLeakage: Apple डिवाइसों पर ब्राउज़र-आधारित timerless speculative execution हमला

 (ileakage.com)
1 पॉइंट द्वारा GN⁺ 2023-10-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Spectre mitigation लगभग 6 साल से जारी है, लेकिन iLeakage दिखाता है कि Mac, iPad और iPhone पर Safari में speculative execution side-channel का अब भी दुरुपयोग किया जा सकता है
  • हमलावर उपयोगकर्ता को किसी malicious webpage पर जाकर क्लिक करने के लिए उकसाने के बाद, JavaScript और WebAssembly से Safari को मनचाहे webpage render करने पर मजबूर कर सकता है और संवेदनशील जानकारी वापस हासिल कर सकता है
  • डेमो में Gmail के हाल के message titles, Instagram autocomplete credentials, YouTube watch history, और Apple M3-आधारित MacBook Pro पर Facebook password व SMS 2FA token की recovery शामिल थी
  • प्रभाव का दायरा उन macOS और iOS डिवाइसों तक है जो Apple A-series·M-series CPU का उपयोग करते हैं, और iOS 17.2 व macOS 14.2 में शामिल Safari 17.2 में इसका mitigation किया गया है
  • Lockdown Mode या JavaScript disable करके भी इससे बचा जा सकता है, लेकिन इससे फीचर सीमित हो जाते हैं, और क्योंकि यह Safari के भीतर चलता है तथा system logs में कोई निशान नहीं छोड़ता, इसका detection बहुत कठिन है

Apple डिवाइसों पर फिर सामने आया Spectre का खतरा

  • iLeakage Safari web browser को निशाना बनाने वाला speculative execution side-channel हमला है
  • इसका लक्ष्य Apple के A-series या M-series CPU इस्तेमाल करने वाले macOS और iOS डिवाइस हैं
    • इसमें हाल के iPhone और iPad शामिल हैं
    • 2020 के बाद के Apple laptop और desktop भी शामिल हैं
  • सामान्य रूप से एक browser tab का code दूसरे tab की सामग्री का अनुमान नहीं लगा पाना चाहिए, लेकिन iLeakage हमलावर के पेज पर जाकर क्लिक करने वाले उपयोगकर्ता के target webpage की सामग्री पढ़ सकता है
  • वापस हासिल की जा सकने वाली जानकारी में निजी डेटा, password और credit card जानकारी शामिल हो सकती है
  • शोधकर्ताओं ने 12 सितंबर 2022 को Apple को अपने निष्कर्ष बताए थे, जो सार्वजनिक रिलीज़ से 408 दिन पहले था

वास्तव में वापस हासिल किया गया संवेदनशील डेटा

  • शोधकर्ताओं ने लोकप्रिय सेवाओं से high-value information वापस हासिल करने के उदाहरण दिखाए

  • Instagram credentials

    • macOS Safari में उस स्थिति का उपयोग किया गया जहाँ उपयोगकर्ता LastPass autocomplete credential manager के साथ Instagram में लॉग इन करता है

  • Gmail inbox

    • iOS Safari में यह मानकर कि उपयोगकर्ता Google में लॉग इन है, iPad पर Gmail खाते के हाल के message titles वापस हासिल किए गए

  • YouTube watch history

    • iOS के Chrome में YouTube watch history वापस हासिल की गई
    • Apple App Store policy की वजह से iOS का Chrome Safari browsing engine के ऊपर एक shell की तरह काम करता है

  • Facebook password और 2FA token

    • Apple M3 chip वाले MacBook Pro, macOS 14.1.1 और Safari 17.1 वातावरण में पहले Facebook password वापस हासिल किया गया
    • इसके बाद Android फोन पर भेजा गया SMS 2FA token, Google Messages के जरिए वापस हासिल किया गया

Spectre और side-channel कैसे काम करते हैं

  • अधिकांश आधुनिक CPU, branch result तुरंत उपलब्ध न होने पर execution path का अनुमान लगाकर उस path के निर्देश पहले प्रोसेस करने के लिए speculative execution का उपयोग करते हैं
  • यदि अनुमान गलत हो, तो CPU state changes को वापस ले लेता है, लेकिन cache जैसी microarchitectural state में निशान रह सकते हैं
  • Spectre एक hardware vulnerability है जो इन्हीं निशानों का उपयोग करके ऐसा डेटा पढ़ती है जिसे मूल program semantics के अनुसार access नहीं किया जा सकता
  • Side-channel, program के सुरक्षित algorithm चलाने पर भी system implementation की विशेषताओं का दुरुपयोग कर सकता है
    • उदाहरण के तौर पर sound, electromagnetic radiation, thermal throttling, और CPU microarchitectural resource sharing शामिल हैं
  • जब हमलावर और target एक ही CPU पर चलते हैं, तो वे core, cache और internal buffer जैसे संसाधन साझा करते हैं, और इस प्रतिस्पर्धा को timing या power consumption जैसे संकेतों से परोक्ष रूप में मापा जा सकता है

Safari की defenses को bypass करने वाला timerless attack design

  • Spectre के बाद browser vendors speculative execution और transient execution हमलों के खिलाफ defenses मजबूत करते रहे हैं
  • Safari defenses में 35-bit addressing, value poisoning, प्रति-tab process isolation policy, और low-resolution timers शामिल हैं
  • iLeakage, Apple Silicon CPU और Safari के खिलाफ पहला demonstrated speculative execution हमला है
  • हमला Apple CPU की सार्वजनिक रूप से अज्ञात cache configuration को अनुभवजन्य तरीके से पुनर्निर्मित करने से शुरू होता है
    • इसके बाद केवल low-resolution timer के सहारे cache hit और miss में फर्क करने वाला speculation-based gadget बनाया जाता है
    • timer के बिना race condition का उपयोग करने वाला एक variant भी दिखाया गया
  • यह gadget eviction set generation test और covert channel, दोनों में इस्तेमाल होता है
  • Safari में तकनीक ले जाने के बाद, CPU ke speculative execution के दौरान Safari को किसी विशेष data type के लिए बने code ko हमलावर द्वारा बनाए गए गलत type object पर चलाने के लिए मजबूर किया जाता है
  • अंततः Safari rendering process address space में कहीं से भी out-of-bounds read संभव हो जाता है
  • अलग-अलग domain की websites को एक ही address space में जोड़ने की नई विधि के साथ मिलाकर, संवेदनशील जानकारी लीक करने वाला speculative type confusion हमला किया जाता है

Mitigation, detection की कठिनाई, और browser-वार प्रभाव

  • iLeakage का mitigation Safari 17.2 में किया गया है, और Safari 17.2 iOS 17.2 व macOS 14.2 में शामिल है
    • इसका उपाय Apple डिवाइसों को नवीनतम OS version पर अपडेट करना है
  • Lockdown Mode Safari के JIT compilation को disable करके iLeakage को mitigate करता है
    • JIT compilation वह performance feature है जिसका उपयोग iLeakage अपने attack primitive बनाने में करता है
    • Lockdown Mode डिवाइस के व्यवहार को बदल सकता है, जैसे कुछ message attachments और अज्ञात FaceTime calls को block करना
    • पूरी सूची Apple के Lockdown Mode दस्तावेज़ में है
  • JavaScript disable करना भी iLeakage को रोकता है, लेकिन इससे Safari कुछ websites को गलत या अधूरे रूप में render कर सकता है, और online payment जैसी advanced web features काम नहीं कर सकतीं
  • iLeakage Safari के भीतर चलता है और system log files में कोई निशान नहीं छोड़ता, इसलिए इसका detection बहुत कठिन है
    • हालांकि हमलावर webpage पर जाने का निशान हाल ही में देखे गए pages के browser cache में रह सकता है
  • वास्तविक exploitation का कोई प्रमाण नहीं है
    • end-to-end attack setup बहुत कठिन है और इसके लिए browser-based side-channel attacks तथा Safari implementation का उन्नत ज्ञान चाहिए
  • credential managers का उपयोग जारी रखने की सिफारिश की जाती है
    • iLeakage webpage में autofill किए गए credentials वापस हासिल कर सकता है
    • कई platforms में autofill होने के लिए user interaction जरूरी होता है
  • macOS पर Chrome, Firefox और Microsoft Edge अलग JavaScript engine का उपयोग करते हैं, इसलिए Safari JavaScript engine की विशिष्टताओं का दुरुपयोग करने वाला iLeakage वहाँ काम नहीं करता
  • iOS में Apple App Store और sandboxing policies के कारण अन्य browser apps भी Safari JavaScript engine का उपयोग करते हैं
    • iOS के Chrome, Firefox और Edge, bookmarks और settings sync जैसी सहायक सुविधाएँ देने वाले Safari wrappers हैं
    • App Store के लगभग सभी browser applications iLeakage के प्रति संवेदनशील हैं
  • शैक्षणिक पेपर iLeakage paper के रूप में उपलब्ध है और 2023 ACM Conference on Computer and Communications Security में प्रकाशित हुआ था

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

1 टिप्पणियां

 
GN⁺ 2023-10-26
Hacker News की राय

  • इस FAQ में कुछ चीज़ें छूटी हुई लगती हैं: यह WebKit vulnerability है या Safari vulnerability, mobile Safari में वह developer setting नहीं है तो क्या Lockdown Mode चालू करने से mitigation होता है, और Apple को कब disclose किया गया था — यह जानना चाहूंगा
    बाद में पेज अपडेट हुआ और आखिरी सवाल का जवाब मिल गया: researchers ने 12 सितंबर 2022 को Apple को अपने नतीजे disclose किए थे, जो public release से 408 दिन पहले था

    • तकनीकी तौर पर इसे Hacker News Favorite Processor, यानी M1/M2 vulnerability कहा जा सकता है, लेकिन बाज़ार में मौजूद संबंधित CPU लगभग सभी वही vulnerability रखते हैं, इसलिए यह ऐसी feature जैसी बन गई है जिसके लिए software को mitigation design करना पड़ता है
      WebKit से सभी संभव Spectre gadgets हटाना अव्यावहारिक है, इसलिए browser को अलग-अलग websites को अलग-अलग processes में isolate करके operating system की Spectre mitigations का उपयोग करना चाहिए
      FAQ में लिखा है कि “आखिरकार Safari rendering process के address space में कहीं भी out-of-bounds read हासिल हो जाता है”, इसलिए निजी तौर पर मैं इसे Safari की site isolation के गलत implementation की vulnerability मानता हूं
    • आखिरी सवाल का जवाब FAQ में है: researchers ने 12 सितंबर 2022 को Apple को अपने नतीजे disclose किए थे, जो public release से 408 दिन पहले था
    • यह Safari या दूसरे browsers के अंदर Spectre जैसी speculative execution side channel का लाभ उठाने वाली architectural vulnerability जैसी लगती है
      किन environments में इसका exploit संभव है, यह उस JavaScript-based gadget के detailed implementation पर निर्भर करता है जो इस side channel को trigger और measure करता है, और यह शायद उस paper में होगा जिसे मैंने अभी नहीं पढ़ा है
    • अब FAQ में जवाब आ गया है: यह Safari vulnerability है, और इसमें लिखा है कि “iLeakage Safari के JavaScript engine की विशेषताओं का दुरुपयोग करता है”
      Lockdown Mode Safari में JIT compilation को disable करता है, इसलिए यह mitigation देता है, और iLeakage जिन performance features का इस्तेमाल attack primitives बनाने के लिए करता है उन्हें रोकता है

  • “अगर credential manager इस्तेमाल करें तो क्या जोखिम है?” इस पर ज़्यादातर जवाब नहीं कहते हैं, लेकिन अगर memory से कुछ leak हो रहा है तो Safari process space के अंदर की सारी memory पर असर पड़ना चाहिए, ऐसा लगता है
    मैं इस क्षेत्र से बहुत परिचित नहीं हूं, इसलिए समझ नहीं आ रहा कि credential manager का इस्तेमाल करना या न करना exception condition क्यों बनता है

    • मूल रूप से वे शायद यह कह रहे हैं: इस खास attack के खिलाफ यह अतिरिक्त सुरक्षा नहीं देता, लेकिन password manager इस्तेमाल करना आम तौर पर अधिक सुरक्षित है, और इससे आप इस attack के प्रति ज़्यादा vulnerable भी नहीं होते
      लगता है वे लोगों को “newpassword2” जैसे तरीकों पर लौटने से रोकना चाहते हैं, और auto-fill बंद करके shortcut key या किसी और user interaction से भरना अधिक सुरक्षित है
    • demos में से एक में password manager ने fields को auto-fill कर दिया, जिससे वे memory में आ गए, और इस वजह से Instagram जैसी third-party site का username/password combo recover किया गया
      इसे ऐसे भी पढ़ा जा सकता है कि अगर आप password manager इस्तेमाल न करें, browser में भी save न करें और हर बार खुद type करें तो immune हैं, लेकिन यह कई वजहों से अच्छा counterargument नहीं है
      password manager कई अन्य कारणों से फायदेमंद हैं, और password चोरी होने पर भी कम-से-कम सिर्फ एक website compromise होती है
      यह technique शायद session tokens भी चुरा सकती है, जो password theft जितना बुरा न सही, फिर भी खराब है
      अगर password manager को click करने पर ही fill करने के लिए set करें, तो यह attack भी रोका जा सकता है
    • मतलब शायद यह है कि password manager इस्तेमाल करने से आप ज़्यादा vulnerable नहीं होते
      page में auto-filled password को manually typed password की तरह recover किया जा सकता है, लेकिन password manager में stored सभी passwords को सीधे read नहीं किया जा सकता
    • मेरी समझ में यह vulnerability संबंधित Safari/WebKit process की memory तक, खासकर window.open call से खोली गई sites तक ही access देती है
      अलग password manager app में stored passwords तब तक inaccessible हैं जब तक वह app उन्हें compromised Safari window या process में auto-fill न कर दे
    • मेरी समझ में Safari आम तौर पर अलग-अलग origins और extensions को अलग-अलग address spaces में रखता है, इसलिए speculative execution attacks के प्रति vulnerable नहीं होता
      इस attack ने ऐसा तरीका खोजा है जिससे दो अलग-अलग origins एक ही address space share करने लगते हैं, और मुझे लगता है यह extensions पर लागू नहीं होता
      paper में लिखा है: “Safari की site isolation policy का दुरुपयोग करते हुए, हम एक नई technique दिखाते हैं जिसमें attacker page को JavaScript window.open API से किसी भी victim page को खोलना भर होता है और वे address space share करने लगते हैं”

  • समझ नहीं आ रहा कि इसे सिर्फ WebKit-specific बताना वाकई सही है या नहीं। cache exploitation खुद तो generic लगती है, और quote में भी कहा गया है कि Safari, Firefox, Tor में लगभग perfect accuracy दिखी
    साथ ही यह भी जानना चाहूंगा कि window.open() के जरिए attack सच में WebKit-specific है, या इस research में सिर्फ WebKit को गहराई से देखा गया
    window.open() में calling window को नई window का reference मिलता है, और नई window के पास window.opener के जरिए back-reference होता है, जिससे shared context का संकेत मिलता है; ऐसे में क्या दूसरे browser engines पूरी isolation हासिल करते हैं, यह भी सवाल है

    • Chromium और Firefox ने desktop browsers में site isolation implement किया है, इसलिए same site न होने वाले pages को same process में load नहीं होना चाहिए
      mobile browsers में Chromium की site isolation सीमित है, और Firefox ने अभी implementation पूरा नहीं किया है
      https://www.chromium.org/Home/chromium-security/site-isolati...

  • उलझन भरा है। यह high-severity issue जैसा दिखता है, लेकिन fix debug menu के पीछे है। समझ नहीं आता कि इसे ठीक से हर जगह deploy होने से पहले public क्यों किया गया
    यह यह भी दिखाता है कि side-channel mitigations असल में लगभग बेकार हैं और ऐसे attacks को fix हो गया मानकर नहीं चलना चाहिए
    आधुनिक CPU पर कई applications चलाने वाला host हो, तो चाहे sandboxing कितनी भी हो, untrusted code चलाना safe नहीं है

    • लगता है Apple के पास इसे fix करने के लिए 400 दिनों से ज़्यादा समय था, और यह उससे भी ज़्यादा है जितना समय मैं देता
      Apple users को risk जाने बिना फिर एक साल से ज़्यादा छोड़ देने से बेहतर है कि उन्हें risk बता दिया जाए
      कंपनियों को bug fix करने का समय देने के पक्ष में हूँ, लेकिन एक समय के बाद प्रभावित लोगों को न बताना ज़्यादा गैर-जिम्मेदाराना हो जाता है
    • mitigation status मुझे भी confusing लगता है, लेकिन website की तुलना में paper ज़्यादा clear है
      paper बताता है कि speculative JavaScript sandbox escape अभी भी संभव है, लेकिन attacker अपने address space और अपना data पढ़ने तक सीमित रहता है
      लिखे जाने के समय Apple patch public था और Safari Technology Preview 173 या उससे ऊपर में implemented बताया गया है, और [57] https://github.com/WebKit/WebKit/pull/10169 है
      उसके नीचे engineer window.open() और process isolation के लिए additional hardening patches लगातार link कर रहा है
    • मुझे लगा था कि standard Safari 17.0 on Ventura में Swap Processes on Cross-Site Window Open पहले से on है और Stable के रूप में marked है
      मैंने खुद इसे on नहीं किया था, इसलिए सोचा कि शायद Apple ने पहले ही enable कर दिया है और description पुराना है, लेकिन बाद में देखा कि मैं मिलते-जुलते नाम वाले Swap Processes on Cross-Site Navigation को देख रहा था, और फिलहाल यह default enabled नहीं लगता
    • क्योंकि “privacy और security का आखिरी किला” कहने वाली Apple ने इसे 400 दिनों से ज़्यादा पकड़े रखा और फिर भी fix नहीं किया
      fix deploy होने से पहले public करने वाले researchers से ज़्यादा, इतने लंबे समय तक हाथ पर हाथ धरे बैठी Apple को दोष देना चाहिए
    • यह fix WebKit के process model को बदलना मांगता था, इसलिए पूरी deployment से पहले शायद अभी testing में है और debug menu के पीछे रखा गया है
      सभी side-channel attacks fix नहीं हुए हैं, लेकिन side-channel mitigations को बेकार कहना ठीक नहीं है
      seatbelt लगाने के बाद भी car accident में लोग मरते हैं, पर इसका मतलब यह नहीं कि seatbelt बेकार है; उसी तरह mitigations exploitation की कठिनाई काफी बढ़ा देते हैं

  • “researchers ने 12 सितंबर 2022 को Apple को findings disclose कीं” — सच में जानना चाहता हूँ कि Apple ने एक साल से ज़्यादा इसे लगभग क्यों छोड़े रखा

    • क्योंकि वे कर सकते हैं
      Apple CVE power holders में से एक है, इसलिए वह अपने products के लिए CVE जारी करने से इनकार कर सकता है, और ऐसी ताकत हो तो वे जितना चाहें उतना slow move कर सकते हैं

  • मुझे iLeakage website पर fix से जुड़ा wording दिखा था, लेकिन वह गायब हो गया। लगा शायद मैं गलत समझा, पर असल में पिछले एक घंटे में website बदल रही थी
    वहाँ लिखा था, “Apple ने अभी iOS 17.1, iPadOS 17.1, macOS Sonoma 14.1 release किए हैं, इसलिए अपनी devices update करें”, और अब इसे rollback कर दिया गया है
    https://github.com/ileakage-authors/ileakage-authors.github....

    • लगता है paper authors में से कोई इस thread को पढ़ रहा है
      जब मैंने point out किया कि site पर disclosure timeline नहीं है, तो FAQ में एक छोटा section add हुआ; यहाँ fix deploy हुआ है या नहीं, यह स्थिति confusing है, इसलिए लगता है researchers भी उसी confusion में आ गए
    • अजीब है। iOS 17.1 पर update करने के बाद Settings -> Safari -> Advanced -> Feature Flags के नीचे Swap Processes on Cross-Site Navigation है और default में on है
      सोच रहा हूँ कि क्या यह macOS के Swap Processes on Cross-Site Window Open से अलग है

  • “iLeakage ऐसा attack है जिसे अंत तक execute करना काफी मुश्किल है, और browser-based side-channel attacks व Safari implementation की advanced knowledge चाहिए” — शायद यही वजह हो कि Apple इसे लेकर बहुत चिंतित नहीं है

    • इसका मतलब लगता है कि इसे execute करना इतना मुश्किल है कि practically impossible है, और वास्तविक risk लगभग 0% के करीब है
      एक और डरावना nickname और domain name जोड़ देना न professional लगता है, न भरोसेमंद

  • अगर Apple A-series या M-series CPU वाले macOS या iOS devices, यानी हाल के iPhone/iPad और 2020 के बाद के Apple laptops/desktops affected हैं, तो rare Intel Mac user होने के नाते शायद मैं affected नहीं हूँ

    • शायद affected होने की संभावना काफी है
      बस cache hierarchy थोड़ी अलग है, और proof of concept में थोड़े changes की जरूरत होगी
    • अगर macOS है तो Safari इस्तेमाल न करें
      अगर iOS है तो Lockdown Mode इस्तेमाल करना चाहिए, और iPhone को safely use करने का यही एकमात्र तरीका है
      Lockdown Mode के बिना किया गया benchmark उतना ही बेकार मानना चाहिए जितना mitigations=off के साथ CPU benchmark चलाना

  • iOS devices पर दूसरे browser engines allow करने की एक और अच्छी वजह है

    • EU regulation आखिरकार Apple को मजबूर कर सकता है

  • नीचे दिया command चलाते समय error आए, तो Terminal को Full Disk Access दें और फिर कोशिश करें
    defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1