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

!

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
! [](/Article/UploadPic/2019-7/2019725232536349. png)
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
! [](/Article/UploadPic/2019-7/2019725232536854. png)
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
! [](/Article/UploadPic/2019-7/2019725232537515. png)
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
! [](/Article/UploadPic/2019-7/2019725232537460. png)
Continue to si
! [](/Article/UploadPic/2019-7/2019725232537914. png)
At this time
! [](/Article/UploadPic/2019-7/2019725232537228. png)
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