Oracle Java Runtime Environment – Heap Corruption During TTF font Rendering in sc_FindExtrema4

  • 作者: Google Security Research
    日期: 2019-04-17
  • 类别:
    平台:
  • 来源:https://www.exploit-db.com/exploits/46722/
  • A heap corruption was observed in Oracle Java Runtime Environment version 8u202 (latest at the time of this writing) while fuzz-testing the processing of TrueType, implemented in a proprietary t2k library. It manifests itself in the form of the following (or similar) crash:
    
    --- cut ---
    $ bin/java -cp . DisplaySfntFont test.ttf
    Iteration (0,0)
    *** Error in `bin/java': munmap_chunk(): invalid pointer: 0x00007f5cf82a6490 ***
    ======= Backtrace: =========
    /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f5cfd492bcb]
    /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f5cfd498f96]
    jre/8u202/lib/amd64/libt2k.so(+0x5443d)[0x7f5cd563343d]
    jre/8u202/lib/amd64/libt2k.so(+0x47b95)[0x7f5cd5626b95]
    jre/8u202/lib/amd64/libt2k.so(Java_sun_font_T2KFontScaler_getGlyphImageNative+0xe5)[0x7f5cd560fa25]
    [0x7f5ce83a06c7]
    ======= Memory map: ========
    00400000-00401000 r-xp 00000000 fe:01 20840680 jre/8u202/bin/java
    00600000-00601000 r--p 00000000 fe:01 20840680 jre/8u202/bin/java
    00601000-00602000 rw-p 00001000 fe:01 20840680 jre/8u202/bin/java
    02573000-02594000 rw-p 00000000 00:00 0[heap]
    3d1a00000-3fba00000 rw-p 00000000 00:00 0
    3fba00000-670900000 ---p 00000000 00:00 0
    670900000-685900000 rw-p 00000000 00:00 0
    685900000-7c0000000 ---p 00000000 00:00 0
    7c0000000-7c00c0000 rw-p 00000000 00:00 0
    7c00c0000-800000000 ---p 00000000 00:00 0
    [...]
    Aborted
    --- cut ---
    
    The crash reproduces on both Windows and Linux platforms. On Linux, it can be also triggered under Valgrind (many out-of-bounds reads and writes in sc_FindExtrema4 were ommitted in the log below):
    
    --- cut ---
    $ valgrind bin/java -cp . DisplaySfntFont test.ttf
    [...]
    ==211051== Invalid write of size 8
    ==211051==at 0x415B30EE: sc_FindExtrema4 (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x4159A402: fs_FindBitMapSize4 (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x415D3247: MakeBWBits (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x415CAE44: T2K_RenderGlyphInternal (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x415CB3CA: T2K_RenderGlyph (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x415B4A24: Java_sun_font_T2KFontScaler_getGlyphImageNative (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x7B8D6C6: ???
    ==211051==by 0x7B7CDCF: ???
    ==211051==by 0x7B7CDCF: ???
    ==211051==by 0x7B7CDCF: ???
    ==211051==by 0x7B7D2BC: ???
    ==211051==by 0x7B7CA8F: ???
    ==211051==Address 0x3f6f1d38 is 19,160 bytes inside a block of size 19,166 alloc'd
    ==211051==at 0x4C2BBEF: malloc (vg_replace_malloc.c:299)
    ==211051==by 0x415D84A4: tsi_AllocMem (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x415B2664: sc_FindExtrema4 (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x4159A402: fs_FindBitMapSize4 (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x415D3247: MakeBWBits (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x415CAE44: T2K_RenderGlyphInternal (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x415CB3CA: T2K_RenderGlyph (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x415B4A24: Java_sun_font_T2KFontScaler_getGlyphImageNative (in jre/8u202/lib/amd64/libt2k.so)
    ==211051==by 0x7B8D6C6: ???
    ==211051==by 0x7B7CDCF: ???
    ==211051==by 0x7B7CDCF: ???
    ==211051==by 0x7B7CDCF: ???
    [...]
    --- cut ---
    
    or with AFL's libdislocator under gdb:
    
    --- cut ---
    Thread 2 "java" received signal SIGSEGV, Segmentation fault.
    [----------------------------------registers-----------------------------------]
    [...]
    R11: 0x7fffb5d89e82 --> 0x0
    [...]
    EFLAGS: 0x10293 (CARRY parity ADJUST zero SIGN trap INTERRUPT direction overflow)
    [-------------------------------------code-------------------------------------]
     0x7fffb63be972 <sc_FindExtrema4+914>:lear11,[r12+r9*2]
     0x7fffb63be976 <sc_FindExtrema4+918>:je 0x7fffb63bea30 <sc_FindExtrema4+1104>
     0x7fffb63be97c <sc_FindExtrema4+924>:lear9d,[r8-0x1]
    => 0x7fffb63be980 <sc_FindExtrema4+928>:addWORD PTR [r11],0x1
     0x7fffb63be985 <sc_FindExtrema4+933>:test r9d,r9d
     0x7fffb63be988 <sc_FindExtrema4+936>:je 0x7fffb63bea30 <sc_FindExtrema4+1104>
     0x7fffb63be98e <sc_FindExtrema4+942>:addWORD PTR [r11+0x2],0x1
     0x7fffb63be994 <sc_FindExtrema4+948>:cmpr8d,0x2
    [...]
    --- cut ---
    
    On Windows, the crash also reliably reproduces with PageHeap enabled for the java.exe process:
    
    --- cut ---
    (244c.1660): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    *** ERROR: Symbol file could not be found.Defaulted to export symbols for C:\Program Files\Java\jre1.8.0_202\bin\server\jvm.dll - 
    jvm+0x8598:
    00000000`61158598 c7040801000000mov dword ptr [rax+rcx],1 ds:00000000`05860280=00000001
    --- cut ---
    
    In total, we have encountered crashes in the t2k!sc_FindExtrema4 function in three different locations, in two cases while adding 1 to an invalid memory location, and in one case while adding 2 to an out-of-bounds address. Attached with this report are three mutated testcases (one for each crashing code location), and a simple Java program used to reproduce the vulnerability by loading TrueType fonts specified through a command-line parameter.
    
    
    Proof of Concept:
    https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46722.zip