GoFetch: डेटा मेमोरी-निर्भर प्रीफेचर का उपयोग करने वाला नया साइड-चैनल अटैक

 (gofetch.fail)
1 पॉइंट द्वारा GN⁺ 2024-03-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डेटा मेमोरी-निर्भर प्रीफेचर (DMP) क्रिप्टोग्राफिक कोड के डेटा वैल्यूज़ को पते की तरह ट्रीट करता है, जिससे constant-time implementations में भी secret key लीक हो सकती है
  • Apple m-series CPU में, जब मेमोरी से लोड की गई वैल्यू pointer जैसी दिखती है, तो DMP dereference करने की कोशिश करता है, जिससे डेटा और एड्रेस के अलगाव पर आधारित constant-time programming की धारणा कमजोर पड़ती है
  • शोधकर्ताओं ने Apple m1 पर OpenSSL Diffie-Hellman, Go RSA decryption, CRYSTALS-Kyber और CRYSTALS-Dilithium से end-to-end key extraction दिखाया, और m2·m3 में भी समान DMP behavior की पुष्टि की
  • m3 में DIT bit DMP को प्रभावी रूप से disable कर देता है, लेकिन यह m1·m2 पर लागू नहीं होता; अप्रैल 2024 में मिला HID setting bit macOS kernel support न होने के कारण तुरंत इस्तेमाल करना कठिन है
  • Mitigation में software को up to date रखना, कुछ CPU पर DIT/DOIT bit का उपयोग, input blinding और hardware sharing से बचना शामिल है; vulnerability assessment के लिए cryptanalysis और code inspection चाहिए

GoFetch अटैक का मूल सार

  • GoFetch डेटा मेमोरी-निर्भर प्रीफेचर (DMP) का उपयोग करने वाला microarchitectural side-channel attack है
  • constant-time में लिखे गए cryptographic implementations से भी secret key extraction संभव है
  • शोधकर्ताओं ने जिन targets पर demonstration किया, वे हैं:
    • OpenSSL Diffie-Hellman Key Exchange
    • Go RSA decryption
    • CRYSTALS-Kyber
    • CRYSTALS-Dilithium
  • पेपर और tools क्रमशः Paper, Tools के रूप में उपलब्ध हैं

DMP constant-time assumption को कैसे तोड़ता है

  • Apple m-series CPU का DMP तब activate होता है और dereference करने की कोशिश करता है, जब memory से loaded data pointer जैसी दिखने वाली value हो
  • constant-time programming में data और address को अलग रखना जरूरी है, ताकि secret value के आधार पर branch, loop, memory access या array index न बदलें
  • victim code इस नियम का पालन करे तब भी, DMP hardware level पर उसकी जगह secret-dependent memory access बना सकता है
  • नतीजतन, जो code मूल रूप से constant-time होना चाहिए, उसमें observable timing differences पैदा होते हैं और वह key extraction attack के exposure में आ जाता है

अटैक की प्रक्रिया

  • attacker cryptographic operation में जाने वाला chosen input ऐसा बनाता है कि secret key के किसी हिस्से का सही अनुमान होने पर ही intermediate state में pointer जैसी दिखने वाली value प्रकट हो
  • इसके बाद cache timing analysis से यह जांचता है कि DMP ने dereference किया या नहीं, और इस तरह अनुमान सही है या नहीं verify करता है
  • सही अनुमान confirm होने पर, वही तरीका अगले key bit group का अनुमान लगाने के लिए इस्तेमाल होता है
  • इस प्रक्रिया से classical cryptography और post-quantum cryptography implementations में end-to-end key extraction संभव है

प्रभावित processors और observations

  • end-to-end GoFetch attack Apple m1 processor वाले hardware पर किया गया
  • m2 और m3 CPU भी इसी तरह exploit किए जा सकने वाले DMP activation patterns दिखाते हैं
  • m2 Pro जैसे अन्य m-series variants को test नहीं किया गया, लेकिन वे simple models जैसी ही microarchitecture इस्तेमाल करते हैं, इसलिए उनमें exploitable DMP होने की संभावना है
  • Intel 13th Gen Raptor Lake microarchitecture में भी DMP है
    • हालांकि activation criteria अधिक सीमित हैं, इसलिए यह GoFetch attack के खिलाफ मजबूत है

Augury से अंतर

  • Apple m-series DMP को सबसे पहले Augury ने खोजा था
  • Augury ने माना कि DMP कुछ conditions में data और address को मिला सकता है
  • GoFetch researchers ने माना कि Augury द्वारा summarize किए गए DMP activation criteria बहुत सीमित हैं
  • वास्तविक behavior में, memory से loaded कोई भी value dereference candidate हो सकती है, जिससे वास्तविक constant-time cryptographic code पर end-to-end attack संभव हो जाता है

Cache और prefetcher background

  • Modern processors memory access latency कम करने के लिए cache का उपयोग करते हैं
  • पहले access किया गया data cache में रह जाता है, जिससे बाद का access तेज होता है
  • उसी machine पर साथ चल रहा attacker shared cache state observe करके victim के access patterns infer कर सकता है
  • सामान्य prefetcher पिछले memory access addresses की tracking के आधार पर भविष्य में access होने वाले addresses predict करता है
  • DMP linked list traversal जैसे irregular access patterns संभालने के लिए memory contents तक को consider कर यह तय करता है कि कौन-सा data लाना है
  • यह behavior hardware level पर data और memory address को मिला देता है, इसलिए पूरा computation stack non-constant-time जैसा बन सकता है

Vulnerability assessment और mitigations

  • implementation vulnerable है या नहीं, यह तय करने के लिए यह जानना जरूरी है कि intermediate value कब और कैसे secret-dependent तरीके से pointer जैसी दिखने वाली बनाई जा सकती है
  • इस assessment के लिए cryptanalysis और code inspection चाहिए; यह manual और धीमा है, साथ ही अन्य attack methods को exclude नहीं कर सकता
  • कुछ processors में DMP को disable किया जा सकता है
    • m3 CPU में DIT bit setting DMP को प्रभावी रूप से disable करती है
    • यह m1 और m2 पर लागू नहीं है
    • Intel Raptor Lake में DOIT bit से DMP disable किया जा सकता है
  • अप्रैल 2024 में Hector Martin(marcan) ने m1·m2 CPU में DMP disable करने वाला HID setting bit SYS_APL_HID11_EL1[30] खोजा
    • इस chicken bit setting के लिए kernel support चाहिए
    • फिलहाल macOS में यह support नहीं है
    • संबंधित जानकारी @marcan की पोस्ट में है
  • users को latest software इस्तेमाल करने और regular updates की सलाह दी जाती है
  • cryptographic library developers समर्थ CPU पर DIT/DOIT bit set कर सकते हैं
  • input blinding कुछ cryptographic schemes में attacker-controlled intermediate values से बचने में मदद कर सकता है
  • attacker को DMP activation measure करने से रोकने के लिए hardware sharing से बचना cryptographic protocol security को और मजबूत कर सकता है

Disclosure और follow-up updates

  • शोधकर्ताओं ने 5 दिसंबर 2023 को Apple को results disclose किए थे, जो public release से 107 दिन पहले था
  • अगस्त 2024 में GoFetch ने Pwnie Award 2024 Best Cryptographic Attack जीता
  • दिसंबर 2024 की follow-up research में Intel DMP semantics को reverse engineer किया गया, और ऐसी technique दिखाई गई जिससे DMP invalid pointers को dereference करने की स्थिति में भी information leak कर सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-03-23
Hacker News की राय

  • जब efficient cores जैसी चीज़ों का दौर है, तो modern architecture में cryptographic cores की भी ज़रूरत हो सकती है
    ऐसे cores को constant-time algorithms से जुड़ी guarantees स्पष्ट रूप से देनी चाहिए, और prefetching या branch prediction वगैरह नहीं करनी चाहिए
    Itanium जैसा, लेकिन “cryptographic processor” तक सीमित रूप हो तो, कई features हट जाने के कारण सिद्धांततः core का silicon area भी बहुत बड़ा नहीं होगा
    cryptographic code implement करने वालों के लिए ऐसी समस्या शायद इतनी कठिन होगी कि शराब पीने का मन करे। सबसे अच्छे हालात में भी यह मुश्किल लड़ाई है, और सब कुछ सही implement करने पर भी आज और भविष्य के अनगिनत processor features कभी भी code को तोड़ सकते हैं

    • cryptographic implementer के नज़रिए से, ऐसी समस्याएँ सचमुच पागल कर देती हैं
      लेकिन cryptographic co-processor बहुत ही disruptive समाधान है। उस core पर switch करके वापस आना, memory share करना आदि के लिए infrastructure का पहाड़ बनाना पड़ेगा
      उससे भी गंभीर बात यह है कि RSA multiplication को ही उस core पर ले जाकर बात खत्म नहीं हो सकती। key कहीं न कहीं parse हुई होगी, तो क्या parser भी cryptographic core पर चले? अगर वह network से आती है तो क्या? सारी keys protect कर भी लें, तो अगर CPU side-channel encrypted message leak कर दे तो क्या वह ठीक है? क्योंकि वह key नहीं है, इसलिए क्या उसे ठीक मानें?
      non-cryptographic code में ऐसे attacks ज़्यादा नहीं दिखते क्योंकि target ढूँढना application के हिसाब से बहुत अलग-अलग होता है, और cryptographic libraries में सभी सहमत हैं कि key leak होना खराब है
      आखिरकार processor designers को assumptions नहीं तोड़नी चाहिए, और कम से कम ऐसा करने से पहले हमसे बात करनी चाहिए
    • ज़्यादा संभावित दिशा शायद code execution के कुछ हिस्सों में CPU के ऐसे components को बंद करने वाला mode switch होगी
      abstraction unit शायद thread level पर होने की संभावना ज़्यादा है
    • क्या यही Secure Enclave के होने की वजह नहीं है?
      https://support.apple.com/guide/security/secure-enclave-sec5...
    • encrypted bus MMU 1990 के दशक से मौजूद थे
      लेकिन cost-optimized cloud architectures consumer hardware की तरफ झुकते हुए CPU market पर छा गईं, और अब बड़े-scale applications के लिए भी practical विकल्प consumer CPU ही हैं
    • कई modern architectures में आम तौर पर कुछ common algorithms को accelerate करने वाली cryptographic extensions होती हैं
      नए algorithms को संभव बनाने के लिए कुछ cryptographic primitive operations instructions जोड़ना भी अच्छा हो सकता है

  • paper के अनुसार “OpenSSL ने बताया कि local side-channel attacks उसके threat model से बाहर हैं, और Go Crypto team इस attack की severity को कम मानती है”

    • कम से कम एक Go cryptography developer ने 2021 में इसी समस्या पर सार्वजनिक रूप से चिंता जताई थी: https://github.com/golang/go/issues/49702

  • ऐसे side-channel attacks का अंतिम निष्कर्ष यह होगा कि कोई optimization न हो, और हर instruction हर स्थिति में समान cycle count में execute हो, ऐसा CPU बने
    लेकिन ऐसा कभी नहीं होगा। कोई भी slow CPU नहीं चाहता
    अगर इसे remotely exploit नहीं किया जा सकता, तो मेरे हिसाब से यह चिंता की बात नहीं है। हाँ, multi-tenant cloud virtualization बिल्कुल नहीं चलेगा

    • सारे untrusted code को भयानक sequential execution core पर डाल देना चाहिए
      न speculative execution, न prefetching, बस computer architecture 101 class में दिखने वाली 5-stage pipeline जैसा core
    • “multi-tenant cloud virtualization” के कारण, मैं उतना चिंतित नहीं हूँ जितना कुछ साल पहले Intel chips की समान vulnerability पर था
      rackmount Mac Mini का compute time किराये पर देने वाले कुछ cloud providers ज़रूर हैं, लेकिन बहुत नहीं, और वे भी बहुत specific workloads या build jobs के लिए हैं
      ऐसी service पर बड़ा पैसा देने वालों के लिए यह समस्या हो सकती है, लेकिन Apple Silicon devices का भारी बहुमत कभी भी cloud services host नहीं करेगा
    • इसलिए बहुत ज़्यादा core count और isolation महत्वपूर्ण हैं
      अगर code को किसी specific core पर isolate कर दें, तो सब कुछ intended तरीके से काम करने की शर्त पर exploit दूसरे tenants को compromise नहीं कर पाएगा

  • “क्या DMP को disable किया जा सकता है?” के जवाब में लिखा है, “हाँ, लेकिन केवल कुछ processors पर। M3 CPU में DIT bit set करने से DMP प्रभावी रूप से disable हो जाता है, लेकिन M1 और M2 में ऐसा नहीं होता”
    ज़रूर कहीं न कहीं इसे बंद करने वाला chicken bit होगा, है न?

    • मुझे हमेशा जिज्ञासा रही है कि ऐसे bits कैसे set किए जाते हैं
      क्या यह Swift में किया जा सकता है, या assembly चाहिए?

  • पढ़ने पर लगता है कि libsodium जैसी libraries M3 और उससे ऊपर में sensitive cryptographic operations से पहले disable bit set कर दें तो काम चल सकता है
    साथ ही लगता है कि key के कुछ aspects पहले से पता करने होंगे
    बहुत cool है, लेकिन खास practical नहीं दिखता

  • 2022 का Augury attack याद आया। इसने भी Apple Silicon CPU की DMP prefetching का फायदा उठाया था
    [1]: https://www.prefetchers.info

    • संदर्भ के लिए, GoFetch के लेखकों में से तीन ने Augury में भी हिस्सा लिया था
    • सही, post और FAQ में इसे specifically mention किया गया है

  • Apple में इतने hardware backdo… pure bugs क्यों होते हैं?

    • पहली बात, cache की ज़रूरत ही क्यों है? prefetching की ज़रूरत क्यों है?
      उस बकवास backdoor conspiracy theory का जवाब यह है कि लोग तेज़ CPU चाहते हैं, इसलिए processors में cache और timing differences होते हैं। constant time और तेज़ performance दोनों साथ नहीं मिल सकते, और Apple अकेली company नहीं है जिसके पास prefetching है
      यहाँ Apple ने cryptography के लिए constant-time operations चालू करने का तरीका document किया है। ऐसा लगता है जैसे hardware में जानबूझकर design किया गया हो। कितना अजीब है: https://developer.apple.com/documentation/xcode/writing-arm6...
    • वही कारण जिसके चलते Intel और AMD में Meltdown और Spectre थे

  • अगर cryptographic routines लिख रहे हैं, तो platform cryptography library इस्तेमाल करें, या documentation follow करें
    https://developer.apple.com/documentation/xcode/writing-arm6...

  • अब Mac और iPad पर भी malware checks और virus scanners meaningful हो गए हैं
    attacker को उसी hardware पर running होना होगा