exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Microsoft Windows Kernel win32k!XDCOBJ::RestoreAttributes Memory Disclosure

Microsoft Windows Kernel win32k!XDCOBJ::RestoreAttributes Memory Disclosure
Posted Mar 21, 2018
Authored by Google Security Research, mjurczyk

The Microsoft Windows kernel suffers from a 64-bit pool memory disclosure vulnerability in win32k!XDCOBJ::RestoreAttributes.

tags | advisory, kernel
systems | windows
advisories | CVE-2018-0811
SHA-256 | 743612dfc5adb2afb95d3bb3ee40d4802c64e811db5c9c184e8b15f712978ebf

Microsoft Windows Kernel win32k!XDCOBJ::RestoreAttributes Memory Disclosure

Change Mirror Download
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:

--- cut ---
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 ................
--- cut ---

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:

--- cut ---
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
--- cut ---

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.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public.



Found by: mjurczyk

Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close