我正在执行我的a.out文件。执行后程序运行一段时间然后退出并显示消息：
**** stack smashing detected ***: ./a.out terminated*
*======= Backtrace: =========*
*/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)Aborted*
可能的原因是什么？如何纠正？
答案 0 :(得分：289)
这里的堆栈粉碎实际上是由于gcc用来检测缓冲区溢出错误的保护机制引起的。例如，在以下代码段中：
#include <stdio.h>
void func()
{
char array[10];
gets(array);
}
int main(int argc, char **argv)
{
func();
}
编译器（在本例中为gcc）添加了具有已知值的保护变量（称为canaries）。大小大于10的输入字符串会导致此变量损坏，从而导致SIGABRT终止程序。
要获得一些见解，您可以尝试在编译时使用选项 -fno-stack-protector 禁用gcc的这种保护。在这种情况下，当您尝试访问非法内存位置时，您将收到不同的错误，很可能是分段错误。请注意，对于发布版本，应始终启用-fstack-protector，因为它是一种安全功能。
通过使用调试器运行程序，您可以获得有关溢出点的一些信息。 Valgrind与堆栈相关的错误不能很好地工作，但是像调试器一样，它可以帮助你确定崩溃的位置和原因。
答案 1 :(得分：19)
带有分解分析的最小复制示例
main.c
void myfunc(char *const src, int len) {
int i;
for (i = 0; i < len; ++i) {
src[i] = 42;
}
}
int main(void) {
char arr[] = {'a', 'b', 'c', 'd'};
int len = sizeof(arr);
myfunc(arr, len + 1);
return 0;
}
编译并运行：
gcc -fstack-protector -g -O0 -std=c99 main.c
ulimit -c unlimited && rm -f core
./a.out
根据需要失败：
*** stack smashing detected ***: ./a.out terminated
Aborted (core dumped)
在Ubuntu 16.04，GCC 6.4.0上进行了测试。
拆卸
现在我们来看一下反汇编：
objdump -D a.out
其中包含：
int main (void){
400579: 55 push %rbp
40057a: 48 89 e5 mov %rsp,%rbp
# Allocate 0x10 of stack space.
40057d: 48 83 ec 10 sub $0x10,%rsp
# Put the 8 byte canary from %fs:0x28 to -0x8(%rbp),
# which is right at the bottom of the stack.
400581: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax
400588: 00 00
40058a: 48 89 45 f8 mov %rax,-0x8(%rbp)
40058e: 31 c0 xor %eax,%eax
char arr[] = {'a', 'b', 'c', 'd'};
400590: c6 45 f4 61 movb $0x61,-0xc(%rbp)
400594: c6 45 f5 62 movb $0x62,-0xb(%rbp)
400598: c6 45 f6 63 movb $0x63,-0xa(%rbp)
40059c: c6 45 f7 64 movb $0x64,-0x9(%rbp)
int len = sizeof(arr);
4005a0: c7 45 f0 04 00 00 00 movl $0x4,-0x10(%rbp)
myfunc(arr, len + 1);
4005a7: 8b 45 f0 mov -0x10(%rbp),%eax
4005aa: 8d 50 01 lea 0x1(%rax),%edx
4005ad: 48 8d 45 f4 lea -0xc(%rbp),%rax
4005b1: 89 d6 mov %edx,%esi
4005b3: 48 89 c7 mov %rax,%rdi
4005b6: e8 8b ff ff ff callq 400546 <myfunc>
return 0;
4005bb: b8 00 00 00 00 mov $0x0,%eax
}
# Check that the canary at -0x8(%rbp) hasn't changed after calling myfunc.
# If it has, jump to the failure point __stack_chk_fail.
4005c0: 48 8b 4d f8 mov -0x8(%rbp),%rcx
4005c4: 64 48 33 0c 25 28 00 xor %fs:0x28,%rcx
4005cb: 00 00
4005cd: 74 05 je 4005d4 <main+0x5b>
4005cf: e8 4c fe ff ff callq 400420 <__stack_chk_fail@plt>
# Otherwise, exit normally.
4005d4: c9 leaveq
4005d5: c3 retq
4005d6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
4005dd: 00 00 00
请注意objdump的{{3}}自动添加的便捷注释。
如果您通过GDB多次运行该程序，则会看到：
myfunc的最后一个循环正是修改金丝雀的地址的地方通过将金丝雀设置为%fs:0x28来对其进行随机化处理，该金丝雀包含如下所述的随机值：
调试尝试
从现在开始，我们修改代码：
myfunc(arr, len + 1);
相反：
myfunc(arr, len);
myfunc(arr, len + 1); /* line 12 */
myfunc(arr, len);
变得更有趣。
然后，我们将尝试看看是否可以使用一种比仅仅阅读和理解整个源代码更加自动化的方法来查明罪魁祸首+ 1的调用。
gcc -fsanitize=address
如果使用此标志重新编译并运行程序，它将输出：
#0 0x4008bf in myfunc /home/ciro/test/main.c:4
#1 0x40099b in main /home/ciro/test/main.c:12
#2 0x7fcd2e13d82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#3 0x400798 in _start (/home/ciro/test/a.out+0x40079
接下来是一些彩色输出。
这清楚地指出了有问题的第12行。
Why does this memory address %fs:0x28 ( fs[0x28] ) have a random value?。
Valgrind SGCheck
像Thank Google一样，Valgrind也不擅长解决此类问题。
它确实具有实验工具mentioned by others：
SGCheck是用于查找堆栈和全局数组溢出的工具。它通过使用启发式方法来工作，该方法是从对堆栈和全局数组访问的可能形式的观察中得出的。
所以当它没有发现错误时，我并不感到惊讶：
valgrind --tool=exp-sgcheck ./a.out
错误消息看起来应该像这样：called SGCheck
GDB
一个重要的观察结果是，如果您通过GDB运行程序，或者在事后检查core文件：
gdb -nh -q a.out core
然后，正如我们在程序集上看到的那样，GDB应该将您指向进行canary检查的函数的结尾：
(gdb) bt
#0 0x00007f0f66e20428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007f0f66e2202a in __GI_abort () at abort.c:89
#2 0x00007f0f66e627ea in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7f0f66f7a49f "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007f0f66f0415c in __GI___fortify_fail (msg=<optimized out>, msg@entry=0x7f0f66f7a481 "stack smashing detected") at fortify_fail.c:37
#4 0x00007f0f66f04100 in __stack_chk_fail () at stack_chk_fail.c:28
#5 0x00000000004005f6 in main () at main.c:15
(gdb) f 5
#5 0x00000000004005f6 in main () at main.c:15
15 }
(gdb)
因此问题可能出在此函数进行的调用之一中。
接下来，我们尝试在设置金丝雀后立即进行一次单步定位，以找出确切的失败电话：
400581: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax
400588: 00 00
40058a: 48 89 45 f8 mov %rax,-0x8(%rbp)
并查看地址：
(gdb) p $rbp - 0x8
$1 = (void *) 0x7fffffffcf18
(gdb) watch 0x7fffffffcf18
Hardware watchpoint 2: *0x7fffffffcf18
(gdb) c
Continuing.
Hardware watchpoint 2: *0x7fffffffcf18
Old value = 1800814336
New value = 1800814378
myfunc (src=0x7fffffffcf14 "*****?Vk\266", <incomplete sequence \355\216>, len=5) at main.c:3
3 for (i = 0; i < len; ++i) {
(gdb) p len
$2 = 5
(gdb) p i
$3 = 4
(gdb) bt
#0 myfunc (src=0x7fffffffcf14 "*****?Vk\266", <incomplete sequence \355\216>, len=5) at main.c:3
#1 0x00000000004005cc in main () at main.c:12
现在，这确实使我们处于正确的冒犯指令：len = 5和i = 4，在这种特殊情况下，确实使我们指向了罪魁祸首第12行。
但是，回溯已损坏，并且包含一些垃圾。正确的回溯应如下所示：
#0 myfunc (src=0x7fffffffcf14 "abcd", len=4) at main.c:3
#1 0x00000000004005b8 in main () at main.c:11
因此，这可能会破坏堆栈并阻止您查看跟踪。
此外，此方法还需要知道金丝雀检查函数的最后一次调用是什么，否则您将产生误报，除非您Valgrind missing error，否则这并不总是可行的。
答案 2 :(得分：16)
请查看以下情况：
ab@cd-x:$ cat test_overflow.c
#include <stdio.h>
#include <string.h>
int check_password(char *password){
int flag = 0;
char buffer[20];
strcpy(buffer, password);
if(strcmp(buffer, "mypass") == 0){
flag = 1;
}
if(strcmp(buffer, "yourpass") == 0){
flag = 1;
}
return flag;
}
int main(int argc, char *argv[]){
if(argc >= 2){
if(check_password(argv[1])){
printf("%s", "Access granted\n");
}else{
printf("%s", "Access denied\n");
}
}else{
printf("%s", "Please enter password!\n");
}
}
ab@cd-x:$ gcc -g -fno-stack-protector test_overflow.c
ab@cd-x:$ ./a.out mypass
Access granted
ab@cd-x:$ ./a.out yourpass
Access granted
ab@cd-x:$ ./a.out wepass
Access denied
ab@cd-x:$ ./a.out wepassssssssssssssssss
Access granted
ab@cd-x:$ gcc -g -fstack-protector test_overflow.c
ab@cd-x:$ ./a.out wepass
Access denied
ab@cd-x:$ ./a.out mypass
Access granted
ab@cd-x:$ ./a.out yourpass
Access granted
ab@cd-x:$ ./a.out wepassssssssssssssssss
*** stack smashing detected ***: ./a.out terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xce0ed8]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xce0e90]
./a.out[0x8048524]
./a.out[0x8048545]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xc16b56]
./a.out[0x8048411]
======= Memory map: ========
007d9000-007f5000 r-xp 00000000 08:06 5776 /lib/libgcc_s.so.1
007f5000-007f6000 r--p 0001b000 08:06 5776 /lib/libgcc_s.so.1
007f6000-007f7000 rw-p 0001c000 08:06 5776 /lib/libgcc_s.so.1
0090a000-0090b000 r-xp 00000000 00:00 0 [vdso]
00c00000-00d3e000 r-xp 00000000 08:06 1183 /lib/tls/i686/cmov/libc-2.10.1.so
00d3e000-00d3f000 ---p 0013e000 08:06 1183 /lib/tls/i686/cmov/libc-2.10.1.so
00d3f000-00d41000 r--p 0013e000 08:06 1183 /lib/tls/i686/cmov/libc-2.10.1.so
00d41000-00d42000 rw-p 00140000 08:06 1183 /lib/tls/i686/cmov/libc-2.10.1.so
00d42000-00d45000 rw-p 00000000 00:00 0
00e0c000-00e27000 r-xp 00000000 08:06 4213 /lib/ld-2.10.1.so
00e27000-00e28000 r--p 0001a000 08:06 4213 /lib/ld-2.10.1.so
00e28000-00e29000 rw-p 0001b000 08:06 4213 /lib/ld-2.10.1.so
08048000-08049000 r-xp 00000000 08:05 1056811 /dos/hacking/test/a.out
08049000-0804a000 r--p 00000000 08:05 1056811 /dos/hacking/test/a.out
0804a000-0804b000 rw-p 00001000 08:05 1056811 /dos/hacking/test/a.out
08675000-08696000 rw-p 00000000 00:00 0 [heap]
b76fe000-b76ff000 rw-p 00000000 00:00 0
b7717000-b7719000 rw-p 00000000 00:00 0
bfc1c000-bfc31000 rw-p 00000000 00:00 0 [stack]
Aborted
ab@cd-x:$
当我禁用堆栈粉碎保护器时没有检测到错误，这应该发生在我使用“./a.out wepassssssssssssssssssss”的时候。
因此，为了回答上面的问题，显示消息“** stack smashing detected：xxx”，因为您的堆栈粉碎保护程序处于活动状态，并且发现程序中存在堆栈溢出。
找出发生的位置并修复它。
答案 3 :(得分：7)
您可以尝试使用valgrind调试问题：
目前Valgrind发行 包括六个生产质量的工具： 内存错误检测器，两个线程 错误检测器，缓存和 分支预测分析器，a 调用图生成缓存分析器， 和一个堆分析器。它还包括 两个实验工具：a 堆/堆栈/全局数组溢出 探测器和一个SimPoint基本块 矢量发电机。它运行在 以下平台：X86 / Linux， AMD64 / Linux，PPC32 / Linux，PPC64 / Linux， 和X86 / Darwin（Mac OS X）。
答案 4 :(得分：3)
这意味着您以非法方式写入堆栈中的某些变量，很可能是Buffer overflow的结果。
答案 5 :(得分：2)
可能的原因是什么？如何纠正？
以下示例中将介绍一种情况：
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void swap ( char *a , char *b );
void revSTR ( char *const src );
int main ( void ){
char arr[] = "A-B-C-D-E";
revSTR( arr );
printf("ARR = %s\n", arr );
}
void swap ( char *a , char *b ){
char tmp = *a;
*a = *b;
*b = tmp;
}
void revSTR ( char *const src ){
char *start = src;
char *end = start + ( strlen( src ) - 1 );
while ( start < end ){
swap( &( *start ) , &( *end ) );
start++;
end--;
}
}
在这个程序中，你可以反转字符串或字符串的一部分，例如你用这样的方式调用reverse()：
reverse( arr + 2 );
如果你决定像这样传递数组的长度：
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void swap ( char *a , char *b );
void revSTR ( char *const src, size_t len );
int main ( void ){
char arr[] = "A-B-C-D-E";
size_t len = strlen( arr );
revSTR( arr, len );
printf("ARR = %s\n", arr );
}
void swap ( char *a , char *b ){
char tmp = *a;
*a = *b;
*b = tmp;
}
void revSTR ( char *const src, size_t len ){
char *start = src;
char *end = start + ( len - 1 );
while ( start < end ){
swap( &( *start ) , &( *end ) );
start++;
end--;
}
}
也可以。
但是当你这样做时：
revSTR( arr + 2, len );
你得到：
==7125== Command: ./program
==7125==
ARR = A-
*** stack smashing detected ***: ./program terminated
==7125==
==7125== Process terminating with default action of signal 6 (SIGABRT)
==7125== at 0x4E6F428: raise (raise.c:54)
==7125== by 0x4E71029: abort (abort.c:89)
==7125== by 0x4EB17E9: __libc_message (libc_fatal.c:175)
==7125== by 0x4F5311B: __fortify_fail (fortify_fail.c:37)
==7125== by 0x4F530BF: __stack_chk_fail (stack_chk_fail.c:28)
==7125== by 0x400637: main (program.c:14)
发生这种情况是因为在第一个代码中arr的长度在revSTR()内检查，这很好，但在第二个代码中你传递了长度：
revSTR( arr + 2, len );
长度现在比你说arr + 2时传递的实际长度长。
strlen ( arr + 2 )的长度！= strlen ( arr )。
答案 6 :(得分：1)
堆栈损坏通常是由缓冲区溢出引起的。 你可以通过防御性编程来防御它们。
无论何时访问数组，都要在其前面放置一个断言，以确保访问不受限制。例如：
assert(i + 1 < N);
assert(i < N);
a[i + 1] = a[i];
这使您可以考虑数组边界，还可以考虑添加测试以在可能的情况下触发它们。如果其中一些断言在正常使用期间失败，请将它们转换为常规if。
答案 7 :(得分：0)
我使用malloc（）在花费一些调试代码后将一些内存分配给struct *时得到了这个错误，我最后使用free（）函数来释放分配的内存，随后错误信息消失了：）
答案 8 :(得分：0)
堆栈粉碎的另一个来源是（错误地）使用vfork()代替fork()。
我刚调试了一个案例，其中子进程无法execve()目标可执行文件并返回错误代码而不是调用_exit()。
因为vfork()已经产生了那个孩子，它在实际上仍然在父进程空间内执行时返回，不仅破坏了父进程的堆栈，而且导致两个不同的诊断集由“下游”代码打印。 / p>
将vfork()更改为fork()修复了这两个问题，将孩子的return语句更改为_exit()也是如此。
但由于子代码在execve()调用之前调用其他例程（在这种特殊情况下设置uid / gid），因此从技术上讲它不符合vfork()的要求，所以将其更改为使用fork()在此是正确的。
（请注意，有问题的return语句实际上并未编码 - 而是调用了一个宏，并且该宏根据全局决定是_exit()还是return因此，儿童代码与vfork()用法不一致并不是很明显。）
有关详细信息，请参阅：
答案 9 :(得分：0)
由于缺少return语句，导致出现此错误。