Exploit-DB #47090
Description: Microsoft DirectWrite / AFDKO - Use of Uninitialized Memory While Freeing Resources in var_loadavar
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 uninitialized memory used in the vulnerable code originates from the client-provided allocator callback. According to our analysis the callback provided by DirectWrite zeroes out the returned memory by itself, which should reduce the impact of the bug to a NULL pointer dereference. However, in case the implementation of the allocator ever changes in the future, we have opted to report the bug despite its apparent low severity at this time, especially considering that the resulting primitive is the invocation of a function pointer loaded from the uninitialized address.

-----=====[ Description ]=====-----

The bug resides in the support of variable fonts, and specifically in the loading of the "avar" table. We're interested in the following structures (from source/varread/varread.c):

--- cut ---
    84  /* avar table */
    85  struct var_avar_;
    86  typedef struct var_avar_ *var_avar;
    87
[...]
    91
    92  /* avar table */
    93
    94  typedef struct axisValueMap_ {
    95      Fixed fromCoord;
    96      Fixed toCoord;
    97  } axisValueMap;
    98
    99  typedef dnaDCL(axisValueMap, axisValueMapArray);
   100
   101  typedef struct segmentMap_ {
   102      unsigned short positionMapCount;
   103      axisValueMapArray valueMaps;
   104  } segmentMap;
   105
   106  typedef dnaDCL(segmentMap, segmentMapArray);
   107
   108  struct var_avar_ {
   109      unsigned short axisCount;
   110      segmentMapArray segmentMaps;
   111  };
--- cut ---

In other words, an "avar" structure contains a list of segment maps, each of which contains a list of value maps. The object is allocated and initialized in the var_loadavar() function. It is possible to bail out of the parsing in several places in the code:

--- cut ---
   297      if (table->length < AVAR_TABLE_HEADER_SIZE + (unsigned long)AVAR_SEGMENT_MAP_SIZE * avar->axisCount) {
   298          sscb->message(sscb, "invalid avar table size or axis/instance count/size");
   299          goto cleanup;
   300      }
   301
   302      dnaINIT(sscb->dna, avar->segmentMaps, 0, 1);
   303      if (dnaSetCnt(&avar->segmentMaps, DNA_ELEM_SIZE_(avar->segmentMaps), avar->axisCount) < 0)
   304          goto cleanup;
[...]
   311          if (table->length < sscb->tell(sscb) - table->offset + AVAR_AXIS_VALUE_MAP_SIZE * seg->positionMapCount) {
   312              sscb->message(sscb, "avar axis value map out of bounds");
   313              goto cleanup;
   314          }
   315
   316          dnaINIT(sscb->dna, seg->valueMaps, 0, 1);
   317          if (dnaSetCnt(&seg->valueMaps, DNA_ELEM_SIZE_(seg->valueMaps), seg->positionMapCount) < 0)
   318              goto cleanup;
--- cut ---

which leads to freeing the entire "avar" object:

--- cut ---
   339  cleanup:;
   340      HANDLER
   341      END_HANDLER
   342
   343      if (!success) {
   344          var_freeavar(sscb, avar);
   345          avar = 0;
   346      }
--- cut ---

When a parsing error occurs, the object may be only partially initialized. However, the var_freeavar() function doesn't take it into account and unconditionally attempts to free all value maps lists inside of all segment maps lists:

--- cut ---
   255  static void var_freeavar(ctlSharedStmCallbacks *sscb, var_avar avar) {
   256      if (avar) {
   257          unsigned short i;
   258
   259          for (i = 0; i < avar->axisCount; i++) {
   260              dnaFREE(avar->segmentMaps.array[i].valueMaps);
   261          }
   262          dnaFREE(avar->segmentMaps);
   263
   264          sscb->memFree(sscb, avar);