Exploit-DB #47097
Description: Microsoft DirectWrite / AFDKO - Heap-Based Out-of-Bounds Read/Write in OpenType Font Handling Due to Unbounded iFD
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 readFDSelect() function in afdko/c/public/lib/source/cffread/cffread.c is designed to read and parse the FDSelect table of an input OpenType font. It is called by cfrBegFont(), the standard entry point function for the "cfr" (CFF Reader) module of AFDKO. The relevant part of the function is shown below:

--- cut ---
  2347      switch (read1(h)) {
  2348          case 0:
  2349              for (gid = 0; gid < h->glyphs.cnt; gid++)
  2350                  h->glyphs.array[gid].iFD = read1(h);
  2351              break;
  2352          case 3: {
  2353              int nRanges = read2(h);
  2354
  2355              gid = read2(h);
  2356              while (nRanges--) {
  2357                  int fd = read1(h);
  2358                  long next = read2(h);
  2359
  2360                  while (gid < next)
  2361                      h->glyphs.array[gid++].iFD = (unsigned char)fd;
  2362              }
  2363          } break;
--- cut ---

The "iFD" field is an unsigned char, as defined in afdko/c/public/lib/api/absfont.h:

--- cut ---
   393      unsigned char iFD;                /* CID-keyed: FD index */
--- cut ---

As shown above, it is initialized directly from the input stream and so the font file has complete control over it. There are no bounds checks to verify if the value is consistent with other structures in the font.

The field is used to store an index into the h->fdicts array, whose size is determined by the length of the FDArray index, see readFDArray():

--- cut ---
  1698      readINDEX(h, &h->region.FDArrayINDEX, &h->index.FDArray);
  1699      if (h->index.FDArray.count > 256)
  1700          fatal(h, cfrErrBadFDArray);
  1701
  1702      /* Read FDArray */
  1703      dnaSET_CNT(h->FDArray, h->index.FDArray.count);
  1704      dnaSET_CNT(h->fdicts, h->index.FDArray.count);
--- cut ---

If any of the iFD fields are set to a value exceeding the lengths of the h->FDArray / h->fdicts arrays, the library may access invalid memory in the following locations in code:

--- cut ---
  2796                  if (h->fdicts.array[info->iFD].Private.LanguageGroup == 1)
  2797                      info->flags |= ABF_GLYPH_LANG_1;
[...]
  2887      t2cAuxData *aux = &h->FDArray.array[info->iFD].aux;
--- cut ---

The second instance is especially dangerous in the context of memory safety, as the "aux" pointer fetched from an invalid memory location (potentially attacker-controlled) is later extensively used during the Type 2 CharString execution for reading and writing.

As a side note, we believe that the FDArray / fdicts arrays should consist of at least one element for every CID-keyed font, so we would suggest adding an additional check for "h->index.FDArray.count < 1" in the if statement shown below:

--- cut ---
  1698      readINDEX(h, &h->region.FDArrayINDEX, &h->index.FDArray);
  1699      if (h->index.FDArray.count > 256)
  1700          fatal(h, cfrErrBadFDArray);
--- cut ---

-----=====[ Proof of Concept ]=====-----

The proof of concept file contains a one-element FDArray. It also sets the iFD index of all glyphs to 1, which triggers a slightly out-of-bounds (off by one) access to h->fdicts.array[1] that is easily detected by AddressSanitizer. In non-ASAN builds, the code crashes later on when trying to access an invalid h->FDArray.array[1].aux pointer.

The font is also specially crafted to parse correctly with DirectWrite but trigger the bug in AFDKO. The original CFF2 t