Lycosa.sys, Razer: दो कर्नेल भेद्यताएँ जो किसी भी स्थानीय उपयोगकर्ता द्वारा पहुँची जा सकती हैं

https://github.com/416rehman/DeepZero के माध्यम से खोजा गया

विक्रेता: Razer Inc. घटक: Lycosa.sys, Razer Lycosa कीबोर्ड फ़िल्टर ड्राइवर, x64 SHA-256: a120a6184ab16864e8a5f1dfd0cd178fca541de463b5cef946e18c34b9b6f716 रिपोर्टर संदर्भ: a120a6184ab16864 स्थिति: अभी तक विक्रेता को रिपोर्ट नहीं किया गया।

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

CVE	दोष	प्रकार	परिणाम
CVE-01	आउटपुट लंबाई की बफ़र के विरुद्ध जाँच नहीं की जाती, इसलिए ड्राइवर कर्नेल स्टैक मेमोरी लौटाता है	CWE-125 आउट-ऑफ़-बाउंड्स रीड	कर्नेल मेमोरी प्रकटीकरण, एड्रेस स्पेस लेआउट रैंडमाइज़ेशन को विफल करता है
CVE-02	इनपुट लंबाई की बफ़र के विरुद्ध जाँच नहीं की जाती, इसलिए ड्राइवर अपना ही रिटर्न एड्रेस अधिलेखित कर देता है	CWE-121 स्टैक बफ़र ओवरफ़्लो	मनमाना कर्नेल कोड निष्पादन

दोनों किसी भी ऐसे खाते से पहुँची जा सकती हैं जो लॉग इन कर सकता है और कोई प्रोग्राम चला सकता है। कोई प्रशासनिक अधिकार नहीं, कोई एलिवेशन नहीं, कोई विशेष विशेषाधिकार नहीं। दोनों की पुष्टि Windows 11 25H2 (बिल्ड 26200.8875) पर कोड इंटीग्रिटी लागू और टेस्ट साइनिंग बंद रखते हुए की गई।

अनुभाग 3 बताता है कि दोनों को एक साथ उपयोग करने पर क्या परिणाम मिलता है, यही कारण है कि इन्हें एक ही समय पर रिपोर्ट किया गया है और श्रृंखलाबद्ध प्रूफ़ ऑफ़ कॉन्सेप्ट इस मूल निर्देशिका में रखा गया है।

---

1. दोष कहाँ हैं

दोनों RVA 0x1270 पर IRP_MJ_DEVICE_CONTROL हैंडलर में मौजूद हैं, और दोनों कर्नेल स्टैक पर उसी 0x400-बाइट बफ़र पर कार्य करते हैं। शिप किए गए बाइनरी से पढ़ा गया प्रोलॉग दोनों के लिए ज्यामिति तय करता है:

Lycosa+0x1270  48 89 54 24 10           mov   [rsp+10h], rdx   ; Irp
Lycosa+0x1275  48 89 4c 24 08           mov   [rsp+8], rcx     ; DeviceObject
Lycosa+0x127a  48 81 ec 98 04 00 00     sub   rsp, 498h        ; the frame
Lycosa+0x1291  ba 00 04 00 00           mov   edx, 400h        ; the buffer size
Lycosa+0x1296  48 8d 8c 24 80 00 00 00  lea   rcx, [rsp+80h]   ; the buffer

rsp+0x80 पर 0x400-बाइट का बफ़र, 0x498-बाइट फ़्रेम के अंदर, बिना कोई नॉन-वोलेटाइल रजिस्टर सहेजे। बफ़र के आरंभ से गिनती करते हुए:

0x000 .. 0x3FF   the buffer, which both defects are supposed to stay inside
0x418            the return address of the dispatch routine
0x420            the saved DeviceObject argument
0x428            the saved Irp argument

0x418 = 0x498 - 0x80 है। प्रकटीकरण (CVE-01) 0x3FF से आगे पढ़ता है और जो पाता है उसे लौटा देता है; ओवरफ़्लो (CVE-02) 0x3FF से आगे लिखता है और उसे बदल देता है।

2. पहुँच, और यह कौन कर सकता है

DriverEntry डिवाइस को बिना किसी सुरक्षा विवरणक के बनाता है और उसके लिए एक सिंबॉलिक लिंक प्रकाशित करता है, इसलिए यह \\.\Lycosa पर पहुँच योग्य है:

IoCreateDevice(param_1, 0x20, L"\\Device\\Lycosa", 0x22, 0, 0, &device);
IoCreateSymbolicLink(L"\\DosDevices\\Lycosa", L"\\Device\\Lycosa");

प्रभावित प्रत्येक कंट्रोल कोड FILE_DEVICE_UNKNOWN, METHOD_BUFFERED, FILE_ANY_ACCESS के रूप में डिकोड होता है। FILE_ANY_ACCESS का अर्थ है कि हैंडल पर कोई विशेष पहुँच अधिकार रखना आवश्यक नहीं है, इसलिए डिवाइस ऑब्जेक्ट का सुरक्षा विवरणक ही एकमात्र द्वार है, और यह सभी को पहुँच प्रदान करता है।

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

ड्राइवर उन मशीनों पर भी लोड होता है जिनमें कभी Razer हार्डवेयर नहीं लगा था, क्योंकि पैकेज वैध रूप से कैटलॉग-साइन किया गया है। यही पैटर्न ब्रिंग-योर-ओन-वल्नरेबल-ड्राइवर हमलों में उपयोग किया जाता है।

3. दोनों दोष मिलकर काम करते हैं

अलग-अलग रिपोर्ट किए गए क्योंकि ये अलग-अलग दोष हैं, लेकिन जो विक्रेता इनकी ट्राइएज कर रहा है उसे पता होना चाहिए कि प्रत्येक दूसरे को और बदतर बनाता है।

आधुनिक Windows कर्नेल को एक रैंडमाइज़्ड एड्रेस पर लोड करता है। जो हमलावर रिटर्न एड्रेस को अधिलेखित कर सकता है, उसे अभी भी यह जानना होता है कि उसे किससे अधिलेखित करना है, और सामान्यतः यही बाधा होती है। यह ड्राइवर दोनों प्रश्नों का उत्तर स्वयं दे देता है:

1. CVE-01 रैंडमाइज़ेशन को हटा देता है। प्रकटीकरण डिस्पैच रूटीन का अपना रिटर्न एड्रेस लौटाता है, जो ntoskrnl.exe के अंदर एक कोड एड्रेस है। इमेज के भीतर उसके ज्ञात ऑफ़सेट को घटाने पर वह बेस मिल जाता है जिस पर कर्नेल लोड है, और वहाँ से कर्नेल के अंदर प्रत्येक एड्रेस ज्ञात हो जाता है। इसकी कोई लागत नहीं है और यह कुछ भी बाधित नहीं करता।

2. CVE-01 वह मान भी प्रदान करता है जो CVE-02 को फ़ॉल्ट से बचने के लिए चाहिए। जैसा कि CVE-02 अनुभाग 4.4 में वर्णित है, ड्राइवर बाहर निकलते समय ऑफ़सेट 0x428 से Irp को पुनः लोड करता है और उसके माध्यम से लिखता है। एक अनाड़ी ओवरफ़्लो जो रिटर्न एड्रेस तक पहुँचता है, उस पॉइंटर को भी नष्ट कर देता है और रूटीन के लौटने से पहले फ़ॉल्ट कर देता है। इसके बजाय विश्वसनीय एक्सप्लॉइट कॉपी को ठीक 0x428 पर रोक देता है, जिससे वर्तमान अनुरोध का लाइव Irp अपनी जगह बना रहता है, और ड्राइवर सामान्य रूप से पूरा हो जाता है।

3. फिर CVE-02 निष्पादन को पुनर्निर्देशित करता है, कर्नेल बेस पहले से ज्ञात होने के साथ।

एक अपरिविलेज्ड खाते से, श्रृंखलाबद्ध प्रूफ़ ऑफ़ कॉन्सेप्ट फ़्रेम को पढ़ता है, कर्नेल बेस और बफ़र के स्वयं के कर्नेल एड्रेस की गणना करता है, और एक रिटर्न-ओरिएंटेड चेन भेजता है:

step 1, read what is above the buffer on the kernel stack:
   +0x418 return address  0xFFFFF807D565CABB
   +0x498 frame pointer   0xFFFFFD042D313750  (read twice, must match)

step 2, turn those into the two addresses the payload needs:
   kernel base     = 0xFFFFF807D565CABB - 0x25CABB = 0xFFFFF807D5400000
   buffer on stack = 0xFFFFFD042D313750 - 0x500    = 0xFFFFFD042D313250

step 4, overflow with a chain that:
   pivots the stack onto the buffer, calls nt!ZwCreateFile, and
   resumes nt!IopfCallDriver+0x5b

sending 0x428 bytes
call returned: accepted=true error=0

PROOF: C:\Windows\System32\dz_lycosa_kernel_exec.txt now exists.

यह पूरी श्रृंखला है, जिसे आरंभ से अंत तक सत्यापित किया गया। अपरिविलेज्ड खाते ने C:\Windows\System32 के अंतर्गत एक फ़ाइल बनाई, जिस निर्देशिका में उसे अन्यथा लेखन पहुँच से मना कर दिया जाता है, कर्नेल मोड में nt!ZwCreateFile निष्पादित करके। accepted=true का अर्थ है कि सिस्टम कॉल सामान्य रूप से लौटा: श्रृंखला उसी एड्रेस पर फिर से आरंभ होती है जिस पर ड्राइवर लौटने वाला था (nt!IopfCallDriver+0x5b, जो add rsp,0x38 ; ret है), इसलिए थ्रेड समाप्त हो जाता है और मशीन चलती रहती है। बनाई गई फ़ाइल की पुष्टि एक प्रशासक शेल से स्वतंत्र रूप से की गई। पूरा ट्रांसक्रिप्ट logs/exec_create_file.log में है, और विधि METHODOLOGY.md में है।

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

4. इन्हें ठीक करना

दोनों समाधान स्वतंत्र हैं और दोनों छोटे हैं, प्रत्येक रिपोर्ट में पूर्ण रूप से बताए गए हैं: