New issue
Advanced search Search tips
Starred by 2 users
Status: Fixed
Owner:
Closed: Sep 12
Cc:



Sign in to add a comment
Windows Kernel stack memory disclosure in win32k!NtQueryCompositionSurfaceBinding
Project Member Reported by mjurczyk@google.com, Jun 26 Back to list
We have discovered that the win32k!NtQueryCompositionSurfaceBinding system call discloses portions of uninitialized kernel stack memory to user-mode clients, as tested on Windows 10 32-bit.

The output buffer, and the corresponding temporary stack-based buffer in the kernel are 0x308 bytes in size. The first 4 and the trailing 0x300 bytes are zero'ed out at the beginning of the function:

--- cut ---
.text:0001939B                 mov     [ebp+var_324], ebx
.text:000193A1                 push    300h            ; size_t
.text:000193A6                 push    ebx             ; int
.text:000193A7                 lea     eax, [ebp+var_31C]
.text:000193AD                 push    eax             ; void *
.text:000193AE                 call    _memset
--- cut ---

However, the remaining 4 bytes at offset 0x4 are never touched, and so they contain whatever data was written there by the previous system call. These 4 bytes are then subsequently leaked to the user-mode caller. Exploitation of this bug is further facilitated by the fact that the contents of the buffer are copied back to user-mode even if the syscall fails (e.g. composition surface handle can't be resolved etc).

The attached proof-of-concept program demonstrates the disclosure by spraying the kernel stack with a large number of 0x41 ('A') marker bytes, and then calling the affected system call. An example output is as follows:

--- cut ---
00000000: 00 00 00 00 41 41 41 41 00 00 00 00 00 00 00 00 ....AAAA........
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 ................
[...]
000002b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000002c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000002d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000002e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000002f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000300: 00 00 00 00 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? ................
--- cut ---

It is clearly visible here that among all data copied from ring-0 to ring-3, 4 bytes at offset 0x4 remained uninitialized. 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.
 
NtQueryCompositionSurfaceBinding.cpp
2.0 KB View Download
Project Member Comment 1 by mjurczyk@google.com, Jun 28
Labels: Reported-2017-Jun-28
Project Member Comment 2 by mjurczyk@google.com, Jun 28
Labels: MSRC-39357
Project Member Comment 3 by mjurczyk@google.com, Aug 7
Labels: CVE-2017-8678
Project Member Comment 4 by mjurczyk@google.com, Sep 12
Labels: Fixed-2017-Sep-12
Status: Fixed
Fixed in today's Patch Tuesday.
Project Member Comment 5 by mjurczyk@google.com, Sep 18
Labels: -Restrict-view-commit
Sign in to add a comment