Windows Kernel Crash in win32k.sys Driver

vendor:

Windows

by:

Project Zero

7,2

CVSS

HIGH

Buffer Overflow

119

CWE

Product Name: Windows

Affected Version From: N/A

Affected Version To: N/A

Patch Exists: YES

Related CWE: N/A

CPE: N/A

Metasploit: N/A

Other Scripts: N/A

Tags: N/A

CVSS Metrics: N/A

Nuclei References: N/A

Nuclei Metadata: N/A

Platforms Tested: Windows

2014

Windows Kernel Crash in win32k.sys Driver

A number of Windows kernel crashes were encountered in the win32k.sys driver while processing corrupted TTF font files. The PAGE_FAULT_IN_NONPAGED_AREA (50) error was encountered, which is caused by an invalid system memory reference. This can be protected by a Probe.

Mitigation:

Proper validation of user-supplied input should be done to prevent buffer overflows.

Source

Exploit-DB raw data:

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1274

We have encountered a number of Windows kernel crashes in the win32k.sys driver while processing corrupted TTF font files:

---
  PAGE_FAULT_IN_NONPAGED_AREA (50)
  Invalid system memory was referenced.  This cannot be protected by try-except,
  it must be protected by a Probe.  Typically the address is just plain bad or it
  is pointing at freed memory.
  Arguments:
  Arg1: ff1effff, memory referenced.
  Arg2: 00000000, value 0 = read operation, 1 = write operation.
  Arg3: 91a65a52, If non-zero, the instruction address which referenced the bad memory
    address.
  Arg4: 00000000, (reserved)

  Debugging Details:
  ------------------

  FAULTING_IP: 
  win32k!fsc_CalcGrayRow+87
  91a65a52 660fbe4fff      movsx   cx,byte ptr [edi-1]

  MM_INTERNAL_CODE:  0

  DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

  BUGCHECK_STR:  0x50

  PROCESS_NAME:  csrss.exe

  CURRENT_IRQL:  0

  ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre

  LAST_CONTROL_TRANSFER:  from 91a65990 to 91a65a52

  STACK_TEXT:  
  981a885c 91a65990 ff1f83f8 ff1f8140 ff1f83a8 win32k!fsc_CalcGrayRow+0x87
  981a88a0 919e26ac 00000008 ff1f8010 fbb36e78 win32k!fsc_CalcGrayMap+0x105
  981a88e8 91b69e1a ff1f8010 ff1f807c 00000005 win32k!fs_ContourScan+0x582
  981a89f4 91b69ef2 00000000 00000005 981a8b08 win32k!lGGOBitmap+0x15f
  981a8a1c 919dd4f0 fbb36e78 00000005 981a8b08 win32k!ttfdGlyphBitmap+0x60
  981a8a40 919dd386 fc23ccf0 00000009 00000005 win32k!ttfdQueryFontData+0x115
  981a8a90 919dc5b2 00000000 fc23ccf0 00000009 win32k!ttfdSemQueryFontData+0x45
  981a8ad8 91b351b4 00000000 fc23ccf0 00000009 win32k!PDEVOBJ::QueryFontData+0x3e
  981a8b90 91b2cd60 fc23ccf0 fc23ccf0 00000006 win32k!GreGetGlyphOutlineInternal+0x534
  981a8c0c 8288587a 04010215 00000022 00000006 win32k!NtGdiGetGlyphOutline+0x95
  981a8c0c 76f370b4 04010215 00000022 00000006 nt!KiFastCallEntry+0x12a
  WARNING: Frame IP not in any known module. Following frames may be wrong.
  0020f504 00000000 00000000 00000000 00000000 0x76f370b4
---

The above crash dump comes from an old version of Windows 7 32-bit, because symbols for win32k.sys on the latest build are currently unavailable on the Microsoft Symbol Server. Nevertheless, a crash summary from an up-to-date system is as follows:

--- cut ---
  PAGE_FAULT_IN_NONPAGED_AREA (50)
  Invalid system memory was referenced.  This cannot be protected by try-except,
  it must be protected by a Probe.  Typically the address is just plain bad or it
  is pointing at freed memory.
  Arguments:
  Arg1: ff1e3fff, memory referenced.
  Arg2: 00000000, value 0 = read operation, 1 = write operation.
  Arg3: 91ce9382, If non-zero, the instruction address which referenced the bad memory
    address.
  Arg4: 00000000, (reserved)

  Debugging Details:
  ------------------

  FAULTING_IP: 
  win32k!EngDeleteClip+4883
  91ce9382 660fbe4fff      movsx   cx,byte ptr [edi-1]

  MM_INTERNAL_CODE:  0

  DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

  BUGCHECK_STR:  0x50

  PROCESS_NAME:  csrss.exe

  CURRENT_IRQL:  0

  ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre

  LAST_CONTROL_TRANSFER:  from 91ce92c0 to 91ce9382

  STACK_TEXT:  
  WARNING: Stack unwind information not available. Following frames may be wrong.
  9aa98858 91ce92c0 ff1ee3f8 ff1ee140 ff1ee3a8 win32k!EngDeleteClip+0x4883
  9aa9889c 91c64346 00000008 ff1ee010 fb9dce78 win32k!EngDeleteClip+0x47c1
  9aa988e4 91dfa025 ff1ee010 ff1ee07c 00000005 win32k!XFORMOBJ_iGetXform+0x5864
  9aa989f0 91dfa0fd 00000000 00000005 9aa98b04 win32k!XLATEOBJ_hGetColorTransform+0x40a1c
  9aa98a18 91c5f086 fb9dce78 00000005 9aa98b04 win32k!XLATEOBJ_hGetColorTransform+0x40af4
  9aa98a3c 91c5ef1c fc22ccf0 00000009 00000005 win32k!XFORMOBJ_iGetXform+0x5a4
  9aa98a8c 91c5e138 00000000 fc22ccf0 00000009 win32k!XFORMOBJ_iGetXform+0x43a
  9aa98ad4 91dc3424 00000000 fc22ccf0 00000009 win32k!EngCTGetGammaTable+0xc967
  9aa98b90 91dbafcc fc22ccf0 fc22ccf0 00000006 win32k!XLATEOBJ_hGetColorTransform+0x9e1b
  9aa98c0c 82888986 0c0104d1 00000022 00000006 win32k!XLATEOBJ_hGetColorTransform+0x19c3
  9aa98c0c 77986c74 0c0104d1 00000022 00000006 nt!KiSystemServicePostCall
  001cf4ac 00000000 00000000 00000000 00000000 0x77986c74
--- cut ---

While we have not determined the specific root cause of the vulnerability, we have pinpointed the offending mutations to reside in the "glyf" table.

The issue reproduces on Windows 7 (other platforms untested). It is easiest to reproduce with Special Pools enabled for win32k.sys. In order to reproduce the problem with the provided samples, it is necessary to use a custom program which calls the GetGlyphOutline() API with various parameters over all of the font's glyphs.

Attached is an archive with several proof-of-concept mutated TTF files.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42746.zip