MS08

只看楼主 · 发表于 2014-7-15 15:30:55

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

您需要登录才可以下载或查看，没有帐号？注册

x

前段时间我一直都忙着精武门，今天才缓过口气来，回头看看很多文章都没读，今天统一整理了下。

关于这个漏洞，虽然我没分析，但是大家分析的够多了，炒作的也够多了，很多人都从里面获得了自己想要的东西。但是在浮躁过后，还是让我们静下心来看看这里面的东西。

首先是漏洞的原因：
Background
The bug was an invalid pointer dereference in MSHTML.DLL when the code handles data binding. It's important to point out that there is no heap corruption and there is no heap-based buffer overrun!

When data binding is used, IE creates an object which contains an array of data binding objects. In the code in question, when a data binding object is released, the array length is not correctly updated leading to a function call into freed memory.

The vulnerable code looks a little like this (by the way, the real array name is _aryPXfer, but I figured ArrayOfObjectsFromIE is a little more descriptive for people not in the Internet Explorer team.)

int MaxIdx = ArrayOfObjectsFromIE.Size()-1;

for (int i=0; i <= MaxIdx; i++) {

   if (!ArrayOfObjectsFromIE[i])

         continue;

   ArrayOfObjectsFromIE[i]->TransferFromSource();

   ...

}

Here's how the vulnerability manifests itself: if there are two data transfers with the same identifier (so MaxIdx is 2), and the first transfer updates the length of the ArrayOfObjectsFromIE array when its work was done and releases its data binding object, the loop count would still be whatever MaxIdx was at the start of the loop, 2.

This is a time-of-check-time-of-use (TOCTOU) bug that led to code calling into a freed memory block. The Common Weakness Enumeration (CWE) classification for this vulnerability is CWE-367.

The fix was to check the maximum iteration count on each loop iteration rather than once before the loop starts; this is the correct fix for a TOCTOU bug - move the check as close as possible to the action because, in this case, the array size might change.

同类型漏洞

很难静态代码分析或者代码review找出来这个漏洞，微软也不知道漏洞怎么发现的，有安全界人士说是fuzz出来的。

这种漏洞类型才是值得关注的，虽然是老东西了，但是也许会在其他地方再次发现这类问题。

漏洞利用，本来捕获的样本里，有个很牛B的shellcode，void在他的blog上分析了，不过好像planet没有聚合

我这里摘一下：

843×158

这就是传说中的通用不挂IE shellcode。

   为了做到和谐溢出,这个sc在CreateProcessA打完收功后做了这么一些事:
   调用shdocvw.dll#101,即其导出函数IEWinMain,开启了一个新的IEFrame窗体,使得浏览器不Crash掉
   但是如此也就导致了触发漏洞页面所在的窗口无法点击关闭,所以sc又inline hook了MessageBeep,用EnumWindow来关闭IEFrame窗口.
   不过感觉这里处理得不算太好,值得改进.
   还有LdrShutdownThread,UnhandledExpcetionFilter的hook感觉有点多余.

补: 2008-12-22
   sc一开头先GlobalAlloc()把自己放到堆里去执行,所以这段sc可以用在只有RX权限的内存去运行(比如文件里).
   hook MessageBeep的另一个作用是让Windows收声. ~_~"
   这个shellcode针对的浏览器肯定不是IE7+,因为IE7虽然不Crash了,但是若用户去点击关闭触发页的tag仍然会导致整个IE7关闭,这个就是所说的处理不算太好的地方.
   另外,这个shellcode在Maxthon 1/2. The World这类使用IE内核的第三方浏览器上工作得非常好.

最后还是漏洞的利用，有在doc文件里利用的，

参见mcafee的一篇blog：

Upon opening the word document the embedded ActiveX control with the following classid is instantiated and executed.

{AE24FDAE-03C6-11D1-8B76-0080C744F389}
This control stores configuration data for the policy setting Microsoft Scriptlet Component.

488×199

The control then makes a request to the webpage hosting the IE 7 exploit. The charm with this approach is that the exploit is downloaded and run without the knowledge or permission of the user. To the unsuspecting user it will just appear as yet another normal Doc file.