यह CVE-2024-38063 के लिए एक (थोड़ा अस्थिर) पीओसी है, जो tcpip.sys में एक RCE है जिसे 13 अगस्त 2024 को पैच किया गया था। मुझे यह भेद्यता नहीं मिली और न ही रिपोर्ट की, वह श्रेय Wei को जाता है।

आवश्यकताएँ

pip3 install scapy

उपयोग

स्क्रिप्ट में फ़ील्ड्स को संशोधित करें:

• iface <- यदि आपके पास एकाधिक एडेप्टर हैं, तो आपको चुनना होगा कि पैकेट भेजने के लिए किसका उपयोग करना है। उदाहरण के लिए लिनक्स पर "eth0" या विंडोज़ पर "Hyper-V Virtual Ethernet Adapter"। यदि आप अपने डिफ़ॉल्ट इंटरफ़ेस का उपयोग करने जा रहे हैं, तो इसे खाली छोड़ दें।
• ip_addr <- लक्ष्य प्रणाली का IP पता (IPv6)
• num_tries & num_batches <- भेजने के लिए कितने अलग-अलग पैकेट बैच। उनमें से अधिक = अधिक हीप भ्रष्टाचार का कारण + भेद्यता को ट्रिगर करने की अधिक संभावना।
• mac_addr <- खाली छोड़ें, जब तक कि scapy शिकायत न करे कि उसे मैक पता नहीं मिल रहा है। समस्या निवारण में नीचे देखें।

स्क्रिप्ट चलाएँ:

python3 cve-2024-38063.py

भेद्यता को पुनः उत्पन्न करने का सबसे आसान तरीका लक्ष्य प्रणाली पर bcdedit /set debug on का उपयोग करना और मशीन/VM को पुनरारंभ करना है। यह डिफ़ॉल्ट नेटवर्क एडेप्टर ड्राइवर kdnic.sys बनाता है, जो पैकेट को सम्मिलित करने के लिए बहुत उत्सुक है। यदि आप किसी भिन्न सेटअप पर भेद्यता को पुनः उत्पन्न करने का प्रयास कर रहे हैं, तो आपको सिस्टम को ऐसी स्थिति में लाना होगा जहां वह आपके द्वारा भेजे गए पैकेट को सम्मिलित करेगा। अधिक विवरण के लिए आप नीचे समस्या निवारण अनुभाग पढ़ सकते हैं।

डेमो

cve-2024-38063.webm

मोटा आरसीए

यदि आप तकनीकी विवरणों में रुचि रखते हैं, तो आप Marcus द्वारा भेद्यता का यह शानदार विश्लेषण पढ़ सकते हैं। नीचे मैंने जो विवरण लिखे हैं, वे गंभीर तकनीकी विश्लेषण के बजाय सारांश के रूप में काम करने के लिए हैं।

• कुछ स्थितियों में, विंडोज़ एक साथ कई IP पैकेटों को सम्मिलित करेगा और उन्हें बैच प्रोसेस करेगा। यह पहले प्रत्येक पैकेट में एक्सटेंशन हेडर को संसाधित करता है, और उसके बाद ही प्रत्येक पैकेट में डेटा को संसाधित करने के लिए आगे बढ़ता है।
• एक्सटेंशन हेडर प्रोसेसिंग के दौरान, इन सम्मिलित पैकेटों के पैकेट ऑब्जेक्ट एक लिंक्ड लिस्ट में एक साथ जुड़े होते हैं। प्रत्येक पैकेट ऑब्जेक्ट में एक NET_BUFFER ऑब्जेक्ट होता है जिसमें बफ़र्ड पैकेट डेटा होता है। ऑफ़सेट 0x30 पर हमारे पास एक current-offset फ़ील्ड भी है जो इंगित करता है कि पैकेट को कितना पार्स किया गया है। इस चरण में, ऑफ़सेट मान आम तौर पर 0x28 होगा, यह दर्शाता है कि IPv6 हेडर पार्स किया गया है लेकिन कुछ और नहीं।
• जब tcpip!Ipv6pReceiveDestinationOptions में "destination options" एक्सटेंशन हेडर को संसाधित किया जाता है, तो एक पार्सिंग त्रुटि के परिणामस्वरूप tcpip!IppSendErrorList को कॉल किया जाएगा। यह फ़ंक्शन लिंक्ड लिस्ट में प्रत्येक पैकेट ऑब्जेक्ट (वर्तमान से शुरू) पर tcpip!IppSendError को कॉल करता है।
• कुछ शर्तों के तहत (जैसे कि यदि पैकेट यूनिकास्ट है), tcpip!IppSendError के दुष्प्रभाव होते हैं। यह बफ़र्ड पैकेट डेटा को वापस शुरुआत में "वापस लाता है" और current-offset फ़ील्ड को शून्य पर रीसेट करता है।
• हालाँकि, घटनाओं की इस पूरी श्रृंखला में, केवल पहले पैकेट को त्रुटि के रूप में चिह्नित किया गया है (ऑफ़सेट 0x8C)। इसका मतलब है कि ड्राइवर लिंक्ड लिस्ट में अन्य पैकेटों के एक्सटेंशन हेडर को पार्स करना जारी रखेगा, भले ही उन्हें IppSendError में "वापस लाया" गया हो।
• जिन पैकेटों को वापस लाया गया है, उनका प्रसंस्करण तब अप्रत्याशित डेटा के साथ किया जाता है: बफ़र्ड पैकेट डेटा एक्सटेंशन हेडर के बजाय पैकेट की शुरुआत (अर्थात IPv6 हेडर) की ओर इशारा कर रहा है, और ऑफ़सेट फ़ील्ड मान 0x28 के बजाय शून्य है।

रणनीति

• भेद्यता का दुरुपयोग करने के लिए, हम Ipv6pReceiveFragment का उपयोग करते हैं। फ़ंक्शन खंड विस्तार हेडर को पार्स करता है और मानता है कि पैकेट में गैर-हेडर डेटा की लंबाई की गणना करते समय पैकेट का ऑफ़सेट फ़ील्ड कम से कम 0x28 होगा, जो वर्तमान ऑफ़सेट मान से 0x30 घटाकर किया जाता है। यह मान तब पुनः जोड़ने वाली वस्तु में संग्रहीत किया जाता है जिसका उद्देश्य खंडित पैकेट को फिर से जोड़ना है।
• हमारे मामले में, फ़ंक्शन को एक पैकेट पर कॉल किया जाएगा जिसे IppSendError द्वारा वापस लाया गया है। ऑफ़सेट मान शून्य होगा और Ipv6pReceiveFragment में पहले कहीं 8 तक बढ़ा दिया जाएगा। गैर-हेडर डेटा के आकार की गणना करते समय, मान अंडरफ़्लो होगा और 0xffd8 के बराबर होगा (घटाव 16 बिट में किया जाता है)।
• लंबाई मान का उपयोग बाद में केवल दो स्थानों पर किया जाता है:
  • Ipv6pReassembleDatagram, जहां इसका उपयोग पुनः जुड़े पैकेट के आउटपुट बफर की लंबाई की गणना करने के लिए किया जाता है। हालाँकि, सभी गणनाएँ 32-बिट में की जाती हैं और एक सैनिटी चेक होता है कि कुल लंबाई 0xFFFF से अधिक नहीं है, जो इस मामले में होता है।
  • Ipv6pReassemblyTimeout, जहां इसी तरह से इसका उपयोग किया जाता है। हालाँकि, यहाँ गणना 16 बिट में की जाती है और एक पूर्णांक ओवरफ़्लो होता है। इससे बाद में बफर में डेटा कॉपी करते समय बफर ओवरफ़्लो होता है।

Ipv6pReassemblyTimeout को ट्रिगर करने के लिए, खंड के भेजने वाले को 1 मिनट तक निष्क्रिय रहना होगा। तब हमारी रणनीति है:

• IppSendError को ट्रिगर करने के लिए दूषित गंतव्य विकल्प भेजें, उसके बाद एक खंड पैकेट भेजें
• उम्मीद करें कि दोनों पैकेट सम्मिलित हो जाएं और दूसरे पैकेट के ऑब्जेक्ट का डेटा और ऑफ़सेट रीसेट हो जाए
• Ipv6pReceiveFragment में अंडरफ़्लो का कारण बनें और उच्च 16-बिट मान के साथ एक नया पुनः जोड़ने वाला ऑब्जेक्ट बनाएं जिसमें खंड डेटा लंबाई हो
• 1 मिनट तक प्रतीक्षा करें बिना कोई और पैकेट भेजे ताकि Ipv6pReassemblyTimeout ट्रिगर हो।
• Ipv6pReassemblyTimeout में बफर आकार गणना में पूर्णांक ओवरफ़्लो का कारण बनें और हीप-आधारित बफर ओवरफ़्लो ट्रिगर करें।

स्क्रिप्ट में पैकेटों को स्पैम किया जाता है ताकि उनके सम्मिलित होने की अधिक संभावना हो। मुख्य पेलोड काफी सरल है:

• एक "destination options" एक्सटेंशन हेडर वाला IPv6 पैकेट जिसमें दूषित विकल्प डेटा हो जो पार्सिंग में त्रुटि उत्पन्न करेगा
• IPv6 खंड #1, जिसे हम उम्मीद करते हैं कि पहले पैकेट से जुड़ जाएगा
• IPv6 खंड #2 (समान आईडी), जो पहले दो से भी जुड़ सकता है, लेकिन इसका मुख्य उद्देश्य दूसरे खंड को पूरा करना है ताकि सामान्य प्रसंस्करण के मामले में त्रुटियाँ न निकलें

हम IPv6 हेडर में hop limit और flow label फ़ील्ड को मैन्युअल रूप से भी सेट करते हैं। याद रखें कि बफ़र्ड पैकेट डेटा भेद्यता के कारण रीसेट हो जाता है। इसका मतलब है कि, खंड पैकेट को संसाधित करते समय, IPv6 हेडर को खंड हेडर डेटा के रूप में व्याख्यायित किया जाएगा। IPv6 हेडर में hop limit फ़ील्ड को खंड हेडर में id फ़ील्ड के एक बिट के रूप में व्याख्यायित किया जाएगा। इसे बदलकर, हम सुनिश्चित करते हैं कि हम कई अलग-अलग खंडों के लिए भेद्यता को ट्रिगर करते हैं और कई अलग-अलग भ्रष्टाचार का कारण बनते हैं, जिससे क्रैश की संभावना बढ़ जाती है (आखिरकार यह एक PoC ही है)। ip हेडर का flow limit फ़ील्ड खंड हेडर के ऑफ़सेट और "more indicator" फ़ील्ड के रूप में व्याख्यायित किया जाएगा। इसे 1 पर सेट करके, हम संकेत देते हैं कि आने वाले और हेडर हैं (इसलिए बाद में Ipv6pReassemblyTimeout को ट्रिगर करने में सक्षम) और ऑफ़सेट शून्य है (क्योंकि यह ऐसी id वाला पहला पैकेट है जो आ रहा है)।