In July, Microsoft released a patch for a memory-corruption vulnerability in the Internet Explorer (IE) Web browser. The vulnerability enabled remote attackers to execute arbitrary code or cause a denial of service through a crafted or compromised website — also known as a drive-by download.
This vulnerability is particularly interesting because it is so simple that even some tutorials on the web can trigger it, and it is unique to IE. The vulnerability exists in onbeforeeditfocus event. Only Internet Explorer supports this event (detailed information can be found at http://help.dottoro.com/ljclqecn.php).
Vulnerability
The vulnerability triggers when the document markup is manipulated inside the handler of onbeforeeditfocus event. It leads to a crash in mshtml!CElement::BubbleBecomeCurrent when the instruction tries to access the freed pointer.
Following is the state of registers at the time of crash.
0:008> reax=00000004 ebx=00000000 ecx=06034f88 edx=80000035 esi=06082fb0
edi=048466a8 eip=636b31fe esp=037cf9b8 ebp=037cf9d4 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
mshtml!CElement::BubbleBecomeCurrent+0xa7:
636b31fe 8b7604 mov esi,dword ptr [esi+4] ds:0023:06082fb4=????????
At this stage ESI holds the freed pointer.
0:008> !heap -p -a esiaddress 06082fb0 found in
_DPH_HEAP_ROOT @ 141000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)
5802a58: 6082000 2000
7c927553 ntdll!RtlFreeHeap+0x000000f9
63625834 mshtml!CTreeNode::Release+0x0000002d
63640cea mshtml!PlainRelease+0x00000033
63662fec mshtml!CTreeNode::NodeRelease+0x0000002a
635bd2d4 mshtml!CElement::BecomeCurrent+0x00000145
636b31eb mshtml!CElement::BubbleBecomeCurrent+0x00000094
637eeb74 mshtml!CElement::BubbleBecomeCurrent+0x0000004c
636b5dd5 mshtml!CDoc::PumpMessage+0x0000096a
635f1fea mshtml!CDoc::OnMouseMessage+0x0000055d
635ef664 mshtml!CDoc::OnWindowMessage+0x000007af
6364207a mshtml!CServer::WndProc+0x00000078
7e418734 USER32!InternalCallWinProc+0x00000028
7e418816 USER32!UserCallWinProcCheckWow+0x00000150
7e4189cd USER32!DispatchMessageWorker+0x00000306
7e418a10 USER32!DispatchMessageW+0x0000000f
02562ec9 IEFRAME!CTabWindow::_TabWindowThreadProc+0x00000461
Following was the size of allocation where ESI is pointing:
ESI: 6082fb0address 06082fb0 found in
_DPH_HEAP_ROOT @ 141000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
5802a58: 6082fb0 4c - 6082000 2000
7c918f01 ntdll!RtlAllocateHeap+0x00000e64
635a8225 mshtml!CHtmRootParseCtx::BeginElement+0x00000030
635bc1e9 mshtml!CHtmTextParseCtx::BeginElement+0x0000006c
635a8420 mshtml!CHtmParse::BeginElement+0x000000b7
635a93b4 mshtml!CHtmParse::ParseBeginTag+0x000000fe
635a6bb6 mshtml!CHtmParse::ParseToken+0x00000082
635a7ff4 mshtml!CHtmPost::ProcessTokens+0x00000237
635a734c mshtml!CHtmPost::Exec+0x00000221
635ac2b8 mshtml!CHtmPost::Run+0x00000015
635ac21b mshtml!PostManExecute+0x000001fd
635cece9 mshtml!CPostManager::PostManOnTimer+0x00000134
6364de62 mshtml!GlobalWndOnMethodCall+0x000000fb
6363c3c5 mshtml!GlobalWndProc+0x00000183
7e418734 USER32!InternalCallWinProc+0x00000028
7e418816 USER32!UserCallWinProcCheckWow+0x00000150
7e4189cd USER32!DispatchMessageWorker+0x00000306
But the story doesn’t end here. The instruction on which we are getting an exception is moving the pointer at [ESI+4] to ESI. So looking to the pointer, which is at [ESI+4], is important. If we monitor the ESI, then we will see the following sequence (note: the value of ESI is changed from the previous one because I collected this information at the second run):
ESI: 48bafb0 [ESI+4]: 6050fb0 [[ESI+4]]: 5ff0fd0 [[[ESI+4]]]: 635ba8c0
ESI: 48bafb0 [ESI+4]: 0 <---------------------- Exception
The exception instruction is expecting 6050fb0 at [ESI+4]. But because the pointer is freed, we hit an exception. The address 6050fb0 is the pointer to object 5ff0fd0 of type 635ba8c0 as we can see in the above lines and can also verify with the below windbg command.
0:008> ln 635ba8c0(635ba8c0) mshtml!CBodyElement::`vftable' | (637812c0) mshtml!CStackDataAry
<unsigned short,128>::`vftable'
Exact matches:
mshtml!CBodyElement::`vftable' = <no type information>
Possible Code Execution Path:
This situation can lead to code execution because the value at [ESI+4] propagates to the CElement::BecomeCurrent method which again calls the CElement::Doc method to access the vftable and call a function.
Following is the disassembly of the faulty function:
Our program crashes here:
loc_636b31BF:
Here, a few checks are getting the value of EBX. But EBX is also in control, and the value of EBX remains the same as it was in the beginning of the function call.
CElement::BecomeCurrent:
CElement::Doc:
This isn't the first IE vulnerability in which the CElement::Doc function played a role — in at least one other past vulnerability, CElement::Doc function played a key role in the code execution.
(Thanks to my colleagues Abhishek Singh and Yichong Lin for their suggestions.)
