kkent030315/pagetableinjectionकोड इंजेक्शन, पेजटेबल pml4 के माध्यम से दुर्भावनापूर्ण पेलोड इंजेक्ट करें।
कोड इंजेक्शन, पेजटेबल्स pml4 के माध्यम से दुर्भावनापूर्ण पेलोड इंजेक्ट करें।
यह केवल पेज टेबल इंजेक्शन तकनीक का एक सिद्धांत प्रमाण है जो मनमाने उपयोगकर्ता प्रक्रियाओं में दुर्भावनापूर्ण कोड इंजेक्ट करता है।
विंडोज़ (और कुछ आधुनिक ऑपरेटिंग सिस्टम) पर, प्रत्येक प्रक्रिया का अपना PML4 होता है जिसे Directory Table Base भी कहा जाता है। इस प्रकार प्रक्रिया A बिना APIs के प्रक्रिया B तक नहीं पहुँच सकती। लेकिन क्या होगा यदि हम एक मनमाना PML4 प्रविष्टि इंजेक्ट कर सकें? बेशक PML4 प्रविष्टि प्रविष्टियों के संबंधित भौतिक पते, PDP, PD और PT को बिल्कुल बैकिंग प्रक्रिया के समान इंगित करेगी।
लक्ष्य प्रक्रिया में दुर्भावनापूर्ण PML4 प्रविष्टि इंजेक्ट करने के लिए, हमें एक वास्तविक रेज़िडेंट पेज (भौतिक मेमोरी) की आवश्यकता है जो दुर्भावनापूर्ण PML4 प्रविष्टि का समर्थन करता है। इस प्रकार शाब्दिक रूप से, रेज़िडेंट पेज को रेज़िडेंट होना चाहिए, अन्यथा सिस्टम क्रैश हो जाएगा या अस्थिर हो जाएगा, क्योंकि MMU द्वारा भौतिक पते में अनुवाद के दौरान, वहाँ कुछ भी नहीं है जिसकी MMU अपेक्षा करता है, साथ ही विंडोज़ मेमोरी मैनेजर को भी कुछ अपेक्षित नहीं है।
आइए बैकिंग प्रक्रिया और लक्ष्य प्रक्रिया दोनों के बफ़र्स को देखें। इस मामले में, बफ़र्स हैं:
0x1A45F8100000x6EA45F810000अगले चरण पर जाने से पहले, आप में से कुछ सोच सकते हैं कि दूसरा पता (0x6EA45F810000) अजीब लगता है, जैसे आमतौर पर हम malloc या VirtualAlloc के माध्यम से बफ़र आवंटित करते हैं, वर्चुअल पता 0x17C7CAC0000 0x23BE9D80000 0x19FE76F0000 या ऐसा कुछ दिखना चाहिए। ऐसा इसलिए है क्योंकि दुर्भावनापूर्ण PML4 प्रविष्टि विंडोज़ के मेमोरी मैनेजर में शामिल नहीं है, और प्रबंधित भी नहीं है। बेशक विंडोज़ 64-बिट प्रक्रिया पर प्रत्येक वर्चुअल पता उपयोगकर्ता मेमोरी रेंज के भीतर कोई भी मान रख सकता है।
तो यदि हम दोनों पतों को देखें...
0: kd> .process ffff9803d8037080
Implicit process is now ffff9803`d8037080
0: kd> db 0x6EA45F810000 l2
00006ea4`5f810000 4d 5a MZ
0: kd> !vtop 7968b000 0x6EA45F810000
Amd64VtoP: Virt 00006ea45f810000, pagedir 000000007968b000
Amd64VtoP: PML4E 000000007968b6e8
Amd64VtoP: PDPE 000000005849b488
Amd64VtoP: PDE 0000000059e9c7e0
Amd64VtoP: PTE 000000003251d080
Amd64VtoP: Mapped phys 0000000014306000
Virtual address 6ea45f810000 translates to physical address 14306000.
0: kd> .process ffff9803d9f6b080
Implicit process is now ffff9803`d9f6b080
0: kd> db 0x1A45F810000 l2
000001a4`5f810000 4d 5a MZ
0: kd> !vtop 564f6000 0x1A45F810000
Amd64VtoP: Virt 000001a45f810000, pagedir 00000000564f6000
Amd64VtoP: PML4E 00000000564f6018
Amd64VtoP: PDPE 000000005849b488
Amd64VtoP: PDE 0000000059e9c7e0
Amd64VtoP: PTE 000000003251d080
Amd64VtoP: Mapped phys 0000000014306000
Virtual address 1a45f810000 translates to physical address 14306000.
दोनों पते बिल्कुल समान पेज टेबल प्रविष्टियों, PDP, PD, PT और एक भौतिक पते से संबंधित हैं। इसलिए यदि हम बैकिंग प्रक्रिया के बफ़र को संशोधित करते हैं, तो परिवर्तन लक्ष्य प्रक्रिया पर भी होगा। यह विंडोज़ पर साझा मेमोरी के समान है, लेकिन अंतर यह है कि लक्ष्य प्रक्रिया पर मेमोरी क्षेत्र कभी भी उसकी प्रक्रिया की किसी VAD प्रविष्टि में नहीं दिखाया जाएगा। लेकिन दूसरी ओर, यदि बैकिंग प्रक्रिया का बफ़र मुक्त किया जाता है, तो इसका अर्थ लक्ष्य प्रक्रिया पर भी होता है लेकिन लक्ष्य प्रक्रिया की पेज टेबल प्रविष्टियों की सफाई के बिना, जिसका अर्थ है कि मेमोरी मैनेजर एक bugcheck MEMORY_MANAGEMENT उत्पन्न करेगा, या CPU पर इससे भी बदतर ट्रिपल फॉल्ट ट्रिगर करेगा।
इस तकनीक में बड़ी स्थिरता समस्याएँ हैं, जैसा कि मैंने कहा कि इंजेक्ट की गई दुर्भावनापूर्ण PML4 प्रविष्टि विंडोज़ मेमोरी मैनेजर या कर्नेल में शामिल नहीं है। और इस बात की कोई गारंटी नहीं है कि बैकिंग प्रक्रिया तब तक जीवित रहेगी जब तक लक्ष्य प्रक्रिया समाप्त नहीं हो जाती, या जब बैकिंग प्रक्रिया समाप्त हो रही हो तो लक्ष्य प्रक्रिया को दुर्भावनापूर्ण PML4 प्रविष्टि की सफाई से कोई लेना-देना नहीं है।
MIT कॉपीराइट Kento Oki <[email protected]>
स्रोत कोड में बाहरी सामग्री हो सकती है, ऐसी सामग्री उसके कॉपीराइट धारक की है।