-----=====[ Background ]=====-----

The Microsoft Font Subsetting DLL (fontsub.dll) is a default Windows helper library for subsetting TTF fonts; i.e. converting fonts to their more compact versions based on the specific glyphs used in the document where the fonts are embedded. It is used by Windows GDI and Direct2D, and parts of the same code are also found in the t2embed.dll library designed to load and process embedded fonts.

The DLL exposes two API functions: CreateFontPackage and MergeFontPackage. We have developed a testing harness which invokes a pseudo-random sequence of such calls with a chosen font file passed as input. This report describes a crash triggered by a malformed font file in the fontsub.dll code through our harness.

-----=====[ Description ]=====-----

We have encountered the following crash in fontsub!WriteTableFromStructure:

--- cut ---
(3890.25ac): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
FONTSUB!WriteTableFromStructure+0x6e:
00007fff`aa544326 0fb74810        movzx   ecx,word ptr [rax+10h] ds:000001ac`2d48a000=????

0:000> dd rax
000001ac`2d489ff0  d0d0d0c0 d0d0d0d0 d0d0d0d0 d0d0d0d0
000001ac`2d48a000  ???????? ???????? ???????? ????????
000001ac`2d48a010  ???????? ???????? ???????? ????????
000001ac`2d48a020  ???????? ???????? ???????? ????????
000001ac`2d48a030  ???????? ???????? ???????? ????????
000001ac`2d48a040  ???????? ???????? ???????? ????????
000001ac`2d48a050  ???????? ???????? ???????? ????????
000001ac`2d48a060  ???????? ???????? ???????? ????????

0:000> !heap -p -a rax
    address 000001ac2d489ff0 found in
    _DPH_HEAP_ROOT @ 1ac2d041000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                             1ac2d0495b0:      1ac2d489ff0                1 -      1ac2d489000             2000
    00007fffcf6530df ntdll!RtlDebugAllocateHeap+0x000000000000003f
    00007fffcf60b52c ntdll!RtlpAllocateHeap+0x0000000000077d7c
    00007fffcf59143b ntdll!RtlpAllocateHeapInternal+0x00000000000005cb
    00007fff9b90be42 vrfcore!VfCoreRtlAllocateHeap+0x0000000000000022
    00007fffcca398f0 msvcrt!malloc+0x0000000000000070
    00007fffaa53fd1e FONTSUB!Mem_Alloc+0x0000000000000012
    00007fffaa545562 FONTSUB!MergeEblcEbdtTables+0x0000000000000b02
    00007fffaa53b0a3 FONTSUB!MergeFonts+0x0000000000000603
    00007fffaa53baac FONTSUB!MergeDeltaTTF+0x00000000000003ec
    00007fffaa5314b2 FONTSUB!MergeFontPackage+0x0000000000000132
[...]

0:000> k
 # Child-SP          RetAddr           Call Site
00 00000078`dc2fd380 00007fff`aa545634 FONTSUB!WriteTableFromStructure+0x6e
01 00000078`dc2fd490 00007fff`aa53b0a3 FONTSUB!MergeEblcEbdtTables+0xbd4
02 00000078`dc2fd6a0 00007fff`aa53baac FONTSUB!MergeFonts+0x603
03 00000078`dc2fd850 00007fff`aa5314b2 FONTSUB!MergeDeltaTTF+0x3ec
04 00000078`dc2fd990 00007ff6`1a8a8a30 FONTSUB!MergeFontPackage+0x132
[...]
--- cut ---

The root cause of the crash seems to be the fact that the MergeEblcEbdtTables() function may allocate a 0-sized buffer and pass it to WriteTableFromStructure() as one of the fields of a structure passed through the fifth argument, but the WriteTableFromStructure() function assumes that the buffer is at least 32 bytes long, and unconditionally reads from it at offset 16, and other offsets later on in the routine.

The issue reproduces on a fully updated Windows 10 1709; we haven't tested earlier versions of the system. It could be potentially used to disclose sensitive data from the process address space. It is easiest to reproduce with PageHeap enabled, but it is also possible to observe a crash in a default system configuration. Attached are 3 proof of concept malformed font files which trigger the crash.


Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/47267.zip