Blog | Talks | Docs | Tools | Advisories | About | RSS
Fermín J. Serna - Blog...
<<<<< July - 2015 >>>>>

6-Jul-2015 [11:40] -- IOKit fuzzing, sMethods and IDA

I was scanning through the BlackHat 2015 talks and found an IOKit fuzzing one. Nice! From the description it sounds they are doing something similar to some research I did in 2014: IOKit fuzzing and vulnerability research.

IOKit fuzzing is not as trivial as it sounds. A vulnerability researcher cannot simply send raw data and expect results. There are constrains such as input buffer size and output buffer size for each Method exposed by a UserClient instance. The kernel will simply reject any request with invalid sizes.

The only fuzzing way I have seen is a MiTM approach but that does not give you 100% coverage leaving a lot of bugs undiscovered.

The approach I take (part of a bigger project I someday will release *or not*) uses an IDA script to find those UserClient derived vtables and with some reverse engineering the exposed methods and the input/output buffer sizes. Since we do not have symbols it is not as straightforward as it seams so I used some heuristics to detect the vtables.

My script looks for references of a function that is highly unlikely to be overriden from an UserClient. This function is IOUserClient::getNotificationSemaphore(). Finding all references means we have found mainly all UserClient derived vtables. This still does not give us much since we do not know what functionality this UserClient exposes and the constrains to reach it.

Then, my approach is to see if IOUserClient::externalMethod() or IOUserClient::getTargetAndMethodForIndex() got overriden. If it happened the UserClient is exposing functionality and being more specific what we are looking for: sMethod table which describes functions, sizes, etc...

Now we know what to reverse and where to find sMethods. Some reversing can be automated since most of these overriden functions are very similar following Apple's guidelines... but some not.

As an example, here is Apple's way of exposing sMethods via getTargetAndMethodForIndex() and via externalMethod() table.

My IDA script can be found here.

And the output:

IOUserClient::getNotificationSemaphore at 8009c614 - IOUserClient::getTargetAndMethodFromIndex overriden (80418d58 - sub_80418D58) - IOUserClient::getTargetAndMethodFromIndex overriden (8043e3e0 - sub_8043E3E0) - IOUserClient::getTargetAndMethodFromIndex overriden (8045345c - sub_8045345C) - IOUserClient::getTargetAndMethodFromIndex overriden (804b7668 - sub_804B7668) - IOUserClient::externalMethod overriden (804d4754 - sub_804D4754) - IOUserClient::externalMethod overriden (804df834 - sub_804DF834) - IOUserClient::externalMethod overriden (8051bf18 - sub_8051BF18) - IOUserClient::externalMethod overriden (8056e984 - sub_8056E984) IOUserClient::getTargetAndMethodFromIndex overriden (8056ea4c - sub_8056EA4C)
[...] - IOUserClient::externalMethod overriden (807be4c0 - ) - - IOUserClient::externalMethod overriden (807e3d40 - sub_807E3D40) - IOUserClient::externalMethod overriden (807e6f0c - sub_807E6F0C) - IOUserClient::externalMethod overriden (808239dc - sub_808239DC) - IOUserClient::getTargetAndMethodFromIndex overriden (80824600 - sub_80824600) - IOUserClient::externalMethod overriden (8082d670 - ) IOUserClient::getTargetAndMethodFromIndex overriden (8082caac - ) - IOUserClient::externalMethod overriden (8083fdd0 - sub_8083FDD0) - IOUserClient::getTargetAndMethodFromIndex overriden (8084c2c4 - sub_8084C2C4)

Fermin J. Serna - @fjserna

Comments (0)

17-Sep-2014 [18:11] -- XNU Kernel stack and heap information leaks

Today Apple released IOS8 and then credited a lot of vulnerability researchers for fixed bugs. Find more information at

Here I am going to present details of 4 of them where I was credited: CVE-2014-4371, CVE-2014-4419, CVE-2014-4420 and CVE-2014-4421. As weird as it sounds, I found them on a plane reading the XNU kernel code :S

One of those is a "kernel stack content information leak" and was confirmed on latest version of MacOSX and IOS at the time I reported to Apple (May 8th 2014). PoC here: ntstat-x.c

$ ./ntstat_x
Leaked 4 bytes at the kernel stack: 0xd5d38dfd

The problem resides at the very end of the file
When going back to user mode you do not clear the field leaving it with the original stack contents.

if (result != 0)
struct nstat_msg_error err;

err.hdr.type = NSTAT_MSG_TYPE_ERROR;
err.hdr.context = hdr->context;
err.error = result;

result = ctl_enqueuedata(kctl, unit, &err, sizeof(err), CTL_DATA_EOR);

Fix should be to zero out the entire structure before setting fields and returning from kernel mode.

The other three instances of this info leak lead to another two kernel stack info leak and a more interesting heap info leak. I am pretty sure the last one can be used to leak pointers to the kernel and bypass K-ASLR.

Stack content leak: nstat_control_send_counts
Heap content leak: nstat_control_send_description
Stack content leak: nstat_control_send_removed

Fermin J. Serna - @fjserna

Comments (0)

21-Aug-2013 [13:26] -- CVE-2013-3186 - The case of a one click sandbox escape on IE

MSFT security updates for August 2013 contained a fix for a vulnerability I reported to MSRC some time ago. Behind a some kind cryptic title of "Internet Explorer Process Integrity Level Assignment Vulnerability " hides a 1 click sandbox escape (CVE-2013-3186).

Some context before the vulnerability. IE sandbox, called protected mode, is based on integrity levels where the renderer (where JS runs among other things) runs as Low Integrity level and the main frame runs as Medium Integrity level. They talk to each other through a broker RPC/pipe interface. A process running under Low IL can read almost anything in the system (ACL allowing) but can write to very few locations (TempLow for example). Basically protected mode is tackling the persistance problem of malware exploiting a security vulnerability at the Low IL process.

Find more about integrity levels and IE protected mode here.

Then we have the concept of ElevationPolicy which basically is a list of pairs (program & elevation policy) at the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy). These are the supported values:

3 - Protected Mode silently launches the broker as a medium integrity process.
2 - Protected Mode prompts the user for permission to launch the process. If permission is granted, the process is launched as a medium integrity process.
1 - Protected Mode silently launches the broker as a low integrity process.
0 - Protected Mode prevents the process from launching.

Basically, if there is an item there with ElevationPolicy 3 the broker will execute that program as Medium IL if requested.

And this is the case for msdt.exe. Funny thing is that CreateProcess() has a hook inside the LowIL IE process and if you try to CreateProcess("msdt.exe") it will get brokered to the IE Medium IL one and applied the Elevation policy there. Some sanitization happens to most of the parameters for security reasons (do not create a Medium IL process where the process token is too unrestricted, ...)

The vulnerability here is that msdt.exe (that due to its elevation policy will run as medium IL outside of any sandbox) has some interesting command line options. Concretely this one:

/path directory | .diagpkg file | .diagcfg file ----
Specifies the full path to a diagnostic package. If you specify a directory, the directory must contain a diagnostic package. You cannot use the /path parameter in conjunction with the /id, /dci, or /cab parameter.

This diagpkg is basically a troubleshooting cab/zip file composed of powershell scripts. msdt.exe initially will show an initial dialog with attacker controlled strings from the cab file (hello social engineering) and once the user clicks the continue button one of the attacker controlled powershell scripts will get executed (again as medium). Voila, sandbox escaped...

Couple of things worth mentioning:

Fermin J. Serna - @fjserna

Comments (0)

19-Jul-2013 [17:56] -- Flash JIT - Spraying ROP info leak gadgets

Long time no see... again!

Back in Fall/2012 I did some research on Flash JIT code generation. This research and lack of constant blinding resulted on the following paper (including Win7/IE9 exploit code for CVE-2012-4787) where Flash could be used for ASLR bypass on IE by spraying ROP info leak gadgets.

Exploit code:

I just found today (without notification from Adobe) that Flash 11.8 implements JIT constant blinding. So consider this technique gone but older versions may still be used for info leak purposes. :)

Fermin J. Serna - @fjserna

Comments (0)