堆栈保护程序适用于strcpy（）示例，但不适用于gets（）示例

Question

I am testing the GCC stack protector. When I overflow the buffer with an unsecure strcpy() function, the stack protector detects what I'm doing and throws the following exception:

*** stack smashing detected ***: ./a.out terminated
Aborted (core dumped)

When I do the same thing with an unsecure gets() function, I get a segmentation fault instead.

segmentation fault: 11

Why is this happening? What is the difference between these two cases? Here is the sample code I have been using

gets() example

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

void say_hello (void);

int main (){

        printf("Enter your name\n");
        say_hello();
        return 0;
}

void say_hello (void) {

        char name[5];
        gets(name); //this is a unsafe function to use. Results in stack overflow
        printf("Hello %s\n", name);

}

strcpy() example

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

int main(int argc, char** argv){

        char buffer [5];
        strcpy(buffer,argv[1]);


 return 0;

}

Answer 1

According to the documentation the strcpy() can cause overflow errors, because there is no check made wherever the data will fit in the new array or not. The outcome of this overflow may sometime never been noticed, it all depends on where the data is written. However a common outcome is heap and/or memory corruption.

A safe alternative of strcpy() is the usage of strcpy_s() that requires also the size of the array.

The same is valid for gets() or fgets() ,any of this outcome are possible:

• No visible affect what-so-ever
• Immediate program termination (a crash)
• Termination at a later point in the programs life time (maybe 1 second later, maybe 15 days later)
• Termination of another, unrelated program
• Incorrect program behaviour and/or calculation ... and the list goes on. This is the problem with "buffer overflow" bugs, you just can't tell when and how they'll bite you.

You can read more here . However your chance of smashing the stack increase if you have many nested calls to another functions (like it is in your fist case).

To conclude, in your situation is just happen to be so, because of their undefined behavior when an overflow occurs.