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正是其中一项。

1
2
3
4
5
6
7
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”属性的时候存在栈溢出。