Zenbleed तकनीक

 (lock.cmpxchg8b.com)
2 पॉइंट द्वारा GN⁺ 2023-07-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Zenbleed AMD Zen 2 श्रृंखला में एक ऐसी कमजोरी है जो गलत अनुमानित vzeroupper recovery का दुरुपयोग करके उसी physical core की vector register file में बचे डेटा को पढ़ने देती है
  • इसे CVE-2023-20593 के रूप में दर्ज किया गया है, और Ryzen 3000/4000/5000 with Radeon Graphics/7020 with Radeon Graphics, Ryzen PRO, Threadripper 3000, EPYC “Rome” जैसे Zen 2 product परिवार इसके प्रभाव क्षेत्र में आते हैं
  • हमला तब संभव होता है जब XMM Register Merge Optimization, register rename, और गलत अनुमानित vzeroupper एक बहुत संकरे समय-खंड में लगातार घटित हों; strlen, memcpy, strcmp जैसे बुनियादी operations भी अवलोकन के दायरे में आ सकते हैं
  • optimized variant प्रति core लगभग 30KB प्रति सेकंड तक data leak कर सकता है, और VM·sandbox·container·process boundary के पार उसी physical core की register file sharing समस्या बनती है
  • AMD microcode update लागू करने की सिफारिश की जाती है; अस्थायी रूप से DE_CFG[9] chicken bit सेट किया जा सकता है, लेकिन इसकी performance cost हो सकती है और सिर्फ SMT disable करना पर्याप्त नहीं है

Zenbleed किस execution unit को निशाना बनाता है

  • x86-64 CPU में 128-bit XMM vector registers होते हैं, और आधुनिक CPU इन्हें 256-bit YMM, 512-bit ZMM तक बढ़ाते हैं
  • vector registers केवल numerical computation में ही नहीं, बल्कि glibc के strcmp, memcpy, strlen जैसे standard C library functions में भी उपयोग होते हैं
  • glibc का AVX2-optimized strlen string में पहले nul byte की स्थिति खोजने के लिए कई vector instructions को जोड़ता है
    • vpxor xmm0,xmm0,xmm0 से ymm0 के निचले हिस्से को 0 किया जाता है
    • vpcmpeqb ymm1,ymm0,[rdi] से string bytes की 0 byte से तुलना की जाती है
    • vpmovmskb eax,ymm1 से comparison result को general register में लाया जाता है
    • tzcnt eax,eax से पहले nul byte की स्थिति निकाली जाती है

vzeroupper और register file

  • vzeroupper vector register के upper bits को 0 करने वाला instruction है
  • जब XMM और YMM registers को मिलाकर उपयोग किया जाता है, तो XMM register पूरी width तक promote हो जाता है, और इस प्रक्रिया में upper-bit dependency बन सकती है
  • glibc अनावश्यक stall से बचने के लिए vzeroupper का उपयोग करता है ताकि बाद का result upper bits पर निर्भर न रहे
  • CPU हर register को किसी fixed physical location पर नहीं रखता; वह Register File और Register Allocation Table के जरिए physical register allocation संभालता है
  • XMM register को 0 करते समय CPU वास्तविक bits store किए बिना RAT में z-bit flag सेट कर सकता है
    • यह flag YMM register के upper और lower हिस्सों पर स्वतंत्र रूप से लागू हो सकता है
    • vzeroupper z-bit सेट करने के बाद register file से संबंधित resource को मुक्त कर सकता है

speculative execution recovery में पैदा होने वाली कमजोरी

  • आधुनिक CPU speculative execution का उपयोग करते हैं, इसलिए गलत अनुमानित branch पर चली operations को rollback करना पड़ता है
  • समस्या यह है कि गलत अनुमानित vzeroupper के execute होने के बाद recovery के समय केवल z-bit को वापस करना पहले से मुक्त किए जा चुके register file resource की स्थिति को सही ढंग से restore नहीं कर पाता
  • सटीक scheduling के जरिए कुछ processors को गलत अनुमानित vzeroupper से गलत तरह recover करने के लिए मजबूर किया जा सकता है
  • यही तकनीक CVE-2023-20593 है, और यह पूरी Zen 2 श्रृंखला को प्रभावित करती है
    • AMD Ryzen 3000 Series Processors
    • AMD Ryzen PRO 3000 Series Processors
    • AMD Ryzen Threadripper 3000 Series Processors
    • AMD Ryzen 4000 Series Processors with Radeon Graphics
    • AMD Ryzen PRO 4000 Series Processors
    • AMD Ryzen 5000 Series Processors with Radeon Graphics
    • AMD Ryzen 7020 Series Processors with Radeon Graphics
    • AMD EPYC “Rome” Processors

हमले की शर्तें और data leak की सीमा

  • bug को trigger करने के लिए XMM Register Merge Optimization, register rename, और गलत अनुमानित vzeroupper को एक सटीक समय-खंड में लगातार होना चाहिए
  • उदाहरण instruction sequence निम्न संरचना का उपयोग करता है
    • vcvtsi2s{s,d} से merge optimization trigger किया जाता है
    • vmovdqa से register rename trigger किया जाता है
    • अगर conditional branch वास्तव में taken है लेकिन CPU not-taken path का अनुमान लगाता है, तो vzeroupper गलत अनुमान के साथ execute होता है और bug trigger हो जाता है
  • strlen, memcpy, strcmp जैसे बुनियादी operations भी vector registers का उपयोग करते हैं, इसलिए वे सिस्टम में कहीं भी चलें, अवलोकन का लक्ष्य बन सकते हैं
  • क्योंकि register file उसी physical core पर साझा होती है, इसलिए अन्य VM, sandbox, container और process भी प्रभाव के दायरे में आते हैं
  • दो hyperthreads एक ही physical register file साझा करते हैं
  • हमले का optimized variant प्रति core लगभग 30KB प्रति सेकंड data leak कर सकता है, जो logged-in user की cryptographic keys और passwords की निगरानी के लिए पर्याप्त गति है
  • technical advisory और संबंधित code, Google के security research repository में सार्वजनिक किए गए हैं
  • testing code Linux के लिए दिया गया है, लेकिन bug किसी खास operating system पर निर्भर नहीं है, इसलिए सभी operating systems प्रभावित हैं

खोज की विधि: CPU fuzzing और Oracle Serialization

  • इस कमजोरी की खोज fuzzing से हुई
  • CPU उद्योग भी hardware defects खोजने के लिए silicon निर्माण के बाद post-silicon validation करता है
  • सामान्य coverage-based fuzzing के विपरीत, CPU में code coverage से सीधे मेल खाने वाला कोई metric नहीं होता
  • इसके बजाय performance counters का उपयोग करके दिलचस्प architectural events को fuzzer के लिए feedback के रूप में दिया जाता है
    • इस तरीके से ऐसे instruction sequences खोजे जा सकते हैं जिन्हें संयोग से ढूँढना मुश्किल होता
    • merge optimization जैसी सुविधाएँ स्वचालित रूप से खोजी जा सकीं
  • software fuzzing आम तौर पर crash ढूँढती है, लेकिन randomly generated CPU programs में crash स्वयं सही व्यवहार भी हो सकता है
  • पहले के approaches में से एक reversi है, जो हर random instruction के लिए inverse operation बनाकर देखता है कि final state शुरुआती state से अलग है या नहीं
    • x86 जैसी CISC architecture में testcase generation जटिल हो जाता है
  • एक और तरीका oracle का उपयोग करके test CPU के परिणामों की तुलना किसी दूसरे CPU या simulator से करना है
  • Oracle Serialization इन दोनों विचारों को जोड़ता है
    • पहले random program बनाया जाता है, फिर उसे serialized रूप में स्वतः बदला जाता है
    • store/load barrier, speculation fence, cache line flush जैसे serialization elements जोड़े जाते हैं
    • मूल और serialized program की performance characteristics अलग हो सकती हैं, लेकिन उनका output समान होना चाहिए
  • अगर final state मेल नहीं खाती, तो यह microarchitectural execution error हो सकता है, और यही mismatch Zenbleed की खोज तक ले गया

mitigation और detection की सीमाएँ

  • इस कमजोरी की रिपोर्ट 15 मई 2023 को AMD को की गई थी
  • AMD ने प्रभावित processors के लिए microcode update जारी किया
  • संभव है कि BIOS या operating system vendor ने पहले से यह update शामिल करने वाला patch उपलब्ध करा दिया हो
  • अनुशंसित mitigation microcode update लागू करना है
  • जब update लागू नहीं किया जा सकता, तब software workaround के रूप में DE_CFG[9] chicken bit सेट किया जा सकता है
    • इसकी performance cost हो सकती है
    • Linux में msr-tools के जरिए इसे सभी cores पर सेट किया जा सकता है
    • FreeBSD में cpucontrol(8) का उपयोग किया जाता है
    • अन्य operating systems में MSR कैसे सेट करना है यह न पता हो तो vendor support की जरूरत होगी
  • सिर्फ SMT disable करना पर्याप्त नहीं है
  • किसी भरोसेमंद attack detection technique के बारे में जानकारी नहीं है
    • क्योंकि इसके लिए किसी खास system call या privilege की जरूरत नहीं होती
    • vzeroupper के अनुचित उपयोग को statically detect करना भी संभव नहीं है

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

1 टिप्पणियां

 
GN⁺ 2023-07-25
Hacker News की राय

  • यह वाकई बहुत दिलचस्प है, और VM में चलाने भर से सुरक्षित नहीं हो जाता का एक क्लासिक उदाहरण बन सकता है
    VM escape के बारे में हमेशा से पता था, लेकिन यह बिना escape के भी लागू करने में आसान और असर के लिहाज से बड़ा, व्यापक vulnerability है
    इस bug का microcode से fix हो जाना यह नहीं बताता कि ऐसे मिलते-जुलते दूसरे bug नहीं हैं। कई 0-day के बारे में अक्सर भाड़े के black hat लोगों को सार्वजनिक होने से बहुत पहले ही पता होता है
    हाल के वर्षों में मिले CPU vulnerabilities:
    https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
    https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
    https://aepicleak.com/
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#SGAxe
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#LVI
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#Plundervolt
    https://en.wikipedia.org/wiki/Software_Guard_Extensions/…
    https://en.wikipedia.org/wiki/Software_Guard_Extensions#Enclave_attack
    https://en.wikipedia.org/wiki/Software_Guard_Extensions/…
    https://www.vusec.net/projects/crosstalk/
    https://en.wikipedia.org/wiki/Hertzbleed
    https://securityweek.com/amd-processors-expose-sensitive-data-new-squi…

    • समस्या यह है कि VM अब असली virtual machine जैसी नहीं रह गई है
      यह कोई बड़ा switch statement चलाकर instructions interpret नहीं करती, बल्कि असली CPU पर instructions execute करती है, और कुछ hardware flags पर निर्भर करती है जो यह गारंटी देने वाले माने जाते हैं कि data या instructions आपस में overlap नहीं होंगे। CPU यह वादा तो करता है, लेकिन व्यवहार में ऐसे वादे निभाना मुश्किल है
    • Meltdown/Spectre से तुलना थोड़ी भ्रामक हो सकती है
      वहाँ CPU ने वही किया जो उसे करना था, लेकिन timing-based तरीके से एक बिल्कुल नया attack संभव हुआ; जबकि Zenbleed पारंपरिक bug के ज्यादा करीब है, जहाँ ऐसा data register में रह जाता है जिसे वहाँ नहीं होना चाहिए
    • चाहे आप untrusted code को sandbox, container या VM में चलाएँ, कम से कम Rowhammer के बाद से वह सुरक्षित नहीं रहा
      मुझे लगता है कि ऐसी कई vulnerabilities की जड़ software और hardware पक्ष के बीच सही संवाद न होना है। software isolation guarantee मानकर चलता है, और hardware उस तरह की assumptions बनने पर पर्याप्त चेतावनी नहीं देता
    • आखिरकार लगता है कि इनमें से ज़्यादातर चीज़ें branch prediction से जुड़ी हैं
      branch prediction स्वभाव से ही इतनी जटिल लगती है कि वह हमेशा इस तरह की vulnerabilities के लिए खुली रहेगी, या फिर code path और instruction execution को सहज रूप से समझने के हमारे तरीके से इतनी अलग है कि बहुत देर होने से पहले boundary conditions का ध्यान ही नहीं आता
      क्या CPU architecture की जटिलता एक बिंदु के बाद इतनी बढ़ जाएगी कि लोग इसे सरल रखने के बदले performance hit स्वीकार करने लगें?
    • मैंने कुछ कंपनियों को internet-exposed/DMZ VM और internal VM को उसी hypervisor पर मिलाकर चलाते देखा है
      मैंने इस पर ध्यान दिलाया और सलाह दी कि इन्हें अलग hypervisor पर air-gap करना चाहिए, लेकिन मेरी बात हमेशा अनदेखी कर दी गई। अब शायद उसका नुकसान उन्हें ही उठाना पड़ेगा

  • exploit tar फ़ाइल के README में ज़्यादा विस्तृत जानकारी और public schedule शामिल है
    2023-05-09 CPU validation pipeline का एक component असामान्य परिणाम बना रहा था
    2023-05-12 समस्या को सफलतापूर्वक isolate और reproduce किया गया, जाँच जारी रही
    2023-05-14 समस्या के दायरे और गंभीरता का पता लगाया गया
    2023-05-15 एक संक्षिप्त status report लिखकर AMD PSIRT के साथ साझा की गई
    2023-05-17 AMD ने रिपोर्ट की पुष्टि की और माना कि इसे reproduce किया जा सकता है
    2023-05-17 भरोसेमंद PoC का development पूरा करके AMD के साथ साझा किया गया
    2023-05-19 प्रमुख kernel और hypervisor vendors को सूचित करना शुरू किया गया
    2023-05-23 AMD से Rome के लिए beta microcode update मिला
    2023-05-24 पुष्टि की गई कि update समस्या को ठीक करता है और AMD को सूचित किया गया
    2023-05-30 AMD ने बताया कि उसने partners को security bulletin भेज दिया है
    2023-06-12 स्थिति और विवरण पर चर्चा के लिए AMD के साथ meeting हुई
    2023-07-20 AMD ने तय embargo date से पहले बिना सूचना patch जारी कर दिया
    2023-07-21 चूँकि fix सार्वजनिक हो चुका था, इसलिए प्रमुख distributions को firmware package update तैयार करने के लिए निजी तौर पर सूचित करने का प्रस्ताव रखा गया
    2023-07-24 सार्वजनिक disclosure

    • लगता है AMD से किसी न किसी बिंदु पर गलती होना लगभग तय था
      तय embargo से पहले patch जारी कर दिया गया, और उसके बाद यह बात निजी तौर पर कहने की नौबत आई कि प्रमुख distributions को firmware package तैयार करना चाहिए
    • यह स्पष्ट नहीं है कि Arch Linux का amd-ucode 20230625.ee91452d-5 इस समस्या को ठीक करने वाला microcode update शामिल करता है या नहीं
      https://archlinux.org/packages/core/any/amd-ucode/ को आख़िरी बार 2023-07-25 11:48 UTC पर update किया गया था, और https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... में fix version 2023-07-18 बताया गया है
      शुरुआत में PKGBUILD के _tag=20230625 और source=("git+[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...](<https://git.kernel.org/pub/scm/…;)") की वजह से लगा कि अभी भी 20230625 firmware ही इस्तेमाल हो रहा है
      लेकिन _backports array में 20 घंटे पहले edit किए गए दो cherry-pick commits हैं, और https://gitlab.archlinux.org/archlinux/packaging/packages/li... का b250b32ab1d044953af2dc5e790819a7703b7ee6 वही kernel.org commit है जिसका ऊपर link दिया गया है, इसलिए उम्मीद है कि नवीनतम Arch Zenbleed के प्रति vulnerable नहीं होगा

  • यह सच में डरावना है। मेरे Zen 2 सिस्टम Ryzen 3600 पर unprivileged user के रूप में exploit चलाकर, और background में चल रहे text editor (Kate) में एक string copy-paste करने पर, कुछ ही सेकंड में उस string के टुकड़े zenbleed output में दर्ज हो गए
    अच्छी बात यह है कि यह exploit एक खास assembly routine पर बहुत अधिक निर्भर लगता है, इसलिए browser के JS या WASM से इसका दुरुपयोग करना काफ़ी मुश्किल होना चाहिए। अगर ऐसा न होता, तो सिर्फ़ किसी malicious tab को कुछ घंटों तक background में खुला छोड़ देने से भी आसानी से data leak हो सकता था
    Fedora maintainer के नया microcode deploy करने का इंतज़ार है ताकि kernel boot प्रक्रिया के दौरान उसे update कर सके

    • यहाँ कम से कम एक व्यक्ति कह रहा है कि इसे JavaScript से भी reproduce किया जा सकता है: https://news.ycombinator.com/item?id=36849767
    • मैंने अपने Zen 2 सिस्टम पर भी इसे आज़माया, और वही हमला KVM के अंदर चलाने पर भी काम करता है
    • एक बार JS में तरीका मिल गया, तो लगता है इसका काफ़ी व्यापक उपयोग हो सकता है
      साथ ही उम्मीद है कि V8 और SpiderMonkey के software patches पहले से और अतिरिक्त रूप से mitigation दे सकें
      हालांकि JS exploit को data बाहर निकालने का तरीका भी चाहिए होगा, और उसे पूरी तरह छिपाना शायद काफ़ी मुश्किल होगा
    • समझ नहीं आ रहा PoC को कैसे build करें। Ubuntu पर "No such file or directory" और error 127 आ रहा है

  • ऐसा लगता है कि OpenBSD ने पिछले 3 दिनों में AMD microcode loading जोड़ी है, यह कोई संयोग नहीं है
    https://news.ycombinator.com/item?id=36838511

  • ऐसा कहना कि AMD ने प्रभावित प्रोसेसरों के लिए microcode update जारी किया है, शायद पूरी तरह सटीक नहीं है
    AMD ने family 17h model 0x31 और 0xa0 के लिए microcode update[0] जारी किया है, और WikiChip[1] के अनुसार ये Rome, Castle Peak, Mendocino से मेल खाते हैं
    अभी तक Renoir, Grey Hawk, Lucienne, Matisse, Van Gogh के लिए microcode update नहीं दिखता। अच्छी बात यह है कि नया kernel इनके लिए बस chicken bit सेट कर सकता है, और वास्तव में ऐसा करता भी है[2]
    [0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
    [1] https://en.wikichip.org/wiki/amd/cpuid#Family_23_.2817h.29
    [2] https://github.com/torvalds/linux/commit/522b1d69219d8f08317...

  • संबंधित हिस्से को देखें तो, यह तकनीक CVE-2023-20593 है और सभी Zen 2-स्तर के प्रोसेसरों पर काम करती है, जिनमें कम से कम ये उत्पाद शामिल हैं
    AMD Ryzen 3000 Series Processors
    AMD Ryzen PRO 3000 Series Processors
    AMD Ryzen Threadripper 3000 Series Processors
    AMD Ryzen 4000 Series Processors with Radeon Graphics
    AMD Ryzen PRO 4000 Series Processors
    AMD Ryzen 5000 Series Processors with Radeon Graphics
    AMD Ryzen 7020 Series Processors with Radeon Graphics
    AMD EPYC “Rome” Processors

    • मैं जानना चाहता हूँ कि क्या इसका मतलब है “सिर्फ Zen 2 पर पुष्टि हुई है”, या यह कि समस्या निश्चित रूप से केवल इसी architecture तक सीमित है
      क्या यह संभव है कि यही या मिलती-जुलती तकनीक पहले के Zen/Zen+ या बाद के Zen 3 cores पर भी काम करे, लेकिन अभी तक इसे साबित न किया गया हो?
    • मेरा 2700X शायद बाल-बाल बच गया। अगर यह मानें कि 7020 series प्रभावित है और 7000 series नहीं, तो ऐसा लगता है
    • PlayStation 5 का क्या होगा, यह जानने की जिज्ञासा है। Xbox और Valve की उस डिवाइस के बारे में भी यही सवाल है
    • क्या Radeon के बिना Ryzen 5000 असुरक्षित नहीं है? वे प्रोसेसर Zen 3 लगते हैं
      मेरा AMD Ryzen 9 5950x Desktop Processor भी Zen 3 दिखता है, इसलिए शायद सुरक्षित है
      मैं अविश्वसनीय workloads नहीं चलाता, लेकिन जैसा कहते हैं, तैयार रहने वालों का साथ किस्मत देती है
    • जानकारी के लिए, Ryzen 3000 APU Zen 2 नहीं है

  • साइट ट्रैफिक के दबाव में डाउन हो रही है: https://web.archive.org/web/20230724143835/https://lock.cmpx...

    • यह तो एक साधारण static HTML page है, इसलिए समझ नहीं आता कि 2023 में static site ट्रैफिक से कैसे डाउन हो सकती है
      ज़्यादातर मामलों में HN ट्रैफिक मुश्किल से 100 pageviews per second तक पहुँचता है
    • तेज़ लिंक: https://archive.is/QAwvQ
    • मूल लिंक भी आखिरकार लोड हो जाता है। यह आपके environment पर निर्भर कर सकता है

  • https://www.amd.com/en/resources/product-security/bulletin/a...
    AMD security bulletin के अनुसार non-EPYC CPU के लिए firmware update साल के अंत तक नहीं आएगा। तब तक क्या users को chicken bit चालू करके performance hit सहना पड़ेगा?

    • क्या AMD सच में होश में है? यह medium severity नहीं है

  • जितना शानदार, उतना ही डरावना। 10MB sample को एक मिनट चलाने पर मैं अपने Bitwarden password के कुछ हिस्से, ssh login password, और banking credentials के टुकड़े “leak” कर सका, और उन्हें आसानी से फिर से जोड़ा जा सकता था

  • लेख वाकई बहुत अच्छा था। खासकर वह हिस्सा बहुत पसंद आया जिसमें बताया गया था कि यह कैसे तय किया जा सकता है कि random generation program सही तरीके से चला या नहीं
    सीधा-सादा तरीका यह है कि उसे किसी दूसरे processor या simulator जैसे oracle पर चलाकर देखा जाए कि क्या वह उसी तरह व्यवहार करता है
    लेकिन संकीर्ण timing window वाले microarchitectural effects की पुष्टि करने के लिए उसी program में कई stall, fence, nop आदि डालकर भी लिखा जा सकता है। single-threaded code में इससे output पर असर नहीं पड़ना चाहिए, लेकिन CPU के भीतर microarchitectural स्तर पर काफ़ी अलग चीज़ें हो रही होती हैं। इस तरह CPU खुद अपना oracle बन सकता है

    • यह हिस्सा सचमुच बहुत दिलचस्प था, और खासकर software fuzzing और hardware fuzzing के बीच का अंतर बहुत अच्छा लगा
      chicken bit भी पसंद आया था