Simple buffer overflow and shellcode example

Question

I've been trying to run Aleph One's example in order to get a BOF and open a shell.

This is Aleph One paper: http://insecure.org/stf/smashstack.html

And this is the simple C code (located nearly at the half of the paper):

char shellcode[] =
"\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00"
"\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80"
"\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff"
"\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3";

void main() {
   int *ret;

   ret = (int *)&ret + 2;
   (*ret) = (int)shellcode;
}

Now, I've tried running this program in an SSH bash, but without success.

Since nothing happened after running it, I guesses that I just didn't write the return address, so I used GDB to see the offset between the ret variable and the real return address, and realized it was 7.

In order to check myself, I tried increasing ret in 3,4,5,6, and indeed, only when I changed line 10 to:

   ret = (int *)&ret + 7;

I got a segmentation fault.

Yet, I do not understand why a bash isn't opened and I get this error instead.

P.S I was running on 'logic smashthestack' SSH servers (which one of their challenges is BOF): http://logic.smashthestack.org:88/

Thanks for the helpers.

Solution 1

From http://blog.markloiseau.com/2012/06/64-bit-linux-shellcode/:

This stub is an updated version of the classic shellcode test stub, with one key difference: In the new stub, the shellcode is #defined at compile-time so it can be placed directly into the main routine by gcc’s preprocessor.

This is necessary because over time, Linux and GCC have become much more cautious about which sections of an executable file can contain executable code (opposed to non-executable variables). The traditional version of the program won’t work on newer versions of Linux:

The classic shellcode c stub will generate a segfault on newer systems because the shellcode[] character array is stored in the explicitly non-executable .rodata section of the ELF file. When the computer recasts the non-executable array as a function and tries to run it, the program crashes

. Also note these changes to writing shellcode:

//old way
char[] shellcode ="shellcode..."
//new way
#define SHELLCODE "shellcode

Solution 2

The problem is in the shellcode. The shellcode is a const string, so you can not modify it. If you take a look at the disassembly of the shellcode, then you can see that the code tries to modify the string.

You could try to allocate memory and allocate the shellcode there. Might still not work, depending on the OS, as you may have to modify the protection settings to allow running code in the allocated memorxy block.

Reason for the self modification is that the stirng for executing the shell requires a 0 byte at the end, but this can not be contained in the string, so the code has to patch it before it can execute the shell. This is the reason for the SIGSEGV.

Your problem is almost identical to this one: Assembly Code keep showing segment fault

The shellcode is basically the same. Not exactly, but following the same principle.

Update

To explain this a bit better, the exploit will work if the BSS segment is writable. Declaring a string like this makes it, according to the C standard, const. Writing to a static string is undefined behaviour, so it can work or not.

Comments

[Devolus]

I don't know. Exploits are always using vulnerabilities which get fixed after they become known. And this is an exploit, so don't expect it to work for all eternity. You might check when this was written and under which OS. I debugged it with cygwin and looked at the code it tries to execute and could exactly see where the crash happens, which is why I linked to this other posting.

[Devolus]

I updated my answer with an additional explanation when this works. After thinking about it, I realized why it may work sometimes.

[qwr]

@MatthewPurdon the link was provided for the real source. One can see the answer Even the link is broken.