Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
cve-2024-21978-poc — AMD SEV-SNP फर्मवेयर भेद्यता CVE-2024-21978 के लिए शोषण, जो संदर्भ पृष्ठों की मेमोरी भ्रष्टाचार के माध्यम से मनमाना गेस्ट मेमोरी के डिक्रिप्शन को सक्षम करता है। | Kitploit
उपकरण/GitHubGitHub/freax13/cve-2024-21978-poc
एन्क्रिप्शन/डिक्रिप्शन उपकरणमेमोरी फोरेंसिकभेद्यता विश्लेषणशोषणपेनिट्रेशन टेस्टिंगहार्डवेयर सुरक्षाबाइनरी शोषण
GitHubfreax13/cve-2024-21978-poc

cve-2024-21978-poc

AMD SEV-SNP फर्मवेयर भेद्यता CVE-2024-21978 के लिए शोषण, जो संदर्भ पृष्ठों की मेमोरी भ्रष्टाचार के माध्यम से मनमाना गेस्ट मेमोरी के डिक्रिप्शन को सक्षम करता है।

रिपॉजिटरी देखें
91 साल पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

SEV फर्मवेयर भेद्यता

इस रिपॉजिटरी में SEV फर्मवेयर में एक भेद्यता का शोषण (exploit) शामिल है। यह शोषण चल रहे SEV-SNP अतिथि (guest) की मनमानी मेमोरी को डिक्रिप्ट करने की अनुमति देता है।

संस्करण 1.55.16 (लेखन के समय नवीनतम) पर परीक्षित।

मूल कारण

SEV_INIT_EX कमांड का nv_paddr फ़ील्ड फर्मवेयर को मेमोरी का एक हिस्सा दान करने के लिए उपयोग किया जा सकता है, ताकि इसका उपयोग स्थायी फ्लैश (persistent flash) के बजाय किया जा सके। यदि SEV-SNP सक्षम है, तो यह मेमोरी FIRMWARE अवस्था में होनी चाहिए। फर्मवेयर SEV_INIT_EX कमांड निष्पादित करते समय एक बार इसकी जाँच करता है। उसके बाद, फर्मवेयर मान लेता है कि यह मेमोरी FIRMWARE अवस्था में है और बिना किसी अतिरिक्त जाँच के उसमें लिखता है। यह धारणा कि मेमोरी अभी भी FIRMWARE अवस्था में है, हमेशा सही नहीं होती; होस्ट को SNP_PAGE_RECLAIM कमांड का उपयोग करके अवस्था को वापस HYPERVISOR में बदलने से कोई नहीं रोकता। एक बार पेज HYPERVISOR अवस्था में आने के बाद, उन्हें अन्य अवस्थाओं जैसे CONTEXT में बदला जा सकता है। भले ही पेज अब FIRMWARE अवस्था में नहीं हैं, फर्मवेयर उन पेजों पर लिखेगा, जिससे कुछ पेज अवस्थाओं के लिए आवश्यक अखंडता (integrity) भंग हो जाएगी।

शोषण

हम इस मेमोरी भ्रष्टाचार (memory corruption) का शोषण CONTEXT पेजों को लक्षित करके कर सकते हैं। CONTEXT पेज एक शक्तिशाली लक्ष्य हैं, लेकिन कुछ समस्याएँ हैं:

  1. CONTEXT पेज अन्य मेमोरी की तुलना में एक अलग कुंजी से एन्क्रिप्टेड होते हैं। परिणामस्वरूप, भले ही हम सिफरटेक्स्ट को नियंत्रित कर सकें, प्लेनटेक्स्ट को नियंत्रित करना आसान नहीं है।
  2. फर्मवेयर द्वारा लिखी गई मेमोरी पर हमारा अधिक नियंत्रण नहीं है।

मेमोरी भ्रष्टाचार प्रभावी रूप से CONTEXT पेज को यादृच्छिक डेटा से भर देता है, इसलिए CONTEXT पेजों को इस तरह से भ्रष्ट करना आसान नहीं है जो हमलावर के लिए उपयोगी हो। इससे निपटने के लिए, हम बार-बार बग को ट्रिगर करके भ्रष्टाचार पैदा कर सकते हैं और SNP_GUEST_STATUS कमांड का उपयोग करके भ्रष्ट CONTEXT पेज के प्रासंगिक फ़ील्ड को पढ़ सकते हैं जब तक कि हमें उपयोगी मान न मिलें।

SNP_DBG_DECRYPT कमांड का उपयोग DEBUG नीति सक्षम वाले SEV-SNP अतिथि की मेमोरी को डिक्रिप्ट करने के लिए किया जा सकता है। यदि हम एक CONTEXT इस प्रकार बना सकते हैं कि उसमें DEBUG फ़्लैग सेट हो और वह किसी अन्य अतिथि का ASID रखता हो, तो हम इसका उपयोग दूसरे अतिथि की मेमोरी को डिक्रिप्ट करने के लिए कर सकते हैं, भले ही उस अतिथि पर DEBUG नीति सेट न हो।

यह पता चलता है कि SNP_DBG_DECRYPT CONTEXT पेज में अधिकांश फ़ील्ड को अनदेखा करता है, यह केवल gctx->guest.asid, gctx->guest.policy_snp और gctx->guest.guest_flags की जाँच करता है। मेमोरी भ्रष्टाचार के बाद इन फ़ील्ड के सही होने की संभावना अधिक नहीं है, लेकिन यह असंभव भी नहीं है। अच्छी खबर यह भी है कि हम GUEST_STATUS कमांड का उपयोग करके उन सभी फ़ील्ड को पढ़ सकते हैं।

निष्कर्ष में, हम निम्नलिखित चरणों के साथ बग का शोषण कर सकते हैं:

  1. rmpupdate निर्देश का उपयोग करके nv_paddr को FIRMWARE अवस्था में बदलें।
  2. SEV_INIT_EX कमांड निष्पादित करें।
  3. SNP_RECLAIM_PAGE कमांड का उपयोग करके nv_paddr को वापस HYPERVISOR अवस्था में बदलें।
  4. nv_paddr पर एक या अधिक CONTEXT पेज बनाएँ।
  5. SEV_PDH_GEN कमांड का उपयोग करके फर्मवेयर को nv_paddr पर लिखने के लिए प्रेरित करें। इससे CONTEXT पेज भ्रष्ट हो जाते हैं।
  6. GUEST_STATUS कमांड का उपयोग करके जाँचें कि क्या SNP_DBG_DECRYPT सफल होगा, यदि नहीं तो चरण 5 पर वापस जाएँ। यहाँ मुख्य बाधा यह है कि ASID 32-बिट इंट में संग्रहीत होते हैं, लेकिन वैध ASID बहुत कम हैं (509 या 1006, CPU पर निर्भर करता है), इसलिए इसे सही करने में काफी प्रयास लगेंगे।

शोषण अपना अधिकांश समय चरण 5 और 6 में बिताता है। सभी सही स्थितियाँ प्राप्त करने की संभावना EPYC Milan पर लगभग 1/20,000,000 है और हम प्रति सेकंड लगभग 100 प्रयास कर सकते हैं, इसलिए हम लगभग हर दो दिनों में एक बार सही स्थितियाँ प्राप्त करने की उम्मीद करते हैं (चेतावनी: गणनाएँ केवल अनुमान हैं और हो सकता है कि मैंने कुछ गड़बड़ किया हो, लेकिन किस्सों के अनुसार, हर दो दिनों में एक बार सही लगता है)। हम एक बार में एक CONTEXT पेज पर हमला करने के बजाय, nv_paddr, nv_paddr+4096, और nv_paddr+8192 पर तीन CONTEXT पेजों पर हमला करके इसे तेज़ कर सकते हैं (SEV_PDG_GEN तीन पेजों को भ्रष्ट करेगा)। सुविधाजनक रूप से, ये चरण पीड़ित अतिथि लॉन्च करने से पहले किए जा सकते हैं और मनमानी संख्या में अतिथियों पर हमला करने के लिए केवल एक बार सफल होने की आवश्यकता है (ध्यान दें कि PoC वर्तमान में केवल एक अतिथि पर हमला करता है)।

प्रभाव

हालाँकि मैं अभी तक इसका परीक्षण करने में सक्षम नहीं हूँ, मेरा मानना है कि एक बार जब हमलावर इस भेद्यता का उपयोग करके अतिथि के वर्चुअल मशीन प्लेटफ़ॉर्म संचार कुंजियों (virtual machine platform communication keys) को लीक कर देता है, तो वह अतिथि की ओर से फर्मवेयर को अतिथि संदेश (guest messages) भेज सकता है और प्रमाणन रिपोर्ट (attestation reports) का अनुरोध करने के लिए इसका उपयोग कर सकता है। यह SEV-SNP के एक प्रमुख सिद्धांत का उल्लंघन करता है जिसमें केवल अतिथि को प्रमाणन रिपोर्ट का अनुरोध करने में सक्षम होना चाहिए।

शमन

कुछ कमांड (जैसे SNP_RECLAIM_PAGE, SNP_GCTX_CREATE, RING_BUFFER, शायद और भी?, शायद सुरक्षित रहने के लिए सभी?) जो FIRMWARE पेज स्वीकार करते हैं, उन्हें जाँचना चाहिए कि क्या वे nv_paddr के साथ ओवरलैप करते हैं और यदि ऐसा करते हैं तो विफल हो जाएँ।

उन्नयन शमन

मेरे मन में एक और चिंता है, जिसके बारे में मुझे यकीन नहीं है कि वह वैध है और मैं आप सभी की राय सुनना चाहूँगा: IIUC (यदि मैं सही ढंग से समझूँ) SEV फर्मवेयर को चल रहे अतिथियों को बाधित किए बिना उन्नत (upgrade) किया जा सकता है। इसका तात्पर्य यह है कि एक पुराने कमजोर फर्मवेयर संस्करण से एक नए स्थिर फर्मवेयर संस्करण में भ्रष्ट CONTEXT पेज को ले जाना संभव होगा। क्या पुराने कमजोर संस्करण पर शुरू करना, ऊपर वर्णित शोषण करना, नए स्थिर फर्मवेयर को उन्नत और प्रतिबद्ध (commit) करना, नए फर्मवेयर के साथ अतिथि लॉन्च करना (ताकि प्रमाणन रिपोर्ट में पुराना फर्मवेयर संस्करण दिखाई न दे) और फिर नए संस्करण का उपयोग करके बनाए गए अतिथि पर हमला करने के लिए पुराने फर्मवेयर का उपयोग करके बनाए गए भ्रष्ट CONTEXT पेज का उपयोग करना संभव होगा? क्या नए अतिथि द्वारा बनाई गई प्रमाणन रिपोर्ट का उपभोक्ता यह बता सकेगा कि नया अतिथि लॉन्च होने से पहले किसी समय पुराना फर्मवेयर संस्करण चल रहा था? यदि नहीं, तो क्या इसे रोकने के लिए और शमन की आवश्यकता है?

PoC उपयोग

  1. linux-patches फ़ोल्डर में पैच को https://github.com/AMDESE/linux/commits/snp-host-v10 के शीर्ष पर लागू करें। कर्नेल बनाएँ, स्थापित करें और बूट करें।
  2. PoC चलाएँ।
    root@kitploit:~
    root@server:~/sev-exploit# cargo run --release
    Finished release [optimized] target(s) in 0.12s
    Running `target/release/sev-exploit`
Corrupt guest context page so that ASID is in range 1..510
Smallest ASID: 0x0000001f iterations: 14052175 zeros: 10539628 unique asids: 31500727 elapsed time: 1d 19h 20m 31s
Creating VM with same ASID
[03, 00, 00, 00, 00, 00, 00, 00, 11, 0f, a0, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, f0, 51, a5, 03, 3f, 69, 6b, 93, e8, d8, 61, 0d, 2e, 5a, 45, f1, ea, 6d, bf, 49, fe, e4, a9, 2d, 8d, af, 76, 5e, 2e, 56, e0, fa, a9, b3, a7, e0, bc, 09, d9, 4f, 28, 5c, 9f, 84, d2, 7e, 34, eb, ea, 3f, 29, 88, 30, 01, 28, 65, 8b, 73, 3c, 84, 00, ae, 4a, 74, a2, 7a, d1, c7, 4f, 63, 7f, 72, 7b, 3b, 2f, 08, b3, 1a, 8c, 99, 1b, ad, b5, 1d, 42, 0b, 4d, 98, d4, 7d, c1, 0b, d6, 2f, b4, 6c, 6b, 51, a2, 92, 17, 3b, 01, e8, 82, 11, 1e, cb, cb, a2, 8f, c9, b0, 52, 1d, 1d, b7, d2, 25, 8d, 32, a9, 7a, 6f, 86, e4, 40, 44, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 80, 00, 88, 00, 00, 00, 00, ee, ff, 00, 00, f0, ff, ff, ff, ff, ff, ff, ff, ff, 3f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, <cut off zeros>]
thread 'main' panicked at src/main.rs:170:13:
not yet implemented: use the leaked secrets to send guest messages
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

ध्यान दें कि शोषण का एक महत्वपूर्ण समय तक चलना सामान्य है (यदि आप भाग्यशाली हैं तो घंटों के क्रम में, यदि नहीं तो दिनों के क्रम में)। EPYC Genoa पर चलना संभवतः तेज़ होगा क्योंकि वहाँ लगभग दो गुना अधिक वैध ASID हैं।

चरण 5 और 6 के दौरान PoC कुछ मीट्रिक प्रदर्शित करता है:

  • "Smallest ASID": अब तक सामना किया गया सबसे छोटा ASID। यह सुनिश्चित करने के लिए एक सामान्यता जाँच मीट्रिक है कि हम समय के साथ छोटे और छोटे ASID का सामना करते हैं।
  • "iterations": इस मीट्रिक को हर बार बग ट्रिगर होने पर बढ़ाया जाता है।
  • "zeroes": लगभग 1/4 मामलों में, CONTEXT पेज ऐसी अवस्था में होता है जहाँ फर्मवेयर इसे अभी तक ASID असाइन नहीं मानता है। उन मामलों में SNP_GUEST_STATUS ASID फ़ील्ड में 0 लौटाएगा।
  • "unique asids": यह सुनिश्चित करने के लिए एक और सामान्यता जाँच मीट्रिक कि ASID यादृच्छिक हैं और कुछ समय बाद दोहराए नहीं जाते।
  • "elapsed time": PoC शुरू होने के बाद से बीता हुआ समय।

अधिकांश मामलों में, भ्रष्ट CONTEXT पेजों को खत्म करने (decommissioning) से फर्मवेयर क्रैश हो जाता है (सबसे अधिक संभावना यहाँ)। AFAICT (जहाँ तक मैं बता सकता हूँ) फर्मवेयर के क्रैश होने से पूरे सिस्टम का रीसेट हो जाता है। ऐसे क्रैश से बचने के लिए कर्नेल पैच CONTEXT पेजों को खत्म होने से रोकते हैं। इसका एक नकारात्मक पहलू यह है कि ccp कर्नेल मॉड्यूल को अनलोड नहीं किया जा सकता है। एक बार PoC शुरू हो जाने के बाद, इसे फिर से शुरू करने से पहले पूरे सिस्टम को रीबूट करना होगा (भले ही PoC सफल हुआ हो या रद्द किया गया हो)।

टूल डाउनलोड करें
  • भ्रष्ट CONTEXT पेज में भ्रष्ट ASID का उपयोग करके एक पीड़ित अतिथि (victim guest) लॉन्च करें (और वैकल्पिक रूप से चलाएँ)। सीक्रेट्स पेज (secrets page) पर नज़र रखें। यह संभव है क्योंकि SEV फर्मवेयर आंतरिक रूप से सक्रिय ASID को ट्रैक करता है और डुप्लिकेट की जाँच करने के लिए सक्रिय CONTEXT पेजों की जाँच नहीं करता है।
  • पीड़ित अतिथि के सीक्रेट्स पेज पर SNP_DBG_DECRYPT निष्पादित करने के लिए भ्रष्ट CONTEXT पेज का उपयोग करें।