Exploit-DB #47098
Description: Microsoft DirectWrite / AFDKO - Heap-Based Buffer Overflow in OpenType Font Handling in readStrings
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 readStrings() function in afdko/c/public/lib/source/cffread/cffread.c is designed to read the font name string and the string INDEX strings from the input font. The relevant part of the function is shown below:

--- cut ---
  1727      /* Get FontName data and compute its size */
  1728      INDEXGet(h, &h->index.name, 0, &FontName);
  1729      lenFontName = FontName.end - FontName.begin;
  1730
  1731      /* Compute string data size */
  1732      lenStrings = (h->index.string.count == 0) ? 0 : (h->region.StringINDEX.end - h->index.string.data + 1 + /* String data bytes */
  1733                                                       h->index.string.count);                                /* Null termination */
  1734
  1735      /* Allocate buffers */
  1736      dnaSET_CNT(h->string.offsets, h->index.string.count + 1);
  1737      dnaSET_CNT(h->string.ptrs, h->index.string.count);
  1738      dnaSET_CNT(h->string.buf, lenFontName + 1 + lenStrings);
  1739
  1740      p = h->string.buf.array;
  1741      *p = '\0';
  1742      if (h->header.major == 1) {
  1743          /* Copy FontName into buffer */
  1744          srcSeek(h, FontName.begin);
  1745          srcRead(h, lenFontName, p);
  1746          p += lenFontName;
  1747          *p++ = '\0';
  1748      }
--- cut ---

The key line is 1738, where an integer overflow may occur. The "lenFontName" variable stores the length of the font name, which can be no greater than 65535. The "lenStrings" variable is initialized in lines 1732/1733 based on the length of the strings INDEX; primarily h->region.StringINDEX.end. The overall h->region.StringINDEX structure is filled out by the generic readINDEX() function, as called by cfrBegFont():

--- cut ---
  2712      if (h->header.major == 1) {
  2713          h->region.StringINDEX.begin = h->region.TopDICTINDEX.end;
  2714          if (h->region.StringINDEX.begin > 0) {
  2715              readINDEX(h, &h->region.StringINDEX, &h->index.string);
  2716              /* Read strings */
  2717              readStrings(h);
  2718          }
--- cut ---

More specifically, h->region.StringINDEX.end is written to in the last line of readINDEX():

--- cut ---
  1582      /* Read and validate offset size */
  1583      index->offSize = read1(h);
  1584      if (index->offSize < 1 || index->offSize > 4)
  1585          fatal(h, cfrErrINDEXHeader);
  1586
  1587      index->offset = region->begin + cntSize + 1; /* Get offset array base */
  1588
  1589      /* Read and validate first offset */
  1590      if (readN(h, index->offSize) != 1)
  1591          fatal(h, cfrErrINDEXOffset);
  1592
  1593      /* Set data reference */
  1594      index->data = index->offset + (index->count + 1) * index->offSize - 1;
  1595
  1596      /* Read last offset and compute INDEX length */
  1597      srcSeek(h, index->offset + index->count * index->offSize);
  1598      region->end = index->data + readN(h, index->offSize);
  1599  }
--- cut ---

On platforms where "long" is a 32-bit type (Windows x86/x64 and Linux x86), this gives us complete control over the aforementioned field, including setting it to a negative value. This enables us to set the "lenStrings" variable to an arbitrary number, and thus makes it possible to choose it such that the result of the "lenFontName + 1 + lenStrings" expression is smaller than the sum of the font name's length and the length of all other strings. As a result, the heap-based h-