Exploit-DB #47088
Description: Microsoft DirectWrite / AFDKO - Stack Corruption in OpenType Font Handling Due to Negative nAxes
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 vulnerability resides in the do_set_weight_vector_cube() function in afdko/c/public/lib/source/t2cstr/t2cstr.c, whose prologue is shown below:

--- cut ---
   985  static int do_set_weight_vector_cube(t2cCtx h, int nAxes) {
   986      float dx, dy;
   987      int i = 0;
   988      int j = 0;
   989      int nMasters = 1 << nAxes;
   990      float NDV[kMaxCubeAxes];
   991      int popCnt = nAxes + 3;
   992      int composeCnt = h->cube[h->cubeStackDepth].composeOpCnt;
   993      float *composeOps = h->cube[h->cubeStackDepth].composeOpArray;
--- cut ---

The "nAxes" argument may be controlled through the tx_SETWVN instruction:

--- cut ---
  1912                          case tx_SETWVN: {
  1913                              int numAxes = (int)POP();
  1914                              result = do_set_weight_vector_cube(h, numAxes);
  1915                              if (result || !(h->flags & FLATTEN_CUBE))
  1916                                  return result;
--- cut ---

Later in do_set_weight_vector_cube(), there is very little sanitization of "nAxes", and the function mostly assumes that the argument is valid. Setting it to a negative value will cause the following check to pass:

--- cut ---
  1022      if (composeCnt < (nAxes + 3))
  1023          return t2cErrStackUnderflow;
--- cut ---

which enables us to execute the rest of the function with "nMasters" equal to an arbitrary power of 2, and "popCnt" set to an arbitrary negative value. This may lead to stack-based out-of-bounds reads and writes in the following loops:

--- cut ---
  1028          /* Pop all the current COMPOSE args off the stack. */
  1029          for (i = popCnt; i < composeCnt; i++)
  1030              composeOps[i - popCnt] = composeOps[i];
[...]
  1039
  1040      /* Compute Weight Vector */
  1041      for (i = 0; i < nMasters; i++) {
  1042          h->cube[h->cubeStackDepth].WV[i] = 1;
  1043          for (j = 0; j < nAxes; j++)
  1044              h->cube[h->cubeStackDepth].WV[i] *= (i & 1 << j) ? NDV[j] : 1 - NDV[j];
  1045      }
  1046      /* Pop all the current COMPOSE args off the stack. */
  1047      for (i = popCnt; i < composeCnt; i++)
  1048          composeOps[i - popCnt] = composeOps[i];
--- cut ---

-----=====[ Proof of Concept ]=====-----

The proof of concept file calls do_set_weight_vector_cube(nAxes=-100000), causing AFDKO to perform largely out-of-bounds read/writes operations relative to the stack, which results in a SIGSEGV / ACCESS_VIOLATION crash of the client program in line 1030:

--- cut ---
  1028          /* Pop all the current COMPOSE args off the stack. */
  1029          for (i = popCnt; i < composeCnt; i++)
  1030              composeOps[i - popCnt] = composeOps[i];
--- cut ---

-----=====[ Crash logs ]=====-----

Crash log of the "tx" 64-bit utility started as ./tx -cff <path to font file>:

--- cut ---
Program received signal SIGSEGV, Segmentation fault.
0x[PII_REDACTED]466f31 in do_set_weight_vector_cube (h=0x7ffffff60188, nAxes=-100000) at ../../../../../source/t2cstr/t2cstr.c:1030
1030                composeOps[i - popCnt] = composeOps[i];
(gdb) where
#0  0x[PII_REDACTED]466f31 in do_set_weight_vector_cube (h=0x7ffffff60188, nAxes=-100000) at ../../../../../source/t2cstr/t2cstr.c:1030
#1  0x[PII_REDACTED]460f3f in t2Decode (h=0x7ffffff60188, offset=19147) at ../../../../../source/t2cstr/t2cstr.c:1914
#2  0x[PII_REDACTED]45e224 in t2Decode (h=0x7ffffff60188, offset=2356