VULHUB ™

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: ``` 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...

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: ``` 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 ``` The layout of the memory area copied to user-mode is as follows: ``` 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 ................ ``` 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. ``` 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; ``` 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.