CVE-2010-2883栈溢出漏洞

CVE-2010-2883是Adobe Reader和Acrobat中的CoolType.dll库在解析字体文件SING表中的uniqueName项时存在的栈溢出漏洞，用户受骗打开了特制的PDF就有可能导致执行任意恶意代码

操作系统： windows xp

虚拟机：VMware

调试器：IDA，OD

漏洞软件：Adobe Reader9.3.4

我调试的环境可能有所偏差，所以一开始定位无法直接跳到0x0803DD74下断点，也无法在cmd插件中用bp 0x0803DD74实现，这里给也遇到的这个问题的同学也给两个解决方法，一是先下断点在strcat，然后函数返回后再在0x0803DD74下断点，重新加载，二是直接用bpx 0x0803DD74，两者的区别是 bp 断是直接把入口改成CC，bpx 是哪里调用的函数，就哪里CC，即前者在这一函数的入口处下断点，后者在所有如call xxxx的代码处下断点。

从此往下分析

在这里调用的函数0x8021B06，实际上处理ecx中的内容，这一点可以直接从ida中看，也可以在这里跟进去，那ecx的是什么呢？由于前面传递参数时使用了两个显式参数（ecx在这里是隐式参数，显式参数直接放在栈里了）中提示SING字符串，那我们就怀疑是在处理sing表了。

查看官方文档可知在pdf中支持的一种Font类型是TrueType（简称ttf），在此字体文件中，从0字节偏移的位置开始有一个表目录，其第一个字段sfnt version是用来表明所用ttf格式版本的，对于1.0版本的TTF字体文件开头要用0x00010000来表示版本。于是我们在数据面板跟随一下ecx中的地址内的内存地址中存储着的值。

发现果然是0x10000的版本号，所以ecx保存的是SING表的入口指针。继续往下来到0x0803dd85的位置，这里明显是在判断0x0a49da6c这个数据段是否为空。那这些数据又是什么呢？

有了前面的SING，推测是和SING相关的数据。了解到ttf格式中的存有TableEntry的数据结构的，而SING正是其中一项。

typedef struct_SING
{
    char tag[4]     //标记->SING
    ULONG checkSum  //校验和->0xD9BCCBB5
    ULONG offset    //相对文件的偏移->011C
    ULONG length    //数据长度->0x1DDF
}

据此，推测那应该是在处理SING的具体内容，为了验证，我们需要找到SING项，得到offset，然后找到文件内容后与OD中0xa49da64的数据做对比。这里我们使用PdfStreamDumper提取寻找后发现确实是在判断SING的内容是否为空，接下来经过提取版本号后我们跳转到0x0803ddc0。

之前在IDA中可能不确定具体strcat用的是哪些数据，在这里可以进一步明确，采用的是从uniqueName开始往后的内容。（具体参照SING数据结构）

那接下去很明显的就是strcat（&ebp，uniqueName~xxxx）的操作，那就是说我们uniqueName开始往后的数据将覆盖从0x12e4d8往后的数据，从而可以控制返回地址。

可以看到程序会回到icucnv36.dll内的一个地址。定位该文件并用010editor查看后该文件后发现 IMAGE_NT_HEADERS NtHeaderIMAGE_OPTIONAL_HEADER中的IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE 的值为0，也就是说这个模块没有开启ASLR。

继续执行下去看到0x0808b308处调用icucnv36.dll的内容，跟进去看。

发现是gadget，返回后又是个gadget

第二个gadget我们返回的地址是0x0c0c0c0c，执行后栈内明显出现了不寻常的数据，一看就是早就在文档里构造好的各种gadget地址。

继续执行下去就是漏洞利用的内容了，主要是用ROP执行CreatFileA，CreateFileMapping，MapViewofFile和memcpy（其实看到这就明白是通过复制shellcode到rwx段的操作）通过其中CreatFileA创建了iso88591的文件，再用CreateFileMapping创建文件内存映射，而MapViewofFile是将文件内存映射到程序内存的函数，并返回地址给memcpy好将shellcode复制到无DEP保护的区域。

cve-2010-3333 Microsoft RTF栈溢出漏洞

问题是在OpenXML文件格式转换器处理RTF中的“pFragments”属性的时候存在栈溢出。