C Buffer Overflow - how many bytes to input - c

Question

I made a simple C program to try understand buffer overflows. I am trying to overflow the input buffer so that flag gets changed to true and the program outputs "got here". The program is here (assume you have password.txt with hey in it):
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char **argv){
int flag = 0;
char pwd[5];
char input[5];
FILE *f = fopen("password.txt", "r");
fscanf(f, "%s", pwd);
fclose(f);
strcpy(input, argv[1]);
if(strcmp(input, pwd)){
printf("wrong password!\n");
}
else{
flag = 1;
printf("correct password!\n");
}
if(flag){
printf("you got into the secret place\n");
}
return 0;
}
So on the stack we have something like this I guess:
[high addresses]
flag ---> 4 bytes
pwd ---> 8 bytes
input ---> 8 bytes
[low addresses]
So I think I just need to give the program just 17 bytes to overwrite the flag variable. So i gave it aaaaaaaaaaaaaaaaa but that didn't work. I had to give it a 23 times, so 23 bytes. Why is 17 bytes not enough?

Answer 1

Disclaimer: I used Ubuntu 14.04 with gcc version 4.8.4, and complied your
code thusly gcc -m32 -g -ansi -pedantic -Wall temp.c -o temp. Different
compilers, or different options to gcc will, in all probability, give
different results.
I also modified you code slightly to make it easier to find things,
I changed line 6 to int flag = 0x41414141;
I changed line 25 to if(flag==1){
After compilation I run the executable under GDB, with a break point set
on main. And then disassembled main (after setting disassembly-flavor to
Intel), we get:
(gdb) disass
Dump of assembler code for function main:
0x0804857d <+0>: push ebp
0x0804857e <+1>: mov ebp,esp
0x08048580 <+3>: and esp,0xfffffff0
0x08048583 <+6>: sub esp,0x30
0x08048586 <+9>: mov eax,DWORD PTR [ebp+0xc]
0x08048589 <+12>: mov DWORD PTR [esp+0xc],eax
=> 0x0804858d <+16>: mov eax,gs:0x14
0x08048593 <+22>: mov DWORD PTR [esp+0x2c],eax
0x08048597 <+26>: xor eax,eax
0x08048599 <+28>: mov DWORD PTR [esp+0x18],0x41414141
The first four lines are the prolog for main The important thing to
notice is the line sub esp,0x30 where we are setting up the
stack frame for the function. As you can see we are subtracting 48 bytes
from esp. (actually a bit more because we first aligned the stack frame
to a 16-byte boundary).
Now, we can look at where our stack frame is by looking at the values
for ESP and EBP:
(gdb) info registers esp
esp 0xffffd110 0xffffd110
(gdb) info registers ebp
ebp 0xffffd148 0xffffd148
and we can find where things are located in the stack frame;
(gdb) print &pwd
$3 = (char (*)[5]) 0xffffd132
(gdb) print &flag
$4 = (int *) 0xffffd128
(gdb) print &input
$5 = (char (*)[5]) 0xffffd137
(gdb) print &f
$6 = (FILE **) 0xffffd12c
From this we can now deduce our stack layout. This memory image is
taken after running past where the program reads the command line
argument which was the string BBBBB (recall that the ASCII code for B is 0x42, so it is easy to see a sequence of 0x42 bytes)
(gdb) x/56xb $esp
0xffffd110: 0x37 0xd1 0xff 0xff
0xffffd114: 0xbf 0xd3 0xff 0xff
0xffffd118: 0x32 0xd1 0xff 0xff
0xffffd11c: 0xe4 0xd1 0xff 0xff
0xffffd120: 0x02 0x00 0x00 0x00
0xffffd124: 0xe4 0xd1 0xff 0xff
0xffffd128: 0x41 0x41 0x41 0x41 (flag)
0xffffd12c: 0x08 0xb0 0x04 0x08 (f)
0xffffd130: 0xc4 0xf3
0xffffd132: 0x68 0x65 0x79 0x00 0xff (pwd buffer)
0xffffd137: 0x42 0x42 0x42 0x42 0x42 (input buffer)
0xffffd13c: 0x00 0xd5 0x61 0x5d
0xffffd140: 0x60 0x86 0x04 0x08
0xffffd144: 0x00 0x00 0x00 0x00
Also note, that if I set the command line argument to BBBBBBBB we have this
for the contents of our stack frame
(gdb) x/56xb $esp
0xffffd110: 0x37 0xd1 0xff 0xff 0xbc 0xd3 0xff 0xff
0xffffd118: 0x32 0xd1 0xff 0xff 0xe4 0xd1 0xff 0xff
0xffffd120: 0x02 0x00 0x00 0x00 0xe4 0xd1 0xff 0xff
0xffffd128: 0x41 0x41 0x41 0x41 0x08 0xb0 0x04 0x08
0xffffd130: 0xc4 0xf3 0x68 0x65 0x79 0x00 0xff 0x42
0xffffd138: 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x00
0xffffd140: 0x60 0x86 0x04 0x08 0x00 0x00 0x00 0x00
Notice that the contents of the flag variable remains unchanged, but the contents of the now overflown input buffer moves toward the top of the stack. Recall that in x86 the stack grows downward (lower memory addresses). Also, because the buffer grows upward is why we can use a buffer overflow to over write stored EIP on the stack.
So on my system, I do not believe that it is possible to overwrite the flag variable with user input. You system might lay things out differently on the stack (you would need to do a similar exercise to verify this).
Also, note that the location of the variable on the stack does not correlate with the order that they are declared in the source file.

Answer 2

You can run into multiple problems when trying this.
The order of the local variable on the stack isn't necessarily in the same order as the one in the code. The compiler is free to rearrange them as he wish.
The compiler often aligns data to boundary for faster execution. This means the space between the different local variable can be much bigger than what you think. It's not uncommon to see stack variable aligned on a 8 or 16 bytes boundary even if it's content is much smaller.
You can get the disassembly of your program with objdump -D or debug it with gdb. This will give you a much better idea of the stack alignment in your program.