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

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

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

मूल कारण

SEV फर्मवेयर में master_handler_table नाम की एक तालिका होती है जिसमें सभी कमांड के लिए फंक्शन पॉइंटर्स के साथ-साथ कमांड से संबंधित कुछ और गुण होते हैं। उन दो अतिरिक्त गुणों में से दो हैं cmd_buf_type और snp_cmd_buf_enforcement। cmd_buf_type यह निर्धारित करता है कि कमांड बफर को होस्ट मेमोरी से/में कॉपी किया जाना चाहिए या नहीं। snp_cmd_buf_enforcement यह निर्धारित करता है कि क्या ये कॉपी ऑपरेशन उन जांचों के अधीन होने चाहिए जो यह सत्यापित करते हैं कि कमांड बफर का बैकअप लेने वाली मेमोरी FIRMWARE या DEFAULT स्थिति में है। वे कमांड जिनके लिए cmd_buf_type या तो CMD_BUF_OUTPUT_ONLY, CMD_BUF_INPUT_AND_OUTPUT, या CMD_BUF_INPUT_AND_OUTPUT_ERROR है, उन सभी के लिए snp_cmd_buf_enforcement को true पर सेट किया जाना चाहिए। अन्यथा कमांड आउटपुट को वापस लिखने से RMP कवर किए गए क्षेत्र के अंदर मेमोरी भ्रष्टाचार हो सकता है। snp_cmd_buf_enforcement ऐसे सभी कमांड के लिए true है, एक अपवाद को छोड़कर - SEV_MCMD_ID_ATTESTATION: इस कमांड का cmd_buf_type CMD_BUF_INPUT_AND_OUTPUT_ERROR पर सेट है, लेकिन इसका snp_cmd_buf_enforcement भी false पर सेट है। परिणामस्वरूप, RMP-कवर मेमोरी की ओर इशारा करते हुए कमांड बफर के साथ SEV_MCMD_ID_ATTESTATION को निष्पादित करना संभव है और आउटपुट वापस लिखे जाने पर वह मेमोरी दूषित हो जाती है।

मैं नहीं देखता कि SEV_MCMD_ID_ATTESTATION को अपवाद होने की आवश्यकता क्यों होगी, मुझे लगता है कि यह एक टाइपो/कॉपी-पेस्ट गलती हो सकती है।

शोषण

SEV_MCMD_ID_ATTESTATION कमांड बफर में केवल एक फ़ील्ड length (4 बाइट्स) में लिखता है और इसलिए केवल वे बाइट्स ही हैं जिनका उपयोग हम मेमोरी को दूषित करने के लिए कर सकते हैं। SEV_MCMD_ID_ATTESTATION हमेशा एक ही मान लिखता है - 0x000000d0। सौभाग्य से, कमांड बफर पर कोई संरेखण आवश्यकता नहीं है और इसलिए हम बड़ी सन्निहित मेमोरी को दूषित करने के लिए कमांड बफर को बार-बार स्थानांतरित कर सकते हैं। हम इसका उपयोग एक स्थिर पैटर्न के साथ गेस्ट कॉन्टेक्स्ट पेज के पहले 16 बाइट्स को दूषित करने के लिए करेंगे। उन पहले 16 बाइट्स में UMC की सीड होती है और इसलिए इसे एक स्थिर मान पर बाध्य करके, हम गेस्ट की एन्क्रिप्शन कुंजी को एक स्थिर मान पर बाध्य कर सकते हैं।

यहां प्रदान किया गया शोषण SWPSIRT-2684/CVE-2023-31355 के लिए मेरे द्वारा प्रदान किए गए शोषण पर भारी रूप से आधारित है।

भेद्यता का शोषण करने के लिए हम निम्नलिखित चरणों का पालन कर सकते हैं:

1. एक SEV या SEV-ES अतिथि लॉन्च करें। यह SEV_MCMD_ID_ATTESTATION के लिए आवश्यक है। इस अतिथि को चालू रखें।
2. पीड़ित अतिथि के लिए पते 0x2000 पर एक गेस्ट कॉन्टेक्स्ट पेज बनाएं। RMP कवर क्षेत्र में कोई भी अन्य पता भी काम करेगा, हालांकि डीबगिंग के लिए एक निश्चित पता उपयोगी है।
3. पीड़ित अतिथि के UMC की सीड को दूषित करने के लिए भेद्यता का उपयोग करें।
4. पीड़ित अतिथि कॉन्टेक्स्ट पेज को सक्रिय करें और पीड़ित अतिथि को लॉन्च और चलाएं।
5. पीड़ित अतिथि को डिकमीशन करें।
6. हमलावर अतिथि के लिए पते 0x2000 पर एक गेस्ट कॉन्टेक्स्ट पेज बनाएं। यह चरण 1 में उपयोग किया गया वही पता होना चाहिए।
7. हमलावर अतिथि के UMC की सीड को दूषित करने के लिए भेद्यता का उपयोग करें।
8. हमलावर अतिथि कॉन्टेक्स्ट पेज को सक्रिय करें और डीबग फ़्लैग सक्षम करके लॉन्च करें।
9. पीड़ित अतिथि की मेमोरी को हमलावर अतिथि को असाइन करें।
10. हमलावर अतिथि के कॉन्टेक्स्ट पेज का उपयोग करके पीड़ित अतिथि की मेमोरी को डिक्रिप्ट करने के लिए SNP_DBG_ENCRYPT कमांड का उपयोग करें। यह सफल होगा क्योंकि पीड़ित अतिथि और हमलावर अतिथि एक UMC की सीड साझा करते हैं।

प्रभाव

यहां प्रभाव कम से कम SWPSIRT-2684 जितना ही होना चाहिए। इस समय मेरे लिए यह स्पष्ट नहीं है कि क्या इस बग का उपयोग डिकमीशन होने से पहले एक चल रहे अतिथि की मेमोरी को डिक्रिप्ट करने के लिए किया जा सकता है।

शमन

snp_cmd_buf_enforcement को SEV_MCMD_ID_ATTESTATION के लिए true पर सेट किया जाना चाहिए।

दिलचस्प बात यह है कि Linux KVM होस्ट समर्थन पैच को अपडेट करने की आवश्यकता नहीं है क्योंकि वे पहले से ही SEV_CMD_ATTESTATION_REPORT को sev_cmd_buf_writable में एक कमांड के रूप में सूचीबद्ध करते हैं, जिसके लिए आवश्यक है कि इसका कमांड बफर FIRMWARE स्थिति में हो। अन्य हाइपरवाइज़रों के लिए परिवर्तनों की आवश्यकता हो भी सकती है और नहीं भी।

PoC उपयोग