📰 🙇🏽 🎷 स्टार संरेखण गाइड: कर्नेल पूल छिड़काव और VMware CVE-2013-2406 🍃 🏇🏾 🔼

यदि आप विंडोज में कर्नेल-मोड कमजोरियों के साथ गड़बड़ करते हैं, तो जल्द ही या बाद में आपको कर्नेल पूल छिड़काव जैसी तकनीक से निपटना होगा (बस इसे "परमाणु हीप परमाणुकरण" नहीं कहेंगे)। मुझे लगता है कि कर्नेल मेमोरी पूल के व्यवहार को नियंत्रित करने की क्षमता शोषक डेवलपर के लिए उपयोगी होगी।

इस तकनीक में महारत हासिल करने के लिए, आपके पास कर्नेल पूल डिवाइस का कम से कम एक विचार होना चाहिए। इस लेख में मैं केवल इसके कार्यान्वयन का विवरण प्रदान करने की कोशिश करूंगा जो पूल छिड़काव तकनीक के संदर्भ में महत्वपूर्ण हैं। कर्नेल पूल के उपकरण का अच्छी तरह से अध्ययन किया जाता है, इसलिए यदि आपको अभी भी अधिक गहराई से ज्ञान की आवश्यकता है, तो आप लेख के अंत में किसी भी खोज सेवा या लिंक से संपर्क कर सकते हैं।

कर्नेल पूल संरचना का अवलोकन

कर्नेल मेमोरी पूल - ऑपरेटिंग सिस्टम के कर्नेल में एक एकल स्थान जहां आप मेमोरी के आवंटन के लिए अनुरोध के साथ जा सकते हैं। कर्नेल मोड में स्टैक केवल छोटे और कई वेरिएबल्स के भंडारण के लिए उपयुक्त होते हैं, जो कि सरणियाँ नहीं हैं। जब ड्राइवर को एक बड़ी डेटा संरचना या स्ट्रिंग बनाने की आवश्यकता होती है, तो वह मेमोरी को आवंटित करने के लिए विभिन्न इंटरफेस का उपयोग कर सकता है, लेकिन अंत में वे पूल से मेमोरी का नेतृत्व करेंगे। "

कई प्रकार के पूल हैं, लेकिन उन सभी में एक ही संरचना है (विशेष पूल (विशेष पूल को छोड़कर), जिसका उपयोग चालक सत्यापनकर्ता उपयोगिता द्वारा किया जाता है)। प्रत्येक पूल में एक नियंत्रण संरचना होती है जिसे पूल विवरणक कहा जाता है। अन्य बातों के अलावा, यह पूल के मुक्त ब्लॉकों (चंक) की सूची संग्रहीत करता है, जो पूल के मुक्त स्थान का निर्माण करते हैं। पूल में ही स्मृति के पृष्ठ होते हैं। वे मानक 4-मेगाबाइट या बड़े 2-मेगाबाइट हो सकते हैं। उपयोग किए गए पृष्ठों की संख्या को गतिशील रूप से समायोजित किया गया है।

कर्नेल पूल के पृष्ठों को विभिन्न आकारों के टुकड़ों में विभाजित किया जाता है - ब्लॉक (चंक)। यह ब्लॉक है जो कर्नेल मॉड्यूल को आवंटित किया जाता है जब वे पूल से मेमोरी के आवंटन का अनुरोध करते हैं।

ब्लॉक में निम्नलिखित मेटाडेटा शामिल हैं:

पिछला आकार - पिछले ब्लॉक का आकार।
पूल इंडेक्स का उपयोग उन स्थितियों में किया जाता है जहां एक ही प्रकार के कई पूल होते हैं। उदाहरण के लिए, सिस्टम में कई पेजेड पूल हैं। इस फ़ील्ड का उपयोग यह निर्धारित करने के लिए किया जाता है कि ब्लॉक किस पूल से संबंधित है।
ब्लॉक का आकार - वर्तमान ब्लॉक का आकार। पिछले आकार क्षेत्र के समान, इसका आकार इनकोडिंग है
(ब्लॉक साइज + हेडर साइज + ऑल्टरनेट 4 बाइट्स टू ए पॉइंटर टू द प्रॉसेस दैट इज ब्लॉक) >> 3 (या >> 4 फॉर x64 सिस्टम)।
पूल प्रकार बिट झंडे का एक सेट है जो प्रलेखित नहीं हैं (!)।
- टी (ट्रैक किया गया): ड्राइवर चेक उपयोगिता द्वारा ब्लॉक को ट्रैक किया जाता है। इस झंडे का इस्तेमाल डिबगिंग के लिए किया जाता है।
- S (सत्र): ब्लॉक सत्र के पृष्ठांकित पूल से संबंधित है, जिसका उपयोग उपयोगकर्ता-विशिष्ट सत्र डेटा के लिए मेमोरी आवंटित करने के लिए किया जाता है।
- क्यू (कोटा): ब्लॉक कोटा प्रबंधन प्रणाली के साथ पंजीकृत है। यह ध्वज केवल 32-बिट सिस्टम पर लागू होता है। यदि इसे सेट किया जाता है, तो इस ब्लॉक का मालिक होने वाली प्रक्रिया के लिए एक पॉइंटर को ब्लॉक के अंत में लिखा जाता है।
- U (उपयोग में): वर्तमान में ब्लॉक उपयोग में है। "उपयोग की गई" स्थिति के विपरीत, एक ब्लॉक मुक्त हो सकता है, जिसका अर्थ है कि मेमोरी को इससे आवंटित किया जा सकता है। यह ध्वज दूसरे बिट में है, Windows Vista से शुरू होता है, इससे पहले यह तीसरे बिट में था।
- B (बेस पूल): यह फ़ील्ड निर्धारित करती है कि ब्लॉक किस बेस पूल से संबंधित है। दो बुनियादी पूल हैं - पृष्ठांकित और गैर पृष्ठांकित। गैर-पंप वाले को शून्य के साथ एन्कोड किया गया है, एक के साथ पंप किया गया है। विंडोज विस्टा से पहले, इस ध्वज ने दो बिट्स पर कब्जा कर लिया था, क्योंकि इसे (बेस पूल प्रकार + 1) के रूप में एन्कोड किया गया था, अर्थात। पृष्ठांकित पूल के लिए 0x10 और गैर पृष्ठांकित पूल के लिए 0x1 है।
पूल टैग का उपयोग डीबगिंग उद्देश्यों के लिए किया जाता है। कर्नेल मॉड्यूल चार प्रिंट करने योग्य वर्णों के हस्ताक्षर का संकेत देते हैं जो उपतंत्र या ड्राइवर की पहचान करते हैं जिससे ब्लॉक संबंधित है। उदाहरण के लिए, "NtFs" टैग का अर्थ है कि ब्लॉक NTFS ntfs.sys फ़ाइल सिस्टम ड्राइवर से संबंधित है।

ब्लॉक संरचना में 64-बिट सिस्टम पर कुछ अंतर हैं। सबसे पहले, हेडर फ़ील्ड बड़े होते हैं, और दूसरी बात, एक सूचक के साथ 8-बाइट फ़ील्ड होता है जो इस ब्लॉक का उपयोग करता है।

एक पूल में स्मृति आवंटित करने के लिए सिद्धांतों का अवलोकन

कल्पना करें कि पूल खाली है। मेरा मतलब है, इसमें कोई जगह नहीं है। यदि हम इससे मेमोरी आवंटित करने का प्रयास करते हैं (कहते हैं, 0xFF0 बाइट्स से कम), तो मेमोरी पेज पहले आवंटित किया जाएगा, और फिर पेज की शुरुआत में स्थित ब्लॉक को उस पर आवंटित किया जाएगा।

अब हमारे पास दो ब्लॉक हैं - एक जिसे हमने आवंटित किया, और मुफ्त। नि: शुल्क, बदले में, बाद के मेमोरी आवंटन संचालन में उपयोग किया जा सकता है। हालाँकि, अब से, पूल आवंटनकर्ता पृष्ठ के अंत में आवंटित ब्लॉकों को रखेगा या इस पृष्ठ पर मुक्त स्थान देगा।

जब यह मुक्त ब्लॉकों की बात आती है, तो वर्णित प्रक्रिया बिल्कुल विपरीत है। यदि वे समीप हैं तो ब्लॉक मुक्त हो जाते हैं और एक ब्लॉक में विलीन हो जाते हैं।

ध्यान दें कि वर्णित स्थिति काल्पनिक है और इसका उपयोग केवल एक उदाहरण के रूप में किया जाता है, क्योंकि अभ्यास पूल में कर्नेल मॉड्यूल द्वारा उपयोग के लिए पूल तैयार होने से बहुत पहले मेमोरी पेज भरे जाते हैं।

पूल से मेमोरी आवंटन को नियंत्रित करना

ध्यान रखें कि कर्नेल पूल अत्यधिक भरी हुई ऑपरेटिंग सिस्टम इकाइयाँ हैं। सबसे पहले, उनका उपयोग सभी प्रकार की वस्तुओं और कर्नेल की आंतरिक डेटा संरचनाओं को बनाने के लिए किया जाता है। इसके अलावा, उपयोगकर्ता-मोड मापदंडों को बफर करने के लिए कई सिस्टम कॉल में पूल का उपयोग किया जाता है। चूंकि ऑपरेटिंग सिस्टम लगातार ड्राइवर और सॉफ़्टवेयर के माध्यम से सिस्टम कॉल के माध्यम से हार्डवेयर बनाए रखता है, आप सिस्टम डाउनटाइम के दौरान भी पूल के उपयोग की आवृत्ति का अनुमान लगा सकते हैं।

जल्दी या बाद में, पूल खंडित हो जाते हैं। यह एक अलग क्रम में विभिन्न आकारों के मेमोरी ब्लॉकों के आवंटन और डीलोकेशन के कारण है। इसलिए, छिड़काव शब्द दिखाई देता है। जब क्रमिक रूप से पूल से मेमोरी आवंटित की जाती है, तो ब्लॉकों को बिल्कुल भी सन्निहित नहीं होना पड़ता है और सबसे अधिक संभावना है कि वे मेमोरी के विभिन्न हिस्सों में होंगे। इसलिए, जब हम मेमोरी को नियंत्रित (लाल) ब्लॉकों से भरते हैं, तो यह अधिक संभावना है कि हम दाईं ओर से बाईं ओर एक तस्वीर देखेंगे।

हालांकि, एक ऐसी स्थिति है जो शोषण के संदर्भ में महत्वपूर्ण है: जब "छायांकित" होने पर कोई काला क्षेत्र नहीं होता है, तो हमें अतिरिक्त स्थानों के बिना एक नया ब्रांड मिलता है। और उस पल से, "स्प्रे ब्रश" एक ठोस भरने के साथ एक नियमित रूप से बदल जाता है। यह तथ्य हमें पूल के व्यवहार और इसके "चित्र" पर महत्वपूर्ण स्तर पर नियंत्रण प्रदान करता है। महत्वपूर्ण पूर्ण नियंत्रण नहीं है, क्योंकि इस मामले में भी कोई गारंटी नहीं है कि हम पूरी तरह से "चित्र" के मालिक हैं, क्योंकि कोई और हमें हमेशा दूसरे रंग के "छींटे" से बाधित कर सकता है।

पूल छिड़काव के लिए उपयोग की जाने वाली वस्तु के प्रकार के आधार पर, हमारे पास पहले से निर्मित वस्तुओं की आवश्यक संख्या को हटाकर मुक्त ब्लॉकों से दिए गए आकार की खिड़कियां बनाने की क्षमता है। लेकिन सबसे महत्वपूर्ण तथ्य जो हमें पूल से स्मृति के आवंटन को नियंत्रित करने की अनुमति देता है, वह यह है कि आवंटनकर्ता अधिकतम प्रदर्शन के लिए प्रयास करता है। प्रोसेसर कैश के सबसे कुशल उपयोग के लिए, अंतिम मुक्त मेमोरी ब्लॉक पहले आवंटित किया जाएगा। यह नियंत्रित आवंटन का पूरा बिंदु है, क्योंकि आवंटित ब्लॉक के पते का अनुमान लगाना संभव है।

बेशक, ब्लॉक आकार मायने रखता है। इसलिए, आपको पहले मुक्त ब्लॉकों से खिड़की के आकार की गणना करनी चाहिए। यदि हम चुनिंदा रूप से 0x315 बाइट्स के ब्लॉक आकार को पूल 0x20 बाइट्स के छिड़काव के लिए ऑब्जेक्ट के आकार के साथ नियंत्रित करना चाहते हैं, तो 0x315 / 0x20 = (0x18 + 1) ब्लॉक को मुक्त करना आवश्यक है। मुझे लगता है कि यह समझ में आता है।

कर्नेल पूल छिड़काव तकनीक का सफलतापूर्वक उपयोग करने के बारे में कुछ नोट:

यदि ऑपरेटिंग ड्राइवर का उपयोग करके पूल से मेमोरी आवंटित करने की कोई संभावना नहीं है, तो ऑपरेटिंग सिस्टम ऑब्जेक्ट्स को छिड़काव के लिए ऑब्जेक्ट के रूप में उपयोग करने का अवसर हमेशा होता है। चूंकि ओएस ऑब्जेक्ट, अजीब तरह से पर्याप्त हैं, ओएस कर्नेल में संग्रहीत हैं, उनके लिए मेमोरी विभिन्न पूलों से आवंटित की जाती है।
- एक नॉन-पेजेड पूल स्टोर प्रक्रियाओं, थ्रेड्स, सेमाफोरेस, म्यूटेक्स आदि को स्टोर करता है।
- स्वैप पूल में निर्देशिका ऑब्जेक्ट, रजिस्ट्री कुंजियाँ, अनुभाग (तथाकथित फ़ाइल संघ या फ़ाइल मैपिंग), आदि होते हैं।
- सत्र पूल GDI और USER सबसिस्टम की वस्तुओं को संग्रहीत करता है: पैलेट, डिवाइस संदर्भ (डीसी), ब्रश, आदि।
इन वस्तुओं द्वारा कब्जा की गई स्मृति को मुक्त करने के लिए, यह संबंधित विवरणकर्ताओं को बंद करने के लिए पर्याप्त है।
जब तक हम पूल को वस्तुओं से भरना शुरू करते हैं, तब तक इसमें कई मेमोरी पेज होंगे, जिनसे ब्लॉक आवंटित किए जा सकते हैं। हालाँकि, ये पृष्ठ खंडित होंगे। चूँकि हमें नियंत्रित ब्लॉकों के साथ निरंतर भरने के साथ स्थान प्राप्त करने की आवश्यकता है, पहली चीज जो हमें करने की ज़रूरत है वह है पूल "स्पैम" ताकि वर्तमान पृष्ठों पर कोई खाली स्थान न हो। केवल इस मामले में हमारे पास नए पृष्ठ उपलब्ध होंगे, जिन्हें क्रमिक रूप से नियंत्रित ब्लॉकों से भरा जा सकता है। संक्षेप में, आपको कई ऑब्जेक्ट बनाने की आवश्यकता है।
आवश्यक विंडो आकार की गणना करते समय, ब्लॉक हेडर के आकार पर भी विचार करें, साथ ही इस तथ्य पर भी कि अंतिम आकार क्रमशः 32-बिट और 64-बिट सिस्टम पर 8 और 16 बाइट्स के लिए गोल है।
इस तथ्य के बावजूद कि हम ब्लॉकों के आवंटन को नियंत्रित कर सकते हैं, उनके सापेक्ष स्थिति की भविष्यवाणी करना मुश्किल है। हालाँकि, जब पूल छिड़काव के लिए OS ऑब्जेक्ट्स का उपयोग किया जाता है, तो SystemExtendedHandleInformation पैरामीटर के साथ NtQuerySystemInformation () फ़ंक्शन का उपयोग करके इसके डिस्क्रिप्टर द्वारा किसी ऑब्जेक्ट का पता लगाना संभव है। पूल छिड़काव की सटीकता में सुधार के लिए उसे प्रदान की गई जानकारी आवश्यक है।
पूल छिड़काव के समय संतुलन रखें। वस्तुओं का चयन करते समय लालची न बनें। स्पष्ट रूप से, ब्लॉक के आवंटन को नियंत्रित करना असंभव है यदि सिस्टम में मेमोरी बस बाहर चलाता है।
कर्नेल पूल का उपयोग करके कारनामों की विश्वसनीयता बढ़ाने के लिए चाल में से एक है थ्रेड की प्राथमिकता को बढ़ाना जो पूल छिड़काव करता है और भेद्यता की शुरुआत करता है। चूंकि थ्रेड्स पूल मेमोरी के लिए एक निरंतर दौड़ में अनिवार्य रूप से हैं, इसलिए सिस्टम में अन्य थ्रेड्स की तुलना में अधिक बार निष्पादित होने की संभावना को बढ़ाकर हीप्स का उपयोग करने की प्राथमिकता को बढ़ाना उपयोगी है। यह तकनीक को अधिक समग्र बनाने में मदद करेगा। पूल छिड़काव और भेद्यता की दीक्षा के बीच देरी को भी ध्यान में रखें: यह जितना छोटा होगा, उतना अधिक मौका होगा कि हम उस ब्लॉक में गिर जाएंगे जिसकी हमें ज़रूरत है।

वीएमवेयर सीवीई 2013-1406

फरवरी की शुरुआत में, VMware उत्पादों को अपडेट करने के लिए दिलचस्प सिफारिशें जारी की गई थीं। उनके द्वारा निर्णय लेते हुए, गैर-अद्यतन घटकों में एक भेद्यता मौजूद थी, जिससे मुख्य और अतिथि ओएस दोनों पर एक स्थानीय विशेषाधिकार वृद्धि हुई। इस तरह के "स्वादिष्ट" कमजोरियों को नजरअंदाज नहीं किया जा सकता है।

कमजोर घटक vmci.sys था। VMCI का मतलब वर्चुअल मशीन कम्युनिकेशन इंटरफेस है। यह इंटरफ़ेस वर्चुअल मशीनों और मुख्य OS के बीच बातचीत के लिए उपयोग किया जाता है। VMCI एक स्वामित्व प्रकार का सॉकेट प्रदान करता है जिसे vsocklib.dll लाइब्रेरी में विंडोज सॉकेट सेवा प्रदाता के रूप में कार्यान्वित किया गया है। Vmci.sys ड्राइवर एक वर्चुअल डिवाइस बनाता है जो आवश्यक कार्यक्षमता को लागू करता है। यह हमेशा मुख्य ओएस पर चल रहा है। अतिथि प्रणालियों के लिए, VMCI के काम करने के लिए, VMware उपकरण स्थापित किए जाने चाहिए।

किसी भी समीक्षा को लिखते समय, भेद्यता के उच्च-स्तरीय तर्क की व्याख्या करना अच्छा है ताकि समीक्षा एक जासूसी कहानी में बदल जाए। दुर्भाग्य से, इस मामले में, यह सफल नहीं होगा, क्योंकि वीएमसीआई के कार्यान्वयन के बारे में बहुत कम खुली जानकारी है। हालांकि, मुझे लगता है कि शोषण करने वाले डेवलपर्स इस बारे में चिंतित नहीं हैं। कम से कम यह अधिक लाभदायक है कि पूरे सिस्टम के काम करने के तरीके का विश्लेषण करने में बहुत समय व्यतीत करने के बजाय एक कार्यशील शोषण प्राप्त करें।

पैचडिफ ने तीन पैच फीचर का खुलासा किया है। सभी एक ही IOCTL नियंत्रण कोड 0x8103208C के प्रसंस्करण से संबंधित हैं। जाहिर है, सब कुछ विशेष रूप से इसके प्रसंस्करण के साथ गलत हो गया ...

तीसरे अपडेट किए गए फ़ंक्शन को अंततः पहले और दूसरे दोनों से बुलाया गया था। उसे अनुरोधित आकार के एक ब्लॉक को 0x68 से गुणा करना और इसे शून्य से भरना शुरू करना था। इस ब्लॉक में अनुरोध को संसाधित करने के लिए एक आंतरिक डेटा संरचना है। समस्या यह थी कि आवंटित ब्लॉक का आकार उपयोगकर्ता मोड में इंगित किया गया था और वास्तव में जांच नहीं की गई थी, जिसके परिणामस्वरूप आंतरिक संरचना आवंटित नहीं की गई थी, जिसके कारण कुछ दिलचस्प परिणाम सामने आए।

नियंत्रण कोड 0x8103208C के लिए, इनपुट और आउटपुट बफर निर्दिष्ट किए गए थे। कमजोर जगह पाने के लिए, इसका आकार 0x624 बाइट होना चाहिए। अनुरोध को संसाधित करने के लिए, 0x20C बाइट्स की एक आंतरिक संरचना आवंटित की गई थी। इसके पहले 4 बाइट्स पते [user_buffer + 0x10] पर निर्दिष्ट मूल्य से भरे गए थे। यह इन बाइट्स थे जिनका उपयोग भविष्य में दूसरे डेटा संरचना को उजागर करने के लिए किया गया था, जिसके पते को पहले के अंत में इंगित किया गया था। इस सब के साथ, दूसरी संरचना के आवंटन के परिणाम की परवाह किए बिना, एक निश्चित प्रेषण समारोह को बुलाया गया।

डिस्पैचर फ़ंक्शन

.text:0001B2B4 ; int __stdcall DispatchChunk(PVOID pChunk) .text:0001B2B4 DispatchChunk proc near ; CODE XREF: PatchedOne+78 .text:0001B2B4 ; UnsafeCallToPatchedThree+121 .text:0001B2B4 .text:0001B2B4 pChunk = dword ptr 8 .text:0001B2B4 .text:0001B2B4 000 mov edi, edi .text:0001B2B6 000 push ebp .text:0001B2B7 004 mov ebp, esp .text:0001B2B9 004 push ebx .text:0001B2BA 008 push esi .text:0001B2BB 00C mov esi, [ebp+pChunk] .text:0001B2BE 00C mov eax, [esi+208h] .text:0001B2C4 00C xor ebx, ebx .text:0001B2C6 00C cmp eax, ebx .text:0001B2C8 00C jz short CheckNullUserSize .text:0001B2CA 00C push eax ; P .text:0001B2CB 010 call ProcessParam ; We won't get here .text:0001B2D0 .text:0001B2D0 CheckNullUserSize: ; CODE XREF: DispatchChunk+14 .text:0001B2D0 00C cmp [esi], ebx .text:0001B2D2 00C jbe short CleanupAndRet .text:0001B2D4 00C push edi .text:0001B2D5 010 lea edi, [esi+8] .text:0001B2D8 .text:0001B2D8 ProcessUserBuff: ; CODE XREF: DispatchChunk+51 .text:0001B2D8 010 mov eax, [edi] .text:0001B2DA 010 test eax, eax .text:0001B2DC 010 jz short NextCycle .text:0001B2DE 010 or ecx, 0FFFFFFFFh .text:0001B2E1 010 lea edx, [eax+38h] .text:0001B2E4 010 lock xadd [edx], ecx .text:0001B2E8 010 cmp ecx, 1 .text:0001B2EB 010 jnz short DerefObj .text:0001B2ED 010 push eax .text:0001B2EE 014 call UnsafeFire ; BANG!!!! .text:0001B2F3 .text:0001B2F3 DerefObj: ; CODE XREF: DispatchChunk+37 .text:0001B2F3 010 mov ecx, [edi+100h] ; Object .text:0001B2F9 010 call ds:ObfDereferenceObject .text:0001B2FF .text:0001B2FF NextCycle: ; CODE XREF: DispatchChunk+28 .text:0001B2FF 010 inc ebx .text:0001B300 010 add edi, 4 .text:0001B303 010 cmp ebx, [esi] .text:0001B305 010 jb short ProcessUserBuff .text:0001B307 010 pop edi .text:0001B308 .text:0001B308 CleanupAndRet: ; CODE XREF: DispatchChunk+1E .text:0001B308 00C push 20Ch ; size_t .text:0001B30D 010 push esi ; void * .text:0001B30E 014 call ZeroChunk .text:0001B313 00C push 'gksv' ; Tag .text:0001B318 010 push esi ; P .text:0001B319 014 call ds:ExFreePoolWithTag .text:0001B31F 00C pop esi .text:0001B320 008 pop ebx .text:0001B321 004 pop ebp .text:0001B322 000 retn 4 .text:0001B322 DispatchChunk endp

इस प्रेषण समारोह ने एक सूचक को संसाधित करने के लिए देखा। प्रसंस्करण में संरचना में निर्धारित झंडे के आधार पर किसी वस्तु की डीफ्रेंसिंग और कुछ फ़ंक्शन को कॉल करना शामिल था। लेकिन चूंकि गलत मापदंडों के साथ प्रसंस्करण के लिए संरचना को अलग करना संभव नहीं था, इसलिए प्रेषण कार्य पहले ब्लॉक की सीमा से परे "पारित" हुआ। इस तरह के प्रसंस्करण ने एक पहुंच उल्लंघन और "मौत की नीली स्क्रीन" का नेतृत्व किया।

इस प्रकार, हम एक नियंत्रित पते पर मनमाने कोड को निष्पादित करने में सक्षम हैं:

 .text:0001B946 UnsafeFire proc near .text:0001B946 .text:0001B946 .text:0001B946 arg_0 = dword ptr 8 .text:0001B946 .text:0001B946 000 mov edi, edi .text:0001B948 000 push ebp .text:0001B949 004 mov ebp, esp .text:0001B94B 004 mov eax, [ebp+arg_0] .text:0001B94E 004 push eax .text:0001B94F 008 call dword ptr [eax+0ACh] ; BANG!!!! .text:0001B955 004 pop ebp .text:0001B956 000 retn 4 .text:0001B956 UnsafeFire endp

शोषण

चूंकि प्रेषण फ़ंक्शन ब्लॉक की सीमा से परे फैली हुई है, इसलिए यह या तो पड़ोसी ब्लॉक के साथ होती है, या एक असुरक्षित पृष्ठ के साथ होती है। यदि यह एक असुरक्षित मेमोरी में चला जाता है, तो एक अखंड अपवाद उत्पन्न होगा, और इसलिए एक "नीली स्क्रीन" प्रदर्शित की जाएगी। लेकिन जब यह पड़ोसी ब्लॉक से टकराता है, तो प्रेषण फ़ंक्शन प्रसंस्करण के लिए एक संरचना के लिए एक संकेतक के रूप में अपने हेडर की व्याख्या करता है।

मान लीजिए कि एक x86 सिस्टम है। डिस्पैचर के रूप में व्याख्या करने की कोशिश करने वाले चार बाइट्स वास्तव में पिछले ब्लॉक आकार, पूल इंडेक्स, वर्तमान ब्लॉक आकार और पूल प्रकार के झंडे हैं। चूँकि हम संसाधित किए जा रहे ब्लॉक के लिए पूल के आकार और सूचकांक को जानते हैं, इसलिए हम सूचक के निम्न शब्द का अर्थ जानते हैं:

0xXXXX0043 - 0x43 ब्लॉक का आकार है, जो पड़ोसी के लिए पिछला आकार क्षेत्र बन जाता है। 0 - पूल इंडेक्स, जो बिल्कुल शून्य होने की गारंटी है, क्योंकि ये ब्लॉक गैर-पंप वाले पूल में हैं, और यह सिस्टम में केवल एक है। ध्यान दें कि यदि पड़ोसी ब्लॉक समान मेमोरी पेज साझा करते हैं, तो वे उसी प्रकार और पूल के सूचकांक से संबंधित हैं।

उच्च शब्द ब्लॉक आकार को संग्रहीत करता है, जिसे हम भविष्यवाणी नहीं कर सकते हैं, और पूल प्रकार के झंडे, जो, इसके विपरीत, भविष्यवाणी की जा सकती है:

बी = 0: नॉनपेजेड पूल से ब्लॉक
U = 1: का अर्थ है कि ब्लॉक उपयोग में है
क्यू = 0/1: ब्लॉक कोटा हो सकता है
S = 0: पूल सत्र नहीं है
T = 0: ब्लॉक को डिफ़ॉल्ट रूप से ट्रैक नहीं किया जाता है
अप्रयुक्त बिट्स शून्य हैं

इस प्रकार, हमारे पास विंडोज 7 और 8 के लिए मान्य मेमोरी क्षेत्र हैं:

0x04000000 - नियमित ब्लॉक के लिए 0x06000000
कोटा ब्लॉक के लिए 0x14000000 - 0x16000000

उपरोक्त जानकारी के आधार पर, आप स्वतंत्र रूप से विंडोज एक्सपी और इस तरह के मेमोरी क्षेत्रों की गणना कर सकते हैं।

जैसा कि आप देख सकते हैं, ये क्षेत्र उपयोगकर्ता स्थान से संबंधित हैं, इसलिए हम किसी भी कोड को निष्पादित करने के लिए प्रेषण फ़ंक्शन को बाध्य कर सकते हैं, जिसमें हमारे द्वारा नियंत्रित भी शामिल हैं। ऐसा करने के लिए, आपको पहले प्रक्रिया में संकेतित मेमोरी क्षेत्रों को प्रोजेक्ट करना होगा, और फिर प्रत्येक 0x10000 बाइट्स के लिए, प्रेषण फ़ंक्शन की आवश्यकताओं को पूरा करना होगा:

पते पर [0x43 + 0x38], निम्नलिखित कारकों को संतुष्ट करने के लिए DWORD = 0x00000001 डालना आवश्यक है:
```
 .text:0001B2E1 010 lea edx, [eax+38h] .text:0001B2E4 010 lock xadd [edx], ecx .text:0001B2E8 010 cmp ecx, 1 
```
पते [0x43 + 0xAC] पर, आपको एक पॉइंटर को शेल कोड पर रखना होगा।
पते [0x43 + 0x100] पर, आपको शेल ऑब्जेक्ट के लिए एक पॉइंटर लगाने की आवश्यकता है, जिसे ओबफेरेफेरेंस ऑबजेक्ट () फ़ंक्शन द्वारा dereferenced जाएगा। ध्यान दें कि संदर्भ काउंटर ऑब्जेक्ट के संबंध में एक नकारात्मक ऑफसेट के साथ हेडर में संग्रहीत है, इसलिए सुनिश्चित करें कि ObfDereferenceObject () फ़ंक्शन में कोड एक असुरक्षित क्षेत्र पर नहीं पड़ता है। संदर्भ काउंटर के लिए उचित मूल्य भी निर्दिष्ट करें, क्योंकि, उदाहरण के लिए, जब संदर्भ काउंटर शून्य तक पहुंचता है, तो ObfDereferenceObject () फ़ंक्शन द्वारा मेमोरी को मुक्त करने का प्रयास करेगा जो उपयोगकर्ता मोड मेमोरी के लिए पूरी तरह से अनुपयुक्त हैं।

ध्यान रखें कि विभिन्न VMware उत्पादों के लिए ऑफ़सेट भिन्न हो सकते हैं।

सब कुछ सही किया है!

शोषित स्थिरता में वृद्धि

इस तथ्य के बावजूद कि हमने इस भेद्यता के दोहन के लिए एक अच्छी रणनीति विकसित की है, यह अभी भी अविश्वसनीय है। उदाहरण के लिए, एक प्रेषण समारोह एक मुक्त ब्लॉक पर गिर सकता है, जिसके खेतों की भविष्यवाणी नहीं की जा सकती है। इस तथ्य के बावजूद कि इस तरह के ब्लॉक का शीर्षक सूचक के रूप में व्याख्या किया जाएगा (क्योंकि यह शून्य के बराबर नहीं है), इसके प्रसंस्करण का परिणाम एक नीली स्क्रीन त्रुटि होगी। यह तब भी होगा जब प्रेषण फ़ंक्शन स्मृति के एक असुरक्षित क्षेत्र में गिर जाता है।

इस मामले में, कर्नेल पूल छिड़काव तकनीक बचाव के लिए आती है। एक पूल छिड़काव वस्तु के रूप में, मैंने सेमीफोर को चुना, क्योंकि वे आकार में सबसे उपयुक्त हैं। इस तकनीक का उपयोग करने के परिणामस्वरूप, शोषण की स्थिरता में काफी वृद्धि हुई है।

मैं आपको याद दिला दूं कि इस तरह के सुरक्षा तंत्र के लिए समर्थन SMEP के रूप में विंडोज 8 में दिखाई दिया, इसलिए डेवलपर आलस्य ने शोषण के विकास को कुछ हद तक जटिल कर दिया। SMEP बायपास के साथ आधार-स्वतंत्र कोड लिखना पाठक के लिए एक अभ्यास है।

X64 सिस्टम के लिए, इस तथ्य के साथ एक समस्या है कि सूचक का आकार 8 बाइट्स के बराबर हो गया है। इसका मतलब है कि पॉइंटर का सबसे पुराना डबल वर्ड (DWORD) पूल टैग फील्ड में आएगा। और चूंकि अधिकांश ड्राइवर और कर्नेल सबसिस्टम ऐसे लेबल के लिए ASCII वर्णों का उपयोग करते हैं, पॉइंटर गैर-विहित पता स्थान में आता है और ऑपरेशन के लिए उपयोग नहीं किया जा सकता है। लेखन के समय, मैंने इस बारे में कुछ भी समझदार नहीं सोचा था।

परिणाम

मुझे आशा है कि प्रदान की गई जानकारी उपयोगी थी। मैं माफी चाहता हूं कि आपको पैराग्राफ के एक जोड़े में जो कुछ भी चाहिए वह फिट नहीं हो सकता है। मैं आपको सुरक्षा के स्तर में पूर्ण वृद्धि के नाम पर अनुसंधान और संचालन में सफलता की कामना करता हूं।

पुनश्च मैं आपको याद दिलाता हूं कि भेद्यता को खत्म करने के लिए, आपको न केवल मुख्य, बल्कि सभी अतिथि प्रणालियों को अपडेट करने की आवश्यकता है!
पीपीएस यदि आप कुछ शर्तों के अनुवाद के साथ कुछ असुविधा महसूस करते हैं, तो भविष्य में इसके साथ रखने के लिए तैयार रहें, क्योंकि यह अनुवाद Microsoft भाषा पोर्टल पर अनुशंसित है।

डेमो!

संदर्भ
[१] तरजी मंड। विंडोज 7 पर कर्नेल पूल शोषण। ब्लैक हैट डीसी, 2011
[२] निकिता तारकानोव। विंडोज एक्सपी से विंडोज 8 से कर्नेल पूल ओवरफ्लो। ज़ीरोनाइट्स, 2011
[३] कोस्त्या कोर्तिन्स्की। वास्तविक दुनिया कर्नेल पूल शोषण। SyScan, 2008
[४] SoBeIt। विंडोज कर्नेल मेमोरी पूल का शोषण कैसे करें। X'con, 2005

स्टार संरेखण गाइड: कर्नेल पूल छिड़काव और VMware CVE-2013-2406