Microsoft安全预警页面：http://www.microsoft.com/technet/sec...ry/981374.mspx
PoC来源：http://www.rec-sec.com/2010/03/10/in...-free-exploit/

调试环境：IE7（可能不是最全补丁版本），XP sp3 简体中文版，对上面链接取得的PoC，我连Heap Spray部分都去掉了，只分析内存是怎么被破坏的，我用的PoC内容在附件。

iepeers.dll中的CPersistUserData::setAttribute对VT_DISPATCH类型的Variant变量进行转化的过程中的处理失误导致内存破坏，有可能导致远程执行任意代码。


1. 网页COmWindowProxy对象通过mshtml!COmWindowProxy::GetSecurityThunk方法调用mshtml!CreateTearOffThunk为自己创建相应的TearoffThunk类结构。

2. 当对TearoffThunk类结构调用jscript!IDispatchExGetDispID时，后者通过TearoffThunk类结构调用mshtml!TearoffThunk7，使其跳到mshtml!COmWindowProxy::subGetDispID。

3. PoC中的网页脚本，在button标签的onClick事件中，采用如下语句将一个新的body标签与UserData绑定：
4. 之后脚本循环调用body标签的setAttribute方法：
5. 上面的脚本调用导致iepeers.dll中的CPersistUserData::setAttribute被调用。
对于VT_DISPATCH类的源Variant变量，该函数没有做特别处理，包括没有增加其相应IDispatch对象（这里是TearoffThunk对象）的访问计数，就直接调用了OLEAUT32!VariantChangeTypeEx试图将封装了TearoffThunk类的Variant变量（其类型为VT_DISPATCH）强制转换为Locale为美国英语的VT_BSTR类型：
6. 这里问题出现了，上面对VariantChangeTypeEx的调用可以看到，pvarSrc和pvargDest均指向封装了TearoffThunk类的Variant变量。为了将转换的结果写入pvargDest指向的目标Variant，VariantChangeTypeEx必须对其原内容进行清理，因此它对pvargDest（由于iepeers!CPersistUserData::setAttribute调用时传入的参数问题，这里其实也就是指向源Variant）调用了VariantClear，后者调用mshtml!PlainRelease减少了相应TearoffThunk类的访问计数。（感谢27楼对该处的指正）
7. 由于以上提到的原因，iepeers!CPersistUserData::setAttribute每被调用一次（也就是那个脚本中的for循环每循环一次），相应TearoffThunk对象的访问计数就会被减少1。多次的循环下来导致了其访问计数被减小为0，从而mshtml!PlainRelease将其内存区域被程序写到mshtml.dll中的一个可用指针
8. 之后在CWindow::PrivateQueryInterface对CreateTearoffThunk的调用中，上面那个“可用指针”被其重用。
9. 此后脚本执行过程中再次涉及对原TearoffThunk类结构指针调用jscript!IDispatchExGetDispID，这时由于该指针其实已经被重用，原来应该为mshtml!COmWindowProxy::s_apfnIDispatchEx的位置现在已经被mshtml!CWindow::s_apfnIHTMLPrivateWindow3 (3e5b56a4)代替，导致在mshtml!TearoffThunk7中以下位置原本的代码
被当成函数指针0x0F09F883：
从而导致Jmp 0x0F09F883，一般情况下该处内存无效，因此会抛出Access Violation异常。如果配合Heap Spray用nop+shellcode将该区域覆盖，则将可以操纵EIP指针跳入shellcode之中，从而远程执行代码。

综上，iepeers.dll中的CPersistUserData::setAttribute函数在对VT_DISPATCH类型的Variant变量进行处理时，在没有增加其相应IDispatch对象（这里是TearoffThunk对象）的访问计数的情况下调用OLEAUT32!VariantChangeTypeEx试图将其强制转换为VT_BSTR类型，且对OLEAUT32!VariantChangeTypeEx调用所传入的目的指针和源指针一致，使得VariantChangeTypeEx函数在写入转换结果之前对目的指针（也即源指针）调用了VariantClear（感谢27楼的指正，进一步讨论见29楼），导致相应IDispatch对象的访问计数减1。
PoC网页利用精心构造的脚本多次调用CPersistUserData::setAttribute函数，可以使得与COmWindowProxy对象关联的TearoffThunk对象的访问计数被减为0，从而其所在内存区域在之后被重用于与CWindow对象关联。而当后续操作导致对与COmWindowProxy对象关联的TearoffThunk对象调用了TearoffThunk7函数时，由于其已被修改而导致取到错误的函数指针，从而可以操纵eip跳到某个固定的错误地址（在我的IE版本中该地址为0x0F09F883）。通常这个地址为无效内存，从而引发Access Violation异常（拒绝服务），但通过结合Heap Spray技术有可能使该地址被shellcode所占据，从而导致以浏览器进程的用户权限远程执行任意代码。

上传的附件

ie_iepeers_wild.rar

调试方法：
WINDBG载入iexplore.exe，命令行参数为PoC网页路径，第一次停在系统断点，放行之：

跑起来后IE7会出现为了保护安全性已阻止有关内容执行的条子，这时先在windbg里暂停回到调试器。
在其下位置（jscript!IDispatchExGetDispID中）
.text:75BE3064                 call    dword ptr [ecx+1Ch] ; mshtml!TearoffThunk7
下硬件执行断点（这样下断是因为这时jscript.dll还没有加载，不能bp），g执行：
这时可以点击允许相关内容执行，很快断下：
记下这个eax=001897e0，即之后内存破坏的位置。
继续单步可以看清楚正常的流程，即分析中的第2点，可以看到正确的流程是跳到mshtml!COmWindowProxy::subGetDispID。
取消刚刚设的断点，对导致内存破坏的始作俑者iepeers.dll!CPersistUserData::setAttribute下断，运行断下：
单步直接看到对OLEAUT32!VariantChangeTypeEx的调用：
单步步进，看到源Variant指针为0x019dc9b4，并从其中取到对应的类指针，正是0x001897e0。
单步步进直到看到对OLEAUT32!ExtractValueProperty的调用，注意其第一个参数（最后push的那个）正是esi=001897e0。
p步过，不要进去OLEAUT32!ExtractValueProperty，跟踪发现它并没有减少访问计数，继续步进直到对OLEAUT32!VariantClear的调用，注意到对OLEAUT32!VariantClear调用传入

的参数即目的Variant指针仍为0x019dc9b4，与源指针一致，这样这个调用导致对相应的对象即0x001897e0指向的TearoffThunk对象的访问计数减1（如果想要深入可以步入其中，

就可以发现把访问计数减1的就是mshtml!PlainRelease）：
步过OLEAUT32!VariantClear，访问计数减1之后，为了不要每次循环都到这里，直接看这个TearoffThunk是在哪里被重写掉的，从前面的TearoffThunk7调用
3e5b95f1 8b4804          mov     ecx,dword ptr [eax+4] ds:0023:001897f0={mshtml!COmWindowProxy::s_apfnIDispatchEx (3e5b2fdc)}
可以知道关键的位置是001897f0处保存的这个函数表，对此处下4字节的硬件写入断点，运行后断下，这时已经在CreateTearoffThunk里的，该处的值确实被改为了mshtml!CWindow::s_apfnIHTMLPrivateWindow3：
最后，把最早的那个断点重新搞上，不过这次加上条件，让它在下次访问相应TearoffThunk结构的时候正好被断下：
步进去，最终的过程就有了：
最后是变成jmp 0x0f09f883，以一个Access Violation异常告终：