Advertisement






Microsoft Windows Kernel win32k!UMPDOBJ::LockSurface Memory Disclosure

CVE Category Price Severity
CVE-2018-0813 CWE-119 Not disclosed High
Author Risk Exploitation Type Date
N/A Critical Local 2018-03-21
CPE
cpe:cpe:/o:microsoft:windows
CVSS EPSS EPSSP
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N 0.02192 0.50148

CVSS vector description

Our sensors found this exploit at: https://cxsecurity.com/ascii/WLB-2018030171

Below is a copy:

Microsoft Windows Kernel win32k!UMPDOBJ::LockSurface Memory Disclosure
Windows 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

Copyright ©2024 Exploitalert.

All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use.