【漏洞分析】Adobe Acrobat和Reader整数溢出漏洞(CVE-2012-0774)

0x00 前言

总体来说坑不多，但是对于windbg没有watchpoint功能这一点，真的是很坑。

0x01 简介

Adobe Acrobat和Reader在True Type Font (TTF)处理的实现上存在整数溢出漏洞，攻击者可利用此漏洞执行任意代码。
受影响软件版本：
Adobe Reader 9.4.[0-5]
Adobe Reader 9.3.[0-4]
Adobe Reader 9.2
Adobe Reader 9.1.[0-3]
更多详情，请参考【bid-52951】

0x02 漏洞原理

True Type Font字体文件中使用预定义的指令集控制字体hinting，当执行到MINDEX指令时，被操作的数组长度n溢出成超大值，导致数组写越界。

MINDEX指令：对size为n的数组进行循环左移一位。

0x03 漏洞分析

运行环境：

	版本
操作系统	windows 7 sp1 32bit
调试器	windbg 6.12 32 bit
漏洞软件	AdbeRdr940_zh_CN.exe
文件查看器	010editor
反编译工具	IDA

poc 如下图所示，问题数值n是由多个值经过计算得到的，无法在poc文件中直接看到，这里展示的计算前的输入数据。

需要说明的是漏洞出发的关键数据猜测是fuzz出来的，所以，010editor在解析到SimpleGlyph[10]的数据时报异常，没有显示出来。途中蓝色选中的数据就在这片黑色领域中。
报错信息如下：

windbg不用开page heap，因为不是堆溢出。运行poc，查看报错：

eax=65ee622c ebx=00000000 ecx=65eef000 edx=3fffdc8a esi=65eef004 edi=00004141
eip=65cb79ce esp=0016cd9c ebp=0016ce30 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Adobe\Reader 9.0\Reader\CoolType.dll -
CoolType+0x79ce:
65cb79ce 8919            mov     dword ptr [ecx],ebx  ds:0023:65eef000=00000000

写入的目标地址是65eef000

查看内存属性

0:000> !address 65eef000
Failed to map Heaps (error 80004005)
Usage:                  Image
Allocation Base:        65cb0000
Base Address:           65eef000
End Address:            65f0f000
Region Size:            00020000
Type:                   01000000    MEM_IMAGE
State:                  00001000    MEM_COMMIT
Protect:                00000002    PAGE_READONLY
More info:              lmv m CoolType
More info:              !lmi CoolType
More info:              ln 0x65eef000

目标地址Protect属性是PAGE_READONLY，表示只读。向只读地址写入数据，估计是写越界了。

回溯函数调用栈

0:000> kb
ChildEBP RetAddr  Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0016ce30 65cbade0 0c6fcbb8 65ee5a28 0c6fce16 CoolType+0x79ce
0016ce60 65cb4e44 0c6fcbb8 65ee5a28 0c6fce16 CoolType+0xade0
0016cea0 65cb587c 0c6fca38 0c6fcbb8 65ee5a28 CoolType+0x4e44
0016cf44 65cb5c36 05eb6aa4 05eb6bfc 05eb6bb4 CoolType+0x587c
0016cfa0 65cb5cc8 05eb6aa4 05eb6bfc 05eb6bb4 CoolType+0x5c36
0016cff0 65cb3a69 05eb6aa4 05eb6bfc 05eb6bb4 CoolType+0x5cc8
0016d058 65cb3b36 0016d15c 0016d08c 00000001 CoolType+0x3a69
0016d1b8 65ccbb43 098df390 00000000 0016d204 CoolType+0x3b36
00000000 00000000 00000000 00000000 00000000 CoolType+0x1bb43

查看当前函数 CoolType+0x79ce

int __cdecl sub_800798B(int a1)
{unsigned int v1; // edi@2_DWORD *v2; // eax@3int v3; // edx@3unsigned int v4; // ecx@3int v5; // edi@5int result; // eax@8if ( (unsigned int)(dword_82323E0 - 4) < *(_DWORD *)dword_82323EC|| (v1 = *(_DWORD *)(dword_82323EC + 340), dword_82323E0 - 4 >= v1)|| (v2 = (_DWORD *)(dword_82323E0 - 4),v3 = *(_DWORD *)(dword_82323E0 - 4),v4 = dword_82323E0 - 4 - 4 * *(_DWORD *)(dword_82323E0 - 4),v4 < *(_DWORD *)dword_82323EC)|| v4 >= v1 ){result = dword_8232438;dword_8232434 = 4368;}else{v5 = *(_DWORD *)v4;if ( v3 > 0 ){do{--v3;*(_DWORD *)v4 = *(_DWORD *)(v4 + 4); //在此处崩溃v4 += 4;}while ( v3 );--v2;}*v2 = v5;dword_82323E0 = (int)(v2 + 1);result = a1;}return result;
}

该函数是MINDEX指令的实现-size为n的数组做循环左移一位，在内存中找数组边界时，n也就是代码中的v3溢出成超大值，导致写越界。
sub_800798B函数之前已经写了一篇比较详细文章做说明【传送门】。

65cb798b a1e023ee65      mov     eax,dword ptr [CoolType!CTCleanup+0xe3ad6 (65ee23e0)] // 函数入口，这里下断点
65cb7990 8b0dec23ee65    mov     ecx,dword ptr [CoolType!CTCleanup+0xe3ae2 (65ee23ec)]
65cb7996 53              push    ebx
65cb7997 56              push    esi
65cb7998 8b31            mov     esi,dword ptr [ecx]
65cb799a 8d50fc          lea     edx,[eax-4]
65cb799d 3bd6            cmp     edx,esi
65cb799f 57              push    edi
65cb79a0 7245            jb      CoolType+0x79e7 (65cb79e7)
65cb79a2 8bb954010000    mov     edi,dword ptr [ecx+154h]
65cb79a8 3bd7            cmp     edx,edi
65cb79aa 733b            jae     CoolType+0x79e7 (65cb79e7)
65cb79ac 83c0fc          add     eax,0FFFFFFFCh
65cb79af 8b10            mov     edx,dword ptr [eax]
65cb79b1 8bda            mov     ebx,edx
65cb79b3 c1e302          shl     ebx,2
65cb79b6 8bc8            mov     ecx,eax
65cb79b8 2bcb            sub     ecx,ebx
65cb79ba 3bce            cmp     ecx,esi
65cb79bc 7229            jb      CoolType+0x79e7 (65cb79e7)
65cb79be 3bcf            cmp     ecx,edi
65cb79c0 7325            jae     CoolType+0x79e7 (65cb79e7)
65cb79c2 85d2            test    edx,edx
65cb79c4 8b39            mov     edi,dword ptr [ecx]
65cb79c6 7e0f            jle     CoolType+0x79d7 (65cb79d7)
65cb79c8 4a              dec     edx //数组大小n自减，也就是反汇编中的v3自减操作
65cb79c9 8d7104          lea     esi,[ecx+4]
65cb79cc 8b1e            mov     ebx,dword ptr [esi]
65cb79ce 8919            mov     dword ptr [ecx],ebx  ds:0023:65eef000=00000000
65cb79d0 8bce            mov     ecx,esi
65cb79d2 75f4            jne     CoolType+0x79c8 (65cb79c8)
65cb79d4 83e804          sub     eax,4
65cb79d7 8938            mov     dword ptr [eax],edi
65cb79d9 83c004          add     eax,4
65cb79dc a3e023ee65      mov     dword ptr [CoolType!CTCleanup+0xe3ad6 (65ee23e0)],eax
65cb79e1 8b442410        mov     eax,dword ptr [esp+10h]
65cb79e5 eb0f            jmp     CoolType+0x79f6 (65cb79f6)

在函数入口出下断点

0:000>bp 65cb798b

可以看到这个值n在进入sub_800798B函数不久v3改变成0x40000001，并开始do-while循环，有人见过0x40000001这么大的数组吗？显然这是一个bug。

跟进v3变量，在存储地址65ee622c下写断点

0:000> ba w4 65ee622c

追踪到v3的值的计算过程
0x3FFF0003 + 0x7FFF + 0x7FFF = 0x40000001

根据这段输入定位到poc.pdf中的关键数据位置

41 41 41 41 41 41 00 03 00 00 00 40 42 41 02 7F FF 7F FF 63 60 41 04 FF E8 00 00 00 00 00 00 43 B0 01 61 42 43 78 41 02 7F FF 7F FF 60 60

0x04 小结

能初步定位问题出在glyf表，并通过官方文档理解这段数据的意义很重要；
windbg没有watchpoint，在观测65ee622c地址的数据变化时，只能靠人眼和记忆了，所以泉哥的分析用的Immunity Debugger；
这种数据是指令集的反汇编代码开始比较难看。在想llvm和jit是不是也会有这样的bug。

0x05 参考文献

http://pwdme.cc/2017/11/05/cve-2012-0774/
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM07/appendixA.html
https://docs.microsoft.com/en-us/typography/opentype/spec/tt_instructions
https://android.googlesource.com/platform/external/freetype/+/f720f0dbcf012d6c984dbbefa0875ef9840458c6/src/truetype/ttinterp.c