Windows Kernel 64-bit stack memory disclosure in win32k!XDCOBJ::RestoreAttributes(CVE-2018-0811)

We have discovered that the win32k!XDCOBJ::RestoreAttributes function leaks portions of uninitialized kernel stack memory to user-mode address space on Windows 7 to 10. It was confirmed on 64-bit platforms, 32-bit builds were not tested.

The overall copied memory area is 0x1a0 bytes long, 4 of which were uninitialized in our case. The layout of the area is as follows:

  00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000110: 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................
  00000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  00000190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values. As can be seen, there are 4 uninitialized bytes at offsets 0x118-0x11b. The values of those bytes originate from the local stack frame of the win32k!XDCOBJ::bModifyWorldTransform function.

More specifically, we have determined that the 4 bytes correspond to the 7-th field of an internal MATRIX structure (layout unknown), declared locally in win32k!XDCOBJ::bModifyWorldTransform. Initialization of the structure is achieved with a win32k!vConvertXformToMatrix call. While the first 6 fields of MATRIX are unconditionally written to in win32k!vConvertXformToMatrix, the 7-th and 8-th fields (offsets 0x18 and 0x1c) may or may not be set, depending on whether the win32k!bFToL succeeds to convert a given floating point number to a LONG. If it fails, one or both of these fields remain uninitialized, and are later copied in that form first to the larger structure of 0x1a0 bytes (at offset 0x100), and then to user-mode memory in win32k!XDCOBJ::RestoreAttributes.

The copying of the disclosed data from kernel to user-mode memory was detected under the following stack trace:

  kd> k
   # Child-SP          RetAddr           Call Site
  00 fffff880`04208b88 fffff960`00109033 win32k!memcpy+0x3
  01 fffff880`04208b90 fffff960`0022e70f win32k!XDCOBJ::RestoreAttributes+0x3b
  02 fffff880`04208bc0 fffff800`0268d093 win32k!NtGdiModifyWorldTransform+0x73
  03 fffff880`04208c20 00000000`74ba2e09 nt!KiSystemServiceCopyEnd+0x13

A proof-of-concept program is not provided for this issue, but it has been observed and confirmed at normal system runtime, and is quite evident in the code.

Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.