Internet Explorer Script Interjection Code Execution
Derek Soeder
ds.adv....@gmail.com
Reported: January 26, 2012, to SecuriTeam Secure Disclosure
http://www.beyondsecurity.com/ssd.html
Published: August 16, 2012
AFFECTED VENDOR
---------------
Microsoft Corporation
AFFECTED ENVIRONMENTS
---------------------
Internet Explorer 7.0 on Windows XP and Windows Vista
Internet Explorer 8.0 on Windows XP, Windows Vista, and Windows 7
Internet Explorer 9.0.0 through 9.0.8 (MS12-044) on Windows Vista and Windows 7
Other versions of Internet Explorer have not been tested.
UNAFFECTED ENVIRONMENTS
-----------------------
Internet Explorer with MS12-052 hotfix applied
IMPACT
------
The vulnerability described in this document can be exploited by a
malicious Web page to execute arbitrary code with low integrity.
Active scripting must be enabled, and the present exploitation
techniques require that font downloading be set to "Enable" or
"Prompt" and that the "mailto:"; protocol be present. (These
requirements are satisfied by default on Windows XP, Windows Vista,
and Windows 7.) The user is presented with a message box which must
be dismissed before code execution can occur.
VULNERABILITY DETAILS
---------------------
Processing of events in Internet Explorer is typically driven by
window messages originating both externally (for instance, due to user
input or paint requests) and internally. As with all window messages,
these messages are retrieved from the current thread's message queue
by a message loop, which dispatches each message to a window
procedure. The window procedure, in turn, invokes code to handle the
associated event based on the type of window message. If the event
handling code can be made to display a message box or dialog, or
otherwise enter a message loop, then another window message relating
to a separate, second event may be dispatched during this "stacked,"
second message loop, meaning the second event will be processed before
the original event has been fully handled. Processing of the original
event continues only after the second message loop has ended (i.e.,
when the displayed message box or dialog closes). If the second event
handling code can cause the program's state to become inconsistent
with the first event handling code's expectations--for instance, by
destroying objects referenced in variables local to the first event
handling code--then it should be possible to cause memory corruption
which can be exploited to achieve arbitrary code execution.
A variety of events can result in script running during the event
handler code. Although it's simple for script to display a message
box or dialog and thereby enter a message loop (e.g., using
window.alert, window.prompt, or window.clipboardData.getData under
default security settings), so far it does not appear that an
interrupting, second event handler can then do anything to disrupt
program state in a way that the first event handler will not
accommodate. This is understandable, since script must be able to
handle other script running at any time and having arbitrary effects
on program state. Objects accessible to script should be properly
reference-counted and garbage-collected, and any exception would
constitute a separate vulnerability that could likely be exploited
without use of the flaw described in this document.
In some cases, it's also possible to make MSHTML.DLL enter a message
loop while handling a page rendering event (as opposed to an event
intended to run script). For one, MSHTML!CMarkup::ProcessURLAction*
is used to check a variety of security settings during page
downloading and rendering; this function calls
URLMON!ProcessUrlAction*, which may display a dialog if the queried
setting's action is set to "Prompt". Unfortunately, most of the
security settings which default to prompting are now handled through
the yellow security band or notification bar rather than a dialog.
Other avenues for reaching a message loop may be discovered by
backtracking from functions such as DispatchMessageW, MessageBoxW, and
DialogBoxParamW. One function call of particular interest is a call
to MessageBoxW found in
MSHTML!CMailtoProtocol::DisplayMailClientNotFoundError. It was
discovered that, if Internet Explorer attempts to download a very long
(approximately 2,030-character) "mailto:"; URL, then
CMailtoProtocol::RunMailClient will fail and call
CMailtoProtocol::DisplayMailClientNotFoundError to display a message
box, thereby entering a message loop. (The message reads, "Could not
perform this operation because the default mail client is not properly
installed.") Furthermore, it was found that displaying this message
box while downloading an embedded font (by specifying a long "mailto:";
URL for the font's "src" property) will result in references to
targetable objects remaining on the stack until the message box is
closed. Thus, a Web page can exploit this vulnerability by declaring
an embedded font with a long "mailto:"; source URL and ensuring that an
event which destroys and replaces targetable objects occurs while the
message box is open. Although the particulars of the targetable
objects are Internet Explorer version-dependent, exploitation should
generally proceed as typical for an Internet Explorer use-after-free
vulnerability.
Events
The most significant complexity of this vulnerability is understanding
Internet Explorer's event handling. As mentioned above, event
handling is based on the processing of window messages. Some window
messages may arise from user input (such as keyboard and mouse
messages), while others may be generated by the operating system (such
as paint and resize messages), but most messages signaling events are
generated interally by Internet Explorer. These messages use a
message identifier value of 0x8002 and are generated when a "method
call" is added to a queue maintained in Thread Local Storage (TLS), if
the queue is empty. A method call is simply a function pointer and
associated data representing a callback to be invoked by the event
handling message loop (or any other message loop). Method calls are
queued using MSHTML!_GWPostMethodCallEx and handled by
MSHTML!GlobalWndOnMethodCall, which the MSHTML!GlobalWndProc window
procedure calls in response to a message 0x8002.
It is important to note that a message 0x8002 will only be posted if
the method call queue is empty and if a message 0x8002 is not
outstanding (being processed or waiting to be processed). Therefore,
with possibly one minor exception, a second message 0x8002 cannot be
pending while a first message 0x8002 is being processed, meaning a
second method call-based event cannot be handled while a first method
call-based event is being handled, even if the first enters a message
loop. When exploiting the vulnerability, one event may be based on a
method call, but the other must correspond to user input or some other
type of message.
Although designing a Web page to provoke a user input message without
user interaction is not difficult, Internet Explorer 9 offers another
possibility by introducing asynchronous events. If a Web page is
viewed in IE9 standards mode, certain events (for example,
body.onfocus) will instead be mediated by messages with an identifier
value of 0x8003, which are generated via
MSHTML!CEventMgr::QueueAsyncEvent ->
MSHTML!CAsyncEventQueue::QueueEvent and processed when GlobalWndProc
calls MSHTML!CAsyncEventQueue::DispatchAllEvents. If the asynchronous
event handling code enters a message loop, a message 0x8002 could then
be dispatched and cause any queued method calls to be processed.
Example (Internet Explorer 7 and 8)
A simple example of how to reproduce this vulnerability in Internet
Explorer versions 7 and 8 follows. A Web page contains an empty style
sheet link, a body with an "onmouseover" event handler, and a script
element which creates a new script element and assigns it an
"onreadystatechange" event handler. The body also has a style which
specifies a large height value, so that the body area will occupy the
full height as well as width of the browser window. The following
HTML illustrates:
[redacted for now]
When the Web page loads, the presence of the mouse cursor over the
window causes MSHTML!CServer::WndProc to receive a mouse window
message, which it passes to MSHTML!CDoc::OnWindowMessage ->
MSHTML!CDoc::OnMouseMessage. Further up the call stack, the script of
the body's "onmouseover" event handler runs, setting the empty style
sheet link's "href" attribute to load "MyFont.css". When the CSS
defining the "MyFont" embedded font is parsed, the long "mailto:"; URL
will ultimately result in
CMailtoProtocol::DisplayMailClientNotFoundError displaying an error
message box, pausing execution of that thread except to process window
messages. Using the "onmouseover" event handler for this purpose
ensures that the message box will appear during processing of a user
input window message, rather than during processing of a method call
(0x8002) window message, which leaves the method call avenue available
for the second event.
While the message box is showing, our attack server completes its
intentionally delayed response to the request for "slow.js", causing
the client to queue a method call which will run the new script
element's "onreadystatechange" event handler. Because a method call
(message 0x8002) is not currently being processed--the event being
processed originated instead as a mouse window message--this means the
thread responsible for downloading "slow.js" is free to post a message
0x8002 after it queues the method call. The window message will then
be dispatched by the message loop that drives the error message box,
causing the "onreadystatechange" event handler to run. In this
example, the event handler tampers with the object representing the
style sheet, which was still being interpreted at the time the message
box was displayed. The tampering provokes a crash once the message
box closes and interpretation of the style sheet is allowed to
continue.
Example (Internet Explorer 9)
Now a simple example specific to Internet Explorer 9 is presented. A
Web page contains a body with an "onfocus" event handler, a style
sheet defining an embedded font and a class which uses it, a "div"
element of the defined class, and a script element which creates a new
script element and assigns it an "onreadystatechange" event handler.
The document begins with a "DOCTYPE" declaration which ensures that
the page will be rendered in IE9 standards mode. The following HTML
illustrates:
[redacted for now]
In IE9 standards mode, embedded fonts are not downloaded until they're
needed to render the page, meaning that the embedded font's long
"mailto:"; URL is interpreted--and therefore the error message box is
displayed--when the body's "onfocus" event fires. Because
body.onfocus is handled in IE9 standards mode as an asynchronous event
(message 0x8003), method calls (message 0x8002) remain free to be
dispatched while the message box message loop is on the call stack.
In this example, we expect "slow.js" to finish downloading after
body.onfocus fires and causes the error message box to appear. The
code in IE that manages the download will queue an
"onreadystatechange" method call for the script, which will be
dispatched by the message box message loop, allowing our Javascript to
execute. Since IE9 accesses embedded fonts on demand, there will be
references to various object on the stack below the message box
message loop, so if our Javascript tampers with these objects, a crash
will result once the message box is closed.
Walkthrough
To help provide a visual understanding of the vulnerability, a
chronological walkthrough of the Internet Explorer 9 example crash is
presented here. Following along in the example is recommended. The
symbols shown correspond to Internet Explorer 9.0.3 on Windows 7 SP1
x86, with MSHTML.DLL version 9.0.8112.16437 loaded at 6D1C0000 and
page heap enabled.
When the example page is loading, a 0x54-byte CTreePos class instance
is allocated on the heap: (This CTreePos instance will be freed and
its memory reused later.)
77365ae0 ntdll!RtlAllocateHeap+0x0000023a
6d423fe1 MSHTML!CHtmRootParseCtx::BeginElement+0x00000035
6d51b14b MSHTML!CHtmTextParseCtx::BeginElement+0x000000a1
6d4245a0 MSHTML!CHtmParse::BeginElement+0x00000151
6d4269aa MSHTML!CHtmParse::ParseBeginTag+0x00000199
6d422422 MSHTML!CHtmParse::ParseToken+0x00000100
6d42292a MSHTML!CHtmPost::Exec+0x00000233
6d427a10 MSHTML!CHtmPost::Run+0x00000041
6d42793c MSHTML!PostManExecute+0x000001a3
6d4278a1 MSHTML!PostManResume+0x000000dd
6d427801 MSHTML!CHtmPost::OnDwnChanCallback+0x00000010
6d40b4d5 MSHTML!CDwnChan::OnMethodCall+0x0000001f
6d5a9d09 MSHTML!GlobalWndOnMethodCall+0x00000115
6d5c9368 MSHTML!GlobalWndProc+0x00000302
7748c4e7 USER32!InternalCallWinProc+0x00000023
7748c5e7 USER32!UserCallWinProcCheckWow+0x0000014b
7748cc19 USER32!DispatchMessageWorker+0x0000035e
7748cc70 USER32!DispatchMessageW+0x0000000f
6e8e1b44 IEFRAME!CTabWindow::_TabWindowThreadProc+0x00000722
6e901a16 IEFRAME!LCIETab_ThreadProc+0x00000317
759315b0 iertutil!CIsoScope::RegisterThread+0x000000ab
6e8efd5b IEFRAME!Detour_DefWindowProcA+0x0000006c
75c4ed6c kernel32!BaseThreadInitThunk+0x0000000e
773737f5 ntdll!__RtlUserThreadStart+0x00000070
773737c8 ntdll!_RtlUserThreadStart+0x0000001b
Next, the page's Javascript executes, creating a new script element
with a source of "slow.js". The idea is that the Web server will
intentionally postpone serving this file for a second or two. This
arranges for an "onreadystatechange" event to fire after the delay
elapses.
Once the page finishes loading (but before the delay has elapsed), the
"body.onfocus" event fires. Because the document is in IE9 standards
mode, "body.onfocus" will be queued as an asynchronous event, meaning
it will be mediated by window message 0x8003. The "body.onfocus"
event handler changes a "div" element's class to a class that uses an
embedded font. This forces Internet Explorer to attempt to download
the font, which fails due to the long "mailto:"; URL. Crucially, the
failure triggers a "mailto"-specific message box to be displayed; this
enters a new, top message loop during the original, bottom message
loop's handling of the 0x8003 window message associated with the
"body.onfocus" event. The call stack, from top to bottom, now looks
like this:
774a382a USER32!NtUserWaitMessage+0xc
774a3b27 USER32!DialogBox2+0x207
774ce0d5 USER32!InternalDialogBox+0xcb
774ce659 USER32!SoftModalMessageBox+0x68a
774ce78c USER32!MessageBoxWorker+0x2ca
774cea08 USER32!MessageBoxTimeoutW+0x7f
6ea15e86 USER32!MessageBoxExW+0x1b
774ceaa4 IEFRAME!Detour_MessageBoxExW+0x47
6db3ac94 USER32!MessageBoxW+0x45
6db3aaf1 MSHTML!CMailtoProtocol::DisplayMailClientNotFoundError+0x10b
6db3a2cc MSHTML!CMailtoProtocol::RunMailClient+0x12e
6db39def MSHTML!CMailtoProtocol::ParseAndBind+0x8b
76ab1c0b MSHTML!CMailtoProtocol::Start+0xcd
76a98fb3 URLMON!COInetProt::StartEx+0xf0
76a9a31f URLMON!CTransaction::StartEx+0x40b
76a8386c URLMON!CBinding::StartBinding+0x883
6d438507 URLMON!operator new+0x20
6d4383ed MSHTML!CTridentFilterHost::BindToMoniker+0xe4
6d4216f3 MSHTML!CDwnBindData::Bind+0x722
6d42153b MSHTML!NewDwnBindData+0x189
6d20c107 MSHTML!CDwnLoad::Init+0x25c
6d5c1f27 MSHTML!CBitsLoad::Init+0x52
6d421279 MSHTML!CDwnInfo::SetLoad+0x11e
6d451257 MSHTML!CDwnInfo::AddDwnCtx+0x67
6d42c695 MSHTML!CDoc::NewDwnCtx2+0x30a
6d953c33 MSHTML!CDoc::NewDwnCtx+0x5b
6d956222 MSHTML!CEmbeddedFontFace::EnsureStartDownload+0x120
6d955aee MSHTML!CFontFace::CFontFaceSrc::EnsureStartDownload+0x8a
6d682c20 MSHTML!CFontFace::AddToFamily+0x18c
6d52ceb2 MSHTML!CStyleSheetArray::BuildFontFaceRuleFamily+0x58
6d52cd28 MSHTML!ApplyClear+0x113
6d51bc41 MSHTML!ApplyFontFace+0x1d4
6d40e103 MSHTML!ApplyFormatInfoProperty+0x33bf
6d40e424 MSHTML!ApplyAttrArrayValues+0x2bd
6d5b5344 MSHTML!CStyleSheetArray::Apply+0x34a
6d47bad8 MSHTML!CMarkup::ApplyStyleSheets+0x6a
6d47b89e MSHTML!CElement::ApplyStyleSheets+0x4a2
6d4cddff MSHTML!CElement::ApplyDefaultFormat+0x8b
6d47b5a0 MSHTML!CBlockElement::ApplyDefaultFormat+0x379
6d47a5a3 MSHTML!CElement::ComputeFormatsVirtual+0x1a1e
6d47a4d6 MSHTML!CElement::ComputeFormats+0xe1
6d47bd39 MSHTML!CTreeNode::ComputeFormats+0xba
6d482d33 MSHTML!CTreeNode::ComputeFormatsHelper+0x40
6d360862 MSHTML!CTreeNode::GetFancyFormat+0x32
6d2d910f MSHTML!CElement::UpdateFormats+0x426
6d4ce10f MSHTML!CControlledFormatter::Init+0xcc
6d47fa14 MSHTML!CElement::OnPropertyChangeInternal+0x3fa
6d49b76b MSHTML!CElement::OnPropertyChange+0x1b
6d2da8db MSHTML!BASICPROPPARAMS::SetStringProperty+0x36a
6d0084d6 MSHTML!CFastDOM::CHTMLElement::Trampoline_Set_className+0x61
6d0cc04d JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4
6d0cc968 JSCRIPT9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x117
6d009a85 JSCRIPT9!Js::JavascriptOperators::SetProperty+0x8c
6d009a2c JSCRIPT9!Js::JavascriptOperators::OP_SetProperty+0x59
039507b8 JSCRIPT9!Js::JavascriptOperators::PatchPutValueNoLocalFastPath+0xbc
6d0084d6 0x39507b8
6d0083fb JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4
6d008332 JSCRIPT9!Js::JavascriptFunction::CallRootFunction+0xb6
6d0082be JSCRIPT9!ScriptSite::CallRootFunction+0x4f
6d0cf12c JSCRIPT9!ScriptSite::Execute+0x63
6d4f24d1 JSCRIPT9!ScriptEngine::Execute+0x11a
6d4f23fb MSHTML!CListenerDispatch::InvokeVar+0x12a
6d54ce40 MSHTML!CListenerDispatch::Invoke+0x40
6d44e624 MSHTML!CEventMgr::_InvokeListeners+0x187
6d54cf37 MSHTML!CEventMgr::_InvokeListenersOnWindow+0xcc
6d5db67d MSHTML!CEventMgr::Dispatch+0x3cc
6d53ba32 MSHTML!CEventMgr::DispatchFocusEvent+0x7d
6d5e6f74 MSHTML!COmWindowProxy::Fire_onfocus+0x84
6d5e6ff1 MSHTML!CAsyncEventQueue::DispatchAllEvents+0x7c
7748c4e7 MSHTML!GlobalWndProc+0x2ed
7748c5e7 USER32!InternalCallWinProc+0x23
7748cc19 USER32!UserCallWinProcCheckWow+0x14b
7748cc70 USER32!DispatchMessageWorker+0x35e
6e8e1b44 USER32!DispatchMessageW+0xf
6e901a16 IEFRAME!CTabWindow::_TabWindowThreadProc+0x722
759315b0 IEFRAME!LCIETab_ThreadProc+0x317
6e8efd5b IERTUTIL!CIsoScope::RegisterThread+0xab
75c4ed6c IEFRAME!Detour_DefWindowProcA+0x6c
773737f5 KERNEL32!BaseThreadInitThunk+0xe
773737c8 NTDLL!__RtlUserThreadStart+0x70
00000000 NTDLL!_RtlUserThreadStart+0x1b
As long as the message box remains open, its message loop will
dispatch new window message-mediated events, and control won't return
to Internet Explorer's original message loop. It doesn't matter which
message loop is dispatching messages, because the same window
procedure is executed in either case. The only problem is that the
code lower on the call stack was operating on various heap objects
(such as the CTreePos allocated earlier) before control entered the
MessageBox call and became stuck. Now, if a window message-mediated
event results in the execution of Javascript that modifies or destroys
those heap objects, corruption manifesting as a use-after-free, for
instance, may result.
As belabored in the Vulnerability Details section, not every type of
event can be "stacked" in every situation like this, but certain
different events can. An 0x8003 window message (for "body.onfocus")
was being processed during the bottom message loop, so if an 0x8002
window message is posted, it will be processed during the top message
loop--and this is exactly what the example has arranged to happen.
Once the delay in serving "slow.js" elapses, an 0x8002 window
message-mediated event (referred to as a "method call") corresponding
to the concluded download will be posted and subsequently processed
during the top message loop. This method call executes the created
script element's "onreadystatechange" event handler, which destroys
the very "div" element that was in the process of being rendered when
Internet Explorer attempted to download the font and became stuck at
the message box. The following partial call stack shows "removeChild"
being called from the "onreadystatechange" event handler:
6d2eb4e3 MSHTML!CElement::ie9_removeChild
6d0084d6 MSHTML!CFastDOM::CNode::Trampoline_removeChild+0x7b
6d0cc04d JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4
039501af JSCRIPT9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x117
6d0084d6 0x39501af
6d0083fb JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4
6d008332 JSCRIPT9!Js::JavascriptFunction::CallRootFunction+0xb6
6d0082be JSCRIPT9!ScriptSite::CallRootFunction+0x4f
6d0cf12c JSCRIPT9!ScriptSite::Execute+0x63
6d4f24d1 JSCRIPT9!ScriptEngine::Execute+0x11a
6d4f23fb MSHTML!CListenerDispatch::InvokeVar+0x12a
6d35a726 MSHTML!CListenerDispatch::Invoke+0x40
6d5db834 MSHTML!CEventMgr::Dispatch+0x537
6d4a5607 MSHTML!CEventMgr::DispatchEvent+0xc9
6d4a02ff MSHTML!CElement::Fire_onreadystatechange+0x99
6d5a9d09 MSHTML!CScriptElement::FireOnReadyStateChange+0x3e
6d5c9368 MSHTML!GlobalWndOnMethodCall+0x115
7748c4e7 MSHTML!GlobalWndProc+0x302
7748c5e7 USER32!InternalCallWinProc+0x23
7748cc19 USER32!UserCallWinProcCheckWow+0x14b
7748cc70 USER32!DispatchMessageWorker+0x35e
774a38d7 USER32!DispatchMessageW+0xf
774a3b27 USER32!DialogBox2+0x15a
774ce0d5 USER32!InternalDialogBox+0xcb
774ce659 USER32!SoftModalMessageBox+0x68a
774ce78c USER32!MessageBoxWorker+0x2ca
774cea08 USER32!MessageBoxTimeoutW+0x7f
6ea15e86 USER32!MessageBoxExW+0x1b
774ceaa4 IEFRAME!Detour_MessageBoxExW+0x47
6db3ac94 USER32!MessageBoxW+0x45
6db3aaf1 MSHTML!CMailtoProtocol::DisplayMailClientNotFoundError+0x10b
6db3a2cc MSHTML!CMailtoProtocol::RunMailClient+0x12e
6db39def MSHTML!CMailtoProtocol::ParseAndBind+0x8b
76ab1c0b MSHTML!CMailtoProtocol::Start+0xcd
...
The free actually happens in a subsequent method call, which is also
processing during the MessageBox message loop, as shown in the
following partial call stack:
75c4c3d4 kernel32!HeapFree+0x00000014
6d5eebed MSHTML!CTreePos::Release+0x00000046
6d5fdc69 MSHTML!CLayoutBlock::~CLayoutBlock+0x000000ba
6d5ff5da MSHTML!CFlexBoxBlock::`scalar deleting destructor'+0x00000013
6d559ee9
MSHTML!TSmartPointer<CPtsPelParaclient>::~TSmartPointer<CPtsPelParaclient>+0x00000014
6d5da773 MSHTML!HtmlLayout::SmartDispClient::Release+0x00000023
6d5da5fb MSHTML!HtmlLayout::FlowBox::ImplicitDestructor+0x0000001d
6d490144 MSHTML!HtmlLayout::CIE9DocumentLayout::FormatPage+0x00000065
6d48c517 MSHTML!CCssDocumentLayout::FindOrFormatPage+0x00000272
6d4872fb MSHTML!CCssDocumentLayout::GetPage+0x00000964
6d48e06f MSHTML!CMarkupPageLayout::CalcSize+0x0000028c
6d48de82 MSHTML!CMarkupPageLayout::CalcTopLayoutSize+0x00000101
6d48fba1 MSHTML!CMarkupPageLayout::DoLayout+0x00000056
6d47e65a MSHTML!CView::ExecuteLayoutTasks+0x00000034
6d476a85 MSHTML!CView::EnsureView+0x000003bf
6d498701 MSHTML!CView::EnsureViewCallback+0x000000b8
6d5a9d09 MSHTML!GlobalWndOnMethodCall+0x00000115
6d5c9368 MSHTML!GlobalWndProc+0x00000302
7748c4e7 USER32!InternalCallWinProc+0x00000023
7748c5e7 USER32!UserCallWinProcCheckWow+0x0000014b
7748cc19 USER32!DispatchMessageWorker+0x0000035e
7748cc70 USER32!DispatchMessageW+0x0000000f
774a38d7 USER32!DialogBox2+0x0000015a
774a3b27 USER32!InternalDialogBox+0x000000cb
774ce0d5 USER32!SoftModalMessageBox+0x0000068a
774ce659 USER32!MessageBoxWorker+0x000002ca
774ce78c USER32!MessageBoxTimeoutW+0x0000007f
...
At this point, a fully developed exploit might use Javascript to
reallocate and overwrite the memory formerly belonging to the
now-freed CTreePos. For the sake of this walkthrough, it suffices to
let page heap wipe the freed memory of the CTreePos with 0xF0.
Finally, once the user closes the message box, execution of the
interrupt font downloading and page rendering code continues, but the
code fails to anticipate that the program state has changed during the
MessageBox call. A pointer on the stack to the destroyed CTreePos is
dereferenced, resulting in an access violation. The following
register dump, disassembly, and call stack illustrate; notice that EBX
points to stack memory from which a pointer to the destroyed CTreePos
is taken:
Access violation - code c0000005 (first chance)
eax=005ba430 ebx=03b5c5c8 ecx=f0f0f0f0 edx=03b5c540 esi=00000000 edi=00557840
eip=6d47b5d7 esp=03b5c450 ebp=03b5c510 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::ComputeFormatsVirtual+0x1a64:
6d47b5d7 0fbf4120 movsx eax,word ptr [ecx+20h]
ds:0023:f0f0f110=????
6d47b5c5 8b03 mov eax,dword ptr [ebx]
6d47b5c7 8b8bd4000000 mov ecx,dword ptr [ebx+0D4h]
6d47b5cd 89442420 mov dword ptr [esp+20h],eax
6d47b5d1 894c242c mov dword ptr [esp+2Ch],ecx
6d47b5d5 8b08 mov ecx,dword ptr [eax]
6d47b5d7 0fbf4120 movsx eax,word ptr [ecx+20h]
6d47a5a3 MSHTML!CElement::ComputeFormatsVirtual+0x1a64
6d47a4d6 MSHTML!CElement::ComputeFormats+0xe1
6d47bd39 MSHTML!CTreeNode::ComputeFormats+0xba
6d482d33 MSHTML!CTreeNode::ComputeFormatsHelper+0x40
6d360862 MSHTML!CTreeNode::GetFancyFormat+0x32
6d2d910f MSHTML!CElement::UpdateFormats+0x426
6d4ce10f MSHTML!CControlledFormatter::Init+0xcc
6d47fa14 MSHTML!CElement::OnPropertyChangeInternal+0x3fa
6d49b76b MSHTML!CElement::OnPropertyChange+0x1b
6d2da8db MSHTML!BASICPROPPARAMS::SetStringProperty+0x36a
6d0084d6 MSHTML!CFastDOM::CHTMLElement::Trampoline_Set_className+0x61
6d0cc04d JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4
6d0cc968 JSCRIPT9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x117
6d009a85 JSCRIPT9!Js::JavascriptOperators::SetProperty+0x8c
6d009a2c JSCRIPT9!Js::JavascriptOperators::OP_SetProperty+0x59
039507b8 JSCRIPT9!Js::JavascriptOperators::PatchPutValueNoLocalFastPath+0xbc
6d0084d6 0x39507b8
6d0083fb JSCRIPT9!Js::JavascriptFunction::CallFunction+0xc4
6d008332 JSCRIPT9!Js::JavascriptFunction::CallRootFunction+0xb6
6d0082be JSCRIPT9!ScriptSite::CallRootFunction+0x4f
6d0cf12c JSCRIPT9!ScriptSite::Execute+0x63
6d4f24d1 JSCRIPT9!ScriptEngine::Execute+0x11a
6d4f23fb MSHTML!CListenerDispatch::InvokeVar+0x12a
6d54ce40 MSHTML!CListenerDispatch::Invoke+0x40
6d44e624 MSHTML!CEventMgr::_InvokeListeners+0x187
6d54cf37 MSHTML!CEventMgr::_InvokeListenersOnWindow+0xcc
6d5db67d MSHTML!CEventMgr::Dispatch+0x3cc
6d53ba32 MSHTML!CEventMgr::DispatchFocusEvent+0x7d
6d5e6f74 MSHTML!COmWindowProxy::Fire_onfocus+0x84
6d5e6ff1 MSHTML!CAsyncEventQueue::DispatchAllEvents+0x7c
7748c4e7 MSHTML!GlobalWndProc+0x2ed
7748c5e7 USER32!InternalCallWinProc+0x23
7748cc19 USER32!UserCallWinProcCheckWow+0x14b
7748cc70 USER32!DispatchMessageWorker+0x35e
6e8e1b44 USER32!DispatchMessageW+0xf
6e901a16 IEFRAME!CTabWindow::_TabWindowThreadProc+0x722
759315b0 IEFRAME!LCIETab_ThreadProc+0x317
6e8efd5b IERTUTIL!CIsoScope::RegisterThread+0xab
75c4ed6c IEFRAME!Detour_DefWindowProcA+0x6c
773737f5 KERNEL32!BaseThreadInitThunk+0xe
773737c8 NTDLL!__RtlUserThreadStart+0x70
00000000 NTDLL!_RtlUserThreadStart+0x1b
EXPLOITATION
------------
Exploitation of this vulnerability is typical for a basic
use-after-free condition in Internet Explorer, in that the exploit:
(1) creates an object on the heap, (2) causes the object to be freed
while references to it persist elsewhere, (3) replaces the contents of
the heap memory formerly occupied by the object with arbitrary data,
and (4) causes Internet Explorer to access a stale reference to the
freed object. In a prepared proof-of-concept EIP control exploit
targeting Internet Explorer 9 (32-bit), these steps were accomplished
by: including two nested, named "div" elements in the HTML; modifying
the outer "div" element to destroy the inner "div" (while the mail
client error message is on the screen); performing a typical heap
spray to store known data at a known address; and creating a large
number of CTreePos-size heap blocks containing specially crafted data
to fill the hole left by the freed inner "div" element. The specially
crafted data includes a substitute vtable pointer which references
heap-sprayed data at a hard-coded address, another feature typical of
such exploits. The only step that this exploit cannot accomplish
entirely on its own is triggering Internet Explorer to access the
stale inner "div" element reference--this access occurs only after the
user dismisses the mail client error message.
MITIGATION
----------
Setting the "Downloads" -> "Font download" security setting to
"Disable" ("HKEY_CURRENT_USER\Software\Microsoft\CurrentVersion\Internet
Settings\Zones\<zone-identifier>" -> "1604": REG_DWORD = "3") prevents
exploitation of this vulnerability using the present technique.
Deleting, renaming, or denying read access to the
"HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PROTOCOLS\Handler\mailto"
registry key (and
"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\PROTOCOLS\Handler\mailto"
as appropriate) also prevents exploitation using the present
technique; however, after implementing the workaround, confirm that
clicking a "mailto:"; link in any zone does not display a message box.
CONCLUSION
----------
This document presents a long-lived vulnerability in Internet Explorer
which permits arbitrary code execution given default security
settings. Although current exploitation involves a modest amount of
user interaction and user notification in the form of a mail client
error message, the message is not security-related, and the message
box does not present the user with an option of aborting exploitation.
Further research into the vulnerability might reveal other means of
exploitation which may change the presented message or reduce or
eliminate the need for user interaction.
GREETINGS
---------
www.thetomatopizza.com
^ The best pizza anywhere near DFW; required eating for locals and remotes.
