The Microsoft Windows kernel suffers from a 64-bit pool memory disclosure vulnerability in the win32kbase!CoreMessagingK interface.
b4af3ca3b1834c222727f776e825c122Windows Kernel 64-bit pool memory disclosure in the win32kbase!CoreMessagingK interface
CVE-2018-0926
We have discovered that the the win32kbase.sys driver sends an ALPC message with portions of uninitialized memory from the paged pool on Windows 10 64-bit (1709). We observed this behavior very early in the system boot process.
The message is 0xd0 (208) bytes long, 4 of which are uninitialized. The layout of the memory 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 ff ff ff ff 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 ................
--- cut ---
Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values. This buffer can be then read back into user-mode with e.g. the nt!NtAlpcSendWaitReceivePort syscall, as observed during system runtime on our test machine:
--- cut ---
kd> k
# Child-SP RetAddr Call Site
00 ffffea89`95743a28 fffff801`5f6ef358 nt!memcpy+0x3
01 ffffea89`95743a30 fffff801`5f6eedb9 nt!AlpcpReceiveMessage+0x408
02 ffffea89`95743b10 fffff801`5f388553 nt!NtAlpcSendWaitReceivePort+0xf9
03 ffffea89`95743bd0 00007ffd`8f8d0f54 nt!KiSystemServiceCopyEnd+0x13
04 00000050`5e67f428 00007ffd`898fda8f ntdll!NtAlpcSendWaitReceivePort+0x14
05 00000050`5e67f430 00007ffd`89902fd7 coremessaging!AlpcConnection::Callback_ProcessIncoming+0x9f
06 00000050`5e67f4f0 00007ffd`898cf606 coremessaging!Microsoft::CoreUI::Registrar::AlpcServerAdapter$R::Delegate0+0x47
07 00000050`5e67f540 00007ffd`898d8f53 coremessaging!Microsoft::CoreUI::Dispatch::WaitController$R::Delegate1+0x86
08 00000050`5e67f590 00007ffd`898d8b47 coremessaging!Microsoft::CoreUI::Dispatch::WaitController::Callback_DoGeneralWait+0x283
09 00000050`5e67f6d0 00007ffd`898d5916 coremessaging!Microsoft::CoreUI::Dispatch::WaitController::Callback_OnDispatch+0x457
0a 00000050`5e67f790 00007ffd`898d5fc9 coremessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop+0x5c6
0b 00000050`5e67f830 00007ffd`8990c613 coremessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_Run+0x9d
0c 00000050`5e67f8a0 00007ffd`8990c522 coremessaging!Microsoft::CoreUI::Registrar::CuiRegistrar::Run+0xdb
0d 00000050`5e67f8f0 00007ffd`8990c46f coremessaging!CoreUIRunRegistrarServer+0xa6
0e 00000050`5e67f9b0 00007ffd`8ed51fe4 coremessaging!CoreUIRegistrarService::RegistrarServerThread+0x3f
0f 00000050`5e67f9e0 00007ffd`8f89ef91 KERNEL32!BaseThreadInitThunk+0x14
10 00000050`5e67fa10 00000000`00000000 ntdll!RtlUserThreadStart+0x21
--- cut ---
The actual data (the ALPC message) that was copied to user-mode in our test environment is as follows:
--- cut ---
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000010: 02 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 ................
00000020: a8 00 00 00 aa aa aa aa a8 00 00 00 01 00 0d 00 ................
00000030: 10 00 00 00 be f5 29 eb 8a e5 e7 11 b5 17 99 31 ......)........1
00000040: df 4f ac 05 88 00 00 00 5c 00 42 00 61 00 73 00 .O......\.B.a.s.
00000050: 65 00 4e 00 61 00 6d 00 65 00 64 00 4f 00 62 00 e.N.a.m.e.d.O.b.
00000060: 6a 00 65 00 63 00 74 00 73 00 5c 00 5b 00 43 00 j.e.c.t.s.\.[.C.
00000070: 6f 00 72 00 65 00 4d 00 73 00 67 00 4b 00 5d 00 o.r.e.M.s.g.K.].
00000080: 2d 00 7b 00 65 00 62 00 32 00 39 00 66 00 35 00 -.{.e.b.2.9.f.5.
00000090: 62 00 65 00 2d 00 65 00 35 00 38 00 61 00 2d 00 b.e.-.e.5.8.a.-.
000000a0: 31 00 31 00 65 00 37 00 2d 00 62 00 35 00 31 00 1.1.e.7.-.b.5.1.
000000b0: 37 00 2d 00 39 00 39 00 33 00 31 00 64 00 66 00 7.-.9.9.3.1.d.f.
000000c0: 34 00 66 00 61 00 63 00 30 00 35 00 7d 00 00 00 4.f.a.c.0.5.}...
--- cut ---
The pool allocation from which the 4 uninitialized bytes at offsets 0x24-0x27 originate was requested in win32kbase!CoreMessagingK::Runtime::AllocUninitialized. Based on the contents of the ALPC message data, we suspect that the caller of the allocator a few stack frames higher was win32kbase!CoreMessagingK::SendHost::AllocateBuffer. Unfortunately, we are unable to establish any further details regarding the system state and broader context around the leak.
It is not clear if any special privileges need to be held to access the disclosed data. In our case, the process reading from the ALPC port was svchost.exe, but we suspect that more restricted processes could access the affected functionality, too. We are leaving it up to the vendor to determine if the leak can be triggered within the context of a regular system user.
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