-----=====[ 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://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/47267.zip
