dcheng69/cve-2022-0185-case-studyशैक्षिक केस स्टडी और CVE-2022-0185 के लिए एक्सप्लॉइट डेवलपमेंट वॉकथ्रू, एक Linux कर्नेल हीप-आधारित बफर ओवरफ्लो जो स्थानीय विशेषाधिकार वृद्धि को सक्षम करता है। इसमें POC, QEMU डीबगिंग, और Ubuntu एक्सप्लॉइट विस्तृत तकनीकी विश्लेषण के साथ शामिल है।
यह केस स्टडी ECE 9069: Introduction to Hacking : https://whisperlab.org/introduction-to-hacking/ असाइनमेंट का परिणाम है।
CVE-2022-0185 एक हीप-आधारित बफर ओवरफ्लो दोष है जो Linux कर्नेल के Filesystem Context कार्यक्षमता में legacy_parse_param फ़ंक्शन द्वारा आपूर्ति किए गए पैरामीटर की लंबाई को सत्यापित करने के तरीके में पाया गया था। एक अनप्रिविलेज्ड (यदि अनप्रिविलेज्ड यूज़र नेमस्पेस सक्षम हैं, अन्यथा नेमस्पेस्ड CAP_SYS_ADMIN विशेषाधिकार की आवश्यकता है) स्थानीय उपयोगकर्ता जो Filesystem Context API का समर्थन नहीं करने वाली फ़ाइल सिस्टम को खोलने में सक्षम है (और इस प्रकार लीगेसी हैंडलिंग पर वापस आ जाता है), इस दोष का उपयोग करके सिस्टम पर अपने विशेषाधिकारों को बढ़ा सकता है। [1]
इस भेद्यता की रिपोर्ट के बाद, इस बग को ठीक करने के लिए पैच जारी किया गया है:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=722d94847de2
https://ubuntu.com/security/CVE-2022-0185#impact-score
एक्सप्लोरर से एक विस्तृत लेख है: https://www.hackthebox.com/blog/CVE-2022-0185:_A_case_study
इस रिपोर्टरी में मैं इस भेद्यता को पुन: उत्पन्न करने के लिए बुनियादी कदमों और संबंधित पृष्ठभूमि जानकारी की व्याख्या करूंगा। साथ ही, अगर आपको कुछ भी अस्पष्ट लगता है, तो आप मुझे एक ईमेल भेज सकते हैं:[email protected] मुझे प्रश्न का उत्तर देने में काफी खुशी होगी।
CVE-2022-0185 भेद्यता 02/11/2022 को प्रकाशित की गई थी, जिसमें CVSS 3.x बेस स्कोर 8.4 (उच्च) था।[1] यह भेद्यता एक हीप-आधारित बफर ओवरफ्लो है, जो एक अहस्ताक्षरित पूर्णांक अंडरफ्लो के कारण होता है।
यह भेद्यता Linux v5.1 कर्नेल में शुरू की गई थी, जो 5.1 से अधिक कर्नेल संस्करणों वाले सभी Linux वितरणों को प्रभावित करती है। उदाहरण के लिए, Ubuntu 20.04 LTS (focal) इस बग के लिए असुरक्षित था। हालांकि, एक पैच जारी किया गया था और संस्करण 5.4.0-96.109 .[3]
इस भेद्यता का शोषण करने से एक अनप्रिविलेज्ड स्थानीय उपयोगकर्ता सिस्टम पर अपने विशेषाधिकारों को बढ़ा सकता है, संभावित रूप से पूरे सिस्टम से समझौता कर सकता है।[1] [2] यहाँ CVSS स्कोर का एक विस्तृत विश्लेषण है: बेस स्कोर: 8.4, एक महत्वपूर्ण सुरक्षा जोखिम का संकेत देता है जिस पर तत्काल ध्यान देने की आवश्यकता है। प्रभाव स्कोर: 5.9, यदि शोषण किया जाता है तो पर्याप्त संभावित क्षति का सुझाव देता है। उच्च गोपनीयता, अखंडता और उपलब्धता मान इस स्कोर में योगदान करते हैं। शोषणीयता स्कोर: 2.5, अपेक्षाकृत उच्च शोषणीयता का सुझाव देता है। स्थानीय आक्रमण वेक्टर, उच्च अखंडता , और उच्च उपलब्धता मान इस स्कोर में योगदान करते हैं।
तालिका 1.1 और तालिका 1.2 इन स्कोर और उनके घटकों के बारे में अधिक जानकारी प्रदान करती हैं।
| CVSS v3.1 गंभीरता | मान |
|---|---|
| बेस स्कोर | 8.4 HIGH |
| प्रभाव स्कोर | 5.9 |
| शोषणीयता स्कोर | 2.5 |
तालिका 1.1 CVSS गंभीरता स्कोर[1]
तालिका 1.2 CVSS वेक्टर[1]
आधुनिक कंप्यूटरों में दो पूर्णांक प्रकार होते हैं, साइन्ड और अहस्ताक्षरित। साइन्ड संख्या का प्रतिनिधित्व आम तौर पर दो के पूरक नामक एक ऑपरेशन शामिल करता है।[4] “दो का पूरक बाइनरी अंक का उपयोग सबसे बड़े स्थान मान के साथ संकेत के रूप में करता है ताकि यह इंगित किया जा सके कि बाइनरी संख्या धनात्मक है या ऋणात्मक”[4]
दो के पूरक को प्रस्तुत करने से घटाव की गणना जोड़ में परिवर्तित हो जाएगी, इसलिए CPU के डिज़ाइन और कार्यान्वयन को सरल बनाया जाएगा। किसी पूर्णांक के दो के पूरक का निर्माण तीन चरणों में शामिल है:[4]
चित्र 2.1.1.1 एक आरेख में रूपांतरण प्रक्रिया दिखाता है जिसमें “-6” को उसके दो के पूरक प्रारूप में परिवर्तित करने का एक वास्तविक उदाहरण है।
चित्र 2.1.1.2 दो के पूरक का उपयोग करके जोड़
चित्र 2.1.1.2 '-6' के दो के पूरक को '+6' में जोड़ने की प्रक्रिया दिखाता है। यह प्रदर्शित करता है कि दो के पूरक का उपयोग कैसे जोड़ को घटाव के विकल्प के रूप में उपयोग करने की अनुमति देता है।
चित्र 2.1.1.2 दो के पूरक का उपयोग करके जोड़
अनुभाग 2.1.1 से, हम पहले से ही समझ गए हैं कि दो का पूरक क्या है। अब, कंप्यूटर में अहस्ताक्षरित संख्या अंडरफ्लो के परिदृश्य पर एक नज़र डालते हैं। आधुनिक कंप्यूटरों में, जब अहस्ताक्षरित संख्याओं का उपयोग किया जाता है, तो सबसे महत्वपूर्ण बिट को साइन्ड बिट के रूप में नहीं माना जाता है; बल्कि, यह स्वयं अहस्ताक्षरित संख्या का हिस्सा है। इस स्थिति का अर्थ है कि जब एक अहस्ताक्षरित संख्या के साथ घटाव करते हैं, तो हमें सतर्क रहना चाहिए, क्योंकि यह अहस्ताक्षरित संख्या अंडरफ्लो के रूप में जानी जाने वाली स्थिति को जन्म दे सकता है।[5]
चित्र 2.1.2.1 एक 8-बिट अहस्ताक्षरित संख्या के लिए 5 में से 6 घटाने की स्थिति को दर्शाता है। अहस्ताक्षरित संख्या के लपेटने के कारण अंतिम परिणाम 255 होता है। जब यह अंडरफ्लो एक सशर्त बयान में होता है, तो इसमें बयान की कार्यक्षमता को बाधित करने की क्षमता होती है।
चित्र 2.1.2.1 अहस्ताक्षरित संख्या अंडरफ्लो
Linux कर्नेल में, स्लैब आवंटक एक मेमोरी प्रबंधन तंत्र है जिसका उपयोग छोटे मेमोरी खंडों के कुशल आवंटन और डीलोकेशन के लिए किया जाता है। यह स्लैब के कई कैश बनाए रखकर प्रदर्शन प्रदान करता है, प्रत्येक में निश्चित आकार के मेमोरी ब्लॉक होते हैं। आम तौर पर, kmalloc-32 32 बाइट्स मेमोरी आवंटित करता है, यह एक kmalloc-32 स्लैब है, जबकि kmalloc-4k 4096 बाइट्स मेमोरी आवंटित करता है, यह एक kmalloc-4k स्लैब है।[6]
इसके अलावा, Linux कर्नेल में स्लैब आवंटन में आम तौर पर कर्नेल के हीप मेमोरी क्षेत्र के भीतर एक सन्निहित पता स्थान से मेमोरी आवंटित करना शामिल होता है। यह सन्निहित पता कर्नेल द्वारा प्रबंधित किया जाता है और इसका उपयोग विभिन्न कर्नेल ऑब्जेक्ट और डेटा संरचनाओं के लिए मेमोरी आवंटित करने के लिए किया जाता है। चित्र 2.2.1.1 Linux कर्नेल मेमोरी में स्लैब के लेआउट को दर्शाता है।
चित्र 2.2.1.1 Linux में स्लैब आवंटक [7] (इस आकृति के लेखक https://leviathan.vip/ हैं)
यदि आप स्वयं संकलित Linux कर्नेल के साथ प्रक्रिया को पुन: उत्पन्न करना चाहते हैं तो कृपया पृष्ठभूमि जानकारी प्राप्त करने के लिए निम्नलिखित मार्कडाउन फ़ाइलें पढ़ें:
नोट:
सभी मार्कडाउन फ़ाइलों के साथ-साथ कोड और स्क्रिप्ट इस रिपॉजिटरी के विभिन्न फ़ोल्डरों में हैं, प्रत्येक फ़ोल्डर अपनी स्वयं की मार्कडाउन फ़ाइल के साथ आता है, कुछ करने का प्रयास करने से पहले इसे पढ़ें!
अनुभाग 2.1 में, हमने समझाया कि अहस्ताक्षरित अंडरफ्लो कैसे काम करता है। अब, हम कर्नेल फ़ंक्शन की जांच करेंगे जिसमें यह भेद्यता है।
उपयोगकर्ता “clubby789” ने कर्नेल फ़ंक्शन legacy_parse_param . में एक भेद्यता की खोज की। यह फ़ंक्शन मुख्य रूप से कर्नेल को पारित किए गए मापदंडों को पार्स करने के लिए जिम्मेदार है। CVE-2022-0185 में, इसे fsopen का उपयोग करके एक फ़ाइल डिस्क्रिप्टर खोलने के बाद, कर्नेल को कॉन्फ़िगरेशन कुंजी-मूल्य जोड़े पास करने के लिए fsconfig फ़ंक्शन का उपयोग करके लागू किया गया था। legacy_parse_param का एक सरलीकृत संस्करण निम्नलिखित कोड में दिखाया गया है। [2]```c static int legacy_parse_param(struct fs_context *fc, struct fs_parameter *param) { struct legacy_fs_context *ctx = fc->fs_private; // [1] unsigned int size = ctx->data_size; // [2] size_t len = 0; int ret; [ ... ] switch (param->type) { case fs_value_is_string: len = 1 + param->size; // [3] case fs_value_is_flag: len += strlen(param->key); break; default: return invalf(fc, "VFS: Legacy: Parameter type for '%s' not supported", param->key); } if (len > PAGE_SIZE-2-size) return invalf(fc, "VFS: Legacy: Cumulative options too large"); // [4] [ ... ] if (!ctx->legacy_data) { ctx->legacy_data = kmalloc(PAGE_SIZE, GFP_KERNEL); // [5] if (!ctx->legacy_data) return -ENOMEM; } ctx->legacy_data[size++] = ','; // [6] len = strlen(param->key); memcpy(ctx->legacy_data + size, param->key, len); size += len; if (param->type == fs_value_is_string) { ctx->legacy_data[size++] = '='; memcpy(ctx->legacy_data + size, param->string, param->size); size += param->size; } ctx->legacy_data[size] = '\0'; ctx->data_size = size; ctx->param_type = LEGACY_FS_INDIVIDUAL_PARAMS; return 0; }
उपरोक्त कोड स्निपेट से, हम देख सकते हैं कि पंक्तियाँ [1] और [2] कोड का संदर्भ स्थापित करती हैं, जबकि पंक्ति [4] में वह कथन है जहाँ अहस्ताक्षरित अंडरफ़्लो होता है। पंक्ति [5] हीप स्लैब आवंटन को संभालती है, और पंक्तियाँ [6] और [7] आवंटित स्लैब में डेटा भरने के लिए जिम्मेदार हैं। विशेष रूप से, पंक्ति [6] में एक अलग विभाजक के रूप में एक अल्पविराम (',') जोड़ा जाता है, और एक समान चिह्न ('=') भी जोड़ा जाता है, जिसके परिणामस्वरूप वास्तविक डेटा आकार से दो अतिरिक्त बाइट होते हैं।
पंक्ति [4] में, if कथन के अंदर के चर में `PAGE_SIZE` (4096 पर सेट एक मैक्रो) और `size` (एक अहस्ताक्षरित 64-बिट संख्या) शामिल हैं। जब कोई अहस्ताक्षरित संख्या 4095 तक जमा हो जाती है, तो अंडरफ़्लो होता है, जिसके कारण if कथन हमेशा गलत माना जाता है। यह पड़ोसी स्लैब में सीमा से बाहर लेखन की अनुमति देता है। अंडरफ़्लो एक अहस्ताक्षरित संख्या को घटाने के कारण होता है, जिसके परिणामस्वरूप 4096 - 4095 प्राप्त होता है, जो एक अहस्ताक्षरित संख्या 18446744073709551615 देता है।[2]
`18446744073709551615` के परिणाम की व्याख्या निम्नलिखित पाठ में की गई है:```c
if (len > PAGE_SIZE-2-size) return invalf(fc, "VFS: Legacy: Cumulative options too large");
ध्यान दें कि यहाँ PAGE_SIZE 4096 बाइट्स के बराबर है, और 2 प्रत्येक key-value जोड़ी को अलग करने के लिए जोड़े गए अक्षर , और = के बराबर है। समस्या यह है कि size एक unsigned value है, इस प्रकार जब size 4095 तक पहुँचता है, तो PAGE_SIZE-2-size का कथन signed value: -1 के बराबर होगा, हालाँकि unsigned value: 18446744073709551615 के लिए, जैसा कि निम्नलिखित आरेख में दिखाया गया है, 2's complement के कारण! [3]
इसलिए उपरोक्त if कथन हमेशा false होगा, जिसका अर्थ है कि बाकी का डेटा हमारे द्वारा आवंटित slab से परे heap पर कॉपी हो जाएगा!
यह समझने के बाद कि यह unsigned number underflow कैसे हो सकता है, हम भेद्यता प्रदर्शित करने के लिए एक proof of concept (POC) कोड बनाने के लिए आगे बढ़ सकते हैं।
उपयोगकर्ता “clubby789” हमें एक विस्तृत POC कोड प्रदान करता है, जो निम्नलिखित कोड स्निपेट में दिखाया गया है। कोड संक्षिप्त है; यह पहले ext4 नामक एक फ़ाइल डिस्क्रिप्टर खोलता है, फिर कर्नेल में डेटा भरने के लिए कई बार fsconfig का उपयोग करता है।
यहाँ दो बातों पर ध्यान देना है:
अनुभाग 3.1.1 में, हमने उल्लेख किया था कि आउट-ऑफ-बाउंड राइट देखने से पहले 4095 बाइट्स डेटा भरा जाना चाहिए। यह देखते हुए कि प्रत्येक चक्र में केवल 35 बाइट्स भरे जाते हैं, प्रूफ ऑफ कॉन्सेप्ट को पूरा करने के लिए हमें ऑपरेशन 117 बार (4095 / 35) करना होगा, फिर हीप मेमोरी का निरीक्षण करना होगा।
### 3.1.3 QEMU के साथ POC
इस रिपॉजिटरी में: GitHub - dcheng69/CVE-2022-0185-Case-Study, हमने poc.sh नामक एक शेल स्क्रिप्ट प्रदान की है जो डीबगिंग प्रक्रिया को सुविधाजनक बनाती है। सेटअप शुरू करने से पहले कृपया Poc फ़ोल्डर में मौजूद मार्कडाउन फ़ाइल पढ़ें।
चूंकि legacy_parse_param एक कर्नेल फ़ंक्शन है, इसलिए आपको कर्नेल फ़ंक्शन को डीबग करना होगा। ऐसा करने के लिए, आपको आवश्यक प्रतीकों और स्रोत कोड प्राप्त करने के लिए कर्नेल स्रोत को संकलित करना होगा। हमने प्रक्रिया में आपका मार्गदर्शन करने के लिए एक विस्तृत मार्कडाउन फ़ाइल भी प्रदान की है। कृपया अधिक विवरण के लिए Compile_linux फ़ोल्डर देखें।
चित्र 3.1.3.1 में, हमने प्रदर्शित किया है कि कर्नेल हीप में 4095 बाइट्स डेटा भरने के बाद, हमने अहस्ताक्षरित अंडरफ्लो का शोषण करके सफलतापूर्वक आउट-ऑफ-बाउंड राइट ट्रिगर किया। इसके अतिरिक्त, हमने कुल 4130 बाइट्स डेटा को kmalloc-4k स्लैब में भरा, जिससे पड़ोसी स्लैब सफलतापूर्वक दूषित हो गया। हालांकि इस उदाहरण में पड़ोसी स्लैब में कोई जानकारी नहीं है (सभी शून्य), हम अपने कोड को सावधानीपूर्वक बना सकते हैं ताकि इस सुविधा का उपयोग हानिकारक डेटा लिखने के लिए किया जा सके। हम प्रदर्शित करेंगे कि इसे अनुभाग 3.2 एक्सप्लॉइट में कैसे प्राप्त किया जाए।
**चित्र 3.1.3.1 QEMU के साथ POC**
अधिक जानकारी के लिए कृपया इस रिपॉजिटरी के `Poc` फ़ोल्डर में https://github.com/dcheng69/CVE-2022-0185-Case-Study/blob/main/Poc/poc.md देखें!
## 3.2 एक्सप्लॉइट
इस भेद्यता को जानने के बाद, हम इसका उपयोग करके एक शोषण कर सकते हैं, जिसके विवरण फ़ोल्डर `exploit-ubuntu` और इस मार्कडाउन फ़ाइल में दर्ज किए गए हैं: https://github.com/dcheng69/CVE-2022-0185-Case-Study/blob/main/explot-ubuntu/exploit.md
संक्षेप में, हमने उबंटू स्रोत कोड संकलित किया, डेब फ़ाइल प्राप्त की, फिर हमने इसे एक वर्चुअल मशीन पर परीक्षण किया ताकि विशिष्ट कर्नेल संस्करण प्राप्त हो सके। फिर हमने `System.map` फ़ाइल से प्राप्त जानकारी का उपयोग करके कर्नेल संस्करण को लक्षित करने के लिए शोषण कोड के ऑफ़सेट को संशोधित किया। अंत में हमने ग्रब को अपडेट किया और शोषण करने के लिए रीबूट किया!
### 3.2.1 एक्सप्लॉइट अवलोकन
उपयोगकर्ता 'clubby789' हमें एक विस्तृत शोषण कोड प्रदान करता है। हम एक अवलोकन से शुरू करेंगे, उसके बाद आरेखों का उपयोग करके कई प्रमुख अवधारणाओं की व्याख्या करेंगे। अंत में, हम वर्चुअल मशीन (VirtualBox) पर चल रहे उबंटू का उपयोग करके शोषण के परिणाम प्रस्तुत करेंगे।
इस भेद्यता के लिए प्रूफ ऑफ कॉन्सेप्ट प्रदर्शित करने के बाद, अब हम इसका शोषण करने के लिए आगे बढ़ सकते हैं। चित्र 3.2.1.1 में, इस भेद्यता का शोषण कैसे किया जाए, इसका एक अवलोकन दर्शाया गया है:
- बायां भाग लिनक्स कर्नेल बेस एड्रेस प्राप्त करने पर केंद्रित है। यह m_ts को ओवरराइड करने के लिए अहस्ताक्षरित अंडरफ्लो का शोषण करके प्राप्त किया जाता है, जो हमें सीमा से बाहर पढ़ने और पहले से छिड़के गए कर्नेल संरचनाओं तक पहुंचने की अनुमति देता है।
- दायां भाग रूट विशेषाधिकार प्राप्त करने का लक्ष्य रखता है। यह msg_msg संरचना के अगले पॉइंटर को modprobe_path पर इंगित करने के लिए अहस्ताक्षरित अंडरफ्लो का उपयोग करके प्राप्त किया जाता है। फिर हम एक पेज फॉल्ट ट्रिगर करते हैं जो हमारे निर्मित फ्यूज़ कोड को लागू करता है, जो कर्नेल स्पेस में मनमाना लिखने में सक्षम बनाता है।
**चित्र 3.2.1.1 एक्सप्लॉइट का अवलोकन**
### 3.2.2 लिनक्स कर्नेल बेस एड्रेस प्राप्त करें
जैसा कि पहले विश्लेषण किया गया था, हम इस भाग में msg_msg संरचना के m_ts फ़ील्ड को ओवरराइड करने के लिए अहस्ताक्षरित अंडरफ्लो का शोषण करेंगे, जिससे सीमा से बाहर पढ़ना संभव हो सकेगा। कर्नेल पॉइंटर्स वाली संरचनाओं के साथ हीप को स्प्रे करके, हम उम्मीद कर सकते हैं कि मेमोरी लीक प्राप्त होगी।
struct msg_msg लिनक्स कर्नेल में एक डेटा संरचना है जो सिस्टम V संदेश कतारों को लागू करने के लिए उपयोग की जाती है। इस अनुभाग में, हम struct msg_msg की आंतरिक संरचना और संदेश भेजने, प्राप्त करने और आवंटित करने से संबंधित कार्यों के तर्क पर ध्यान केंद्रित करते हैं। जैसा कि चित्र 3.2.2.1 में दिखाया गया है, ये वे कार्य हैं जिन्हें हमें समझने की आवश्यकता है।
संदेश भेजने का कार्यान्वयन msg.c फ़ाइल में स्थित है, जो एक संदेश की अधिकतम लंबाई 8192 बाइट्स के रूप में परिभाषित करता है। alloc_msg फ़ंक्शन में, संदेशों को उनकी लंबाई के आधार पर खंडों में विभाजित किया जाता है। यदि संदेश की लंबाई, संदेश हेडर के साथ, एक पेज (4096 बाइट्स) से अधिक है, तो संदेश पॉइंटर्स द्वारा एक साथ जुड़े कई खंडों में संग्रहीत किया जाएगा।
**चित्र 3.2.2.1 struct msg_msg भेजें और प्राप्त करें**
चित्र 3.2.2.2 में, हम देख सकते हैं कि struct msg_msg एक संदेश हेडर के रूप में कार्य करता है, जो 0x30 बाइट्स मेमोरी घेरता है। यदि संदेश में शेष डेटा है, तो इसे संदेश खंडों में संग्रहीत किया जाएगा और struct msg_msgseg से जोड़ा जाएगा। इसलिए, यदि कर्नेल अधिकतम 8192 बाइट्स तक के संदेशों की अनुमति देता है, तो डेटा अधिकतम तीन संदेश खंडों में संग्रहीत किया जाएगा।
**चित्र 3.2.2.2 struct msg_msg**
चित्र 3.2.2.3 में, हम struct msg_msg की संरचना को दर्शाते हैं। कोड से, हम जानते हैं कि m_ts फ़ील्ड वह है जिसे हमें सीमा से बाहर पढ़ने के लिए ओवरराइड करने की आवश्यकता है। (यदि आवश्यक हो तो आप `res` फ़ोल्डर के नीचे draw.io स्रोत फ़ाइल पा सकते हैं!)
**चित्र 3.2.2.2 struct msg_msg संरचना**
अब जब हम struct msg_msg की संरचना को समझ गए हैं, तो हमें यह सीखने की आवश्यकता है कि कर्नेल लीक कैसे प्राप्त करें। लिनक्स कर्नेल में कर्नेल एड्रेस स्पेस लेआउट रैंडमाइजेशन (KASLR) सुविधा है, जिसका अर्थ है कि कर्नेल कोड बूट चरण के दौरान तय किए गए एक यादृच्छिक पते पर लोड किया जाता है। हालांकि, कर्नेल के शुरुआती बिंदु से किसी भी फ़ंक्शन पते तक का ऑफ़सेट स्थिर रहता है, जिससे हम विशिष्ट कर्नेल फ़ंक्शन वाली संरचनाओं के साथ हीप स्पेस भरने के लिए विशिष्ट संचालन कर सकते हैं। ऑफ़सेट को कम करके, हम कर्नेल प्रारंभ पता पा सकते हैं।
सौभाग्य से, हम /proc/self/stat खोलकर seq_operations संरचनाओं के साथ आसानी से हीप को स्प्रे कर सकते हैं, जो kmalloc-32 स्लैब में रहता है। seq_operations की परिभाषा चित्र 3.2.2.3 में दिखाई गई है।
**चित्र 3.2.2.3 कर्नेल लीक के लिए स्ट्रक्ट्स**
अंत में, समग्र प्रक्रिया चित्र 3.2.2.4 में दर्शाई गई है। हम ओवरराइड की तैयारी के लिए legacy_data को 4095 बाइट्स डेटा से भरना शुरू करते हैं। फिर, हम struct msg_msg का उपयोग करके संदेश बनाते हैं। क्योंकि हीप मेमोरी लगातार आवंटित की जाती है, बनाए गए संदेश संभवतः पड़ोसी kmalloc-4k स्लैब के निकट होंगे। हम legacy_data में लिखे गए डेटा को नियंत्रित करके m_ts फ़ील्ड को ओवरराइड करते हैं।
इसके बाद, हम कई kmalloc-32 seq_operations संरचनाओं के साथ हीप को स्प्रे करते हैं। फिर हम संदेश कतार से डेटा प्राप्त करते हैं, जो सीमा से बाहर पढ़ने को ट्रिगर करता है। कर्नेल फ़ंक्शन से ऑफ़सेट को समायोजित करके, हम कर्नेल बेस एड्रेस प्राप्त कर सकते हैं।
**चित्र 3.2.2.3 आउट ऑफ बाउंड रीड का अवलोकन**
### 3.2.3 रूट विशेषाधिकार प्राप्त करें
हमारे पिछले विश्लेषण के समान, इस भाग में, हमें एक FUSE फ़ाइल सिस्टम स्थापित करने की आवश्यकता है, जो हमारे उपयोगकर्ता स्पेस कोड को कर्नेल स्पेस से पेज फॉल्ट को संभालने की अनुमति देता है। साथ ही, हम msg_msgseg *next पॉइंटर को modprobe_path पर इंगित करने के लिए ओवरराइड करेंगे, जिससे कर्नेल स्पेस में मनमाना लिखना संभव हो सकेगा।
आइए पहले चित्र 3.2.3.1 में दर्शाए गए FUSE कॉल स्टैक की जांच करें। सामान्य तौर पर, FUSE हमें उपयोगकर्ता स्पेस में एक फ़ाइल सिस्टम लागू करने की अनुमति देता है। जब कोई नया ऑपरेशन होता है, तो सिस्टम FUSE के लिए हमारे द्वारा परिभाषित कोड को लागू करेगा!
**चित्र 3.2.3.1 फ्यूज़ अवलोकन**
आइए विश्लेषण करें कि कर्नेल स्पेस में मनमाना लिखने के लिए FUSE का उपयोग कैसे करें। पहले, struct msg_msg के लिए संदेश भेजने के ऑपरेशन पर विचार करें। इस ऑपरेशन में कर्नेल स्पेस में डेटा लिखना शामिल है। यदि हम संदेश को दो खंडों के साथ बनाते हैं, तो हम पॉइंटर को ओवरराइड कर सकते हैं और किसी भी कर्नेल पते पर लिख सकते हैं। इस अवधारणा को चित्र 3.2.3.2 में दर्शाया गया है।
इसके अतिरिक्त, कतार में संदेश भेजने के तर्क की जांच करने के बाद, हम जानते हैं कि प्रक्रिया में उपयोगकर्ता स्पेस से कर्नेल स्पेस में बफर की प्रतिलिपि बनाना शामिल है। यदि संदेश पर्याप्त लंबे हैं, तो उन्हें खंड दर खंड कॉपी किया जाएगा। यदि हम इस प्रक्रिया के दौरान एक पेज फॉल्ट ट्रिगर कर सकते हैं, तो हम चित्र 3.2.3.2 में दिखाए गए परिदृश्य को प्राप्त कर सकते हैं।
सौभाग्य से, FUSE आवश्यक कार्यक्षमता प्रदान करता है। हम एक पेज को FUSE पर मैप कर सकते हैं, और जब पेज फॉल्ट ट्रिगर होता है, तो सिस्टम पेज फॉल्ट को संभालने के लिए हमारे FUSE रीड फ़ंक्शन को कॉल करेगा। पढ़ने की प्रक्रिया को तब तक रोककर जब तक अहस्ताक्षरित अंडरफ्लो msg_msg_seg *next पॉइंटर को ओवरराइड नहीं कर देता, और फिर संदेश भेजने की प्रक्रिया को फिर से शुरू करके, हम मनमाना लिखना प्राप्त कर सकते हैं। पूरी प्रक्रिया चित्र 3.2.3.3 में प्रदर्शित की गई है।
**चित्र 3.2.3.2 संदेश भेजने का उपयोग करना**
**चित्र 3.2.3.3 फ्यूज़ और संदेश भेजना**
### 3.2.4 वर्चुअल बॉक्स के साथ शोषण
मार्कडाउन फ़ाइल के अनुसार: https://github.com/dcheng69/CVE-2022-0185-Case-Study/blob/main/explot-ubuntu/exploit.md
एक बार संकलन पूरा हो जाने पर, आप चित्र 3.2.4.1 में शोषण के परिणाम देख सकते हैं।
**चित्र 3.2.4.1 वर्चुअल बॉक्स शोषण**
# 4. भेद्यता का शमन
## 4.1 आधिकारिक पैच
इस भेद्यता की रिपोर्ट करने के बाद, लिनक्स और इसके कई वितरणों ने इस बग को ठीक करने के लिए पैच को मर्ज कर दिया।[9] [10] [11]
निम्नलिखित स्क्रीनशॉट में, हम लिनस टॉर्वाल्ड्स द्वारा मर्ज किए गए पैच को दिखाते हैं। इस अंडरफ्लो समस्या का शमन केवल घटाव संक्रिया को जोड़ में परिवर्तित करना है।
# 5. वास्तविक दुनिया का प्रभाव
इस रिपोर्ट में, हम प्रदर्शित करते हैं कि इस भेद्यता का उपयोग करके उबंटू सिस्टम से समझौता कैसे किया जा सकता है। इसके अतिरिक्त, यह संभावित रूप से पुराने सिस्टम को लक्षित कर सकता है जिनमें नियमित सुरक्षा अद्यतनों का अभाव है।
कुबेरनेट्स के संबंध में, यह भेद्यता विशेषाधिकार वृद्धि, कंटेनर पलायन, या सेवा से इनकार हमलों का परिणाम हो सकती है।
हालांकि समाचारों में इस भेद्यता के कारण होने वाले किसी भी नुकसान की सूचना नहीं मिली है, यह लगातार महत्वपूर्ण सुरक्षा अद्यतनों को लागू करने के महत्व को रेखांकित करता है। जिस शोधकर्ता ने इस भेद्यता की सूचना दी, वह नैतिक हैकिंग प्रथाओं का उदाहरण है जिसका हम सभी को पालन करना चाहिए।[12]
# संदर्भ
[1] https://nvd.nist.gov/vuln/detail/CVE-2022-0185
[2] https://www.hackthebox.com/blog/CVE-2022-0185:_A_case_study
[3] https://ubuntu.com/security/CVE-2022-0185#impact-score
[4] [https://en.wikipedia.org/wiki/Two%27s_complement](https://en.wikipedia.org/wiki/Two's_complement)
[5]https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Unsigned-Overflow.html
[6] https://www.kernel.org/doc/gorman/html/understand/understand011.html
[7] https://leviathan.vip/
[8] https://www.willsroot.io/2021/08/corctf-2021-fire-of-salvation-writeup.html
[9] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=722d94847de2
[10] https://ubuntu.com/security/CVE-2022-0185
[11] https://access.redhat.com/security/cve/CVE-2022-0185
[12]https://jfrog.com/blog/the-impact-of-cve-2022-0185-linux-kernel-vulnerability-on-popular-kubernetes-engines/
[14] https://github.com/chenaotian/CVE-2022-0185?tab=readme-ov-file
[15] https://www.tutorialspoint.com/two-s-complement
| CVSS v3.1 मीट्रिक | मान |
|---|
| आक्रमण वेक्टर (AV) | Local |
| आवश्यक विशेषाधिकार (PR) | None |
| उपयोगकर्ता सहभागिता (UI) | None |
| गोपनीयता (C) | High |
| अखंडता (I) | High |
| उपलब्धता (A) | High |