The fstack-protector feature of gcc is used to detect Stack Overflow and its implementation.

The fstack-protector feature of gcc is used to detect Stack Overflow and its implementation.

I encountered another crash recently, and stack tracing is very weird.

/lib/i386-linux-gnu/libc.so.6(gsignal+0x4f) [0xb2b751df]/lib/i386-linux-gnu/libc.so.6(abort+0x175) [0xb2b78825]/lib/i386-linux-gnu/libc.so.6(+0x6b39a) [0xb2bb239a]/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x45) [0xb2c4b0e5]/lib/i386-linux-gnu/libc.so.6(+0x102eba) [0xb2c49eba]/ramdisk/xxxxxx() [0x8467639]/ramdisk/xxxxxx() [0x849a802]/ramdisk/xxxxxx() [0x84b75da]/ramdisk/xxxxxx(xxxxxxxxxxxx+0x444) [0x84b9224]

Among them, xxxxx is the company's modules and functions, so it is hidden. The analysis on the connection has no impact.

In the first place, the _ fortify_fail function was not touched. In addition, some stack backtracking functions do not have the corresponding symbols. I thought Array Overflow destroyed stack information. But in fact, I think it's wrong. If the stack information is damaged and unexpected, we should not be able to trace some very orderly functions. I am not on these functions.

Later, my colleague accidentally said that _ fortify_fail is a memory check, so I just Baidu used this _ fortify_fail function. Under what circumstances will this function be called?

I. Gcc compilation options-fstack-protector and-fstack-protector-all

The reason for the above error is that Stack Guard came up with a way to protect Stack information. Put a number of protections under the addresses of ebp and ip information. If the Stack overflows, then this 8-digit number will be modified, which will cause the function to enter the stack overflow error handler function, that is, the above stack.

II. Compare the disassembly code before and after the Add Option

Source code:

#include <stdio.h>int main(){        char a;        int i;        memcpy(&a,"ss",2);        printf("1\n");        memcpy(&i,"sssss",4);        printf("2\n");　　　　 return 0;}

Use gdb to debug the program. First, check the address of a and I,

(gdb) p &a$1 = 0xbffff69b "\b\364\037\374\267\220\204\004\b"(gdb) p &i$2 = (int *) 0xbffff694

Obviously, the address of variable a is higher, which is closer to the top of the stack. It can be proved that I overflow may not be detected, and a's detection will certainly be detected.

Let's take a look at the comparison of the assembly code.

The movw $0x7373 statement is to copy ss to a, so the difference between the whole program is to insert two sections of code. The two sections of code are used to detect local variables.

Stack during Overflow

#0  0xb7fdd424 in __kernel_vsyscall ()#1  0xb7e4f1ef in raise () from /lib/i386-linux-gnu/libc.so.6#2  0xb7e52835 in abort () from /lib/i386-linux-gnu/libc.so.6#3  0xb7e8a2fa in ?? () from /lib/i386-linux-gnu/libc.so.6#4  0xb7f20dd5 in __fortify_fail () from /lib/i386-linux-gnu/libc.so.6#5  0xb7f20d8a in __stack_chk_fail () from /lib/i386-linux-gnu/libc.so.6#6  0x08048485 in main ()

The error is the same as the previous error in this article.

3. An error occurred while modifying the reading code.

 

4. Summary

Of course, this action cannot completely suppress stack overflow. If the number of protections is skipped, the stack overflow still cannot be detected, and the overflow of other local variables is not protected. Of course, every variable protection will greatly increase the complexity of the program.