-2

I have the following code that I'm using to test buffer overflow:

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

int PasswordOkay() {
    char GoodPassword = 'F';
    printf("The memory address of GoodPassword is: %p\n", (void*) &GoodPassword);
    char Password[8];
    printf("The memory address of password is: %p\n", (void*) &Password);
    gets(Password);

    if(!strcmp(Password, "SPOCKSUX"))
        GoodPassword = 'T';
    return (GoodPassword == 'T');
}

int main() {
    puts("Enter Password:");
    if(PasswordOkay())
        puts("Hello, Dr. Bones");
    else
        puts("Access denied.");
}

On 32-bit the overflow works fine and 9T's as the password lets me succesfully log in.

On 64-bit I had these memory addresses:

The memory address of GoodPassword is: 0x7fff1b452a8f
The memory address of password is: 0x7fff1b452a80

So to try the overflow there, I did 16T's as the password. The login message appeared succesfull again, but it also gave a segmentation fault.(Which it did not with 32-bit).

My question is: Why does it give a segmentation fault on 64-bit? It shouldn't should it? Since I'm only overwriting GoodPassword.

Additional note: File was compiled with gcc, tried with optimizer on and off.

user3284549
  • 313
  • 3
  • 9
  • Why don't you use `fgets(Password, sizeof(Password), stdin);`? – Iharob Al Asimi Jan 27 '15 at 18:30
  • This is for educational testing of buffer overflow – user3284549 Jan 27 '15 at 18:31
  • Wound not 'not overflowing the buffer' be more educational? – Martin James Jan 27 '15 at 18:37
  • Please read [Why is the `gets()` function dangerous?](http://stackoverflow.com/questions/1694036/why-is-the-gets-function-dangerous-why-should-it-not-be-used) and then repent thy evil ways. Note that the maximum valid password you can enter into `char Password[8];` is 7 characters long, so it can never match an 8-letter password. – Jonathan Leffler Jan 27 '15 at 18:38
  • @Martin Not now, because the purpose of this is to learn how buffer overflow exploits work properly, so I can understand them well. – user3284549 Jan 27 '15 at 18:40
  • Understanding buffer overflows well enough to exploit them requires detailed knowledge of the platform on which you're working, and what works for a 32-bit program will seldom if ever work for 64-bit, and vice versa. You have to tailor your exploit to the actual environment it is running in. – Jonathan Leffler Jan 27 '15 at 18:42
  • Yeah I understand that in reality it will usually be much harder, but this is just about learning the basics at this point – user3284549 Jan 27 '15 at 18:44
  • Yes, exactly 16T: Enter Password: The memory address of GoodPassword is: 0x7fff85ef34cf The memory address of password is: 0x7fff85ef34c0 TTTTTTTTTTTTTTTT Hello, Dr. Bones Segmentation fault – user3284549 Jan 27 '15 at 18:46

2 Answers2

3

You're overflowing the buffer alright, but not all buffer overflows end with a segmentation fault. It depends on what you write, where, what your program (or the runtime library) does afterwards - all sorts of factors.

zmbq
  • 38,013
  • 14
  • 101
  • 171
3

You entered 16 characters (TTTTTTTTTTTTTTTT) but you also have to consider the terminating null character of the string as the 17th character which means that after GoodPassword another byte is also overwritten in the stack frame.

The addresses difference between GoodPassword and password is 15 (0x7fff1b452a8f - 0x7fff1b452a80) meaning GoodPassword is the 16th character and you have another off-by-one in your stack frame with the null byte.

If the byte right after (upper in the stack GoodPassword) is part of the frame pointer address or the saved stack pointer address (or even a security canary value!) you may have a segfault.

ouah
  • 142,963
  • 15
  • 272
  • 331
  • Ahh, I was not aware of the terminating null character. Thank you, just the answer I was looking for. – user3284549 Jan 27 '15 at 20:34
  • @user3284549 I answered because if I was asking the same question, I would not be satisfied with a simple "it is undefined behavior, so everything can happen". Most buffer overflow exploits are in the realm of undefined behavior so you better have to understand what is going on. – ouah Jan 27 '15 at 20:38