DxgkDdiEscape handler for 0x7000194 OOB Read/Write Vulnerability

vendor:

N/A

by:

Project Zero

7,8

CVSS

HIGH

Out-of-Bounds Read/Write

119

CWE

Product Name: N/A

Affected Version From: N/A

Affected Version To: N/A

Patch Exists: YES

Related CWE: N/A

CPE: N/A

Metasploit: N/A

Other Scripts: N/A

Tags: N/A

CVSS Metrics: N/A

Nuclei References: N/A

Nuclei Metadata: N/A

Platforms Tested: Windows 10 x64

2016

DxgkDdiEscape handler for 0x7000194 OOB Read/Write Vulnerability

The DxgkDdiEscape handler for 0x7000194 doesn't do bounds checking with the user provided lengths it receives. When these lengths are passed to memcpy, overreads and memory corruption can occur. The PoC provided causes an OOB read, but it should be possible to pass an input that results in the third memcpy being executed instead of the first two, which leads to kernel memory corruption (OOB write).

Mitigation:

Ensure that user-supplied lengths are properly validated before being used in memory operations.

Source

Exploit-DB raw data:

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=895

The DxgkDdiEscape handler for 0x7000194 doesn't do bounds checking with the
user provided lengths it receives. When these lengths are passed to memcpy,
overreads and memory corruption can occur.

void __fastcall escape_7000194(NvMiniportDeviceContext *ctx, Escape7000194 *escape_data)
  ...

  alloc_0_ = ExAllocatePoolWithTag_(PagedPool, escape->size_0, 0x7061564Eu);

  ...

  alloc_1 = ExAllocatePoolWithTag_(PagedPool, escape->size_1, 0x7061564Eu);

  ..

  if ( (_BYTE)v11 ) {
    memcpy(alloc_0, escape->buf_0, escape->size_0);
    memcpy(alloc_1, escape->buf_2, escape->size_1);
  }
  v8 = Escape7Handler(0i64, dword_7DCB84, *(_DWORD *)(v3 + 24), 0x402C0105, &escape->data, 96);
  v9 = v8;
  if ( !(_BYTE)v11 && !v8 )
    memcpy(escape->buf_0, alloc_0, escape->size_0);

  ...

The PoC I've provided causes an OOB read, but it should be possible to pass an
input that results in the third memcpy being executed instead of the first two,
which leads to kernel memory corruption (OOB write).

(Win 10 x64 372.54) crashing context with PoC:

PAGE_FAULT_IN_NONPAGED_AREA (5)
...
Some register values may be zeroed or incorrect.
rax=0000000000000007 rbx=0000000000000000 rcx=ffffc000f5220f80
rdx=fffffffff3d5509c rsi=0000000000000000 rdi=0000000000000000
rip=fffff8007d4dad66 rsp=ffffd00166b9d2a8 rbp=ffffc000e8f55038
 r8=0000000000020fc0  r9=000000000006603e r10=0000000000020000
r11=ffffc000f5200000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
nvlddmkm+0x5dad66:
fffff800`7d4dad66 f30f6f4c0ae0    movdqu  xmm1,xmmword ptr [rdx+rcx-20h] ds:ffffc000`e8f75ffc=????????????????????????????????
Resetting default scope

To reproduce, compile the PoC as a x64 binary (requires linking with
setupapi.lib, and WDK for D3DKMTEscape), and run. It may require some changes
as for it to work as the escape data must contain the right values (e.g. a
field that appears to be gpu bus device function). My PoC should hopefully set
all the right values for the machine it's running on.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40658.zip