-
-
[原创]对Cve-2011-0978稳定利用的分析
-
2012-2-1 20:40
-
在微软发布的ms11-021中，包含了两个CVE编号- Cve-2011-0104、Cve-2011-0978。网上常见对Cve-2011-0104的分析（http://sebug.net/vuldb/ssvid-23168），demo文件也能够比较容易地找到。但是， 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 ：暂时并没有找到合适的地址，没有成功利用… 接下来就看你的了
在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）或者其他值的。调试的时候，就以这个作为例子，试了一下。 |
|
|
|
|
|
|
|
|
|
