Exploit-DB #47101
Description: Microsoft DirectWrite / AFDKO - Multiple Bugs in OpenType Font Handling Related to the _post_ Table
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 readCharset() function in afdko/c/public/lib/source/cffread/cffread.c is called from cfrBegFont(), the main entry point for parsing an input OpenType/CFF font by the "cfr" (CFF Reader) component of AFDKO. At the beginning of the function, it handles variable CFF2 fonts:

--- cut ---
  2138      if (h->header.major == 2) {
  2139          postRead(h);
  2140          if (h->cff2.mvar)
  2141              MVARread(h);
  2142          if (!(h->flags & CID_FONT))
  2143              readCharSetFromPost(h);
  2144          else {
  2145              long gid;
  2146              for (gid = 0; gid < h->glyphs.cnt; gid++) {
  2147                  abfGlyphInfo *info = &h->glyphs.array[gid];
  2148                  info->cid = (unsigned short)gid;
  2149              }
  2150          }
  2151          return;
  2152      }
--- cut ---

In this report, we are most interested in lines 2139 and 2143, i.e. the calls to postRead() and readCharSetFromPost(). The postRead() routine is responsible for processing the "post" optional SFNT table, extracting the glyph names that it contains and copying them into the internal engine structures. Let's analyze some of its most important parts:

--- cut ---
  1960      if (h->flags & CID_FONT)
  1961          return; /* Don't read glyph names for CID fonts */
  1962
  1963      if (h->post.format != 0x00020000) {
  1964          buildGIDNames(h);
  1965          return;
  1966      }
--- cut ---

In order to pass the two checks, the font must not be CID-keyed and the "post" table format must be 2.0. Then, the number of glyphs described by the table is loaded, and if it's inconsistent with the font's number of glyphs, a warning message is printed. 

--- cut ---
  1975      /* Parse format 2.0 data */
  1976      numGlyphs = read2(h);
  1977      if (numGlyphs != h->glyphs.cnt)
  1978          message(h, "post 2.0: name index size doesn't match numGlyphs");
--- cut ---

Then, the function proceeds to fill out three internal objects: h->post.fmt2.glyphNameIndex (a dynamic array of "unsigned short", containing indexes into "strings"), h->post.fmt2.strings (a dynamic array of string pointers) and h->post.fmt2.buf (a dynamic array of characters, storing the textual data pointed to by "strings"). One very peculiar feature of the function is that upon encountering invalid input data, it flips the "post" table format to 0x00000001 (even though it was originally 0x00020000) and returns with success:

--- cut ---
  2026  parseError:
  2027      /* We managed to read the header but the rest of the table had an error that
  2028       prevented reading some (or all) glyph names. We set the the post format
  2029       to a value that will allow us to use the header values but will prevent
  2030       us from using any glyph name data which is likely missing or invalid */
  2031      h->post.format = 0x00000001;
  2032  }
--- cut ---

While the message explains the developer's intention quite well, it is not factually correct, as the above post format doesn't prevent the code from using glyph name data later on. 

The "parseError" label can be reached from four different locations, each of them being the result of a failed sanity check:

--- cut ---
  1968      if (invalidStreamOffset(h, table->offset + table->length - 1)) {
  1969          message(h, "post: table truncated");
  1970          goto parseError;
  1971      }
[...]
  1982      if (length < numGlyphs * 2) {