Buffer Overflow - Find address of shellcode

Question

I've been working on Buffer-Overflow Vulnerability Lab from SEED (Lab Description and Tasks). The environment is Ubuntu 12.04 32 bit. Please consider the following code:

/* stack.c */
/* This program has a buffer overflow vulnerability. */
/* Our task is to exploit this vulnerability */
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int bof(char *str)
{
    char buffer[24];
    /* The following statement has a buffer overflow problem */
    strcpy(buffer, str);
    return 1;
}
 int main(int argc, char **argv)
{
    char str[517];
    FILE *badfile;
    badfile = fopen("badfile", "r");
    fread(str, sizeof(char), 517, badfile);
    bof(str);
    printf("Returned Properly\n");
    return 1;
}

I found that in order to overwrite the return address we would have to overwrite the array starting from 36th place because we would have to jump 24 bytes (the size of the array) plus 4 bytes (for the previous frame pointer) plus 8 bytes for the some compiler data (not specified for what purpose). I calculated this with the difference of the EBP and the address of the buffer (using the debugger).

I realized that in order to jump to the malicious code we can jump to any address on the NOP sled. For a sufficiently large value the attack succeeded. I tried to calculate the minimum possible address. The logic (and the lecturer) said it was EBP + 8 because we wanted to pass both the return address and the previous frame pointer (4 bytes each). Unfortunately the attack did not succeed when I tried to run it with that value. I found through an exhaustive search that the minimum possible address is 0xBFFFF168, which is EBP + 48, and I do not understand why. I even tried to run the attack without the NOP sled and encountered problems.

Can someone please explain? Below there is a description of the stack before and after the overrun and some additional values.

Thank you very much in advance.

14        strcpy(buffer, str);
(gdb) x/20x $sp
0xbffff100:    0x0804b008    0xbffff157    0x00000205    0xb7e34374
0xbffff110:    0xb7fc4ff4    0xb7fc4ff4    0x00000000    0xb7e1f900
0xbffff120:    0xbffff368    0xb7ff26b0    0x0804b008    0xb7fc4ff4
0xbffff130:    0x00000000    0x00000000    0xbffff368    0x080484ff
0xbffff140:    0xbffff157    0x00000001    0x00000205    0x0804b008
(gdb) next
16        return 1;
(gdb) x/20x $sp
0xbffff100:    0xbffff118    0xbffff157    0x00000205    0xb7e34374
0xbffff110:    0xb7fc4ff4    0xb7fc4ff4    0x90909090    0x90909090
0xbffff120:    0x90909090    0x90909090    0x90909090    0x90909090
0xbffff130:    0x90909090    0x90909090    0x90909090    0xbffff168
0xbffff140:    0x90909090    0x90909090    0x90909090    0x90909090
(gdb) p &buffer
$1 = (char (*)[24]) 0xbffff118
(gdb) p $ebp
$2 = (void *) 0xbffff138
(gdb) p $sp
$3 = (void *) 0xbffff100

Answer 1

The actual size of the stack depends greatly on compiler optimizations, and be affected by the presence of the debugger. In this case, minimizing the stack to ebp+8 isn't necessary, so I wouldn't overthink it.

Keep in mind that counting on stack organization to be the same run to run isn't a realistic exploit scenario anymore. In more realistic scenarios, you will be tasked with bypassing Nxbit/dep and ASLR, so counting on your exploit code to be somewhere in particular you can jump to wont cut it anyway.

If you want a NOP-sled free version of the attack, I would instead focus on finding a way to disclose an address without crashing the program. In such a small example, that may not be possible.