Recently, the U.S. Department of Labor website was compromised and had been serving malicious code, capable of detecting and disabling some antivirus products such as Avira, F-Secure, Kaspersky, AVG, Sophos, etc.  It would also attack Internet Explorer 8 users with an 0-day exploit.  The Metasploit vulnerability research community was particularly interested in the exploit part, therefore that's what we'd like to talk about in this blog. Understanding how the evolving browser security landscape operates is key to formulating defense strategies, after all.

First off, according to Microsoft's advisory, only Internet Explorer 8 is vulnerable to this exploit, and we verified that with a fully patched Windows 7 with IE8.  If you are looking for an excuse to upgrade to something more recent, the following image demonstrates IE8's weakness:

![](/content/images/post-images/17009/Screen Shot 2013-05-04 at 11.44.20 PM.png)

Some people say this is a CVE-2012-4792 (a patched vulnerability), we beg to differ.  CVE-2012-4792 is a cbutton use-after-free, but the DoL exploit doesn't use this object at all (Exodus has an excellent writeup about that vulnerability).  Instead, a mshtml!CGenericElement::`vtable' is created while appending a datalist element:

Allocating 0x4C bytes from InsertElementInternal: 0x0563cfb0 ... 0:008>
!heap -p -a poi(0x0563cfb0)
address 06a99fc8 found in
_DPH_HEAP_ROOT @ 151000
in busy allocation (
DPH_HEAP_BLOCK:
UserAddr
UserSize -
VirtAddr
VirtSize)
5087390:
6a99fc8
38 - 
6a99000
2000
mshtml!CGenericElement::`vftable'     7c918f01
ntdll!RtlAllocateHeap 0x00000e64     635db42e
mshtml!CGenericElement::CreateElement 0x00000018     635a67f5
mshtml!CreateElement 0x00000043     637917c0
mshtml!CMarkup::CreateElement 0x000002de     63791929
mshtml!CDocument::CreateElementHelper 0x00000052     637918a2
mshtml!CDocument::createElement 0x00000021     635d3820
mshtml!Method_IDispatchpp_BSTR 0x000000d1     636430c9
mshtml!CBase::ContextInvokeEx 0x000005d1     63643595
mshtml!CBase::InvokeEx 0x00000025     63643832
mshtml!DispatchInvokeCollection 0x0000014b     635e1cdc
mshtml!CDocument::InvokeEx 0x000000f1     63642f30
mshtml!CBase::VersionedInvokeEx 0x00000020     63642eec
mshtml!PlainInvokeEx 0x000000ea     633a6d37
jscript!IDispatchExInvokeEx2 0x000000f8     633a6c75
jscript!IDispatchExInvokeEx 0x0000006a     633a9cfe
jscript!InvokeDispatchEx 0x00000098

And freed during garbage collection:

0:008> !heap -p -a poi(0x0563cfb0)
address 06a99fc8 found in
_DPH_HEAP_ROOT @ 151000
in free-ed allocation (  DPH_HEAP_BLOCK:
VirtAddr
VirtSize)
5087390:
6a99000
2000
7c927553 ntdll!RtlFreeHeap 0x000000f9     636b52c6
mshtml!CGenericElement::`vector deleting destructor' 0x0000003d
63628a50 mshtml!CBase::SubRelease 0x00000022     63640d1b
mshtml!CElement::PrivateRelease 0x00000029     6363d0ae
mshtml!PlainRelease 0x00000025     63663c03
mshtml!PlainTrackerRelease 0x00000014     633a10b4
jscript!VAR::Clear 0x0000005c     6339fb4a
jscript!GcContext::Reclaim 0x000000ab     6339fd33 jscript!GcContext::CollectCore 0x00000113     63405594 jscript!JsCollectGarbage 0x0000001d     633a92f7 jscript!NameTbl::InvokeInternal 0x00000137     633a6650 jscript!VAR::InvokeByDispID 0x0000017c     633a9c0b jscript!CScriptRuntime::Run 0x00002989     633a5ab0 jscript!ScrFncObj::CallWithFrameOnStack 0x000000ff     633a59f7 jscript!ScrFncObj::Call 0x0000008f     633a5743 jscript!CSession::Execute 0x00000175

Even though the CGenericElement vftable is freed, the reference is stil kept:

0:008> dc 0x0563cfb0; .echo; dc poi(0x0563cfb0) 0563cfb0  06a99fc8
00000000 ffff0075 ffffffff  ........u....... 0563cfc0  00000071
00000000 00000000 00000000  q............... 0563cfd0  00000000
0563cfd8 00000152 00000001  ......c.R....... 0563cfe0  00000000
00000000 0563cfc0 00000000  ..........c..... 0563cff0  00000010
00000000 00000000 d0d0d0d0  ................ 0563d000  ????????
???????? ???????? ????????  ???????????????? 0563d010  ????????
???????? ???????? ????????  ???????????????? 0563d020  ????????
???????? ???????? ????????  ???????????????? 06a99fc8  ????????
???????? ???????? ????????  ???????????????? 06a99fd8  ????????
???????? ???????? ????????  ???????????????? 06a99fe8  ????????
???????? ???????? ????????  ???????????????? 06a99ff8  ????????
???????? ???????? ????????  ???????????????? 06a9a008  ????????
???????? ???????? ????????  ???????????????? 06a9a018  ????????
???????? ???????? ????????  ???????????????? 06a9a028  ????????
???????? ???????? ????????  ???????????????? 06a9a038  ???????? ???????? ???????? ????????  ????????????????

And of course, this invalid reference ends up with a crash when used by mshtml!CElement::Doc():

0:008> g (5f4.2c0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=63aae200
ebx=0563cfb0
ecx=06a99fc8
edx=00000000
esi=037cf0b8
edi=00000000
eip=6363fcc4
esp=037cf08c
ebp=037cf0a4
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::Doc: 6363fcc4 8b01
mov
eax,dword ptr [ecx]  ds:0023:06a99fc8=????????

As of now, we are not aware of any patch from Microsoft specifically for IE8, but we will be updating this blog as soon as we hear something.  If you're a current IE8 user, then please consider the following workarounds:

  • For newer Windows, upgrade to Internet Explorer 9 or 10.
  • For Windows XP users, please use other browsers such as Google Chrome or Mozilla Firefox.
  • If for some reason you must use Internet Explorer 8, please use EMET.  Or, you can also try setting IE's security zone to High, and customize your Active Scripting settings.

Note that while Microsoft's advisory also suggests setting IE8's Internet security zones to 'High' for ActiveX controls, this, by itself, will not mitigate -- the exploitation technique used here does not leverage ActiveX controls at all. So, while that is generally good advice, it will not help in this case.

If you'd like to try out this Metasploit module to better validate your defenses, please feel free to download Metasploit here.  If you already have Metasploit Framework, you may just use the msfupdate utility to receive this module.  For Metasploit Pro users, you will see this module in the upcoming update.

Special thanks to: EMH

TimelineMay 3rd - Microsoft advisory 2847140, no patch yet.May 5th - Metasploit releases ie_cgenericelement_uaf exploitMay 8th - Microsoft releases "fix-it"May 14th - Microsoft releases MS13-038 patch