View source for CVE-2014-4109 Microsoft Internet Explorer 6 through 11 內存損壞漏洞

==INFO==
Microsoft Internet Explorer 6 through 11 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, aka "Internet Explorer Memory Corruption Vulnerability," a different vulnerability than CVE-2014-2799, CVE-2014-4059, CVE-2014-4065, CVE-2014-4079, CVE-2014-4081, CVE-2014-4083, CVE-2014-4085, CVE-2014-4088, CVE-2014-4090, CVE-2014-4094, CVE-2014-4097, CVE-2014-4100, CVE-2014-4103, CVE-2014-4104, CVE-2014-4105, CVE-2014-4106, CVE-2014-4107, CVE-2014-4108, CVE-2014-4110, and CVE-2014-4111.

<pre>
This crash is difficult to reproduce.  The included proof of concept makes it a little easier to trigger the crashing code path.  My super scientific process of checking the crash was to click on the url with one hand and press enter with the other.  It usually crashes within 15 attempts.  "IE=9" also helps but isnt needed.

Its is a use after free of a script element.

		eax=00000000 ebx=00000000 ecx=094c9bd8 edx=00000000 esi=00000000 edi=094c9bd8
		eip=6d94ab83 esp=0943ca7c ebp=0943caa8 iopl=0         nv up ei pl zr na pe nc
		cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
		MSHTML!CMarkup::IsPrimaryMarkup+0xa:
		6d94ab83 8b87a4000000    mov     eax,dword ptr [edi+0A4h] ds:002b:094c9c7c=????????
		0:007> !heap -p -a edi
		    address 094c9bd8 found in
		    _DPH_HEAP_ROOT @ 9441000
		    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
		                                    9442af8:          94c9000             2000
		    754690b2 verifier!AVrfDebugPageHeapFree+0x000000c2
		    77cd1564 ntdll!RtlDebugFreeHeap+0x0000002f
		    77c8ac29 ntdll!RtlpFreeHeap+0x0000005d
		    77c334a2 ntdll!RtlFreeHeap+0x00000142
		    769614ad kernel32!HeapFree+0x00000014
		    6df61fa7 MSHTML!CMarkup::`scalar deleting destructor'+0x00000036
		    6db62649 MSHTML!CBase::SubRelease+0x0000002e
		    6d9bf02f MSHTML!CEventMgr::Dispatch+0x000005ba
		    6d9f5ae5 MSHTML!CEventMgr::DispatchEvent+0x00000115
		    6d9edcec MSHTML!COmWindowProxy::Fire_onload+0x0000016b
		    6e18cccc MSHTML!COmWindowProxy::DeferredFire_onload+0x0000000d  <---------------unique to crash stack trace
		    6d9c05c9 MSHTML!CAsyncEventQueue::DispatchAllEvents+0x00000086
		    6d9c0776 MSHTML!GlobalWndProc+0x000001df
		    75e362fa user32!InternalCallWinProc+0x00000023
		    75e36d3a user32!UserCallWinProcCheckWow+0x00000109
		    75e377c4 user32!DispatchMessageWorker+0x000003bc
		    75e3788a user32!DispatchMessageW+0x0000000f
		    7148bdfc IEFRAME!CTabWindow::_TabWindowThreadProc+0x00000445
		    715d602f IEFRAME!LCIETab_ThreadProc+0x0000031c
		    7649d14c iertutil!_IsoThreadProc_WrapperToReleaseScope+0x0000000e
		    754d31cc IEShims!NS_CreateThread::DesktopIE_ThreadProc+0x00000071
		    7696338a kernel32!BaseThreadInitThunk+0x0000000e
		    77c39f72 ntdll!__RtlUserThreadStart+0x00000070
		    77c39f45 ntdll!_RtlUserThreadStart+0x0000001b

The !heap command shows that edi was free'd.  This memory is then accessed in the crash.

		0:007> kb
		ChildEBP RetAddr  Args to Child              
		0943ca80 6df774f2 0d3c6fd8 10045ff0 1029ff01 MSHTML!CMarkup::IsPrimaryMarkup+0xa
		0943caa8 6e18cccc 0943cad8 6d9c05c9 0b6eff68 MSHTML!COmWindowProxy::Fire_onload+0x1bb
		0943cab0 6d9c05c9 0b6eff68 00000000 0b584cd0 MSHTML!COmWindowProxy::DeferredFire_onload+0xd  <---------------boom
		0943cad8 6d9c0776 00000001 10fbb424 00000000 MSHTML!CAsyncEventQueue::DispatchAllEvents+0x86
		0943cb28 75e362fa 000d03e4 0000001c 1029fff0 MSHTML!GlobalWndProc+0x1df
		0943cb54 75e36d3a 6d929676 000d03e4 00008003 user32!InternalCallWinProc+0x23
		0943cbcc 75e377c4 00000000 6d929676 000d03e4 user32!UserCallWinProcCheckWow+0x109
		0943cc2c 75e3788a 6d929676 00000000 0943fdfc user32!DispatchMessageWorker+0x3bc
		0943cc3c 7148bdfc 0943cc84 08e35fe0 00000000 user32!DispatchMessageW+0xf
		0943fdfc 715d602f 00000001 040e0ff0 08ab1fe8 IEFRAME!CTabWindow::_TabWindowThreadProc+0x445
		0943feb4 7649d14c 040dee48 00000000 0943fef0 IEFRAME!LCIETab_ThreadProc+0x31c
		0943fec4 754d31cc 040e0ff0 00000000 7649d13e iertutil!_IsoThreadProc_WrapperToReleaseScope+0xe
		0943fef0 7696338a 08ab1fe8 0943ff3c 77c39f72 IEShims!NS_CreateThread::DesktopIE_ThreadProc+0x71
		0943fefc 77c39f72 08ab1fe8 7bd40320 00000000 kernel32!BaseThreadInitThunk+0xe
		0943ff3c 77c39f45 754d315b 08ab1fe8 ffffffff ntdll!__RtlUserThreadStart+0x70
		0943ff54 00000000 754d315b 08ab1fe8 00000000 ntdll!_RtlUserThreadStart+0x1b

The crash only occurs when the DeferredFire_onload code path is taken.  This does not always happen and I haven't tried to figure out why.

In windbg you can use something like bp mshtml + 0x2a2635 "!heap -p -a ecx;dds @ecx L1;g" to print out the object being sent to CBase::SubRelease() and you'll see the following:

		0f368f38  704625b0 MSHTML!CScriptElement::`vftable'  <----dds shows a script element
		    address 0f36cbd8 found in
		    _DPH_HEAP_ROOT @ b0f1000
		    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
		                                 b0f39f4:          f36cbd8              428 -          f36c000             2000
		          MSHTML!CMarkup::`vftable'
		    75528e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
		    77cd0d96 ntdll!RtlDebugAllocateHeap+0x00000030
		    77c8af0d ntdll!RtlpAllocateHeap+0x000000c4
		    77c33cfe ntdll!RtlAllocateHeap+0x0000023a
		    754a1504 vfbasics!AVrfpRtlAllocateHeap+0x000000c3
		    70c4e993 MSHTML!_MemIsolatedAllocClear+0x00000010
		    704830b1 MSHTML!CDoc::DoNavigate_CreateMarkupForExistingWindow+0x00000057
		    708716e8 MSHTML!CDoc::DoNavigate+0x000008ae
		    704804e5 MSHTML!CDoc::FollowHyperlink2+0x0000096c
		    70483748 MSHTML!CWindow::SuperNavigateInternal+0x00000213
		    704837f0 MSHTML!CWindow::SuperNavigate2WithBindFlags+0x00000034
		    72637ba8 IEFRAME!CDocObjectHost::_NavigateDocument+0x0000019e
		    726379e1 IEFRAME!CDocObjectHost::SetTarget+0x00000411
		    7251eb63 IEFRAME!CDocObjectView::_CreateViewWindow+0x000000f5
		    7251ea1b IEFRAME!CDocObjectView::CreateViewWindow3+0x00000073
		    724de827 IEFRAME!FileCabinet_CreateViewWindow2+0x00000132
		    7251f667 IEFRAME!CBaseBrowser2::_CreateViewWindow+0x0000003a
		    7251f57a IEFRAME!CBaseBrowser2::_CreateNewShellView+0x0000016a
		    7251f3e5 IEFRAME!CBaseBrowser2::_CreateNewShellViewPidl+0x00000099
		    7251f29b IEFRAME!CBaseBrowser2::v_NavigateToPidl+0x0000019d
		    72638131 IEFRAME!CBaseBrowser2::_OnGoto+0x0000024c
		    72637edb IEFRAME!CBaseBrowser2::_OnAsyncOperation+0x00000043
		    724e1274 IEFRAME!CBaseBrowser2::v_WndProc+0x00000160
		    724dcace IEFRAME!CShellBrowser2::v_WndProc+0x000001ae
		    724c872d IEFRAME!CShellBrowser2::s_WndProc+0x00000058
		    75e362fa user32!InternalCallWinProc+0x00000023
		    75e36d3a user32!UserCallWinProcCheckWow+0x00000109
		    75e377c4 user32!DispatchMessageWorker+0x000003bc
		    75e3788a user32!DispatchMessageW+0x0000000f
		    724cbdfc IEFRAME!CTabWindow::_TabWindowThreadProc+0x00000445
		    7261602f IEFRAME!LCIETab_ThreadProc+0x0000031c
		    7649d14c iertutil!_IsoThreadProc_WrapperToReleaseScope+0x0000000e

		 
		0f36cbd8  70199aa0 MSHTML!CMarkup::`vftable'
		(674.338): Access violation - code c0000005 (first chance)
		First chance exceptions are reported before any exception handling.
		This exception may be expected and handled.
		eax=00000000 ebx=00000000 ecx=0f36cbd8 edx=00000000 esi=00000000 edi=0f36cbd8
		eip=701eab83 esp=0aeec674 ebp=0aeec6a0 iopl=0         nv up ei pl zr na pe nc
		cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
		MSHTML!CMarkup::IsPrimaryMarkup+0xa:
		701eab83 8b87a4000000    mov     eax,dword ptr [edi+0A4h] ds:002b:0f36cc7c=????????

The document.write() call in the proof of concept have nothing to do with the vulnerability, its just something that eats cycles.

@day6reak
</pre>