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:
: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 toCDispNode::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. InsideCDispNode::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 thevftable 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 .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.