fuzz CVE-2019-1118-vulnerability warning-the black bar safety net

2019-07-25T00:00:00
ID MYHACK58:62201995213
Type myhack58
Reporter 佚名
Modified 2019-07-25T00:00:00

Description

!

This article is to analysis about CVE-2019-1118, the problem is stack corruption in the OpenType font handling due to negative cubeStackDepth

Vulnerability reproduction Build environment, simple to reproduce it git clone https://github.com/adobe-type-tools/afdko cd afdko git checkout 2.8.8 cd c bash buildalllinux.sh debug According to the poc test ! Can be found wrong, but is afdko capture it. In this case, the focus position is set a bit off the point, and then look at First Test do_blend_cube. otf pwndbg> b t2cstr. c:1057 Breakpoint 1 at 0x466af2: file../../../../../source/t2cstr/t2cstr. c, line 1057. pwndbg> run-cff do_blend_cube. otf Look at the effect ! In conjunction with the disassembly code to see, the effect may be better . text:0000000000466AF2 mov esi, [rbp+nBlends] . text:0000000000466AF5 mov rdi, [rbp+h] . text:0000000000466AF9 add rdi, 32D60h . text:0000000000466B00 mov rax, [rbp+h] ; h . text:0000000000466B04 movsxd rax, dword ptr [rax+32D44h]; obtain the index . text:0000000000466B0B imul rax, 1920h; cube size . text:0000000000466B12 add rdi, rax . text:0000000000466B15 imul esi, [rdi+10h] . text:0000000000466B19 mov [rbp+nElements], esi Can be found in the h->cube array values by multiplication to achieve the, when the index is -1 i.e. h->cubeStackDepth==-1, imul rax, 1920h ==> imul 0xffffffff, 1920h cube arrays each of size: sizeof(h->cube[0]) == 0x1920 Then transform it ((struct cube)h->cube)-1 Equivalent to the h->cube pointer is moved forward an array value, i.e. 0x1920 bytes Then look at the struct _t2cCtx the size of the ! To move forward, but((struct cube)h->cube)-1 position or in the _t2cCtx structure of the body, verify the Continue stepping to this, the index is worth a ! Continue to si ! At this time ! Can be found 0x9d3f8 > 0x31880, verify and indeed also in the structure of the body. Thus, even if the h->cubeStackDepth==-1 does not cause a memory access error, the maximum of which is the analysis error, is afkdo capture also is not surprising. Our results also indeed is such a But PJ0 example given, there is a called the redzone patch the operation, so after the patch after that will appear user-after-poison of error. Like this ==96052==ERROR: AddressSanitizer: use-after-poison on address 0x7ffea1a88890 at pc 0x00000069e6e2 bp 0x7ffea1a46bb0 sp 0x7ffea1a46ba8 READ of size 4 at 0x7ffea1a88890 thread T0

0 0x69e6e1 in do_blend_cube afdko/c/public/lib/source/t2cstr/t2cstr. c:1057:58

1 0x6855fd in t2Decode afdko/c/public/lib/source/t2cstr/t2cstr. c:1857:38

2 0x670a5b in t2cParse afdko/c/public/lib/source/t2cstr/t2cstr. c:2591:18

3 0x542960 in readGlyph afdko/c/public/lib/source/cffread/cffread. c:2927:14

4 0x541c32 in cfrIterateGlyphs afdko/c/public/lib/source/cffread/cffread. c:2966:9

5 0x509662 in cfrReadFont afdko/c/tx/source/tx. c:151:18

6 0x508cc3 in doFile afdko/c/tx/source/tx. c:429:17

[1] [2] [3] next