Internet Explorer clip:rect(0) Memory Corruption Vulnerability

Today we're going to talk about a currently unpatched vulnerability in IE reportedly affecting versions 6/7/8. In this brief analysis we're going to focus on Internet Explorer version 7.0.5730.13 in Windows XP SP3. This bug tagged CVE-2010-3962, made it into the public because apparently it was found being actively exploited in the wild (SYMANTEC). Trigger code has been widely published in many sites, and for documentation purposes, it's reproduced here: style = position :absolute;clip:rect(0)> There isn't much to say about it. It's seems that the original purpose of this properties (besides allowing system compromise :-), is to manipulate table borders in certain elements. But do we care about fancy HTML shapes here? not really... The essence of the bug lies in the implementation of certain methods inside mshtml.dll, the HTML rendering engine in Windows. First we need to look at CTableLayoutBlock::EnsureTableDispNode which allocates a new object: 
.text:7E9A93E5                 push    esi
.text:7E9A93E6                 lea     eax, [ebx+0Ch]
.text:7E9A93E9                 push    eax
.text:7E9A93EA                 call    ?New@CDispContainer@@SGPAV1@PAVCDispClient@@K@Z ; CDispContainer::New(CDispClient *,ulong)
.text:7E9A93EF                 mov     esi, eax
.text:7E9A93F1                 test    esi, esi
.text:7E9A93F3                 jz      loc_7E9EA792
.text:7E9A93F9                 or      dword ptr [esi+4], 40000000h
.text:7E9A9400                 mov     ecx, [ebx+8]Next, this very object gets passed to
CDispNode::SetUserClip inside the same CTableLayoutBlock::EnsureTableDispNode function: 
.text:7E9EA691                 xor     eax, eax
.text:7E9EA693                 mov     [ebp+var_9C], eax
.text:7E9EA699                 mov     [ebp+var_A0], eax
.text:7E9EA69F                 mov     [ebp+var_A4], eax
.text:7E9EA6A5                 mov     [ebp+var_A8], eax
.text:7E9EA6AB                 lea     eax, [ebp+var_A8]
.text:7E9EA6B1                 push    eax
.text:7E9EA6B2                 mov     ecx, esi ; our object
.text:7E9EA6B4                 call    ?SetUserClip@CDispNode@@QAEXABUtagRECT@@@Z ; CDispNode::SetUserClip(tagRECT const &)And here comes the funny part. Inside
CDispNode::SetUserClip the vftable address gets dereferenced and OR'ed with 0x1, corrupting the table as a result: 
.text:7EA3FB95                 mov     eax, edi ; load object in eax
.text:7EA3FB97                 shl     ecx, 2
.text:7EA3FB9A                 sub     eax, ecx
.text:7EA3FB9C                 or      dword ptr [eax], 1 ; BUG!
.text:7EA3FB9F                 mov     eax, [edi+4]Once we have a corrupted entity, we need to actually call any method in the
vftable because it will point to corrupted memory. This happens inside CTableLayout::CalculateLayout: 
.text:7E9A9604                 mov     ecx, [ebp+corruptObj_ptr]
.text:7E9A9607                 and     [ebp+var_8], 0
.text:7E9A960B                 lea     edx, [ebp+var_8]
.text:7E9A960E                 mov     [ebp+var_4], eax
.text:7E9A9611                 mov     eax, [ecx]      ; vtable[0]
.text:7E9A9613                 push    edx
.text:7E9A9614                 call    dword ptr [eax+44h] ; PWN!
.text:7E9A9617                 jmp     loc_7E8A3954As many other researchers pointed out this bug is a bit difficult to exploit reliably because it depends largely on mshtml.dll's version (7.0.5730.13 was used here). Heap Spray anyone?
Links: P.D: While I was writing this I noticed that the guys at hdlsec.com had a nice work relating to this very vulnerability. Unfortunately their site seems to be down, suggested read when it's running again.