CVE-2016-0199浅析-Internet Explorer内存损坏漏洞

本文转载自对CVE-2016-0199的简单分析

POC如下(Windows 7 32bit，IE 11)。

<meta http-equiv="X-UA-Compatible" content="IE=7">
<script>
oElement = document.createElement("IMG");
var oAttr = document.createAttribute("loop");
oAttr.nodeValue = oElement;
oElement.loop = 0x41424344;
oElement.setAttributeNode(oAttr);
oElement.removeAttributeNode(oAttr);
CollectGarbage();
</script>

异常访问的地址与

oElement.loop=0x41424344

的赋值相同，多次更改这个数值发现都一致。可以看出eax中应该是存放c++对象基址。



现在从头详细的开始调试这个POC，把这个POC改一下。由于我的windbg没有正确加载mshtml.dll的符号，所以符号信息还是以IDA为准。另外再说两个小技巧。

IDA打开mshtml.dll这种复杂的文件自动分析会花费很长的时间，用-a命令启动IDA就可以关闭自动分析。

每做一步都保存虚拟机镜像方便随时回退，这样基地址和对象分配的地址都不会发生变化，非常易于调试。

<meta http-equiv="X-UA-Compatible" content="IE=7">
<script>
alert(0);
oElement = document.createElement("IMG");
alert(1);
var oAttr = document.createAttribute("loop");
alert(2);
oAttr.nodeValue = oElement;
alert(3);
oElement.loop = 0x41424344;
alert(4);
oElement.setAttributeNode(oAttr);
alert(5);
oElement.removeAttributeNode(oAttr);
alert(6);
CollectGarbage();
</script>

注意

<meta http-equiv="X-UA-Compatible" content="IE=7">

以IE7模式渲染，只有在IE7模式渲染才能触发漏洞。POC代码创建了IMG对象和loop属性，之后的操作都是围绕着它们展开的，所以先找下它们的地址。

gflags.exe /i iexplore.exe +hpa +ust

打开hpa和ust。在IDA中打开mshtml.dll，查看所有CImgElement的函数，CreatElement这个函数名明显是创建对象。



下断点步过HeapAlloc后得到IMG的地址0x0cfdcfa0。





虽然没有像MSHTML!CAttribute::CreateXXX这样的函数，但是有构造函数，虚表指针就是在这里放在对象首位的。



下断点运行到这里得到Attribute的地址0x0b344fa0。





接下来

oAttr.nodeValue=oElement

很明显是为Attribute对象的一个成员变量赋值，而且还是IMG对象。CAttribute的成员函数中put_nodeValue比较像干这个的。



跟进PutNodeValueVariantHelper。



进入VariantCopy之后到达了赋值处。





可以看出

oAttr.nodeValue=oElement

将IMG对象的地址放到了attribute的偏移0x30处。

oElement.loop=0x41424344

是给IMG对象的一个属性赋值，但是从函数名称上来看没有找到相关的函数，因此使用

s-d 0x0 L?0x7fffffff 41424344

命令分别在alert(3)和alert(4)之后在内存中搜索。



可以看出确实多了一个0x41424344这个值，看看内存怎么分配的。



这里分配的内存从0xb0a4fc0开始，也就是41424344所在地址的前8个字节。回退到以前的镜像，在调用栈中最后一个被调用的mshtml.dll中的函数上下断点。





看看IMG对象所处的内存综合如下。



alert(4)之后看到IMG.loop属性被存放。



下面

oElement.setAttributeNode(oAttr)

应该也是调用IMG对象的成员函数把attributenode对象地址放到IMG对象的内存片中。



其实不用详细去跟，alert(5)之后直接看到Attribute对象地址被存放。



最后

oElement.removeAttributeNode(oAttr)

同样也可以在IDA中轻易找到对应的函数。



同样不详细去跟，alert(6)之后直接看到Attribute对象偏移0x30处变成了0x41424344，这里本来是IMG对象。



回顾程序崩溃时的栈回溯看看

MSHTML!CAttribute::EnumerateTrackedObjects

的反汇编代码。





这也就能说明接下来崩溃的原因了。