Blog | Talks | Docs | Tools | Advisories | About | RSS
Fermín J. Serna - Blog...
<<<<< August - 2013 >>>>>
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

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.

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

Comments (0)

11-Mar-2013 [21:17] -- LLVM patch: VTXor

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

Comments (0)

26-Jul-2012 [10:53] -- BlackHat talk - Las Vegas 2012

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

Comments (4)