Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1198895
  • 博文数量: 272
  • 博客积分: 3899
  • 博客等级: 中校
  • 技术积分: 4734
  • 用 户 组: 普通用户
  • 注册时间: 2012-06-15 14:53
文章分类

全部博文(272)

文章存档

2012年(272)

分类: 网络与安全

2012-06-25 16:53:27

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

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

首先是漏洞的原因:
http://blogs.msdn.com/sdl/archive/2008/12/18/ms08-078-and-the-sdl.aspx

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 .

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没有聚合

我这里摘一下:

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

void写的blog: http://hi.baidu.com/54nop/blog/item/fb02e0fb945a07254e4aea2a.html

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

参见mcafee的一篇blog:

http://www.avertlabs.com/research/blog/index.php/2008/12/17/ie-7-exploit-reloaded-the-new-face-of-drive-by-attacks-using-doc-files/

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.

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.

阅读(1138) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~