Adobe Acrobat和Reader都是美国Adobe公司开发的非常流行的PDF文件阅读器。
基于Window和Mac OS X的Adobe Reader和Acrobat 9.4之前的9.x版本，8.2.5之前的8.x版本的CoolType.dll中存在基于栈的缓冲区溢出漏洞。远程攻击者可借助带有TTF字体 Smart INdependent Glyphlets (SING)表格中超长字段的PDF文件执行任意代码或者导致拒绝服务（应用程序崩溃）。
泉哥是上来直接就定位到漏洞函数了，我感觉这样有点“上帝视角”了，对于我们来说可能定位漏洞关键点还是要用调试去说话的。所以这里我是用poc去根据调试推出的漏洞崩溃点。没有去搜索SING的处理函数。打开poc后，crash信息如下。
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=4a8a08c6 ebx=0012e584 ecx=4a8a08c6 edx=07016aac esi=0012e584 edi=0ab37ed0
eip=070013b1 esp=0012e3d4 ebp=0012e454 iopl= nv up ei pl nz na pe nc
cs=001b ss= ds= es= fs=003b gs= efl=
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files\Adobe\Reader 8.0\Reader\BIB.dll -
BIB+0x13b1:
070013b1 ff491c dec dword ptr [ecx+1Ch] ds::4a8a08e2=????????
通过对此处下断点可以发现这里是一个被频繁调用的地方，所以我们不下中断的断点，改用条件记录断点，记录的内容是 dc esp l1，即记录一下是那个函数调用的它，之所以这样是担心栈溢出会搞坏回溯信息。等到crash后再来看下栈回溯。
:> kp
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
002cddc0 BIB+0x1400
002cde44 da55d18a CoolType+0x1261
002cde48 4a82a714 0xda55d18a
002cde4c 0c0c0c0c 0x4a82a714
002cde50 df6f2606 0xc0c0c0c
002cde54 2787e915 0xdf6f2606
002cde58 1129d97f 0x2787e915
002cde5c 9b7ba307 0x1129d97f
002cde60 f9d13efb 0x9b7ba307
002cde64 f977c1f6 0xf9d13efb
002cde68 dc7bf416 0xf977c1f6
002cde6c de535b4a 0xdc7bf416
002cde70 cd8e6928 0xde535b4a
002cde74 57e3bf18 0xcd8e6928
002cde78 c834489b 0x57e3bf18
002cde7c 2c6dae69 0xc834489b
002cde80 e89428e8 0x2c6dae69
002cde84 e1c8adfd 0xe89428e8
002cde88 2a25abf1 0xe1c8adfd
002cde8c d7900451 0x2a25abf1
根据上面的信息可以看到其实这个时候的栈已经被破坏的很厉害了，比如da55d18a明显是一个错误的地址。记录断点的值和栈回溯的结果是一样的，确实是67371261这个位置调用了crash函数，而这个地址也是正好在CoolType模块中，符合漏洞的描述。
070013f2 push ebp
070013f3 8bec mov ebp,esp
070013f5 push ecx
070013f6 push ecx
070013f7 8d411c lea eax,[ecx+1Ch]
070013fa 8945f8 mov dword ptr [ebp-],eax
070013fd 8b45f8 mov eax,dword ptr [ebp-]
f0ff08 lock dec dword ptr [eax] ds::4a8a08e2=????????
如上是BIB.dll崩溃函数中的反汇编，我们可以看出之所以会发生crash是因为ecx的值有问题。为此我们在BIB的上层函数中来追踪ecx的值的来源。最后发现了ecx是由一条pop ecx;指令来的，那么我们只需要看下栈里的数据是谁写的就可以知道了是哪里出现的问题了。
这么做是基于一个基本的事实：
- 这是一个栈溢出
- ecx值来自于栈中
- ecx值导致异常
- 由1、2、3推导出ecx的值是溢出写的数据
那么我们就来调试着看看
在上面那个地址下断后，单步下来却发现原来调用的并不是这个crash函数而是经过了一个jmp，如下，但是我们不管call的是谁，总之对取值的栈下断就可以。
eax=4a8a08c6 ebx=0012e634 ecx=0012e504 edx=07018bfc esi=0012e634 edi=07813f3c
eip=07005caf esp=0012e484 ebp=0012e504 iopl= nv up ei pl nz na pe nc
cs=001b ss= ds= es= fs=003b gs= efl=
BIB!BIBInitialize4+0x1efc:
07005caf 8b4c2404 mov ecx,dword ptr [esp+] ss::0012e488=4a8a08c6
:> p
eax=4a8a08c6 ebx=0012e634 ecx=4a8a08c6 edx=07018bfc esi=0012e634 edi=07813f3c
eip=07005cb3 esp=0012e484 ebp=0012e504 iopl= nv up ei pl nz na pe nc
cs=001b ss= ds= es= fs=003b gs= efl=
BIB!BIBInitialize4+0x1f00:
07005cb3 e93ab7ffff jmp BIB+0x13f2 (070013f2)
我们找到了要断的栈地址，如下所示
:> t
eax=4a8a08c6 ebx=0012e634 ecx=0012e504 edx=07018bfc esi=0012e634 edi=08a23f3c
eip=07005caf esp=0012e484 ebp=0012e504 iopl= nv up ei pl nz na pe nc
cs=001b ss= ds= es= fs=003b gs= efl=
BIB!BIBInitialize4+0x1efc:
07005caf 8b4c2404 mov ecx,dword ptr [esp+] ss::0012e488=4a8a08c6
:> dd esp
0012e484 4a8a08c6 0012e744
0012e494 0803dbb3 0012e504 f6e349d1
0012e4a4 0012e6fc 08a21ea0 08a21d20
0012e4b4 0ab25000 0ab24ffc 0012e4ec 781474d8
0012e4c4 08a21d20 0ab25000 000001fc
0012e4d4 0012e72c 0012e6fc 0012e744 08a22158
0012e4e4 00001ddf 00a30a0f
0012e4f4 0012e49c 0012e738 0818436d
:> ? esp+
Evaluate expression: = 0012e488
我们对这个地方下写入记录断点
ba w 1 0800125b ".echo 写入：;r eip;g"
得到如下结果
eip=009ffee5
eip=009ffd45
eip=070013f6
eip=00e62c2e
eip=00e62ce6
eip=08047fff
eip=08047fff
eip=08047fff
eip=08047fff
eip=08047fff
eip=08047fff
eip=08047fff
eip=08047fff
eip=
eip=781473a6
eip=
eip=08021a28
eip=
eip=0800125b
看一下0800125b地址结果发现居然是一个push eax，在IDA中跟入这个地址，原来这个eax也是来自于上层的ecx。那么我们怎么知道是谁调用了sub_8001243呢？
.text: sub_8001243 proc near ; CODE XREF: sub_8001952+1Bp
.text: ; sub_8016AF9+2F1p ...
.text:
.text: arg_0 = dword ptr
.text:
.text: push esi
.text: push edi
.text: push [esp++arg_0]
.text: mov esi, ecx
.text:0800124B call dword_8231220
.text: mov edi, eax
.text: mov eax, [esi]
.text: test eax, eax
.text: pop ecx
.text: jz short loc_8001262
.text:0800125A push eax
.text:0800125B call dword_8231224
对下条件记录断点，bp 08001243 "dd esp l1;g"。结果得到的结果是0803DBAE这个地址的调用。我们在IDA中看一下，果然0803DBAE就是SING的处理函数。strcat函数造成了栈的溢出，致使实参被覆盖，而ecx正是来自于这个实参，导致了子函数调用的crash。我们对strcat下断来看下到底是怎么一回事。
:> dc esp
0012e494 0012e504 034097d0 1bcfe9a8 ......@.........
0012e4a4 0012e6fc 1bcfe87c ...........|...
0012e4b4 0823a650 0012e6fc 0012e4b0 P.#.............
0012e4c4 0012e560 0817516c `...lQ.........
0012e4d4 0012e72c 0012e6fc 0012e744 034097c0 ,.......D.....@.
0012e4e4 00001ddf 00e50a0f ................
0012e4f4 0012e49c 0012e738 0818436d .......mC......
0012e504 0012e500 0012e6dc 1bcfe9c0 ................
:> ? ebp
Evaluate expression: = 0012e504
原来是试图往一个0字节空间的栈区域复制0.0。。。这个肯定会溢出。再来看下源字符串是什么玩意。因为漏洞描述中已经给出了是内嵌的TTF的问题，那么就直接用pdfstreamdumper把ttf文件dump出来
根据调试的结果搜索一下
:> r
eax=0012e504 ebx=0012e634 ecx= edx=0823a650 esi= edi=0012e744
eip=0803dba1 esp=0012e494 ebp=0012e504 iopl= nv up ei pl nz na po nc
cs=001b ss= ds= es= fs=003b gs= efl=
CoolType+0x3dba1:
0803dba1 e802391300 call CoolType!CTCleanup+0x231d3 (081714a8)
:> dd esp l2
0012e494 0012e504 034097d0
:> db 034097d0
034097d0 e6 ab 8b e7- a7 4a 0c 0c 0c 0c .fQ..S.....J....
034097e0 0a 7a 8c e7 -3f dc a9 a1 e1 cf cb ...7z..?.......
034097f0 7b c5 8b 8c f7 5f-3d c8 2f d3 1e {x....._=./.@..
0b 5f 6d 0a-1d 5b 9e 6c 2e f6 6a eb $.E_dma..[.l..j.
fb 3e cc 1a 2b-d3 1b fe ed da ..>.e..+..h..c..
ca 9a 6b b3-cc c7 d5 d9 2a 2c 0f .A(..k..Q...*,.
ef b4 4c 5e-cd b9 f3 ce a.Q..4L^...&..qH
1f 4f ad 5d -b8 ba 1c e7 7d .%7O.(]..S.W...}
搞定！