Windows 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