Branch Privilege Injection: ब्रांच प्रेडिक्टर की race condition का दुरुपयोग

 (comsec.ethz.ch)
1 पॉइंट द्वारा GN⁺ 2025-05-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Branch Privilege Injection Intel CPU के branch predictor की race condition के कारण लगभग 6 साल से कायम Spectre-BTI परिवार की hardware defenses को फिर से bypass करने वाली vulnerability है
  • हमले का मुख्य बिंदु यह है कि branch predictor updates instruction flow से asynchronously process होते हैं, और कुछ स्थितियों में ये दर्जनों से सैकड़ों cycles तक देर से लागू हो सकते हैं
  • privilege transition या IBPB execution के दौरान अगर delayed updates बचे रह जाएँ, तो बाद में वे गलत security domain से जुड़ सकते हैं, जिससे eIBRS और IBPB की security guarantees टूट सकती हैं
  • शोधकर्ताओं ने Ubuntu 24.04 पर, सभी default mitigations enabled रखते हुए, Intel Raptor Lake 13th Gen पर arbitrary memory को 5.6KiB/s की दर से leak करने वाला end-to-end attack दिखाया
  • Intel के microcode update ने Alder Lake evaluation में vulnerability detection primitive को block किया, और अधिकतम 2.7% overhead दिखाया

Branch Privilege Injection किन शर्तों में संभव होता है

  • Branch Privilege Injection एक branch target injection attack है, यानी यह Intel environment में Spectre-BTI की ताकत को फिर से संभव बनाता है
  • Intel की hardware mitigations ने लगभग 6 साल तक इस तरह के हमलों को रोका था, लेकिन यह research दिखाती है कि Intel CPU की race condition उस defense को कमजोर कर सकती है
  • हमला दो observations पर आधारित है
    • Intel processors का branch predictor instruction flow से asynchronously update होता है
      • कुछ स्थितियों में update दर्जनों या सैकड़ों cycles तक delay हो सकता है
      • asynchronous update अपने आप में vulnerability नहीं, बल्कि एक feature है
    • security-critical operations के दौरान branch predictor और instruction flow के बीच synchronization पर्याप्त नहीं है
      • user mode से kernel में, या guest से hypervisor में transition के दौरान update अभी भी चल रहा हो सकता है
      • IBPB execution के दौरान भी in-progress updates बचे रह सकते हैं
      • अगर ऐसे updates privilege transition के बाद पहुँचते हैं, तो वे पुराने privilege के बजाय नए privilege mode से जुड़ जाते हैं
  • इस vulnerability category का नाम Branch Predictor Race Conditions है

कौन-सी mitigations टूटती हैं और impact scope

  • eIBRS Intel द्वारा 9th Gen Coffee Lake Refresh के बाद सभी processors में पेश की गई Spectre-BTI mitigation है
    • इसका लक्ष्य indirect branch prediction को अलग-अलग security domains के हिसाब से isolate करना है
    • इसे इस तरह design किया गया है कि हर prediction को उसके generated domain से जोड़ा जाए, और बाद में केवल current domain की predictions ही इस्तेमाल हों
    • अगर privilege transition के दौरान in-progress update नए security domain से जुड़ जाए, तो इस association में हेरफेर किया जा सकता है
  • IBPB एक ही hardware security domain के भीतर sandboxes या आपस में भरोसा न करने वाली virtual machines को isolate करने के लिए इस्तेमाल होने वाला mechanism है
    • यह सभी indirect branch predictions को invalidate करने की functionality देता है
    • in-progress updates IBPB से flush नहीं होते, इसलिए invalidation के बाद भी branch predictor में store हो सकते हैं
  • impact scope generation और architecture के हिसाब से अलग है
    • Intel 9th Gen Coffee Lake Refresh के बाद के सभी processors Branch Privilege Injection से प्रभावित हैं
    • IBPB bypass predictions 7th Gen Kaby Lake तक में observe हुईं
    • evaluated AMD और ARM systems में समस्या नहीं मिली
    • proof-of-concept attack Linux के लिए बनाया गया था, लेकिन मूल समस्या hardware में है, इसलिए affected hardware पर चलने वाले operating systems प्रभावित होते हैं

mitigations, performance cost, और public resources

  • latest operating system और BIOS updates install करने की सलाह दी जाती है
  • Intel ने affected processors के लिए microcode update develop किया, और शोधकर्ताओं ने इसे Alder Lake पर evaluate किया
    • microcode mitigation vulnerability detection primitive को block करती है
    • Alder Lake पर अधिकतम 2.7% overhead दिखा
  • software alternative mitigations भी evaluate की गईं
    • Coffee Lake Refresh पर 1.6% overhead
    • Rocket Lake पर 8.3% overhead
  • विस्तृत technical जानकारी paper में देखी जा सकती है
  • Branch Privilege Injection paper USENIX Security 2025 में प्रस्तुत किया जाएगा, और Black Hat USA 2025 presentation भी scheduled है
  • attack और experiment source code github पर public है

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

1 टिप्पणियां

 
GN⁺ 2025-05-14
Hacker News की राय

  • शोधकर्ताओं का ब्लॉग पोस्ट: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
    पेपर: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf

    • प्रभाव का उदाहरण: Rüegge बताते हैं कि समय के साथ पूरी मेमोरी की सामग्री पढ़ी जा सकती है, और बार-बार fault पैदा करके प्रति सेकंड 5000 bytes से ज्यादा की read speed हासिल की जा सकती है
      हमले की स्थिति में आखिरकार पूरी CPU memory की जानकारी गलत हाथों में जाना बस समय की बात रह जाता है
    • अच्छा होगा अगर title URL को उस ब्लॉग पोस्ट में बदल दिया जाए। press release बेकार ही नहीं, नुकसानदेह स्तर की है

  • अच्छा लेख है। सार यह है कि branch predictor updates को branch instruction के retire होने के काफी बाद तक टाला जा सकता है
    ऐसा न हो तो branch instruction retire होने में ज्यादा समय लगेगा, इसलिए यह समझ में आता है। dispatch-serializing instructions भी predictor state के pending updates की वजह से pipeline को रोकती नहीं लगतीं, और यह स्वाभाविक है क्योंकि “branch instruction result commit” और “prediction result commit” को पहले ही अलग किया गया है
    privilege-changing instructions भी pending updates की वजह से pipeline को नहीं रोकतीं, लेकिन यह तभी सही है जब prediction बनाते समय और commit करते समय privilege level के consistent होने की गारंटी दी जा सके। वरना एक privilege level के code द्वारा बनाई गई prediction किसी दूसरे privilege level में इस्तेमाल होने वाली state में commit हो सकती है
    शायद यह कठिन समस्या इसलिए भी हो सकती है कि pipeline के अंदर current privilege level कोई एकल और स्पष्ट value नहीं है

  • Kaveh Razavi को देखकर अच्छा लगा। पहले वे Amsterdam की Vrije Universiteit में पढ़ाते थे, और Hardware Security कोर्स ऐसी चीजों को गहराई से cover करता था, इसलिए वह वाकई शानदार था

    • कुछ साल पहले मैंने यह कोर्स और Vrije के malware से जुड़े दूसरे courses खोजे थे, लेकिन उस समय public material बहुत कम था
      जानना चाहूंगा कि क्या official recordings या notes online उपलब्ध हैं

  • किसी को पता है कि इसका अभी-अभी public हुए Training Solo attack से क्या संबंध है? https://www.vusec.net/projects/training-solo/

    • दोनों Spectre V2 का फायदा उठाते हैं, लेकिन तरीके अलग हैं
      Training Solo kernel में प्रवेश कर privilege level बदलने के बाद “self-training” के जरिए branch को disclosure gadget की ओर mispredict करवाता है और memory leak करता है
      Branch predictor race conditions में learned branch predictor update अभी process हो रहा हो तभी kernel में प्रवेश किया जाता है, ताकि वह update गलत privilege level से जुड़ जाए। फिर इसका इस्तेमाल करके kernel की branch को disclosure gadget की ओर मोड़ा जाता है और memory leak की जाती है

  • अगर CPU branch predictor के पास buffer boundaries और code privilege level जांचने की जानकारी तुरंत उपलब्ध होती, तो ऐसी समस्याओं को रोकना कहीं आसान होता
    लेकिन जब तक C programmers के ठंडे हाथों से void* नहीं छीना जाता और pointers में महत्वपूर्ण जानकारी नहीं जोड़ी जाती, तब तक ऐसा होता नहीं दिखता

    • समझ नहीं आता कि इससे कैसे मदद मिलेगी। यह software abstraction नहीं, बल्कि hardware समस्या है, इसलिए “pointer” बदलने से transistors पर कोई असर नहीं पड़ेगा
      आप जो चाहते हैं उसके लिए ऐसी hardware architecture चाहिए जिसमें हर load/store किसी तरह के “augmented address” से गुजरे, जो boundary information store करता हो
      यानी आप मूलतः 80286 segmentation की मांग कर रहे हैं, जो पहले से मौजूद था और वह मनचाहा काम नहीं कर पाया। वजह यह है कि उन segment descriptors को भी software को सही तरीके से load करना पड़ता है। software के नजरिए से आखिरकार वह “बस pointer” ही है, इसलिए वही गलतियों के प्रति कमजोर रहता है
    • आपको जो चाहिए वह CHERI है
    • समस्या के दायरे को बेहतर समझा जा सकता है। vulnerability होने का मतलब यह नहीं कि वह तुरंत attack में बदल जाए
      speculative execution के मामले में उस vulnerability को सचमुच किसी काम में लेने के लिए अजीब हद तक preparation चाहिए। व्यवहार में इसका लगभग इकलौता usable तरीका यह है कि उस computer तक direct access हो और low-level code execute किया जाए। यह ऐसा नहीं है कि browser में चल रहे JS code से मनमाने secrets leak हो जाएं
      अगर कोई system इतना मूल्यवान है कि dedicated private organization या state-backed organization आवश्यक research और targeting करे, तो शुरू से ही ऐसी व्यवस्था होनी चाहिए कि unauthorized arbitrary code execute न हो सके
      निजी तौर पर मुझे performance improvement सचमुच महसूस होता है, इसलिए मैंने सभी mitigations बंद कर रखी हैं

  • Intel security advisory: https://www.intel.com/content/www/us/en/security-center/advi...

  • सोच रहा हूँ कि AMD हार्डवेयर में भी ऐसी ही कोई खामी है या नहीं। speculative execution साझा processor space में patch करने के लिए बहुत कठिन vulnerability जैसी लगती है, इसलिए जिज्ञासा है कि AMD इससे कैसे बचता आया

    • शोधकर्ताओं के blog के मुताबिक Branch Privilege Injection Intel के अलावा दूसरे CPU को प्रभावित नहीं करता
      जिन AMD और ARM systems का मूल्यांकन किया गया, उनमें समस्या नहीं मिली
      स्रोत: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
    • संक्षेप में कहें तो AMD “बचता आया” ऐसा नहीं है। speculative execution side-channel कोई एक vulnerability नहीं, बल्कि vulnerabilities की एक श्रेणी है
      यह खास vulnerability Meltdown की तरह Intel-only लगती है, लेकिन AMD मूल Spectre के प्रति vulnerable था
    • सख्ती से कहें तो speculative execution अपने-आप में vulnerability नहीं है। यह आजकल के सभी high-performance CPU के लिए जरूरी mechanism है, और यहाँ “आजकल” से मतलब लगभग सदी के मोड़ से है
      लेकिन speculative execution engine जटिल होता है, इसलिए bugs और vulnerabilities बहुत व्यापक रूप से मौजूद हैं
      AMD और ARM में भी मिलते-जुलते bugs होने की संभावना बड़ी है। बस यह सोचिए कि Intel में ऐसे bugs कितने लंबे समय तक बिना पकड़े रहे
      दुर्भाग्य से असली समाधान यह मान लेना है कि आधुनिक systems पर चल रहे code को isolate नहीं किया जा सकता, जो कुछ बहुत अमीर कंपनियों के business model के लिए घातक हो सकता है
    • इस खास vulnerability का समाधान सहज लगता है। branch predictor update को queue में डालते समय मौजूदा privilege level को snapshot के रूप में save करें, और जब वह update processor के internal buffer से होकर गुजरे, तो snapshot भी साथ लेकर चले
      क्या यह software में होने वाली समस्या और उसके समाधान जैसा ही नहीं है?

  • कहा गया है, “ऐसी खामियों को रोकने के लिए processor microcode का special update चाहिए। यह BIOS या operating system update से संभव है, इसलिए Windows के latest cumulative updates में से किसी एक के जरिए PC पर install होना चाहिए”, तो सिर्फ Windows का ही जिक्र क्यों? Linux users का क्या?

    • Intel Linux के लिए microcode updates यहाँ distribute करता है: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...
      distributions यहाँ से लेकर automatically distribute करने के लिए configured हैं
      हालांकि इस खास mitigation के शामिल हो जाने की पुष्टि करने के लिए क्या देखना चाहिए, यह ठीक से नहीं पता
    • Linux kernel में काफी पहले से microcode loading support (CONFIG_MICROCODE / CONFIG_MICROCODE_INTEL) रहा है
      बस Intel को वे जरूरी microcode files publish करनी होंगी ताकि distro maintainers package update कर सकें, और फिर वह system update में शामिल हो जाएगा

  • जिज्ञासा है कि Intel के पास recover करने का कोई रास्ता है या नहीं। बाजार में कोई खास दमदार product नहीं है, R&D में लंबा समय लगता है, और foundry competitors से पीछे है, इसलिए लगातार loss का source बनी हुई है
    ऊपर से x86 को ARM hardware धीरे-धीरे धकेल रहा है, और अब चीन से RISC-V भी बढ़ रहा है। बेशक US semiconductor angle भी है। खासकर Covid के दौरान problems झेलने के बाद, क्या US Intel जैसे critical manufacturer को ढहने देगा?

    • Intel उतने बड़े संकट में नहीं है जितना tech blogs शोर मचाते हैं
      स्थिति अच्छी नहीं है, लेकिन sensationalism हास्यास्पद है
      gamers Intel product users का सिर्फ कुछ percent हैं, लेकिन सबसे ज्यादा बातें उन्हीं की सुनाई देती हैं। datacenter के एक-दो orders Intel के साल भर में बिकने वाले gaming CPUs से बड़े होते हैं। Intel अभी भी datacenter market में ठीक से टिका हुआ है
      इसके अलावा Intel enterprise laptop market पर भी अभी तक dominate करता है, और यह market भी gamer market से काफी बड़ा है
    • Intel के पास अब भी x86 market share 70% से काफी ज्यादा है। runway अभी लंबा बचा है
      Arm का पिछले साल datacenter market share सिर्फ 15% था, और Windows market में भी अभी उसने बड़ी प्रगति नहीं की है
    • लगता है यह expectations पर निर्भर है। कंपनी के रूप में ठीक रहेगा? मेरे हिसाब से हाँ। क्या वह history के कई दौरों की तरह बेहद prominent player रहेगा? शायद नहीं
      products से अलग, shareholder/business perspective से मैं इसे अलग सोचने की कोशिश करता हूँ, क्योंकि आजकल financial performance final products को कम से कम reflect करता दिखता है; Intel मुझे too big to fail के करीब लगता है
    • मुझे लगता है मैंने पढ़ा था कि Apple, Nvidia जैसी कंपनियाँ Intel foundry इस्तेमाल करना चाहती हैं; अगर वह inferior है तो वे ऐसा क्यों करेंगी? या बात कुछ और थी?

  • मैं confirm करना चाहता हूँ कि सही समझा हूँ या नहीं: इस समय तक सभी major operating systems ने इस issue को mitigate करने या related microcode apply करने के patches जारी कर दिए हैं?

    • सही। embargo हटने की तारीख 13 मई, यानी आज है