New issue
Advanced search Search tips

Issue 1192 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2017
Cc:



Sign in to add a comment

Windows Kernel stack memory disclosure in win32kfull!SfnINLPUAHDRAWMENUITEM

Project Member Reported by mjurczyk@google.com, Mar 17 2017

Issue description

We have discovered that it is possible to disclose portions of uninitialized kernel stack memory to user-mode applications in Windows 10 indirectly through the win32k!NtUserPaintMenuBar system call, or more specifically, through the user32!fnINLPUAHDRAWMENUITEM user-mode callback (#107 on Windows 10 1607 32-bit).

In our tests, the callback is invoked under the following stack trace:

--- cut ---
a75e6a8c 81b63813 nt!memcpy
a75e6aec 9b1bb7bc nt!KeUserModeCallback+0x163
a75e6c10 9b14ff79 win32kfull!SfnINLPUAHDRAWMENUITEM+0x178
a75e6c68 9b1501a3 win32kfull!xxxSendMessageToClient+0xa9
a75e6d20 9b15361c win32kfull!xxxSendTransformableMessageTimeout+0x133
a75e6d44 9b114420 win32kfull!xxxSendMessage+0x20
a75e6dec 9b113adc win32kfull!xxxSendMenuDrawItemMessage+0x102
a75e6e48 9b1138f4 win32kfull!xxxDrawMenuItem+0xee
a75e6ecc 9b110955 win32kfull!xxxMenuDraw+0x184
a75e6f08 9b11084e win32kfull!xxxPaintMenuBar+0xe1
a75e6f34 819a8987 win32kfull!NtUserPaintMenuBar+0x7e
a75e6f34 77d74d50 nt!KiSystemServicePostCall
00f3f08c 7489666a ntdll!KiFastSystemCallRet
00f3f090 733ea6a8 win32u!NtUserPaintMenuBar+0xa
00f3f194 733e7cef uxtheme!CThemeWnd::NcPaint+0x1fc
00f3f1b8 733ef3c0 uxtheme!OnDwpNcActivate+0x3f
00f3f22c 733ede88 uxtheme!_ThemeDefWindowProc+0x800
00f3f240 75d8c2aa uxtheme!ThemeDefWindowProcW+0x18
00f3f298 75d8be4a USER32!DefWindowProcW+0x14a
00f3f2b4 75db53cf USER32!DefWindowProcWorker+0x2a
00f3f2d8 75db8233 USER32!ButtonWndProcW+0x2f
00f3f304 75d8e638 USER32!_InternalCallWinProc+0x2b
00f3f3dc 75d8e3a5 USER32!UserCallWinProcCheckWow+0x218
00f3f438 75da5d6f USER32!DispatchClientMessage+0xb5
00f3f468 77d74c86 USER32!__fnDWORD+0x3f
00f3f498 74894c3a ntdll!KiUserCallbackDispatcher+0x36
00f3f49c 75d9c1a7 win32u!NtUserCreateWindowEx+0xa
00f3f774 75d9ba68 USER32!VerNtUserCreateWindowEx+0x231
00f3f84c 75d9b908 USER32!CreateWindowInternal+0x157
00f3f88c 000d15b7 USER32!CreateWindowExW+0x38
--- cut ---

The layout of the i/o structure passed down to the user-mode callback that we're seeing 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 ff ff ff ff ................
00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00000080: 00 00 00 00 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? ................
--- cut ---

Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values copied back to user-mode. As shown above, there are 20 bytes leaked at offsets 0x6c-0x7f. We have determined that these bytes originally come from a smaller structure of size 0x74, allocated in the stack frame of the win32kfull!xxxSendMenuDrawItemMessage function.

We can easily demonstrate the vulnerability with a kernel debugger (WinDbg), by setting a breakpoint at win32kfull!xxxSendMenuDrawItemMessage, filling the local structure with a marker 0x41 ('A') byte after stepping through the function prologue, and then observing that these bytes indeed survived any kind of initialization and are printed out by the attached proof-of-concept program:

--- cut ---
3: kd> ba e 1 win32kfull!xxxSendMenuDrawItemMessage
3: kd> g
Breakpoint 0 hit
win32kfull!xxxSendMenuDrawItemMessage:
9b11431e 8bff            mov     edi,edi
1: kd> p
win32kfull!xxxSendMenuDrawItemMessage+0x2:
9b114320 55              push    ebp
1: kd> p
win32kfull!xxxSendMenuDrawItemMessage+0x3:
9b114321 8bec            mov     ebp,esp
1: kd> p
win32kfull!xxxSendMenuDrawItemMessage+0x5:
9b114323 81ec8c000000    sub     esp,8Ch
1: kd> p
win32kfull!xxxSendMenuDrawItemMessage+0xb:
9b114329 a1e0dd389b      mov     eax,dword ptr [win32kfull!__security_cookie (9b38dde0)]
1: kd> p
win32kfull!xxxSendMenuDrawItemMessage+0x10:
9b11432e 33c5            xor     eax,ebp
1: kd> p
win32kfull!xxxSendMenuDrawItemMessage+0x12:
9b114330 8945fc          mov     dword ptr [ebp-4],eax
1: kd> p
win32kfull!xxxSendMenuDrawItemMessage+0x15:
9b114333 833d0ca6389b00  cmp     dword ptr [win32kfull!gihmodUserApiHook (9b38a60c)],0
1: kd> f ebp-78 ebp-78+74-1 41
Filled 0x74 bytes
1: kd> g
--- cut ---

Then, the relevant part of the PoC output should be similar to the following:

--- cut ---
00000000: 88 b2 12 01 92 00 00 00 00 00 00 00 01 00 00 00 ................
00000010: 00 00 00 00 39 05 00 00 01 00 00 00 00 01 00 00 ....9...........
00000020: 61 02 0a 00 1a 08 01 01 08 00 00 00 1f 00 00 00 a...............
00000030: 50 00 00 00 32 00 00 00 00 00 00 00 61 02 0a 00 P...2.......a...
00000040: 1a 08 01 01 00 0a 00 00 00 00 00 00 00 00 00 00 ................
00000050: 00 00 00 00 3a 00 00 00 0f 00 00 00 00 00 00 00 ....:...........
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 41 41 41 41 ............AAAA
00000070: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
00000080: a0 64 d8 77 60 66 d8 77 ?? ?? ?? ?? ?? ?? ?? ?? .d.w`f.w........
--- cut ---

The 20 aforementioned bytes are clearly leaked to ring-3 in an unmodified, uninitialized form. If we don't manually insert markers into the kernel stack, an example output of the PoC can be as follows:

--- cut ---
00000000: 88 b2 ab 01 92 00 00 00 00 00 00 00 01 00 00 00 ................
00000010: 00 00 00 00 39 05 00 00 01 00 00 00 00 01 00 00 ....9...........
00000020: db 01 1d 00 47 08 01 17 08 00 00 00 1f 00 00 00 ....G...........
00000030: 50 00 00 00 32 00 00 00 00 00 00 00 db 01 1d 00 P...2...........
00000040: 47 08 01 17 00 0a 00 00 00 00 00 00 00 00 00 00 G...............
00000050: 00 00 00 00 3a 00 00 00 0f 00 00 00 00 00 00 00 ....:...........
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 28 d3 ab 81 ............(...
00000070: 80 aa 20 9b 33 26 fb af fe ff ff ff 00 5e 18 94 .. .3&.......^..
00000080: a0 64 d8 77 60 66 d8 77 ?? ?? ?? ?? ?? ?? ?? ?? .d.w`f.w........
--- cut ---

Starting at offset 0x6C, we can observe leaked contents of a kernel _EH3_EXCEPTION_REGISTRATION structure:

.Next             = 0x81abd328
.ExceptionHandler = 0x9b20aa80
.ScopeTable       = 0xaffb2633
.TryLevel         = 0xfffffffe

This immediately discloses the address of the kernel-mode stack and the win32k image in memory -- information that is largely useful for local attackers seeking to defeat the kASLR exploit mitigation, or disclose other sensitive data 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.
 
xxxSendMenuDrawItemMessage.cpp
2.2 KB View Download
Project Member

Comment 1 by mjurczyk@google.com, Mar 20 2017

Labels: Reported-2017-Mar-20
Project Member

Comment 2 by mjurczyk@google.com, Mar 20 2017

Labels: MSRC-37863
Project Member

Comment 3 by mjurczyk@google.com, Mar 30 2017

Labels: -Vendor-mjurczyk Vendor-Microsoft
Project Member

Comment 4 by mjurczyk@google.com, Apr 5 2017

Labels: CVE-2017-0167
Project Member

Comment 5 by mjurczyk@google.com, Apr 12 2017

Labels: Fixed-2017-Apr-11
Status: Fixed (was: New)
Fixed in yesterday's Patch Tuesday.
Project Member

Comment 6 by mjurczyk@google.com, Apr 13 2017

Labels: -Restrict-View-Commit

Sign in to add a comment