Exploit-DB #47093
Description: Microsoft DirectWrite / AFDKO - Heap-Based Buffer Overflow in OpenType Font Handling in readEncoding
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.

In this specific case, the CFR_NO_ENCODING flag must be unset while interacting with AFDKO to trigger the bug. According to our analysis, DirectWrite currently does specify this flag, but it still contains the readEncoding() function including the vulnerable code. In case the code can be reached in a way we haven't considered, or the CFR_NO_ENCODING flag is ever removed in the future, we have opted to report the bug despite its apparent unreachability at this time.

-----=====[ Description ]=====-----

The readEncoding() function in afdko/c/public/lib/source/cffread/cffread.c is designed to read and parse the encoding table of an input OpenType font. It is called by cfrBegFont(), the standard entry point function for the "cfr" (CFF Reader) module of AFDKO, if the CFR_NO_ENCODING flag is not set. The relevant part of the function is shown below:

--- cut ---
  2288              fmt = read1(h);
  2289
  2290              switch (fmt & 0x7f) {
  2291                  case 0:
  2292                      cnt = read1(h);
  2293                      while (gid <= cnt)
  2294                          encAdd(h, &h->glyphs.array[gid++], read1(h));
  2295                      break;
  2296                  case 1:
  2297                      cnt = read1(h);
  2298                      while (cnt--) {
  2299                          short code = read1(h);
  2300                          int nLeft = read1(h);
  2301                          while (nLeft-- >= 0)
  2302                              encAdd(h, &h->glyphs.array[gid++], code++);
  2303                      }
  2304                      break;
  2305                  default:
  2306                      fatal(h, cfrErrEncodingFmt);
  2307              }
--- cut ---

In both loops in lines 2292-2294 and 2297-2303, the code doesn't consider the size of the h->glyphs array and writes to it solely based on the encoding information. If the values read from the input stream in lines 2292, 2297 and/or 2300 exceed the number of glyphs in the font, the array may be overflown by the encAdd() function, corrupting adjacent objects on the heap. The h->glyphs array is initialized in readCharStringsINDEX() based on the number of CharStrings found in the font:

--- cut ---
  1791      dnaSET_CNT(h->glyphs, index.count);
--- cut ---

-----=====[ Proof of Concept ]=====-----

The three attached proof of concept files were generated by a fuzzer running against the "tx" utility compiled with AddressSanitizer. They are not complete OpenType fonts but rather raw CFF streams, which causes tx to not use the CFR_NO_ENCODING flag, which is necessary to reach the vulnerable readEncoding() function (c/tx/source/tx.c):

--- cut ---
   425              case src_OTF:
   426                  h->cfr.flags |= CFR_NO_ENCODING;
   427                  /* Fall through */
   428              case src_CFF:
   429                  cfrReadFont(h, rec->offset, rec->iTTC);
   430                  break;
--- cut ---

-----=====[ Crash logs ]=====-----

A 64-bit "tx" program compiled with ASAN crashes with the following report when started with a ./tx -cff poc.cff command:

--- cut ---
=================================================================
==205898==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62a00000b220 at pc 0x[PII_REDACTED]aa bp 0x7fff35b2b5c0 sp 0x7fff35b2b5b8
READ of size 8 at 0x62a00000b220 thread T0
    #0 0x5573a9 in encAdd afdko/c/public/lib/source/cffread/cffread.c:2203:14
    #1 0x540f80 in readEncoding afdko/c/public/lib/source/cffread/cffread.c:2302:29
    #2 0x529eb9 in cfrBegFont afdko/c/public/lib/source/cffre