Internet Explorer Script Interjection Code Execution Derek Soeder ds.adv.pub@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.