Exploit-DB #47099
Description: Microsoft DirectWrite / AFDKO - Stack Corruption in OpenType Font Handling While Processing CFF Blend DICT Operator
Type: dos
Platform: windows
Date: 2019-07-10
Author: Google Security Research

Exploit:
-----=====[ 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 handleBlend() function in afdko/c/public/lib/source/cffread/cffread.c is called when a cff_blend operator is encountered while parsing a CFF DICT object in readDICT():

--- cut ---
  1466              case cff_blend:
  1467                  if (h->stack.numRegions == 0) {
  1468                      /* priv->vsindex is set to 0 by default; it is otherwise only if the vsindex operator is used */
  1469                      setNumMasters(h, priv->vsindex);
  1470                  }
  1471                  handleBlend(h);
  1472                  continue;
--- cut ---

The prologue of handleBlend() is as follows:

--- cut ---
   757  static void handleBlend(cfrCtx h) {
[...]
   776
   777      int numBlends = INDEX_INT(h->stack.cnt - 1);
   778      stack_elem *firstItem;
   779      int i = 0;
   780      int numDeltaBlends = numBlends * h->stack.numRegions;
   781      int firstItemIndex;
   782      h->flags |= CFR_SEEN_BLEND;
   783
   784      h->stack.cnt--;
   785
   786      if (numBlends < 0 || numDeltaBlends < 0)
   787          fatal(h, cfrErrStackUnderflow);
   788      CHKUFLOW(numBlends + numDeltaBlends);
   789      firstItemIndex = (h->stack.cnt - (numBlends + numDeltaBlends));
   790      firstItem = &(h->stack.array[firstItemIndex]);
   791
--- cut ---

Here is what happens in the code: the 32-bit numBlends variable is initialized with a fully controlled value from the top of the interpreter stack. The numDeltaBlends variable is calculated using numBlends and h->stack.numRegions, which is a typically small (theoretically up to 65535) but also controlled value. The code then makes sure that neither numBlends or numDeltaBlends are negative (line 786), and that there are at least numBlends+numDeltaBlends values on the stack (line 788). If these conditions are met, the function proceeds to writing to h->stack.array[h->stack.cnt - (numBlends + numDeltaBlends)] and further elements assuming the access is safe.

However, the sanity checks in lines 786-788 are not sufficient, as they miss one corner case - when both numBlends and numDeltaBlends are positive, but the numBlends + numDeltaBlends sum is negative due to signed 32-bit integer arithmetic. For example, if:

- numBlends is 0x31313131
- h->stack.numRegions is 2

then:

- numDeltaBlends is 0x62626262
- numBlends + numDeltaBlends is 0x93939393

The above values can be set by a specially crafted font and they meet the conditions verified by handleBlend(), yet the index of -0x93939393 (which translates to[PII_REDACTED]) is largely out of bounds. This may be used to overwrite memory both inside of the stack-based cfrCtx object, and outside of it.

-----=====[ Proof of Concept ]=====-----

The proof of concept file contains a Private DICT beginning with the following two operators:

1. cff_longint(0x31313131)
2. cff_blend

This causes the above signedness issue to occur, leading to an attempt to write to a stack element at h->stack.array[[PII_REDACTED]].

The font is also specially crafted to parse correctly with DirectWrite but trigger the bug in AFDKO. The original CFF2 table was left untouched, and a second copy of it with the modified DICT was inserted at the end of the font with the tag "CFF ". This way, DirectWrite successfully loads the legitimate variable font, and AFDKO processes the modified version as the CFF table takes precedence over CFF2 due to the logic implemented in srcOpen() in afdko/c/public/lib/source/cffread/cffread.c.