आधुनिक ओएस में कर्नेल की मेमोरी प्रकटीकरण

कटर के नीचे M86usz Jurczyk द्वारा X86 एमुलेशन और टेंट ट्रैकिंग ( आर्टिकल प्रोजेक्ट ज़ीरो ) के साथ कर्नेल मेमोरी डिस्क्रिप्शन का पता लगाने वाले दस्तावेज़ के उद्घाटन भाग का अनुवाद है।

दस्तावेज़ के अनुवादित भाग में:

• सी प्रोग्रामिंग भाषा विशेषण (स्मृति विस्तार समस्या के भाग के रूप में)
• विंडोज और लिनक्स गुठली के संचालन की बारीकियों (स्मृति विस्तार समस्या के भाग के रूप में)
• कर्नेल मेमोरी प्रकटीकरण का महत्व और OS सुरक्षा पर प्रभाव
• कर्नेल मेमोरी के प्रकटीकरण का पता लगाने और उसका मुकाबला करने के लिए मौजूदा तरीके और तकनीक

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

परिचय

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

X86 / x86-64 प्लेटफॉर्म पर काम करने वाले आधुनिक ऑपरेटिंग सिस्टम मल्टीट्र्रेड हैं और क्लाइंट-सर्वर मॉडल का उपयोग करते हैं जिसमें उपयोगकर्ता-मोड एप्लिकेशन (क्लाइंट) को स्वतंत्र रूप से निष्पादित किया जाता है और सिस्टम द्वारा प्रबंधित संसाधन के साथ काम करने के इरादे से ओएस कर्नेल (सर्वर) को कॉल करता है। कर्नेल फ़ंक्शन (रिंग 0) के पूर्वनिर्धारित सेट को कॉल करने के लिए उपयोगकर्ता मोड कोड ( रिंग 3 ) द्वारा उपयोग किए जाने वाले तंत्र को सिस्टम कॉल या (संक्षेप में) syscalls कहा जाता है। एक विशिष्ट प्रणाली कॉल चित्र 1 में दिखाया गया है:

चित्र 1: सिस्टम कॉल जीवन चक्र।

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

विशेषाधिकार प्राप्त सिस्टम मेमोरी का प्रकटीकरण तब होता है जब ओएस कर्नेल संबंधित जानकारी (अंदर समाहित) को स्टोर करने के लिए आवश्यक मेमोरी से अधिक (अधिक) का एक क्षेत्र लौटाता है। अक्सर निरर्थक बाइट्स में एक अलग संदर्भ में आबादी वाले डेटा होते हैं, और फिर मेमोरी को पूर्व-प्रारंभ नहीं किया गया था, जो नए डेटा संरचनाओं में सूचना के प्रसार को रोक देगा।

C प्रोग्रामिंग भाषा की बारीकियाँ

इस खंड में, हम सी भाषा के कई पहलुओं को देखते हैं जो स्मृति विस्तार समस्या के लिए सबसे महत्वपूर्ण हैं।

निर्विवाद चरों की अपरिभाषित स्थिति

सरल प्रकारों के व्यक्तिगत चर (जैसे कि चार या इंट), साथ ही डेटा संरचनाओं (सरणियों, संरचनाओं और यूनियनों) के सदस्य पहले प्रारंभिककरण तक अपरिभाषित स्थिति में रहते हैं (चाहे वे स्टैक पर या ढेर पर रखे गए हों)। C11 विनिर्देशन से प्रासंगिक उद्धरण (ISO / IEC 9899: 201x समिति ड्राफ्ट N1570, अप्रैल 2011):

6.7.9 इनिशियलाइज़ेशन
...
10 यदि ऐसी वस्तु जिसमें स्वत: भंडारण अवधि है, को स्पष्ट रूप से प्रारंभ नहीं किया गया है, तो इसका मूल्य अनिश्चित है ।

7.22.3.4 मॉलोक फ़ंक्शन
...
2 मालॉक फ़ंक्शन किसी ऑब्जेक्ट के लिए स्थान आवंटित करता है जिसका आकार विशिष्ट है i एड आकार के अनुसार और जिसका मूल्य अनिश्चित है ।

7.22.3.5 रियललोक फ़ंक्शन
...
2 realloc फ़ंक्शन ptr द्वारा बताई गई पुरानी ऑब्जेक्ट को हटा देता है और एक पॉइंटर को एक नई ऑब्जेक्ट पर लौटाता है, जिसका साइज़ speci by ed होता है। नई वस्तु की सामग्री, पुरानी वस्तु की तरह ही होगी, जो कि पहले से संबंधित थी, नए और पुराने आकारों के कम तक। पुरानी वस्तु के आकार से परे नई वस्तु में किसी भी बाइट का अनिश्चित मान होता है ।

सिस्टम कोड पर लागू होने वाला हिस्सा स्टैक पर स्थित वस्तुओं के लिए सबसे अधिक प्रासंगिक है, क्योंकि ओएस कर्नेल में आमतौर पर अपने स्वयं के शब्दार्थ के साथ गतिशील आवंटन इंटरफेस होता है (जरूरी नहीं कि मानक सी लाइब्रेरी के साथ संगत हो, जैसा कि बाद में वर्णित किया जाएगा)।

जहां तक ​​हम जानते हैं, विंडोज और लिनक्स (Microsoft C / C ++ कंपाइलर, gcc, LLVM) के लिए तीन सबसे लोकप्रिय सी कंपाइलरों में से कोई भी कोड नहीं बनाता है जो रिलीज-बिल्ड मोड (या इसके समकक्ष) में स्टैक पर प्रोग्रामर-अनइंस्टॉल किए गए वैरिएबल को प्री-इनिशियलाइज़ करता है। स्टैक फ्रेम को विशेष बाइट्स के साथ चिह्नित करने के लिए कंपाइलर विकल्प हैं - उदाहरण के लिए (माइक्रोसॉफ्ट विज़ुअल स्टूडियो में मार्कर / / आरटीसी), लेकिन प्रदर्शन कारणों से रिलीज़ बिल्ड में उनका उपयोग नहीं किया जाता है। नतीजतन, स्टैक पर अनइंस्टॉल किए गए चर संबंधित मेमोरी क्षेत्रों के पुराने मूल्यों को विरासत में लेते हैं।

एक काल्पनिक विंडोज सिस्टम कॉल के मानक कार्यान्वयन के एक उदाहरण पर विचार करें जो एक इनपुट पूर्णांक को दो से गुणा करता है और गुणा (परिणाम 1) का परिणाम देता है। स्पष्ट रूप से, विशेष स्थिति में (InputValue == 0), चर OutputValue असिंचित रहता है और ग्राहक को वापस कॉपी किया जाता है। यह त्रुटि आपको प्रत्येक कॉल के लिए कर्नेल स्टैक मेमोरी के चार बाइट खोलने की अनुमति देती है।

NTSTATUS NTAPI NtMultiplyByTwo(DWORD InputValue, LPDWORD OutputPointer) { DWORD OutputValue; if (InputValue != 0) { OutputValue = InputValue * 2; } *OutputPointer = OutputValue; return STATUS_SUCCESS; } 

कोड सूची 1: एक असमान स्थानीय चर के माध्यम से मेमोरी का विस्तार करना।

एक असिंचित स्थानीय चर के माध्यम से लीक व्यवहार में बहुत आम नहीं हैं: एक तरफ, आधुनिक कंपाइलर अक्सर ऐसी समस्याओं का पता लगाते हैं और चेतावनी देते हैं, दूसरी तरफ, ऐसे लीक कार्यात्मक त्रुटियां हैं जिन्हें विकास या परीक्षण के दौरान पता लगाया जा सकता है। हालांकि, दूसरा उदाहरण (लिस्टिंग 2 में) दिखाता है कि संरचना क्षेत्र के माध्यम से एक रिसाव भी हो सकता है।

इस स्थिति में, आरक्षित संरचना फ़ील्ड कोड में स्पष्ट रूप से उपयोग नहीं की जाती है, लेकिन फिर भी उपयोगकर्ता मोड में वापस कॉपी की जाती है और इसलिए, कॉलिंग कोड को कर्नेल मेमोरी के चार बाइट्स भी उजागर करती है। यह उदाहरण स्पष्ट रूप से दिखाता है कि कोड निष्पादन की सभी शाखाओं के लिए क्लाइंट को लौटाए गए प्रत्येक संरचना के प्रत्येक क्षेत्र को प्रारंभ करना एक आसान काम नहीं है। कई मामलों में, जबरन आरंभिकता अतार्किक लगती है, खासकर अगर यह क्षेत्र कोई व्यावहारिक भूमिका नहीं निभाता है। लेकिन यह तथ्य है कि स्टैक पर (या ढेर पर) एक अनइंस्टीट्यूटेड वैरिएबल (या स्ट्रक्चर फील्ड) इस मेमोरी एरिया (एक अन्य ऑपरेशन के संदर्भ में) में पहले से संग्रहीत डेटा की सामग्री को स्वीकार करता है, कर्नेल विस्तार विस्तार समस्या के दिल में है।

 typedef struct _SYSCALL_OUTPUT { DWORD Sum; DWORD Product; DWORD Reserved; } SYSCALL_OUTPUT, *PSYSCALL_OUTPUT; NTSTATUS NTAPI NtArithOperations( DWORD InputValue, PSYSCALL_OUTPUT OutputPointer ) { SYSCALL_OUTPUT OutputStruct; OutputStruct.Sum = InputValue + 2; OutputStruct.Product = InputValue * 2; RtlCopyMemory(OutputPointer, &OutputStruct, sizeof(SYSCALL_OUTPUT)); return STATUS_SUCCESS; } 

लिस्टिंग 2: एक आरक्षित संरचना क्षेत्र के माध्यम से मेमोरी का विस्तार करना।

संरचनाओं और पैडिंग बाइट्स का संरेखण

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

6.5.3.4 आकार और Alignof ऑपरेटरों
...
4 [...] जब एक ऑपरेंड पर लागू किया जाता है जिसमें संरचना या संघ प्रकार होता है, तो परिणाम आंतरिक और अनुगामी गद्दी सहित ऐसी वस्तु में कुल बाइट्स की संख्या होती है।

6.2.8 वस्तुओं का संरेखण
1 पूर्ण वस्तु प्रकारों में संरेखण आवश्यकताएं होती हैं जो उन पतों पर प्रतिबंध लगाती हैं जिन पर उस प्रकार की वस्तुओं को आवंटित किया जा सकता है । एक संरेखण एक कार्यान्वयन-परिभाषित एकीकृत पूर्णांक मान है जो क्रमिक बाइट्स के बीच बाइट्स की संख्या का प्रतिनिधित्व करता है जिस पर किसी दिए गए ऑब्जेक्ट को आवंटित किया जा सकता है। [...]

6.7.2.1 संरचना और संघ के नमूने .1 ers
...
17 एक संरचना या संघ के अंत में अनाम पैडिंग हो सकती है ।

यही है, x86 (-64) आर्किटेक्चर के लिए सी भाषा संकलक संरचनाओं के क्षेत्रों के प्राकृतिक संरेखण का उपयोग करते हैं (एक आदिम प्रकार): प्रत्येक ऐसे क्षेत्र को एन बाइट्स द्वारा संरेखित किया जाता है, जहां एन क्षेत्र का आकार है। इसके अलावा, संपूर्ण संरचनाएं और जोड़ भी तब संयोजित किए जाते हैं जब उन्हें किसी ऐरे में घोषित किया जाता है, और नेस्टेड फ़ील्ड के संरेखण की आवश्यकता पूरी होती है। संरेखण सुनिश्चित करने के लिए, अंतर्निहित पैडिंग बाइट्स को आवश्यक संरचनाओं में डाला जाता है। यद्यपि वे स्रोत कोड में सीधे पहुंच योग्य नहीं हैं, ये बाइट्स स्मृति क्षेत्रों से पुराने मान भी प्राप्त करते हैं और उपयोगकर्ता मोड में जानकारी संचारित कर सकते हैं।

Listing 3 में उदाहरण में, SYSCALL_OUTPUT संरचना को कॉलिंग कोड पर वापस लौटा दिया गया है। इसमें 4 और 8 बाइट फ़ील्ड शामिल हैं, जिन्हें 4 पैडिंग बाइट्स द्वारा अलग किया गया है, लार्जसम फील्ड के पते के लिए आवश्यक है कि वह 8 से अधिक हो। इस तथ्य के बावजूद कि दोनों क्षेत्रों को सही ढंग से आरंभ किया गया है, पैडिंग बाइट्स को स्पष्ट रूप से सेट नहीं किया गया है, जो फिर से कूड़े के ढेर मेमोरी के विस्तार की ओर जाता है। मेमोरी में संरचना का विशिष्ट स्थान चित्र 2 में दिखाया गया है।

 typedef struct _SYSCALL_OUTPUT { DWORD Sum; QWORD LargeSum; } SYSCALL_OUTPUT, *PSYSCALL_OUTPUT; NTSTATUS NTAPI NtSmallSum( DWORD InputValue, PSYSCALL_OUTPUT OutputPointer ) { SYSCALL_OUTPUT OutputStruct; OutputStruct.Sum = InputValue + 2; OutputStruct.LargeSum = 0; RtlCopyMemory(OutputPointer, &OutputStruct, sizeof(SYSCALL_OUTPUT)); return STATUS_SUCCESS; } 

लिस्टिंग 3: संरचना को संरेखित करके मेमोरी का विस्तार करना।

चित्रा 2: स्मृति में संरचना को ध्यान में रखते हुए संरेखण का प्रतिनिधित्व।

संरेखण के माध्यम से लीक अपेक्षाकृत सामान्य हैं, क्योंकि सिस्टम कॉल के बहुत सारे आउटपुट पैरामीटर संरचनाओं द्वारा दर्शाए जाते हैं। समस्या 64-बिट प्लेटफ़ॉर्म के लिए विशेष रूप से तीव्र है, जहां पॉइंटर्स, size_t और इसी प्रकार के आकार 4 से 8 बाइट्स तक बढ़ जाते हैं, जिससे ऐसी संरचनाओं के क्षेत्रों को संरेखित करने के लिए आवश्यक पैडिंग की उपस्थिति होती है।

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

  memset(&OutputStruct, 0, sizeof(OutputStruct)); 

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

6.2.6 प्रकार के प्रतिनिधि
6.2.6.1 सामान्य
...
6 जब किसी सदस्य ऑब्जेक्ट में संरचना या यूनियन प्रकार के ऑब्जेक्ट में एक मान संग्रहीत किया जाता है , तो किसी भी पैडिंग बाइट्स के अनुरूप ऑब्जेक्ट प्रतिनिधित्व के बाइट्स अनिर्दिष्ट ec एड वैल्यू लेते हैं । [...]

हालाँकि, व्यवहार में, सी संकलक में से कोई भी हमने स्पष्ट रूप से घोषित क्षेत्रों के मेमोरी क्षेत्रों के बाहर पढ़ा या लिखा है। ऐसा लगता है कि यह राय ऑपरेटिंग सिस्टम के डेवलपर्स द्वारा साझा की गई है जो कि मेमसेट का उपयोग करते हैं।

विभिन्न आकारों के संघ और क्षेत्र

कम विशेषाधिकार प्राप्त कॉलिंग कोड के साथ संचार के संदर्भ में जोड़ एक और जटिल सी भाषा निर्माण हैं। विचार करें कि C11 विनिर्देश कैसे स्मृति में यूनियनों के प्रतिनिधित्व का वर्णन करता है:

6.2.5 प्रकार
...
20 किसी भी प्रकार की व्युत्पन्न प्रकारों का निर्माण वस्तु और फ़ंक्शन प्रकारों से किया जा सकता है, इस प्रकार है: [...] एक संघ प्रकार सदस्य वस्तुओं के एक अतिव्यापी सेट का वर्णन करता है , जिनमें से प्रत्येक में वैकल्पिक रूप से name एड नाम और संभवतः अलग प्रकार होता है।

6.7.2.1 संरचना और संघ के नमूने .1 ers
...
6 जैसा कि 6.2.5 में चर्चा की गई है, एक संरचना एक प्रकार है जिसमें सदस्यों का अनुक्रम होता है, जिसका भंडारण एक क्रमबद्ध क्रम में आवंटित किया जाता है, और एक संघ एक प्रकार है जिसमें सदस्यों का अनुक्रम ओवरलैप होता है ।
...
16 एक संघ का आकार अपने सदस्यों में सबसे बड़ा होने के लिए पर्याप्त नहीं है । अधिकांश सदस्यों में से किसी एक के मूल्य को किसी भी समय एक यूनियन ऑब्जेक्ट में संग्रहीत किया जा सकता है।

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

 typedef union _SYSCALL_OUTPUT { DWORD Sum; QWORD LargeSum; } SYSCALL_OUTPUT, *PSYSCALL_OUTPUT; NTSTATUS NTAPI NtSmallSum( DWORD InputValue, PSYSCALL_OUTPUT OutputPointer ) { SYSCALL_OUTPUT OutputStruct; OutputStruct.Sum = InputValue + 2; RtlCopyMemory(OutputPointer, &OutputStruct, sizeof(SYSCALL_OUTPUT)); return STATUS_SUCCESS; } 

कोड सूची 4: एक संघ को आंशिक रूप से प्रारंभिक करके मेमोरी का विस्तार करना।

चित्रा 3: संरेखण के साथ स्मृति में संघ का प्रतिनिधित्व।

यह पता चला है कि SYSCALL_OUTPUT संघ का कुल आकार 8 बाइट्स (बड़े लार्जसम क्षेत्र के आकार के कारण) है। हालाँकि, फ़ंक्शन केवल छोटे फ़ील्ड का मान सेट करता है, जिससे 4 अनुगामी बाइट्स को अनइंस्टॉल किया जाता है, जो बाद में उनके क्लाइंट एप्लिकेशन को लीक करता है।

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

असुरक्षित आकार

जैसा कि पिछले दो खंडों में दिखाया गया है, आकार के ऑपरेटर का उपयोग कर्नेल मेमोरी को प्रकट करने में प्रत्यक्ष या अप्रत्यक्ष रूप से योगदान कर सकता है, जिससे पहले आरंभिक की तुलना में अधिक डेटा कॉपी किया जा सकता है।

C के पास कर्नेल से उपयोगकर्ता स्थान पर डेटा को सुरक्षित रूप से स्थानांतरित करने के लिए आवश्यक उपकरण नहीं है - या, अधिक सामान्यतः, किसी भी अलग सुरक्षा संदर्भों के बीच। भाषा में रनटाइम मेटाडेटा नहीं है जो स्पष्ट रूप से इंगित कर सकता है कि प्रत्येक डेटा संरचना में कौन से बाइट सेट किए गए थे जो कि ओएस कर्नेल के साथ बातचीत करने के लिए उपयोग किया जाता है। नतीजतन, जिम्मेदारी प्रोग्रामर के पास होती है, जिसे यह निर्धारित करना चाहिए कि कॉलिंग कोड में प्रत्येक ऑब्जेक्ट के किन हिस्सों को पास किया जाना चाहिए। यदि सही ढंग से किया जाता है, तो आपको सिस्टम कॉल में उपयोग किए जाने वाले प्रत्येक आउटपुट संरचना के लिए एक अलग सुरक्षित कॉपी फ़ंक्शन लिखने की आवश्यकता है। जो बदले में कोड के आकार में एक सूजन पैदा करेगा, इसकी पठनीयता में गिरावट और सामान्य रूप से, एक थकाऊ और समय लेने वाला कार्य होगा।

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

OS की बारीकियाँ

कुछ कर्नेल डिज़ाइन समाधान, प्रोग्रामिंग विधियाँ, और कोड पैटर्न हैं जो प्रभावित करते हैं कि ऑपरेटिंग सिस्टम मेमोरी एक्सपेंशन कमजोरियों से कैसे प्रभावित होता है। उन्हें निम्नलिखित उप-वर्गों में माना जाता है।

पुन: गतिशील स्मृति

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

निम्नलिखित पैराग्राफ में, हम विंडोज और लिनक्स कर्नेल, और उनके सबसे उल्लेखनीय गुणों में उपयोग किए जाने वाले आवंटनकर्ताओं का एक संक्षिप्त अवलोकन देते हैं।

विंडोज
Windows कर्नेल पूल मैनेजर का मुख्य कार्य ExAllocatePoolWithTag है , जिसे सीधे या उपलब्ध शेल के माध्यम से कहा जा सकता है: ExAllocatePool {∅, Ex, WithQuotaTag, WithTagPriority}। इन कार्यों में से कोई भी डिफ़ॉल्ट रूप से या किसी इनपुट झंडे के माध्यम से, वापस की गई मेमोरी की सामग्री को फ्लश नहीं करता है। इसके विपरीत, वे सभी अपने संबंधित MSDN प्रलेखन में निम्नलिखित चेतावनी देते हैं:

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

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

लिनक्स
लिनक्स कर्नेल में गतिशील रूप से मेमोरी आवंटित करने के लिए तीन मुख्य इंटरफेस हैं:

• kmalloc - एक सामान्य फ़ंक्शन का उपयोग मनमाने आकार के मेमोरी ब्लॉकों को आवंटित करने के लिए किया जाता है (आभासी और भौतिक पता स्थान दोनों में निरंतर), स्लैम मेमोरी आवंटन का उपयोग करता है।
• kmem_cache_create और kmem_cache_alloc - एक निश्चित आकार (संरचनाएं, उदाहरण के लिए) की वस्तुओं को आवंटित करने के लिए एक विशेष तंत्र, स्लैब मेमोरी आवंटन का भी उपयोग करता है।
• vmalloc एक शायद ही कभी इस्तेमाल किया जाने वाला आवंटन कार्य है जो ऐसे क्षेत्रों को लौटाता है जिनकी निरंतरता की गारंटी भौतिक मेमोरी स्तर पर नहीं है।

ये फ़ंक्शन (स्वयं के द्वारा) यह गारंटी नहीं देते हैं कि चयनित क्षेत्रों में पुराना (संभावित गोपनीय) डेटा नहीं होगा, जो कर्नेल के ढेर की स्मृति को खोलना संभव बनाता है। हालाँकि, कई तरीके हैं जिनमें कॉलिंग कोड अशक्त मेमोरी का अनुरोध कर सकता है:

• Kmalloc फ़ंक्शन में kzalloc का एक एनालॉग होता है , जो यह सुनिश्चित करता है कि लौटी हुई मेमोरी साफ़ हो गई है।
• वैकल्पिक __GFP_ZERO ध्वज को उसी परिणाम को प्राप्त करने के लिए kmalloc , kmem_cache_alloc और कुछ अन्य कार्यों में पास किया जा सकता है।
• kmem_cache_create एक वैकल्पिक निर्माता फ़ंक्शन को एक पॉइंटर स्वीकार करता है जिसे कॉलिंग कोड पर लौटने से पहले प्रत्येक ऑब्जेक्ट को पूर्व-प्रारंभ करने के लिए कहा जाता है। किसी दिए गए मेमोरी क्षेत्र को शून्य करने के लिए कंस्ट्रक्टर को एक आवरण के चारों ओर एक आवरण के रूप में लागू किया जा सकता है।

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

निश्चित आकार का सारणी

कई ओएस संसाधनों तक पहुंच उनके परीक्षण नामों से प्राप्त की जा सकती है। विंडोज में नामित संसाधनों की विविधता बहुत बड़ी है, उदाहरण के लिए: फ़ाइलें और निर्देशिकाएं, कुंजियाँ और रजिस्ट्री कुंजियाँ, विंडोज़, फोंट और बहुत कुछ। उनमें से कुछ के लिए, नाम की लंबाई सीमित है और एक निरंतरता द्वारा व्यक्त की जाती है, जैसे कि MAX_PATH (260) या LF_FACESIZE (32)। ऐसे मामलों में, कर्नेल डेवलपर्स अक्सर अधिकतम आकार के बफ़र्स की घोषणा करके और उन्हें केवल एक पंक्ति के रूप में कॉपी करते हैं (उदाहरण के लिए, साइज़ोफ़ कीवर्ड का उपयोग करके) केवल पंक्ति के संबंधित भाग के साथ काम करने के बजाय कोड को सरल बनाते हैं। यह विशेष रूप से उपयोगी है अगर तार बड़ी संरचनाओं के सदस्य हैं। इस तरह की वस्तुओं को स्वतंत्र रूप से गतिशील स्मृति को इंगित करने के बारे में चिंता किए बिना स्मृति में स्थानांतरित किया जा सकता है।

जैसा कि आप उम्मीद करेंगे, बड़े बफ़र्स शायद ही कभी पूरी तरह से उपयोग किए जाते हैं, और शेष भंडारण स्थान अक्सर फ्लश नहीं होता है। यह कर्नेल मेमोरी के लंबे सन्निहित क्षेत्रों के विशेष रूप से गंभीर लीक को जन्म दे सकता है। लिस्टिंग 5 में उदाहरण में, सिस्टम कॉल स्थानीय बफर में सिस्टम पथ को लोड करने के लिए RtlGetSystemPath फ़ंक्शन का उपयोग करता है, और यदि कॉल सफल होता है, तो सभी 260 बाइट्स वास्तविक लाइन की लंबाई की परवाह किए बिना, कॉलर को पास किए जाते हैं।

 NTSTATUS NTAPI NtGetSystemPath(PCHAR OutputPath) { CHAR SystemPath[MAX_PATH]; NTSTATUS Status; Status = RtlGetSystemPath(SystemPath, sizeof(SystemPath)); if (NT_SUCCESS(Status)) { RtlCopyMemory(OutputPath, SystemPath, sizeof(SystemPath)); } return Status; } 

लिस्टिंग 5: स्ट्रिंग बफर को आंशिक रूप से प्रारंभिक करके मेमोरी का विस्तार करना।

इस उदाहरण में उपयोगकर्ता क्षेत्र में वापस स्मृति क्षेत्र को चित्र 4 में दिखाया गया है।

चित्रा 4: एक आंशिक रूप से प्रारंभिक लाइन बफर की मेमोरी।

एक सुरक्षित कार्यान्वयन केवल अनुरोधित पथ को वापस करना चाहिए, न कि भंडारण के लिए उपयोग किए जाने वाले संपूर्ण बफर। यह उदाहरण एक बार फिर से प्रदर्शित करता है कि कैसे आकार आकार ऑपरेटर के साथ डेटा आकार का आकलन (RtlCopyMemory के लिए एक पैरामीटर के रूप में उपयोग किया जाता है) डेटा की वास्तविक मात्रा के संबंध में पूरी तरह से गलत हो सकता है जिसे कर्नेल को उपयोगकर्ता क्षेत्र में पास करना होगा।

मनमाना सिस्टम कॉल आउटपुट का आकार

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

 NTSTATUS NTAPI NtMagicValues(LPDWORD OutputPointer, DWORD OutputLength) { if (OutputLength < 3 * sizeof(DWORD)) { return STATUS_BUFFER_TOO_SMALL; } LPDWORD KernelBuffer = Allocate(OutputLength); KernelBuffer[0] = 0xdeadbeef; KernelBuffer[1] = 0xbadc0ffe; KernelBuffer[2] = 0xcafed00d; RtlCopyMemory(OutputPointer, KernelBuffer, OutputLength); Free(KernelBuffer); return STATUS_SUCCESS; } 

लिस्टिंग 6: मनमाने आकार के आउटपुट बफर के माध्यम से मेमोरी का विस्तार करना।

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

चित्र 5: मनमाने आकार की बफर मेमोरी।

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

• , Windows, . , .
• . , , . , ( — ) .

, . , , .

,

, . , Windows .

, , . , : AddressSanitizer , PageHeap Special Pool . , , - . , . , , , , , . , ( ).

, , , . , .

, API
API, Windows (Win32/User32 API). API , , , . , , , , . .

, . , . , , , . , , .

, , . , KASLR (Kernel Address Space Layout Randomization ), . : Windows, Hacking Team 2015 ( Juan Vazquez. Revisiting an Info Leak ) (derandomize) win32k.sys, . , Matt Tait' Google Project Zero ( Kernel-mode ASLR leak via uninitialized memory returned to usermode by NtGdiGetTextMetrics ) MS15-080 (CVE-2015-2433).

(/) , , (control flow), : , , , , StackGuard Linux /GS Windows . , . , , .

(/)
(/) , , , : , , , . , , . . , ( , ) , , .

Microsoft Windows

2015 Windows. 2015 Matt Tait win32k!NtGdiGetTextMetrics. Windows Hacking Team. , , , 0-day Windows.

2015, WanderingGlitch (HP Zero Day Initiative) ( Acknowledgments – 2015 ). Ruxcon 2016 ( ) "Leaking Windows Kernel Pointers" .

, 2017 fanxiaocao pjf IceSword Lab (Qihoo 360) "Automatically Discovering Windows Kernel Information Leak Vulnerabilities" , , 14 2017 (8 ). Bochspwn Reloaded, , . VMware (Bochs) . , Bochspwn Reloaded, .

, , 2010-2011 , win32k: "Challenge: On 32bit Windows7, explain where the upper 16bits of eax come from after a call to NtUserRegisterClassExWOW()" "Subtle information disclosure in WIN32K.SYS syscall return values" . Windows 8, 2015 Matt Tait , : Google Project Zero Bug Tracker .

( ), , 2017 - Windows -, : Joseph Bialek — "Anyone notice my change to the Windows IO Manager to generically kill a class of info disclosure? BufferedIO output buffer is always zero'd" . , IOCTL- .

, Visual Studio 15.5 POD- , "= {0}", . , padding- () .

Linux

Windows, Linux , 2010 . , ( ) ( ) . , Windows Linux , — , .

, Linux . "Linux kernel vulnerabilities: State-of-the-art defenses and open problems" 2010 2011 28 . 2017- "Securing software systems by preventing information leaks" Lu K. 59 , 2013- 2016-. . : Rosenberg Oberheide 25 , Linux 2009-2010 , . Linux c grsecurity / PaX-hardened . Vasiliy Kulikov 25 2010-2011 , Coccinelle . , Mathias Krause 21 2013 50 .

, , Linux. — -Wuninitialized ( gcc, LLVM), . kmemcheck , Valgrind' . , . , KernelAddressSANitizer KernelMemorySANitizer . KMSAN syzkaller ( ) 19 , .

Linux. 2014 — 2016 Peir´o Coccinelle , Linux 3.12: "Detecting stack based kernel information leaks" International Joint Conference SOCO14-CISIS14-ICEUTE14, pages 321–331 (Springer, 2014) "An analysis on the impact and detection of kernel stack infoleaks" Logic Journal of the IGPL. , . 2016- Lu UniSan — , , : , . , 20% (350 1800), 19 Linux Android.

— (multi-variant program execution), , . , . , KASLR, -, . , 2006 DieHard: probabilistic memory safety for unsafe languages, 2017 — BUDDY: Securing software systems by preventing information leaks. John North "Identifying Memory Address Disclosures" 2015- . , SafeInit (Comprehensive and Practical Mitigation of Uninitialized Read Vulnerabilities) , , . , , , Linux.

, . , : , . , , - , . .

CONFIG_PAGE_POISONING CONFIG_DEBUG_SLAB, -. -, . , , , Linux.

grsecurity / PaX . , PAX_MEMORY_SANITIZE , slab , ( — ). , PAX_MEMORY_STRUCTLEAK , ( ), . padding- (), 100% . , — PAX_MEMORY_STACKLEAK, . , , . (Kernel Self Protection Project) STACKLEAK .

Linux:

, , ( ) . Linux .

, .

, , .

SafeInit , , , , .

, Linux .

( )

, , ( ). : (), , , , ( - ) . , . , , .

, :

• Bochspwn Reloaded – detection with software x86 emulation
• Windows bug reproduction techniques
• Alternative detection methods
• Other data sinks
• Future work
• Other system instrumentation schemes

, :) , .