-
-
[原创]对Cve-2011-0978稳定利用的分析
-
发表于: 2012-2-1 20:40
-
在微软发布的ms11-021中，包含了两个CVE编号- Cve-2011-0104、Cve-2011-0978。网上常见对Cve-2011-0104的分析（33aK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4y4W2j5Y4g2Y4i4K6u0W2L8X3g2@1i4K6u0r3N6Y4g2D9k6r3u0Q4x3V1k6K6M7%4k6A6k6q4)9J5k6o6t1K6x3e0j5^5i4@1g2r3i4@1u0o6i4K6R3&6i4@1g2r3i4@1u0o6i4K6S2o6k6r3g2E0L8#2!0q4y4W2)9&6y4W2)9^5y4#2!0q4y4q4!0n7b7W2!0n7y4W2!0q4y4q4!0n7z5g2)9&6c8W2!0q4z5q4)9^5x3#2!0n7c8q4!0q4y4g2!0m8y4q4)9&6c8W2!0q4y4W2!0m8c8W2)9&6y4q4!0q4z5q4!0n7c8g2)9^5x3#2!0q4y4g2!0m8c8g2!0n7z5g2!0q4y4W2)9&6z5q4)9&6x3#2!0q4y4g2)9&6b7#2!0n7x3q4!0q4y4W2)9^5z5g2!0n7c8g2!0q4y4g2)9^5z5q4!0n7x3q4!0q4x3#2)9^5x3q4)9^5x3W2!0q4y4q4!0n7c8q4)9^5y4W2!0q4y4W2)9&6z5q4!0m8c8W2!0q4c8W2!0n7b7#2)9^5b7H3`.`. office 2007环境下却会自动修补数据，使得Cve-2011-0104不能触发。于是，找来Cve-2011-0978分析一番。
在office 2003环境下，需要用户打开第二个sheet才会触发漏洞，而在office 2007环境下自动就触发漏洞了。Instruder曾经写过一个分析的帖子（http://bbs.pediy.com/showthread.php?t=138428），看完之后应该对漏洞原因比较清楚了。要利用这个漏洞，修补ebx的值，使其不产生访问异常，然后函数流程将调用memmove。调用的结果有两种：
1、 覆盖函数返回地址。
2、 覆盖she链。
按照Instruder的说法，可能覆盖函数返回链成功的可能性比较大。
在文章中，作者在表格中填入”jjjjjjjjj”字符，载入excel后，excel已经把这些字符转换为unicode了，所以在文章的结尾，作者提出需要找到xx00xx00形式的跳转地址，来实现对溢出的利用。但是，我通过分析后觉得可以有以下改进：
直接对excel文件中的biffRecord记录进行填充，那么excel加载后对这部分填充数据不会做unicode编码，也就是说可以通过对文件字节的填充实现一个稳定的内存字节填充。这样就不存在不好找跳转地址的问题。（附件poc1中填A及填B部分）。
异常时内存有如下状态：
这里可以看到eax指向一个指针数组，数组中的地址指向一个unicode的字符串。
进过实验后发现eax指向的unicode字符串保存在文件的0xDC7处，经过研究后发现0xDC7处保存的是一个XLUnicodeRichExtendedstring结构。
进过对该结构的分析（微软给出的xls格式说明）。可以通过修改该结构的flag标记，使得加载后eax指向的值不被转换为unicode。另外，通过对cch字段的修改可以扩大指针数组元素指向的数据块的大小。（附件poc2中填D部分）
假设ebx能够被修改为0x00（文件0x39E7处），那么
mov eax,dword ptr [eax+ebx*4]
后eax指向的内存将能够被控制。但是经过对文件的调试分析后，发现这中利用的思路根本行不通。因为拷贝目的缓冲区的大小将根据cch的大小来分配。因此不可能实现对栈中邻近缓冲区的覆盖。
那么只有找到poc文件中某个定偏移地址，该偏移处的数据加载到内存后与eax指向数组有某种固定关系，这样才能够实现稳定利用了。
但是由于eax本身是在程序执行中动态分配地址，因此要找到这样一个固定偏移比较困难。
于是，对该漏洞的稳定利用陷入了僵局。套用instrude的一句话：
Ps ：暂时并没有找到合适的地址，没有成功利用… 接下来就看你的了
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
|
|
|
图咋没了
 能让字符不转换成unicode 不错哈 顶 |
|
|
|
|
|
|
|
|
|
|
|
楼上对我了解很深啊。我好像是过年没事详细看了一下这个东西。经你这么一说，原来我两年前就研究webDEViL牛放的东西了。
ebx的值取自文件偏移 0x39E7处，在poc文件中被修改为0xAAAA。这个值位于一个Biffgeneral记录中，作为数据存在，肯定是可以改为00（扩展后变成0xFFFF0000）或者其他值的。调试的时候，就以这个作为例子，试了一下。 |
|
|
|
|
|
|
|
|
|
