FireEye Research Labs identified a new Internet Explorer zero-day exploit used in targeted attacks.  The vulnerability nearly affects  all Internet Explorer versions (6/7/8/9/10/11).  The exploit bypasses ASLR/DEP.  CVE-2014-1776  was assigned to the vulnerability by Microsoft.

There is not any public PoC / Exploit of the vulnerability on web.  So we will not share it too.

Vulnerability and Analysis

Firstly,  Websense’s claim is not truth, the vulnerability is not a buffer overflow. This is exactly a use after free. The vulnerability exists within the object used by MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0x6. Exploit  forces to re-use a dangling pointer of the object and this causes use-after-free error.

Here is the crash point when we trigger the vulnerability with PoC.html. Crash occurs on MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0x6 function. The function tries to “mov” an object that ESI points.

After running !heap command  for a quick analysis,   we see that ESI points to an object which has been already free-ed:

The object  is free-ed by  MSHTML!Cmarkup::PrivateRelease function as we see in heap trace. If we look at these functions , we will see that it calls HeapFree function:

And this  free-ed  object  re-used by  MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0x6 and this causes the use after free condition.

Exploitation

Exploit uses Flash vector object technique to bypass ASLR and DEP successfully. This is a common technique which used by fresh exploits nowadays.  Exploit loads a flash file (SWF) before triggering the vulnerability and prepare the heap with this technique.

To exploit use after free vulns, firstly we should know what size of object allocated before it becomes free-ed ? If we can create a fake object with same size using heap spray, then it’s possible to exploit this vulnerability. So I looked the crash function and wanted to follow where ESI comes from etc.

So I put a breakpoint on MSHTML!CMarkup::IsConnectedToPrimaryMarkup  and want to look at the heap allocations until it crashes.

Here is the windbg command that I use;

BP MSHTML!CMarkup::IsConnectedToPrimaryMarkup “!heap -p -a esi; g”

and this is the result of windbg until it crashes:

[code]address 21be4bd8 found in
_DPH_HEAP_ROOT @ 1f1000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr   UserSize – VirtAddr    VirtSize)
21a038bc: 21be4bd8      428   – 21be4000   2000
MSHTML!CMarkup::`vftable’
553b8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77270d96 ntdll!RtlDebugAllocateHeap+0x00000030
7722af0d ntdll!RtlpAllocateHeap+0x000000c4
771d3cfe ntdll!RtlAllocateHeap+0x0000023a
60cc0ee7 MSHTML!CDoc::CreateMarkupFromInfo+0x00000158
60d0de89 MSHTML!CDoc::CreateMarkup+0x00000064
612a6329 MSHTML!RemoveDOMNodeHelper+0x00000093
60ed48a3 MSHTML!CElement::removeNode+0x00000033
611d87bf MSHTML!Method_IDispatchpp_oDoVARIANTBOOL+0x0000006f
61019697 MSHTML!CBase::ContextInvokeEx+0x000002b6
60e257a5 MSHTML!CElement::ContextInvokeEx+0x0000004c
61025e62 MSHTML!CElement::VersionedInvokeEx+0x0000002a
60d9f492 MSHTML!CBase::PrivateInvokeEx+0x0000006d
690c5ef6 jscript9!HostDispatch::CallInvokeEx+0x000000ae
690ce85a jscript9!HostDispatch::InvokeMarshaled+0x0000004b
690ce79a jscript9!HostDispatch::InvokeByDispId+0x000001cf
690ce5c3 jscript9!DispMemberProxy::DefaultInvoke+0x00000023
68fe7530 jscript9!Js::InterpreterStackFrame::Process+0x00001e3c
68fe7028 jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x000001e8

address 21be4bd8 found in
_DPH_HEAP_ROOT @ 1f1000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)
21a038bc: 21be4000 2000
553b90b2 verifier!AVrfDebugPageHeapFree+0x000000c2
77271564 ntdll!RtlDebugFreeHeap+0x0000002f
7722ac29 ntdll!RtlpFreeHeap+0x0000005d
771d34a2 ntdll!RtlFreeHeap+0x00000142
769514ad kernel32!HeapFree+0x00000014
60df4d1a MSHTML!CMarkup::`vector deleting destructor’+0x00000025
60c60492 MSHTML!CBase::PrivateRelease+0x00000103
60c59909 MSHTML!CMarkup::PrivateRelease+0x0000002c
60f6f811 MSHTML!CMarkup::ProcessPeerTask+0x00000066
60fd88a1 MSHTML!CMarkup::ProcessPeerTaskContext+0x0000008e
60fd8803 MSHTML!CMarkup::ProcessPeerTasks+0x0000003f
60fd9016 MSHTML!CElement::VersionedGetDispID+0x0000008f
61037a70 MSHTML!CBase::PrivateGetDispID+0x00000041
690c5d1c jscript9!HostDispatch::GetDispID+0x00000091
69172421 jscript9!HostDispatch::EnsureDispIdForProperty+0x0000003d
69172544 jscript9!HostDispatch::PutValue+0x00000019
69172521 jscript9!HostDispatch::SetPropertyCore+0x00000046
69172686 jscript9!HostDispatch::SetProperty+0x00000032
68fe29e1 jscript9!Js::JavascriptOperators::SetProperty_Internal+0x0000005c
6901fde7 jscript9!Js::JavascriptOperators::OP_SetProperty+0x00000040
6901fe43 jscript9!Js::JavascriptOperators::PatchPutValueNoFastPath+0x0000004d
6901f931 jscript9!Js::InterpreterStackFrame::Process+0x0000319d
68fe7028 jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x000001e8

(24c8.218c): 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=21be4bd8 edx=0a4bad54 esi=21be4bd8 edi=00000000
eip=60e15956 esp=0a4bad84 ebp=0a4badd4 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246
MSHTML!CMarkup::IsConnectedToPrimaryMarkup+0x6:
60e15956 8b86a4000000 mov eax,dword ptr [esi+0A4h] ds:002b:21be4c7c=????????
[/code]

So the object size is 0x428 and we should create a fake object with this size using heap spray technique to exploit this vulnerability.

Solution 

Actually VML is the not the root cause of the vulnerability so unregistering VGX.DLL  will only block the current exploit in the wild.

We are working with ZEMANA to release a 3rd party patch for this vulnerability soon. We will update you about the patch soon.