简体   繁体   中英

Program didn't crash when buffer overflow

I want to read a string from keyboard and store in buf . I set a char buf[6] array , this array at most can store 5 characters and \\0 .

Then I type 123 456 789 it contain 11 characters and a \\0 , the program still can run , but if I type a longer string 123 456 789 123 456 789 it will crash at run time . these two inputs also out of the range of buf , but one can run , the other crash?

Here is my code:

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

void read_str();

int main(){
    read_str();
    system("pause");
    return 0;
}
void read_str(){

    char buf[6] = {};
    scanf("%[^\n]",buf);
    printf("%d\n",strlen(buf));
    printf("%s\n",buf);
}

This is just undefined behavior to write outside the bounds of allocated memory. It may work now but it can not be relied on to work. The C99 draft standard in Annex J.2 Undefined behavior says:

An array subscript is out of range, even if an object is apparently accessible with the given subscript (as in the lvalue expression a[1][7] given the declaration int a[4][5]) (6.5.6).

Note that section 3.4.3 undefined behavior which defines the term in paragraph 2 says( emphasis mine ):

Possible undefined behavior ranges from ignoring the situation completely with unpredictable results , to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

The real reason is most likely that you're just overwriting the contents of your stack since you're in a function call, and you don't actually get to memory you don't own until you to try to write characters past the bottom of it. Even though it doesn't crash, this is almost always bad because you're overwriting values that your program put there for a reason. After all, if you always crashed every time you overwrote a buffer, then buffer overflow bugs could never occur, and we know they do.

For instance, your stack is likely growing downwards. When you make a function call, you might get register values, a return address, argument values, and other things placed onto the stack. Then, and only then, will your 6 bytes for buf be allocated. If all that other stuff took up, say, 12 bytes, then you could write 18 characters to buf and still be only touching memory that you shouldn't be changing, but that your process owns. Since your process owns it, you won't get an illegal memory access, and you won't crash. Once you go past the 18 bytes, then you may very well get into memory that your process doesn't own, and you'll get a segfault and the game will be up.

The C reason is that you just have undefined behavior and weird stuff happens that you shouldn't even try to understand.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM