0X00 漏洞描述
CVE-2012-0774是Adobe Acrobat和Reader在True Type Font (TTF)处理的实现上存在整数溢出漏洞,攻击者可利用此漏洞执行任意代码。
0X01 分析环境
目标系统:Windows 7 32位
调试器:WinDbg
反汇编器:IDA Pro
漏洞软件:AdbeRdr940_zh_CN.exe
0X02 基本信息
我们用pdfstreamdump工具打开poc文件 发现第五项里面嵌有TrueType字体
第五项又间接引用第六项来描述字体
接下来在对象16右击 选择“Save Decompressed Stream”文件导出字体文件
接下来用windbg附加AcroRd32.exe 然后打开poc 看到报错
查看内存属性 目标地址Protect属性是PAGE_EXECUTE_READ是只读的 向只读内存写入数据 触发崩溃
查看栈回溯
用IDA查看CoolType.dll+0x7978(在IDA中是0x8007935函数)
定位函数的基地址为0x08007935 这里我们记下偏移为7935
然后交叉引用查看上一个调用的函数
这是个函数数组 其中ecx是虚拟指令索引号 用于查找对应虚拟指令的处理函数
回到windbg重新运行 给这个函数下断点
加载poc后函数断在断点处 看到ecx=0x26 即虚拟索引号为0x26 该虚拟索引号对应的虚拟指令为MINDEX 该指令的功能是弹出栈值作为栈上的索引号 将索引到的元素值移到栈顶 原来在元素值上方的栈数据则各自往后移到4字节
在IDA中分析该函数 造成整数溢出的关键点是0x40000001这个值 是由虚拟指针操作实现的
为了动态追踪虚拟指令的实际操作 我们记录执行前后vm_esp的值及虚拟指令 以”B0 01”虚拟指令为例 他将1压入vm_esp 我们跟进pushb(B0)虚拟指令处理函数 看被压入的1在哪个位置 该位置就是vm_esp 我们给漏洞函数的虚拟指令ecx下条件断点
运行后断下 跟进虚拟指令的处理函数 单步运行后发现函数返回前此时vm_esp=[[68496240]-4]==0x01
接下来回到调用漏洞函数处 记录执行前后vm_esp的值 设置条件断点记录 虚拟索引号
然后可以看到执行后的日志信息如下
用010editor打开ttf字体文件 搜索60 26可以看到触发漏洞的虚拟指令
根据日志文件可知生成的0x40000001是怎么来的 这里就看泉哥的书上的解释吧
0X03 补丁分析
这次无法用BunDiff进行补丁比较 因为漏洞版本中的漏洞函数和补丁中的修复函数在BinDiff里面无法匹配 也就无法比较了 先用虚拟指令定位到函数数组 再通过偏移0x26*4找到MINDEX虚拟指令处理函数 用IDA加载修复后的CoolType.dll 定位到函数数组后 看到修复后的函数主要对虚拟栈上的数据差值和0xFFFFFFC相与运算后的值进行检测 然后防止整数溢出
0X04 经验总结
这次分析整数溢出的例子 调试过程中走了很多弯路 认真分析后觉得是自己不够细节 不够认真的识别到书上的每一点。
通过条件断点可以得到很多调试过程中的信息 得到我们目标值是如何来的 好好利用条件断点 可以使我们更好的调试分析漏洞
不理解的点是无法通过BinDiff分析的补丁是如何通过定位函数数组然后偏移得来的?还有就是以后碰到无法匹配的补丁该如何去做?