linux中非法内存,Linux下数组非法访问导致内存破坏 —— 引发segmentation fault的原因...

2012-02-05 wcdj

1, 调试时必需的栈知识

2, 数组非法访问导致内存破坏

调试时必需的栈知识

栈(stack)是程序存放数据的内存区域之一，其特征是LIFO(Last In First Out, 后进先出)式数据结构，即后放进的数据最先备取出。向栈中存储数据的操作称为PUSH(压入)，从栈中取出数据称为POP(弹出)。在保存动态分配的自动变量时要使用栈。此外在函数调用时，栈还用于传递函数参数，以及用于保存返回地址和返回值。

#include

#include

#include

#define MAX (1UL << 20)

typedef unsigned long long u64;

typedef unsigned int u32;

u32 max_addend = MAX;

u64 sum_till_MAX(u32 n)

{

u64 sum;

n++;

sum = n;

if (n < max_addend)

sum += sum_till_MAX(n);

return sum;

}

int main(int argc, char** argv)

{

u64 sum = 0;

if ((argc == 2) && isdigit(*(argv[1])))

max_addend = strtoul(argv[1], NULL, 0);

if (max_addend > MAX || max_addend == 0) {

fprintf(stderr, "Invalid number is specified\n");

return 1;

}

sum = sum_till_MAX(0);

printf("sum(0..%lu) = %llu\n", max_addend, sum);

return 0;

}

计算从0到10的总和：

$ gcc -o sum -g sum.c

$ ./sum 10

sum(0..10) = 55

函数调用和栈的关系 —— 函数调用前后栈的变化情况

栈上依次保存了传给函数的参数、调用者的返回地址、上层栈帧指针和函数内部使用的自动变量。此外，处理有些函数时还会用栈来临时保存寄存器。每个函数都独自拥有这些信息，称为栈帧(stack frame)。此时需要适当地设置表示栈帧起始地址的帧指针(FP)。此外，栈指针(SP)永远指向栈的顶端。

数组非法访问导致内存破坏

错误地操作数组导致的典型bug之一就是缓冲区溢出，即向我们分配的内存空间之外写入数据。特别是，如果这类bug发生在栈上的缓冲区中，就可能引发安全漏洞，因此出现了许多预防措施和应对措施，如通过指定缓冲区大小来编写安全的函数、源代码检查工具、编译器在构建时的报警等。即便如此，这种bug仍时有发生。

下面通过一个简单的例子进行分析：

#include

#include

char szInfo[] = "Oops! here is a buffer overflow, wcdj";

void func()

{

char buf[5];

strcpy(buf, names);

}

int main()

{

func();

return 0;

}

编译：

gcc -Wall -g -o hack28 hack28.c

打开coredump：

ulimit -c unlimited

运行：

gerryyang@wcdj:~/test/HACK>./hack28

段错误 (coredumped)

gerryyang@wcdj:~/test/HACK> ls -rtl

总计 160K

-rw-r--r-- 1 gerryyang users    186 2012-02-05 14:17 hack28.c

-rwxr-xr-x 1 gerryyang users   7986 2012-02-05 14:17 hack28

-rw------- 1 gerryyang users 1474562012-02-05 14:17 core

下面对程序进行调试：

gerryyang@wcdj:~/test/HACK> gdb hack28 core

GNU gdb 6.6

Copyright (C) 2006 Free SoftwareFoundation, Inc.

GDB is free software, covered by the GNUGeneral Public License, and you are

welcome to change it and/or distributecopies of it under certain conditions.

Type "show copying" to see theconditions.

There is absolutely no warranty forGDB.  Type "show warranty" fordetails.

This GDB was configured as"i586-suse-linux"...

Using host libthread_db library"/lib/libthread_db.so.1".

warning: Can't read pathname for load map:Input/output error.

Reading symbols from /lib/libc.so.6...done.

Loaded symbols for /lib/libc.so.6

Reading symbols from/lib/ld-linux.so.2...done.

Loaded symbols for /lib/ld-linux.so.2

Core was generated by `./hack28'.

Program terminated with signal 11,Segmentation fault.

#0 0x73692065 in ?? ()

(gdb) bt

#0 0x73692065 in ?? ()

#1 0x62206120 in ?? ()

#2 0x65666675 in ?? ()

#3 0x766f2072 in ?? ()

#4 0x6c667265 in ?? ()

#5 0x202c776f in ?? ()

#6 0x6a646377 in ?? ()

#7 0xbfb48600 in ?? ()

#8 0xb7e5a89c in __libc_start_main () from /lib/libc.so.6

Backtrace stopped: previous frame inner tothis frame (corrupt stack?)

(gdb)x/i 0x73692065

0x73692065:     Cannot access memory at address 0x73692065

(gdb)x/i 0x62206120

0x62206120:    Cannot access memory at address0x62206120

(gdb)

backtrace无法正确显示，在这种情况下backtrace是不可靠的。因为backtrace显示的内容很可能不是实际跟踪的内容。即代码突然跳转到或者调用了错误的地址 0x73692065，导致了segmentation fault的发生。

注意：栈帧#0、#1显示的地址上很难放置程序、共享内存等。大多数i386架构的Linux发行版中，程序被定位到0x08000000地址附近，共享库被定位到0xb0000000之后的地址。因此，记住在调试对象的环境中，标准情况下程序和共享库会被定位到什么地址，在阅读backtrace时就会很方便。

(gdb) x/30c $sp

0xbfb48660:     32 ' ' 97 'a'  32 ' '  98 'b' 117 'u' 102 'f' 102 'f' 101 'e'

0xbfb48668:     114 'r' 32 ' '  111 'o' 118 'v' 101 'e' 114 'r' 102 'f' 108'l'

0xbfb48670:     111 'o' 119 'w' 44 ','  32 ' ' 119 'w' 99 'c'  100 'd' 106 'j'

0xbfb48678:     0 '\0' -122 '\206'     -76 '´' -65 '¿' -100 '\234'     -88 '¨'

(gdb) x/30c $sp-15

0xbfb48651:     31 '\037'       -8 'ø' 79 'O'  111 'o' 112 'p' 115 's' 33'!'  32 ' '

0xbfb48659:     104 'h' 101 'e' 114 'r'101 'e' 32 ' '  105 'i' 115's'32 ' '

0xbfb48661:     97 'a' 32 ' '  98 'b'  117 'u' 102 'f' 102 'f' 101 'e' 114 'r'

0xbfb48669:     32 ' ' 111 'o' 118 'v' 101 'e' 114 'r' 102 'f'

(gdb)p(char*)$sp-15

$1 = 0xbfb48651 "\037øOops! here is abuffer overflow, wcdj"

(gdb) x/30w $sp-15

0xbfb48651:     0x6f4ff81f      0x20217370      0x65726568      0x20736920

0xbfb48661:     0x75622061      0x72656666      0x65766f20      0x6f6c6672

0xbfb48671:     0x77202c77      0x006a6463      0x9cbfb486      0x01b7e5a8

0xbfb48681:     0x04000000      0x0cbfb487      0x3dbfb487      0x00b7f9cc

0xbfb48691:     0x90000000      0x01b7f8f6      0x01000000      0xf4000000

0xbfb486a1:     0xc0b7f81f      0x00b7fabc      0xd8000000      0x80bfb486

0xbfb486b1:     0x6140be86      0x0048efa8      0x00000000      0x00000000

0xbfb486c1:     0x70000000      0xcdb7fa20

寻找错误地写入0x73692065这个数据的地方。很重要的是需要怀疑数据是否为字符串的一部分，因为错误地将数据写入地址的典型情况之一就是字符串复制。由于字符串的输入长度很难预测，若缓冲区过小，再加上对输入字符串的长度检查不完善，就可能发生这种状况。考虑到i386架构为littleendian，因此怀疑是“...eis...”这个字符串的一部分被写入了。然后此假设进行验证。首先栈指针指向的空间前后几乎都是字符串，因此将这种字符串写入栈上的错误位置的可能性很高，而且通过代码发现buf只有5字节长，复制的字符串超过了这个长度，从而导致缓冲区溢出。

通过以上分析，错误的原因就是，strcpy()写入字符串的空间，原本是用于保存返回main()地址的空间，所以func()结束之后返回main()时，就把“...e is...”对应的0x73692065数值当做了函数的返回地址，从而导致segmentation fault。

本例中的地址是字符串的一部分，比较容易判断，而只是将数值错误地写入的情况会更难调查。即便如此，如果那个数值经常在程序中出现，就可以将调查范围缩小到使用该数值的部分。

有时确定在哪里写入的错误数值不好确定，还可以借用objdump工具。

gerryyang@wcdj:~/test/HACK> objdump -shack28

hack28：   文件格式 elf32-i386

.interp 节的内容：

8048154 2f6c6962 2f6c642d 6c696e75782e736f  /lib/ld-linux.so

8048164 2e3200

......

.got.plt 节的内容：

8049644 78950408 00000000 0000000006830408  x...............

8049654 16830408 26830408                    ....&...

.data 节的内容：

8049660 00000000 00000000 70950408 00000000  ........p.......

8049670 00000000 00000000 0000000000000000  ................

8049680 4f6f7073 21206865 72652069 73206120  Oops! here is a

8049690 62756666 6572206f 766572666c6f772c  buffer overflow,

80496a0 20776364 6a000000                     wcdj...

.comment 节的内容：

......

总结

确定内存内容被破坏的过程可以按照某种步骤进行，但找到引发破坏的地方就必须依靠一定的感觉和经验。

参考：Debug Hacks