Tuesday, 16 June 2009

Exploiting code on Ubuntu

Ok, so it looks like it has been about a month since my first and only post and as far as I can tell, this is going to be a second post. I have had a number of ideas for things to go here and have now settled on something.

It will only be a short post (once the rambling is over) and to many I'm sure this will be quite basic. However, for a sysadmin looking at security, it might be helpful.

So, lets say you're reading a book like "Hacking, The Art of Exploitation" and you want to do some of the cool exercises on your shiny new Linux distro (Ubuntu Jaunty in my case). You may need to make a few adjustments to get things to work.

Disable address space randomization

This kernel option randomizes process address space (duh) which makes a basic exploit rather difficult:

With it turned off:

$ ./exploit
Stack pointer (ESP) : 0xbffff4b4
Offset from ESP : 0x0
Desired return addr : 0xbffff4b4

Now, turn it back on:

# echo 1 > /proc/sys/kernel/randomize_va_space
# cat /proc/sys/kernel/randomize_va_space
# exit
$ ./exploit
Stack pointer (ESP) : 0xbf9a4654
Offset from ESP : 0x0
Desired return addr : 0xbf9a4654
Segmentation fault
$ ./exploit
Stack pointer (ESP) : 0xbf86c524
Offset from ESP : 0x0
Desired return addr : 0xbf86c524
Segmentation fault
$ ./exploit
Stack pointer (ESP) : 0xbfc0d8c4
Offset from ESP : 0x0
Desired return addr : 0xbfc0d8c4
Segmentation fault

As you can see, the address in the ESP register is randomized, which makes filling the stack of the vulnerable process with a pre-determined address somewhat useless.

No stack protector and preferred stack boundary

The first gcc option specifically adds extra code to check for buffer overflows. Obviously, if you're playing with a vulnerable app you've written, you probably want to be able to exploit it.

The second option should help simplify stack smashing, although I haven't tested it much.

From the gcc manpage:

This extra alignment does consume extra stack space, and generally increases code size. Code that is sensitive to stack space usage, such as embedded systems and operating system kernels, may want to reduce the preferred alignment to -mpreferred-stack-boundary=2.

So, simply compile your code with the -fno-stack-protector and -mpreferred-stack-boundary options:

$ gcc -fno-stack-protector -mpreferred-stack-boundary=2 -ggdb -o vuln vuln.c

Note that I have also added the -ggdb debug symbols option to allow me to nicely debug the code.

Actually, while I'm on the subject, my current preferred gdb GUI is Insight. It has a nice source code view and a very good memory dumper. In fact, this might be the subject of my next post.

As you can see from the below code, not disabling stack protection makes a difference:

0x08048459 <main+69>: mov eax,0x0 <--- preparing our return 0
0x0804845e <main+74>: mov edx,DWORD PTR [ebp-0x8]
0x08048461 <main+77>: xor edx,DWORD PTR gs:0x14
0x08048468 <main+84>: je 0x804846 <--- FAIL
0x0804846a <main+86>: call 0x8048350 <__stack_chk_fail@plt>
0x0804846f <main+91>: add esp,0x214

No comments:

Post a Comment