ZenHammer: AMD Zen आधारित प्लेटफ़ॉर्म को निशाना बनाने वाला Rowhammer हमला

 (comsec.ethz.ch)
1 पॉइंट द्वारा GN⁺ 2024-03-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • TRR mitigation लागू AMD Zen 2·Zen 3 DDR4 सिस्टम में भी Rowhammer bit flip हुए, जिससे यह स्पष्ट है कि AMD प्लेटफ़ॉर्म भी वास्तविक attack surface बन सकते हैं
  • रिसर्च टीम ने AMD के लिए अनुकूलित DRAMA तकनीक से गोपनीय DRAM address function की reverse engineering की, और यह पुष्टि की कि system address remapping की वजह से physical address offset प्रोसेसिंग ज़रूरी है
  • ZenHammer fuzzer ने Samsung, Micron, SK Hynix सहित 10 DDR4 डिवाइसों में से Zen 2 पर 7 और Zen 3 पर 6 में bit flip उत्पन्न किए, और Zen 3 डिवाइसों ने Intel Coffee Lake से अधिक कमजोर परिणाम दिखाए
  • मौजूदा page table, RSA-2048 public key corruption, और sudoers.so हमले क्रमशः 7/6/4 डिवाइसों पर कॉन्फ़िगर किए जा सके, और exploit योग्य bit flip खोजने का औसत समय 164/267/209 सेकंड था
  • Zen 4 की DDR5 evaluation में 10 में से 1 डिवाइस पर लगभग 42,000 bit flip हुए, लेकिन बाकी 9 में असफलता मिली, इसलिए DDR5 के लिए अतिरिक्त pattern research की ज़रूरत है

AMD Zen में भी पाए गए Rowhammer bit flip

  • ZenHammer ने TRR mitigation वाले DDR4 डिवाइसों में AMD Zen 2 और Zen 3 सिस्टम पर Rowhammer bit flip उत्पन्न किए
  • इससे पुष्टि हुई कि AMD सिस्टम भी Intel सिस्टम की तरह Rowhammer vulnerability रख सकते हैं
  • AMD का x86 desktop CPU market share लगभग 36% होने के कारण attack surface छोटा नहीं है
  • DRAM डिवाइस तैनाती के बाद आसानी से ठीक नहीं किए जा सकते, और पहले के शोध दिखा चुके हैं कि Rowhammer हमले कई environments में व्यावहारिक हो सकते हैं

AMD DRAM address function की reverse engineering और hammering optimization

  • AMD सिस्टम के लिए DRAMA तकनीक लागू कर गोपनीय DRAM address function की reverse engineering की गई
  • अधिक स्थिर परिणाम पाने के लिए timing routine बदला गया
  • system address remapping की वजह से DRAM address function को recover करने से पहले physical address offset लागू करना पड़ा, और इससे address function को पूरी तरह recover किया गया
  • सिर्फ recovered address function का उपयोग करने वाले तरीके में bit flip की संख्या सीमित रही
    • Zen 2 में 10 डिवाइसों में से केवल 5 में bit flip की पुष्टि हुई
    • Zen 3 में 10 डिवाइसों में से 0 में bit flip की पुष्टि हुई

refresh synchronization और command sequence

  • पहले के शोध SMASH और Blacksmith की तरह refresh synchronization bit flip उत्पन्न करने का महत्वपूर्ण तत्व था
  • AMD पर non-repeating rows को लक्ष्य बनाकर लगातार timing measurement करने की विधि सटीक और भरोसेमंद refresh synchronization के लिए प्रभावी रही
  • AMD Zen+/3 सिस्टम में non-uniform Rowhammer pattern की activation rate Intel Coffee Lake की तुलना में काफी कम थी
  • सर्वोत्तम hammering command sequence में सामान्य load MOV और CLFLUSHOPT का उपयोग कर aggressor को cache से flush किया गया, और aggressor access के तुरंत बाद flush करने वाली “scatter” शैली सबसे प्रभावी रही
  • Zen 2 के विपरीत, Zen 3 में flush के बाद स्पष्ट fence की आवश्यकता नहीं थी
  • fence के प्रकार और fence scheduling policy ने भी परिणामों को प्रभावित किया, और रिसर्च टीम ने 6 pattern recognition·cache avoidance policies प्रस्तावित कर हर डिवाइस पर 6 घंटे तक परीक्षण किया
    • Zen 2 के अधिकांश डिवाइसों पर SP_none सर्वोत्तम था
    • Zen 3 के अधिकांश मामलों में SP_pair अधिक उपयुक्त था

DDR4 evaluation परिणाम और exploit की संभावना

  • evaluation Samsung, Micron, SK Hynix सहित 10 DDR4 DRAM डिवाइसों पर किया गया
  • ZenHammer fuzzer को हर fence प्रकार mfence, sfence और हर fence scheduling policy के संयोजन के साथ 3 घंटे तक चलाया गया
  • हर रन के बाद खोजे गए सभी pattern के साथ 4MiB रेंज में minisweep किया गया ताकि सर्वोत्तम pattern चुना जा सके, और सर्वोत्तम policy के सर्वोत्तम pattern को 256MB continuous memory region पर sweep किया गया
  • परिणामस्वरूप 10 DDR4 DRAM डिवाइसों में से Zen 2 पर 7 और Zen 3 पर 6 में bit flip हुए
  • bit flip की exploitability का मूल्यांकन पिछले शोध के तीन हमलों से किया गया
    • page table entry के page frame number पर हमला कर attacker-controlled page table page पर pivot करने वाला हमला
    • SSH host authentication में प्रयुक्त संबंधित private key को recover करने में सक्षम बनाने वाला RSA-2048 public key हमला
    • root privilege हासिल करने में सक्षम sudoers.so library के password verification logic पर हमला
  • मौजूदा हमले क्रमशः 7/6/4 डिवाइसों पर कॉन्फ़िगर किए जा सके, और exploit योग्य bit flip खोजने का औसत समय 164/267/209 सेकंड था

DDR5 evaluation, public code, और घोषणा कार्यक्रम

  • AMD Zen 4 पर DDR5 DRAM function की भी reverse engineering की गई और 10 DDR5 डिवाइसों का मूल्यांकन किया गया
  • ZenHammer ने 10 में से 1 DDR5 डिवाइस पर लगभग 42,000 bit flip उत्पन्न किए
  • यह सामान्य commercial system पर DDR5 bit flip की सार्वजनिक रूप से रिपोर्ट की गई पहली घटना है
  • बाकी 9 DDR5 डिवाइसों में bit flip नहीं हुए, इसलिए DDR5 डिवाइसों के लिए अधिक प्रभावी pattern खोजने हेतु अतिरिक्त शोध की आवश्यकता है
  • पूरी जानकारी अगस्त 2024 में USENIX Security 2024 में प्रस्तुत होने वाले paper में शामिल है
  • ZenHammer fuzzer code GitHub पर उपलब्ध है, और इसका उपयोग AMD Zen 2/3/4 CPU पर DRAM डिवाइसों में bit flip की उपस्थिति का आकलन करने के लिए किया जा सकता है
  • Rowhammer को उद्योग-व्यापी ज्ञात समस्या मानते हुए सामान्य disclosure प्रक्रिया आवश्यक नहीं समझी गई, लेकिन AMD को 26 फ़रवरी 2024 को सूचित किया गया और AMD के अनुरोध पर 25 मार्च 2024 तक सार्वजनिक नहीं किया गया
  • यह पेज गलती से 21 मार्च 2024 को थोड़ी देर के लिए ऑनलाइन सार्वजनिक हो गया था

FAQ की व्यावहारिक सीमाएँ

  • AMD सिस्टमों पर पहले कम काम होने का कारण यह था कि मूल Rowhammer शोध में Intel सिस्टमों पर bit flip की संख्या कहीं अधिक थी, बाद के शोध भी मुख्यतः Intel पर केंद्रित रहे, और Intel CPU microarchitecture की जानकारी AMD की तुलना में अधिक उपलब्ध थी
  • 10 DDR4 डिवाइसों में Zen 2 पर 3 और Zen 3 पर 4 में bit flip नहीं हुए, लेकिन Intel Coffee Lake पर भी इन डिवाइसों में bit flip कम थे, इसलिए fuzzer को और fine-tune करने पर bit flip सामने आ सकते हैं
  • evaluation डिवाइसों की संख्या 10 तक सीमित रहने का कारण लैब में AMD Zen 2/3 उपकरणों की सीमित उपलब्धता और कुछ experiments का लंबा runtime था, और random subset में तीनों DRAM vendors के डिवाइस शामिल थे
  • JEDEC अब तक समस्या ठीक क्यों नहीं कर पाया, इस पर शोधकर्ताओं ने कहा कि Rowhammer का समाधान कठिन है लेकिन असंभव नहीं, और पहले के शोध ProTRR और REGA में यह दिखाया गया है
  • DDR3 पर पिछले शोध ने दिखाया कि ECC Rowhammer को नहीं रोक पाता, और वर्तमान DDR4 डिवाइसों में bit flip की संख्या अधिक होने के कारण ECC को पूर्ण सुरक्षा नहीं बल्कि exploit को अधिक कठिन बनाने वाला उपाय माना गया
  • refresh rate को दोगुना करने वाली विधि में performance overhead और power consumption बढ़ता है, और Mutlu et al. तथा Frigo et al. जैसे पिछले शोधों में इसे पूर्ण सुरक्षा न देने वाला कमजोर समाधान बताया गया

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

1 टिप्पणियां

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

  • मूल Rowhammer exploit का सह-लेखक हूँ। ECC अभी भी इस समस्या को बड़े पैमाने पर security issue से reliability issue में बदलने में बहुत प्रभावी है
    अगर आप निजी server के मालिक हैं, और आपके server में ECC है तथा आप उम्मीद करते हैं कि uncorrectable ECC error की वजह से machine रुकने पर आपको पता चल जाएगा, तो security पर असर बहुत बड़ा नहीं है
    लेकिन अगर आप multi-tenant host पर VM देने वाले cloud provider हैं, तो threat model बदल सकता है
    किसी भी स्थिति में, ECC के बिना machines से बचना चाहिए। TRR तब भी एक असफल defense था जब Rowhammer अभी-अभी सामने आया था, और जब तक DRAM manufacturing की economics नहीं बदलती, DRAM bit flips खत्म नहीं होंगे

    • संभव हो तो मैं ECC memory इस्तेमाल करना चाहूँगा। पहले मैं ECC वाले TR 2920x का इस्तेमाल करता था, लेकिन अब non-ECC Ryzen 7950x इस्तेमाल कर रहा हूँ
      Ryzen सिर्फ unbuffered ECC support करता है, जो समान capacity की non-ECC memory से धीमी या महंगी, या दोनों होती है
      नए Threadripper lineup में Registered ECC support है, लेकिन मेरे जैसे home user के लिए cost, threads और PCIe lanes—सब कुछ जरूरत से ज्यादा है
    • अगर “जब तक DRAM manufacturing की economics नहीं बदलती, DRAM bit flips खत्म नहीं होंगे”, तो यह सभी computers में ECC memory mandatory करने के लिए पर्याप्त तर्क लगता है
      security risk बहुत बड़ा है और सब कुछ इतना integrated है कि इस बदलाव को टालना मुश्किल है। सिर्फ gaming के लिए computer इस्तेमाल करने वाले gamers भी उस machine पर अहम जानकारी रखते होंगे; अब तक यह बदलाव क्यों नहीं हुआ, समझ नहीं आता
    • मैंने सुना है कि DDR2 Rowhammer से immune है; सोचता हूँ क्या यह सच में ऐसा है, या बस किसी ने ठीक से जांच नहीं की
      यह भी सोचता हूँ कि क्या सच में सिर्फ SRAM ही immune है
    • AMD भी अब Intel-style market segmentation अपना रहा है और ज्यादातर Ryzen CPUs में ECC disable कर रहा है
      सिर्फ Pro और Threadripper में guarantee है, और कुछ desktop Ryzen में यह केवल कुछ motherboards पर ही संभव है
    • मौजूदा papers में मुझे कुछ सवालों के संतोषजनक जवाब नहीं मिले। क्या आधुनिक patrol read engine Rowhammer जैसी attacks से निपटने के लिए memory access patterns से guidance लेता है?
      Rowhammer से पैदा होने वाले bit flips से सुरक्षित रूप से आगे रहने के लिए patrol read engine को DRAM कितनी aggressive तरीके से scan करनी चाहिए?
      अगर ECC words पारंपरिक 64+8 से बड़े हों और multi-bit error correction हो, तो क्या इससे इतनी स्थिति बदलती है कि pattern vulnerabilities वाली DRAM से भी ज्यादा reliable systems बनाए जा सकें?

  • “ECC Rowhammer को नहीं रोकता” जैसी अभिव्यक्ति काफी misleading है। जिस paper का हवाला दिया गया है, वह भी कहता है कि “ECC detection सही तरीके से इस्तेमाल होने पर भी कुल bit flips के 0.65%~7.42% silent corruption पैदा करते हैं… AMD-1 configuration में uncorrectable error system को crash कर देता है”
    attacker को exploit करने लायक एक bit flip पाने के लिए दर्जनों machine interruptions कराने पड़ेंगे। दर्जनों machine interruptions ऐसी चीज नहीं हैं जो unnoticed रह जाएं
    JEDEC की Rowhammer response बहुत खराब है, यह बात उठाना अच्छा है, लेकिन short-term solution के रूप में ECC को कम नहीं आंकना चाहिए

    • सोचता हूँ कि system संभालने वाली operations team के पास क्या ऐसी process होती है जिससे वे इस घटना को सिर्फ unstable hardware नहीं, बल्कि attack मान सकें
    • अगर किसी खास machine को target किया जा रहा हो तो यह सही है, लेकिन अगर exploit को हजारों machines पर shotgun की तरह फैलाया जाए, तब भी botnet मिल सकता है। बस scale थोड़ा छोटा हो जाएगा
    • घर के desktop के लिए ECC खरीदने की एक वजह Rowhammer defense थी
      यह Zen2 TR platform है, और वह वाक्य देखकर एक पल के लिए दिल बैठ गया। यह काफी misleading phrasing है
    • सोचता हूँ कि क्या ECC memory वाले client devices की कोई recommendation है

  • सोचता हूँ कि आम व्यक्ति के लिए Rowhammer, Spectre, Meltdown जैसे hardware security issues सच में risk हैं या नहीं
    Spectre और Meltdown को मैं VM escape जैसी attacks के लिए problem समझता था; यह AWS engineers के ध्यान देने की चीज लगती थी, personal users के लिए नहीं

    • solution है JavaScript बंद करना और untrusted apps न चलाना
      और चूंकि आप modern society से कट चुके हैं, जंगल की किसी cabin में जाकर आत्मनिर्भर बन जाएं
    • एक स्पष्टवादी hardware security researcher के नजरिए से, average user को प्रभावित करने वाली real exploited vulnerabilities कहीं ज्यादा साधारण और ज्यादातर software-based होती हैं
    • हर किसी को किसी न किसी तरह का script allowlist extension install करना चाहिए, और सिर्फ उन websites की JavaScript चलानी चाहिए जिन पर वे सच में भरोसा करते हैं
      निजी तौर पर मुझे NoScript पसंद है। Chrome में क्या चुनना चाहिए, यह मुझे ठीक से नहीं पता
      इसके अलावा… क्या लोग इंटरनेट से random programs अक्सर चलाते हैं?
      इस तरह के bugs में अभी सिर्फ सतह खुरची गई है। modern hardware इतना complex है कि भरोसा करना मुश्किल है कि हम सब कुछ खोज पाएंगे
    • Rowhammer का browser में चलने वाला JavaScript implementation भी है: https://github.com/IAIK/rowhammerjs
    • security के नजरिए से web browser एक तरह का VM hypervisor है, और हर website के पास अपनी VM जैसी चीज होती है
      इसलिए हर कोई प्रभावित हो सकता है

  • DDR बिट-फ्लिप हमलों को मैं बस बहुत धुंधले तौर पर ही समझता था, लेकिन मूल Hammertime पेपर देखने पर पता चला कि वह वाकई पढ़ने में आसान है
    अभी पूरा नहीं पढ़ा है, लेकिन समझने लायक तरीके से अच्छी तरह समझाता है। “बिट फ्लिप” शब्द अनगिनत बार सुना था, पर कभी ठीक से समझा नहीं था; इसे देखकर बात समझ में आई
    https://comsec.ethz.ch/wp-content/files/hammertime_raid18.pd...
    ऐसा लगा जैसे इलेक्ट्रिकल/इलेक्ट्रॉनिक्स का एक introductory class ले लिया हो। मुझे बिल्कुल नहीं पता था कि इसका संबंध असल हार्डवेयर manufacturing defects से है
    Rowhammer नाम भी तभी समझ में आया। शायद मैं बहुत पीछे था और यह सबको पहले से पता हो सकता है
    “आधुनिक DRAM arrays की अत्यधिक density के कारण छोटी manufacturing defects पड़ोसी cells के बीच कमजोर electrical coupling बना सकती हैं। जब इसे इन cells की बेहद छोटी capacitance के साथ जोड़ा जाता है, तो हर बार bank से किसी DRAM row को read किए जाने पर पड़ोसी rows के memory cells थोड़ी मात्रा में charge खो देते हैं। अगर यह दो refresh cycles के बीच पर्याप्त बार हो, तो प्रभावित cell इतना charge खो सकता है कि उसका stored bit value पलट जाए; इसे ‘disturbance error’ या हाल में Rowhammer कहा जाता है”

    • सिर्फ यह explanation देखें तो लगता है कि DRAM बनाते समय यह कोई unavoidable intrinsic चीज है, लेकिन ऐसा नहीं है
      वजह यह है कि DRAM निर्माताओं ने limits को चरम तक धकेल दिया है। यह profit-seeking है
      यह Ford से अलग नहीं है, जिसने माना था कि injuries और deaths से जुड़े Pinto lawsuit settlements की लागत vehicle design fix की लागत से कम होगी

  • सोच रहा हूँ कि Secure Memory Encryption इसमें मदद करता है या नहीं
    https://www.amd.com/en/developer/sev.html

    • मदद तो करता है, लेकिन reliability में काफी बड़ा नुकसान हो सकता है
      सिर्फ एक bit flip भी fatal error बन सकता है

  • hardware security के बारे में मैं बहुत कम जानता हूँ; सोच रहा हूँ कि क्या यह CPU optimization से पैदा होने वाली कई अपरिहार्य vulnerabilities में से एक है और real world में कम feasible वाली category की चीज है

    • उल्टा, इसे इससे भी खराब माना जा सकता है। यह DRAM की physics से पैदा होता है
      यह उन edge cases से कहीं lower level पर होता है जहाँ कोई feature side channel से information leak कराता है
      data lattice में छोटे charges के रूप में stored होता है, और पास के lattice points को बहुत बार flip करें तो target charge की तरफ कुछ charge leak कराया जा सकता है
      charge जितना छोटा और एक-दूसरे के जितना पास होगा, Rowhammer attack उतना आसान होगा। साथ ही charge जितना छोटा और पास होगा, RAM उतनी ही तेज, सस्ती, dense और efficient होगी
      mitigations हैं, लेकिन चीजें पहले ही limit तक धकेली जा चुकी हैं
    • यह RAM issue है, CPU issue नहीं

  • सोच रहा हूँ कि full memory encryption, poisoning और address XOR enabled होने पर भी क्या यह काम करता है

    • memory encryption होने पर यह system takeover तक नहीं पहुँचता, बस system crash होता है
      इसलिए memory encryption इस्तेमाल करने पर यह ज्यादा सुरक्षित है

  • अगर “ZenHammer 10 devices में से 9 में flips trigger नहीं कर पाया… DDR5 devices पर ज्यादा effective patterns खोजने के लिए आगे research की जरूरत है”, तो लगता है DDR5 के पास अभी थोड़ा समय बचा है
    क्या किसी को पता है कि यह LPDDR5x को भी affect करता है या नहीं?

    • DRAM interface, memory array itself से काफी अच्छी तरह separated होता है
      इसलिए DDR5, LPDDR5(x), GDDR6(x), HBM3(e) में से कौन-सा है, यह core question नहीं है
      अहम चीज manufacturer discretion वाले implementation details हैं, जैसे on-die ECC

  • Zen 2 और 3 का जिक्र है, लेकिन Zen 1 के बारे में कोई जानकारी है क्या?
    क्या यह बस उसी तरह लागू होता है?