
गिगाबाइट gdrv3.sys IOCTLs का शोषण करके अनचेक्ड फिजिकल मेमोरी रीड के माध्यम से उपयोगकर्ता प्रक्रिया में SYSTEM टोकन लिखने वाला प्रूफ-ऑफ-कॉन्सेप्ट लोकल प्रिविलेज एस्केलेशन।
नमस्ते हैकर्स।
gdrv3.sys वह हस्ताक्षरित कर्नेल ड्राइवर है जो Gigabyte App Center और EasyTune के साथ आता है। यह \.\GIOV3 बनाता है जिसमें कोई सुरक्षा विवरणक नहीं होता, इसलिए कोई भी स्थानीय उपयोगकर्ता इसे खोल सकता है — न एडमिन, न UAC। इसके दो IOCTL ही पूरी कहानी हैं।
पहला (0xC3502019) कहता है कि यह भौतिक मेमोरी पढ़ता है। आप इसे एक भौतिक पता, एक लंबाई और एक आउटपुट पॉइंटर देते हैं, और यह बाइट्स को वहाँ कॉपी कर देता है। आउटपुट पॉइंटर ही समस्या है: ड्राइवर कभी जाँचता नहीं कि यह उपयोगकर्ता स्थान में है। कोई ProbeForWrite नहीं, कोई सीमा जाँच नहीं, कुछ भी नहीं। तो एक "रीड" वास्तव में write-what-where है, आप बस चुनते हैं कि उत्तर कहाँ गिरेगा। भौतिक मेमोरी से SYSTEM प्रक्रिया टोकन पढ़ें, फिर आउटपुट को सीधे अपने ही EPROCESS टोकन फ़ील्ड पर इंगित करें। ड्राइवर आपके लिए आपकी प्रक्रिया में SYSTEM टोकन लिख देता है।
यही पूरा एक्सप्लॉइट है। कोई मेमोरी करप्शन नहीं, कर्नेल मोड में कोई शेलकोड नहीं। SMEP, SMAP, KVAS, CET और CFG कभी चित्र में नहीं आते क्योंकि CPL0 पर कुछ भी नहीं चलता जो नहीं चलना चाहिए। यह केवल डेटा है, और यह हर बार काम करता था। दूसरी IOCTL जोड़ी (0xC3502584 रीड, 0xC3502580 राइट) क्लासिक वाली है। मनमाना MSR, कोई इंडेक्स व्हाइटलिस्ट नहीं। IA32_LSTAR पढ़ना अकेले ही KASLR तोड़ देता है, और इसे लिखना सिसकॉल एंट्री को हाईजैक कर लेता है। इसे SMEP/SMAP काम की ज़रूरत है इसलिए मैंने इसे द्वितीयक पथ के रूप में रखा, लेकिन अकेले भी यह बुरा है।
एक सामान्य उपयोगकर्ता खाते से बिल्ड करें और चलाएँ:
gcc -O2 -o poc.exe poc.c -lpsapi
poc.exe
Windows 10 x64 22H2 (build 19045) पर परीक्षण किया गया। ड्राइवर Gigabyte App Center के साथ आता है, इसलिए बहुत सारे Gigabyte बोर्डों पर यह पहले से लोडेड होता है।
मैंने इसे जून 2026 में Gigabyte को रिपोर्ट किया और उन्होंने इसे ठीक कर दिया। नए बिल्ड डिवाइस पर एक SDDL लगाते हैं जो इसे एडमिन तक सीमित कर देता है, और MSR राइट पर एक व्हाइटलिस्ट जोड़ते हैं। वर्तमान gdrv3 अब इस तरह से एक्सप्लॉइट करने योग्य नहीं है।
