| 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 |
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)
