The Microsoft Windows kernel suffers from a 64-bit pool memory disclosure vulnerability in win32k!UMPDOBJ::LockSurface.
f4417022fdcd2d49b4249a164f5dd3faWindows Kernel 64-bit pool memory disclosure in win32k!UMPDOBJ::LockSurface
CVE-2018-0813
We have discovered that the win32k!UMPDOBJ::LockSurface function discloses portions of uninitialized pool memory to user-mode clients. The bug was encountered on Windows 7 64-bit; other versions were not tested.
The leak was detected in the context of the splwow64.exe process, under the following stack trace:
--- cut ---
kd> k
# Child-SP RetAddr Call Site
00 fffff880`03e5cb58 fffff960`002da736 win32k!memcpy+0x3
01 fffff880`03e5cb60 fffff960`0026272e win32k!UMPDOBJ::LockSurface+0xbe
02 fffff880`03e5cbf0 fffff800`0268d093 win32k!NtGdiEngLockSurface+0x42
03 fffff880`03e5cc20 000007fe`ff016d8a nt!KiSystemServiceCopyEnd+0x13
04 00000000`01c2f1f8 000007fe`f32a4d58 GDI32!ZwGdiEngLockSurface+0xa
05 00000000`01c2f200 000007fe`f32a42e3 mxdwdrv!edocs::PDev::CreateThumbnailBitmap+0x25c
06 00000000`01c2f680 000007fe`f32947af mxdwdrv!edocs::PDev::CreateBitmapsForThumbnail+0x2b
07 00000000`01c2f6d0 000007fe`ff020e9b mxdwdrv!DrvEnableSurface+0x13b
08 00000000`01c2f730 00000000`ffc6c329 GDI32!GdiPrinterThunk+0x11b
09 00000000`01c2f7f0 00000000`ffc6c608 splwow64!TLPCMgr::ProcessRequest+0xb1
0a 00000000`01c2f840 00000000`ffc6c916 splwow64!TLPCMgr::TLPCRequest::Run+0x50
0b 00000000`01c2f870 00000000`ffc65459 splwow64!TLPCMgr::TDispatcher::Run+0x4e
0c 00000000`01c2f8a0 00000000`772720b1 splwow64!NThreadingLibrary::TWorkCrew::tpSimpleCallback+0x21
0d 00000000`01c2f8d0 00000000`7727f8e0 ntdll!TppSimplepExecuteCallback+0x91
0e 00000000`01c2f920 00000000`771559cd ntdll!TppWorkerThread+0x893
0f 00000000`01c2fbb0 00000000`7728a561 kernel32!BaseThreadInitThunk+0xd
10 00000000`01c2fbe0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d
--- cut ---
The layout of the memory area copied to user-mode 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 ff ff ff ff ................
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 ................
--- cut ---
Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values. We have a strong suspicion that the region corresponds to a SURFOBJ structure, and the 4 uninitialized bytes at offsets 0x2c-0x2f are a compiler-introduced padding between the cjBits and pvBits fields, to align the pvBits field to a 8-byte boundary. This would also explain why the bug only manifests itself on 64-bit builds of Windows.
--- cut ---
typedef struct _SURFOBJ {
DHSURF dhsurf;
HSURF hsurf;
DHPDEV dhpdev;
HDEV hdev;
SIZEL sizlBitmap;
ULONG cjBits;
PVOID pvBits;
PVOID pvScan0;
LONG lDelta;
ULONG iUniq;
ULONG iBitmapFormat;
USHORT iType;
USHORT fjBitmap;
} SURFOBJ;
--- cut ---
The disclosed bytes originate from a pool allocation made in win32k!AllocateObject, and specifically from a surface object descriptor. The buffer is copied to a user-mode mapping created with the win32k!EngAllocUserMemEx function, whose address is then returned by the win32k!NtGdiEngLockSurface system call.
As the splwow64.exe process runs with the privileges of the local user, we believe no special rights in the system are required to access the disclosed kernel memory. A proof-of-concept program is not provided for this issue, but it has been observed at normal system runtime.
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