Technical Analysis of CVE-2013-3147In 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> r
eax=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 esi
address 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: 6082fb0
address 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:
class="alignnone size-full wp-image-3161 landscape-lg" alt="1st"
src="/content/dam/legacy/blog/2013/09/1st.png" width="918" height="87" />
loc_636b31BF:
class="alignnone size-full wp-image-3162 landscape-lg" alt="2nd"
src="/content/dam/legacy/blog/2013/09/2nd.png" width="1139" height="444" />
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:
class="alignnone size-full wp-image-3163 landscape-lg" alt="3rd"
src="/content/dam/legacy/blog/2013/09/3rd.png" width="1063" height="211" />
CElement::Doc:
class="alignnone size-full wp-image-3164 landscape-lg" alt="4th"
src="/content/dam/legacy/blog/2013/09/4th.png" width="1026" height="146" />
This isn't the first IE vulnerability in
which the CElement::Doc function played a role — in href="http://technet.microsoft.com/en-us/security/bulletin/ms11-050">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.)
Source:
Technical Analysis of CVE-2013-3147
