Microsoft DirectWrite / AFDKO – Stack Corruption in OpenType Font Handling While Processing CFF Blend DICT Operator

  • 作者: Google Security Research
    日期: 2019-07-10
  • 类别:
    平台:
  • 来源:https://www.exploit-db.com/exploits/47099/
  • -----=====[ 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 handleBlend() function in afdko/c/public/lib/source/cffread/cffread.c is called when a cff_blend operator is encountered while parsing a CFF DICT object in readDICT():
    
    --- cut ---
    1466case cff_blend:
    1467if (h->stack.numRegions == 0) {
    1468/* priv->vsindex is set to 0 by default; it is otherwise only if the vsindex operator is used */
    1469setNumMasters(h, priv->vsindex);
    1470}
    1471handleBlend(h);
    1472continue;
    --- cut ---
    
    The prologue of handleBlend() is as follows:
    
    --- cut ---
     757static void handleBlend(cfrCtx h) {
    [...]
     776
     777int numBlends = INDEX_INT(h->stack.cnt - 1);
     778stack_elem *firstItem;
     779int i = 0;
     780int numDeltaBlends = numBlends * h->stack.numRegions;
     781int firstItemIndex;
     782h->flags |= CFR_SEEN_BLEND;
     783
     784h->stack.cnt--;
     785
     786if (numBlends < 0 || numDeltaBlends < 0)
     787fatal(h, cfrErrStackUnderflow);
     788CHKUFLOW(numBlends + numDeltaBlends);
     789firstItemIndex = (h->stack.cnt - (numBlends + numDeltaBlends));
     790firstItem = &(h->stack.array[firstItemIndex]);
     791
    --- cut ---
    
    Here is what happens in the code: the 32-bit numBlends variable is initialized with a fully controlled value from the top of the interpreter stack. The numDeltaBlends variable is calculated using numBlends and h->stack.numRegions, which is a typically small (theoretically up to 65535) but also controlled value. The code then makes sure that neither numBlends or numDeltaBlends are negative (line 786), and that there are at least numBlends+numDeltaBlends values on the stack (line 788). If these conditions are met, the function proceeds to writing to h->stack.array[h->stack.cnt - (numBlends + numDeltaBlends)] and further elements assuming the access is safe.
    
    However, the sanity checks in lines 786-788 are not sufficient, as they miss one corner case - when both numBlends and numDeltaBlends are positive, but the numBlends + numDeltaBlends sum is negative due to signed 32-bit integer arithmetic. For example, if:
    
    - numBlends is 0x31313131
    - h->stack.numRegions is 2
    
    then:
    
    - numDeltaBlends is 0x62626262
    - numBlends + numDeltaBlends is 0x93939393
    
    The above values can be set by a specially crafted font and they meet the conditions verified by handleBlend(), yet the index of -0x93939393 (which translates to 1819044973) is largely out of bounds. This may be used to overwrite memory both inside of the stack-based cfrCtx object, and outside of it.
    
    -----=====[ Proof of Concept ]=====-----
    
    The proof of concept file contains a Private DICT beginning with the following two operators:
    
    1. cff_longint(0x31313131)
    2. cff_blend
    
    This causes the above signedness issue to occur, leading to an attempt to write to a stack element at h->stack.array[1819044973].
    
    The font is also specially crafted to parse correctly with DirectWrite but trigger the bug in AFDKO. The original CFF2 table was left untouched, and a second copy of it with the modified DICT was inserted at the end of the font with the tag "CFF ". This way, DirectWrite successfully loads the legitimate variable font, and AFDKO processes the modified version as the CFF table takes precedence over CFF2 due to the logic implemented in srcOpen() in afdko/c/public/lib/source/cffread/cffread.c.
    
    -----=====[ Crash logs ]=====-----
    
    A 64-bit build of "tx" started with ./tx -cff poc.otf crashes with a SIGSEGV while trying to write to an unmapped memory address:
    
    --- cut ---
    Program received signal SIGSEGV, Segmentation fault.
    0x000000000041670e in handleBlend (h=0x7103a0) at ../../../../../source/cffread/cffread.c:811
    811 firstItem->numBlends = (unsigned short)numBlends;
    
    (gdb) print numBlends
    $1 = 825307441
    (gdb) print numDeltaBlends
    $2 = 1650614882
    (gdb) print numBlends+numDeltaBlends
    $3 = -1819044973
    (gdb) print firstItemIndex
    $5 = 1819044973
    
    (gdb) x/10i $rip
    => 0x41670e <handleBlend+878>:mov%cx,0x8(%rdx)
     0x416712 <handleBlend+882>:mov-0x8(%rbp),%rdi
     0x416716 <handleBlend+886>:movslq -0x20(%rbp),%rdx
     0x41671a <handleBlend+890>:shl$0x2,%rdx
     0x41671e <handleBlend+894>:mov%rdx,%rsi
     0x416721 <handleBlend+897>:callq0x416880 <memNew>
     0x416726 <handleBlend+902>:mov-0x18(%rbp),%rdx
     0x41672a <handleBlend+906>:mov%rax,0x10(%rdx)
     0x41672e <handleBlend+910>:mov-0x1c(%rbp),%eax
     0x416731 <handleBlend+913>:cmp-0x20(%rbp),%eax
    
    (gdb) info reg $rdx
    rdx0xa2a9b328043664487040
    (gdb) x/10gx $rdx
    0xa2a9b3280:Cannot access memory at address 0xa2a9b3280
    
    (gdb) bt
    #00x000000000041670e in handleBlend (h=0x7103a0) at ../../../../../source/cffread/cffread.c:811
    #10x0000000000411318 in readDICT (h=0x7103a0, region=0x7156d8, topdict=0) at ../../../../../source/cffread/cffread.c:1471
    #20x000000000041241f in readPrivate (h=0x7103a0, iFD=0) at ../../../../../source/cffread/cffread.c:1637
    #30x0000000000411a17 in readFDArray (h=0x7103a0) at ../../../../../source/cffread/cffread.c:1711
    #40x000000000040dc5c in cfrBegFont (h=0x7103a0, flags=4, origin=0, ttcIndex=0, top=0x6f6048, UDV=0x0) at ../../../../../source/cffread/cffread.c:2761
    #50x0000000000405e4e in cfrReadFont (h=0x6f6010, origin=0, ttcIndex=0) at ../../../../source/tx.c:137
    #60x0000000000405c9e in doFile (h=0x6f6010, srcname=0x7fffffffdf1b "poc.otf") at ../../../../source/tx.c:429
    #70x000000000040532e in doSingleFileSet (h=0x6f6010, srcname=0x7fffffffdf1b "poc.otf")
    at ../../../../source/tx.c:488
    #80x0000000000402f59 in parseArgs (h=0x6f6010, argc=2, argv=0x7fffffffdc20) at ../../../../source/tx.c:558
    #90x0000000000401df2 in main (argc=2, argv=0x7fffffffdc20) at ../../../../source/tx.c:1631
    (gdb)
    --- cut ---
    
    A similar Microsoft Edge renderer process crash (but in a slightly different code path) is also shown below:
    
    --- cut ---
    (50d4.f24): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    DWrite!handleBlend+0xc1:
    00007ffb`29e68f5d 4439a4cb28030000 cmp dword ptr [rbx+rcx*8+328h],r12d ds:0000016e`de978c30=????????
    0:039> ? rbx
    Evaluate expression: 1532035423952 = 00000164`b46d5ed0
    0:039> ? rcx
    Evaluate expression: 5457134919 = 00000001`45454547
    0:039> k
     # Child-SPRetAddr Call Site
    00 00000021`5eeea990 00007ffb`29e6b2e3 DWrite!handleBlend+0xc1
    01 00000021`5eeea9d0 00007ffb`29e6c41e DWrite!readDICT+0xf67
    02 00000021`5eeeaa30 00007ffb`29e6bc33 DWrite!readPrivate+0x3a
    03 00000021`5eeeaa60 00007ffb`29e6ddf4 DWrite!readFDArray+0xcb
    04 00000021`5eeeaa90 00007ffb`29e621e7 DWrite!cfrBegFont+0x548
    05 00000021`5eeeb320 00007ffb`29df157a DWrite!AdobeCFF2Snapshot+0x10f
    06 00000021`5eeeb820 00007ffb`29df0729 DWrite!FontInstancer::InstanceCffTable+0x212
    07 00000021`5eeeba00 00007ffb`29df039a DWrite!FontInstancer::CreateInstanceInternal+0x249
    08 00000021`5eeebc20 00007ffb`29dd5a4e DWrite!FontInstancer::CreateInstance+0x192
    09 00000021`5eeebf80 00007ffb`34eb61ab DWrite!DWriteFontFace::CreateInstancedStream+0x9e
    0a 00000021`5eeec010 00007ffb`34ea9148 d2d1!dxc::TextConvertor::InstanceFontResources+0x19f
    0b 00000021`5eeec130 00007ffb`0f8b50f4 d2d1!dxc::CXpsPrintControl::Close+0xc8
    0c 00000021`5eeec180 00007ffb`0f88fcb0 edgehtml!CDXPrintControl::Close+0x44
    0d 00000021`5eeec1d0 00007ffb`0f8947ad edgehtml!CTemplatePrinter::EndPrintD2D+0x5c
    0e 00000021`5eeec200 00007ffb`0f76b515 edgehtml!CPrintManagerTemplatePrinter::endPrint+0x2d
    0f 00000021`5eeec230 00007ffb`0f3c9175 edgehtml!CFastDOM::CMSPrintManagerTemplatePrinter::Trampoline_endPrint+0x45
    10 00000021`5eeec270 00007ffa`f02e68f1 edgehtml!CFastDOM::CMSPrintManagerTemplatePrinter::Profiler_endPrint+0x25
    --- cut ---
    
    -----=====[ References ]=====-----
    
    [1] https://blog.typekit.com/2014/09/19/new-from-adobe-type-open-sourced-font-development-tools/
    [2] https://github.com/adobe-type-tools/afdko
    [3] https://docs.microsoft.com/en-us/windows/desktop/directwrite/direct-write-portal
    [4] https://medium.com/variable-fonts/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369
    
    
    Proof of Concept:
    https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/47099.zip