Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863102422

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

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

We have encountered a Windows kernel crash in the win32k.sys driver while processing a corrupted TTF font file. An example of a crash log excerpt generated after triggering the bug is shown below:

---
BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 00000021, the data following the pool block being freed is corrupt.  Typically this means the consumer (call stack ) has overrun the block.
Arg2: ff66c000, The pool pointer being freed.
Arg3: 00001038, The number of bytes allocated for the pool block.
Arg4: 00000000, The corrupted value found following the pool block.

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


BUGCHECK_STR:  0x19_21

POOL_ADDRESS: GetPointerFromAddress: unable to read from 8277684c
Unable to read MiSystemVaType memory at 82755780
 ff66c000 

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  0

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

LAST_CONTROL_TRANSFER:  from 82942f90 to 8272cc6b

STACK_TEXT:  
b5ccb5c0 82942f90 ff66c000 00000000 ff66c000 nt!ExFreePoolWithTag+0x1b1
b5ccb5d4 9916b9e2 ff66c000 00000000 fb834e78 nt!VerifierExFreePoolWithTag+0x30
b5ccb5e8 99159ebf ff66c010 fb82af24 00000001 win32k!EngFreeMem+0x1f
b5ccb728 9914eda9 0000002c 0000001c b5ccb818 win32k!lGetGlyphBitmap+0x258
b5ccb750 9914ebf6 00000000 00000001 0000001c win32k!ttfdQueryFontData+0x15e
b5ccb7a0 9914de12 ff7a5010 fb82acf0 00000001 win32k!ttfdSemQueryFontData+0x45
b5ccb7e8 991538bd ff7a5010 fb82acf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
b5ccb860 991cc470 b5ccbb3c ff6b0300 ff6ab094 win32k!xInsertMetricsPlusRFONTOBJ+0x120
b5ccb890 99145a6f 0000000a ff7bf050 b5ccbbda win32k!RFONTOBJ::bGetGlyphMetricsPlus+0x179
b5ccb8c8 991cbf6e b5ccbb1c b5ccbb3c 00000008 win32k!ESTROBJ::vCharPos_H3+0xf0
b5ccb90c 991456f2 b5ccbbd0 0000000a b5ccbb1c win32k!ESTROBJ::vInit+0x268
b5ccbb2c 991458b5 00000000 b5ccbbd0 fb82acf0 win32k!GreGetTextExtentExW+0x12a
b5ccbc0c 82647a06 2b01027a 006e0bac 0000000a win32k!NtGdiGetTextExtentExW+0x141
b5ccbc0c 76e871b4 2b01027a 006e0bac 0000000a nt!KiSystemServicePostCall
WARNING: Frame IP not in any known module. Following frames may be wrong.
0026f2ac 00000000 00000000 00000000 00000000 0x76e871b4
---

The type of the bugcheck implies a pool-based buffer overflow or some other type of pool corruption, potentially allowing for remote code execution in the context of the Windows kernel. While we have not determined the specific root cause of the vulnerability, we have pinpointed the offending mutations to reside in the "EBLC" and "EBSC" tables.

The issue reproduces on Windows 7. It is easiest to reproduce with Special Pools enabled for win32k.sys, but it is also possible to observe a crash on a default Windows installation in win32k.sys or another location in kernel space, as caused by the corrupted pool state.

Attached is an archive with the proof-of-concept mutated TTF file, together with the original font used to generate it and a corresponding crash log from Windows 7 32-bit.

The vendor communication timeline is as follows:

12/22/2015 Vulnerability is reported to Microsoft.
12/22/2015 MSRC acknowledges the receipt of the report.
01/09/2016 MSRC informs us they are unable to reproduce the issue and ask for a crash dump that may help.
01/11/2016 We send MSRC 32-bit and 64-bit crash dumps, together with additional repro information.
01/11/2016 MSRC acknowledges the receipt of the new information.
01/21/2016 MSRC informs us they still cannot reproduce the crash, and the provided crash dumps didn't help. They ask for more detailed information (full crash dump, environment details, POC program etc.)
01/25/2016 Upon further investigation, we realize that the bugcheck only occurs if the [Computer => Properties => Advanced system settings => Advanced => Performance => Settings => Visual Effects => Smooth edges of screen fonts] option is unchecked in system settings, and let MSRC know about this discovery.
01/25/2016 MSRC confirm that the crash now reproduces reliably on their side.

Since Microsoft was only able to get a repro of this issue on 01/25/2016 due to the non-standard system settings, we are resetting the 90-day period start date to that day.

When the "Smooth edges of screen fonts" option is disabled, the bugcheck also occurs on versions of Windows other than 7 (confirmed with Windows 8.1). By further minimizing the POC sample, it is also possible to trigger the crash by simply opening it in the default "Windows Font Viewer" utility.


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