Microsoft directwrite / afdko stack corruption in opentype font handling due to outofbounds cubestackdepth Vulnerability / Exploit
/
/
/
Exploits / Vulnerability Discovered : 2019-07-10 |
Type : dos |
Platform : windows
[+] Code ...
----=====[ Background ]=====-----
AFDKO (Adobe Font Development Kit for OpenType) is a set of tools for examining, modifying and building fonts. The core part of this toolset is a font handling library written in C, which provides interfaces for reading and writing Type 1, OpenType, TrueType (to some extent) and several other font formats. While the library existed as early as 2000, it was open-sourced by Adobe in 2014 on GitHub [1, 2], and is still actively developed. The font parsing code can be generally found under afdko/c/public/lib/source/*read/*.c in the project directory tree.
At the time of this writing, based on the available source code, we conclude that AFDKO was originally developed to only process valid, well-formatted font files. It contains very few to no sanity checks of the input data, which makes it susceptible to memory corruption issues (e.g. buffer overflows) and other memory safety problems, if the input file doesn't conform to the format specification.
We have recently discovered that starting with Windows 10 1709 (Fall Creators Update, released in October 2017), Microsoft's DirectWrite library [3] includes parts of AFDKO, and specifically the modules for reading and writing OpenType/CFF fonts (internally called cfr/cfw). The code is reachable through dwrite!AdobeCFF2Snapshot, called by methods of the FontInstancer class, called by dwrite!DWriteFontFace::CreateInstancedStream and dwrite!DWriteFactory::CreateInstancedStream. This strongly indicates that the code is used for instancing the relatively new variable fonts [4], i.e. building a single instance of a variable font with a specific set of attributes. The CreateInstancedStream method is not a member of a public COM interface, but we have found that it is called by d2d1!dxc::TextConvertor::InstanceFontResources, which led us to find out that it can be reached through the Direct2D printing interface. It is unclear if there are other ways to trigger the font instancing functionality.
One example of a client application which uses Direct2D printing is Microsoft Edge. If a user opens a specially crafted website with an embedded OpenType variable font and decides to print it (to PDF, XPS, or another physical or virtual printer), the AFDKO code will execute with the attacker's font file as input. Below is a description of one such security vulnerability in Adobe's library exploitable through the Edge web browser.
-----=====[ Description ]=====-----
The _t2cCtx structure defined in c/public/lib/source/t2cstr/t2cstr.c contains a "cube" array and a "cubeStackDepth" index:
--- cut ---
84 int cubeStackDepth;
85 float transformMatrix[6];
86 struct /* Stem hints */
87 {
88 float start_x; /* Path x-coord at start of Cube library element processing */
89 float start_y; /* Path y-coord at start of Cube library element processing */
90 float offset_x; /* cube offset, to add to first moveto in cube library element (LE) */
91 float offset_y; /* cube offset, to add to first moveto in cube library element (LE) */
92 int nMasters;
93 int leIndex;
94 int composeOpCnt;
95 float composeOpArray[TX_MAX_OP_STACK_CUBE];
96 double WV[kMaxCubeMasters]; /* Was originally just 4, to support substitution MM fonts. Note: the PFR rasterizer can support only up to 5 axes */
97 } cube[CUBE_LE_STACKDEPTH];
--- cut ---
The CUBE_LE_STACKDEPTH constant is defined in c/public/lib/resource/txops.h as:
However there is no upper bound check of the value of the field, so by invoking the tx_compose operation several times in a row, it is possible to set it out of bounds. As user-controlled reads and writes can be performed on h->cube[h->cubeStackDepth], this may lead to non-continuous memory corruption and remote code execution. Various members of the _t2cCtx structure make a good target for overwriting, including the interpreter stack index/limit, the cff2/glyph/mem callback pointers etc. Furthermore, the _t2cCtx object itself is declared in the stack frame of the t2cParse() function, so stack frame pointers, return addresses and other control flow information can be corrupted through this vulnerability as well.
-----=====[ Proof of Concept ]=====-----
The proof of concept file triggers the bug upon decoding the instruction stream for letter "A". It calls the only global subroutine (index 0), which then indefinitely, recursively invokes itself through the tx_compose operator, each time incrementing h->cubeStackDepth by one. After several dozen iterations the function reaches the bottom of the stack and crashes with SIGSEGV / ACCESS_VIOLATION while accessing an invalid memory address.
-----=====[ Crash logs ]=====-----
A crash log from the "tx" tool being part of AFDKO, run as ./tx -cff <path to font file>:
A crash log from the Microsoft Edge renderer process, while trying to print a webpage containing the malformed variable font:
--- cut ---
(3fa8.3104): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
DWrite!t2Decode+0x203:
00007ff9`ac0f1777 89943938590000 mov dword ptr [rcx+rdi+5938h],edx ds:000000d9`a5541448=????????