扫码分享
验证：
体验盒子|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=927 The DxgkDdiEscape handler for escape code 0x100010b looks like: char escape_100010b(NvMiniportDeviceContext *miniport_context, HANDLE handle, unsigned int idx) { PVOID *Object; if ( !handle ) do_debug_thingo(); Object = (PVOID *)&miniport_context->UNKNOWN[8 * idx + 22696]; if ( !ObReferenceObjectByHandle(handle_, SYNCHRONIZE, )ExEventObjectType, UserMode, Object, 0i64) ) { result = 0; if ( *Object ) result = UserMode; } return result; } It essentially takes in a user mode event handle from userspace, and calls ObReferenceObjectByHandle on it, writing the object pointer to |Object|. Note that the kernel implementation of ObReferenceObjectByHandle always begins with writing NULL to this pointer regardless of whether or not the handle is valid. |Object| is calculated using a user provided index that is not bounds checked, leading to OOB write of either NULL or the KEVENT pointer: Object = (PVOID *)&miniport_context_->UNKNOWN[8 * idx + 22696]; The attached PoC causes the following crashing context on Win x64 372.54: PAGE_FAULT_IN_NONPAGED_AREA (50) ... rax=ffffe0025ea28f50 rbx=0000000000000000 rcx=0000000000000000 rdx=0000000000100000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff801d8f3daf5 rsp=ffffd000203deda0 rbp=0000000000000001 r8=ffffe000506d4b50r9=ffffe000524fb201 r10=0000000000000000 r11=ffffd000203df370 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl zr na po nc nt!ObReferenceObjectByHandleWithTag+0x45: fffff801<code>d8f3daf5 488908mov qword ptr [rax],rcx ds:ffffe002</code>5ea28f50=???????????????? To reproduce, compile as a x64 executable and run (requires WDK for D3DKMTEscape). Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40661.zip |
体验盒子
