首页 > 代码库 > Linux下的栈溢出案例分析-GDB调试操练

Linux下的栈溢出案例分析-GDB调试操练

摘要:
 本文主要演示linux平台下的栈溢出,首先根据理论对示例代码进行溢出攻击;结果是溢出攻击成立,但是与设想的有差别;然后采用GDB调试工具对发生的意外,进行深入的分析。

测试的平台:
1.  ubuntu 9;   gcc 4.4.1;   Gdb 7.0-ubuntu
2.  ubuntu系统安装在virtual box 3.2.8虚拟机上;

示例代码如下:

#include<string.h>void overflow(char* arg){	char buf[12];	strcpy(buf, arg);}int main(int argc, char *argv[]){	if(argc > 1)		overflow(argv[1]);	return 0;}

如果按照一般的方式编译:
gcc –o stackoverflow stackoverflow.c
linux系统能够探测到程序中的stack  overflow,从而终止程序,如下图所示:

那有没有办法让系统不探测到stack overflow,此处可以在编译时,禁用堆栈保护,具体命令如下:
gcc –fno-stack-protector –o stackoverflow stackoverflow.c
然后采用gdb调试stackoverflow,

这里的输出跟设想的存在很大的差别,因为设想中的函数栈如下:

前面的12个字节填充buf,然后接下来的4个字节填充ebp,最后的4个字节填充RET地址,那么照理说,这里的eip应该是0x65656565,那为什么此处是0x61616161,刚好是aaaa的值呢?

根据单步调试的结果,发现eip变为0x61616161是在main函数退出后达到的,按照设想应该是在overflow退出时,eip变为0x65656565。

为什么overflow退出后还能回到main函数?可能的原因:输入的字符串没有覆盖掉ret地址,但是字符串却意外地将main的返回地址给覆盖掉了?

但就算是覆盖,为什么覆盖的值没有采用e的值,而是采用的a的值?要知道a是在字符串的起始处?这点的确让人奇怪。

1. 我们还是采用一步步调试的方式来观察问题所在,先看下gcc编译后的反汇编代码:
使用到的命令:
set disassembly-flavor intel  //将汇编设定为intel风格;
disassemble main  //反汇编main函数;

Main函数:

1. push ebp2. mvo ebp, esp3. and esp, 0xfffffff04. sub esp, 0x105. cmp DWORD PTR [ebp+0x8], 0x16. jle  0x804841d <main+31>7. mov eax, DWORD PTR [ebp+0xc]8. add eax, 0x49. mov eax, DWORD PTR [eax]10. mov DWORD PTR [esp], eax11. call 0x80483e4 <overflow>12. mov eax, 0x013. leave14. ret

然后再来看下,overflow的反汇编代码,命令:disassemble overflow
Overflow函数:

1. push ebp2. mov ebp, esp3. sub esp, 0x284. mov  eax, DWORD PTR[ebp+0x8]5. mov  DWORD PTR[esp+0x4], eax6. lea  eax, [ebp-0x14]7. mov  DWORD  PTR [esp], eax8. call  0x804831c <strcpy@plt>9. leave10. ret


我们单步调试上述的指令,关注其中esp值的变化。总图如下,后面是对其中每一步的分析:

在完成main.1后,命令p $esp后,esp的值变为:Esp = 0xbffff438
Main.3后,esp的值变为0xbffff430,估计是用于对齐;
Main.4后,esp的值为0xbffff420;
Main.7-10,这里主要将argv[]的arg[1]字符串的首地址取出来,并且将其放置在esp中,此时esp的值为0xbffff420;

执行overflow.1后,esp的值变为:0xbffff41c,其中存放着main的下一条语句的地址,
通过命令:x $esp可以看到overflow返回的地址:
0xbffff41c   0x0804841d
Overflow.1执行后,esp的值变为0xbffff418,用于存放ebp的值;
Overflow.3执行后,esp的值变为0xbffff3f0,
Overflow.5-7执行后,将字符串的地址放置在3f0+0x4地址处,然后再将临时字符串也即buf的首地址[ebp-0x14]放置在3f0地址处(当前的esp指向处);

执行完overflow.8后,我们查看buf起始处后,发现的确完成了内容的赋值,命令如下:
X 地址;

执行完leave指令后,发现esp的值变为:0xbffff41c,刚好指向的返回main的地址;然后再执行ret指令后,发现esp变为0xbffff420;然后,程序跳回到main函数;

然后再执行main函数中的leave指令,按照设想中leave指令执行后,esp的值应该变为43c,指向main的返回地址;但是实际我们执行后,esp的值变为0xbffff404,其中的内容刚好是0x61616161,也就是aaaa的值;这里我们测试时使用的参数的头四个字符刚好是aaaa;

到这里为止,就明白整个问题的症结:
 Main函数中调用leave指令时,esp的值并没有调整到位。本来应该指向43c(前面的地址忽略)的,此处却指向的404?
 那么为什么会产生这样的状况?照理说这是编译器该干的事,为什么此处编译器没有尽责呢?

奇怪的是:
 不发生栈溢出时,也即我们输入的字符串长度不超过12时,main中的leave指令执行后,程序可以正常的返回到43c的位置,顺利退出;
 那这里的问题就很奇怪了:栈溢出是发生在overflow中,程序可以从overflow中顺利返回到main中,然后main的leave指令就不正常了;如果overflow中没有栈溢出,程序也顺利返回到main函数,然后main的leave指令可以正常工作。

上述的问题的症结在于搞清楚leave指令本身;猜想其可能会依赖某些寄存器,或者依赖特定的存储单元来达到恢复目的。

首先看看能不能stepi进入leave;答案是leave是单条指令,不是一个处理函数;
所以我们试试能不能从寄存器上发现点什么,发现其实对照vistual studio中的操作,
Leave指令应该等效为:
 Mov  esp, ebp
 Pop  ebp

之前关注的都是esp,那按照上面的等效的话,接下来应该关注ebp寄存器的变化。所以,接下来要做的1. 首先验证上述的的等效成立,2. 要盯着ebp在执行过程中的变化。

对于问题1的验证,我们偷个懒,直接baidu之,发现的确符合我们的猜想,leave指令主要就是恢复esp和ebp之前的存储值。(后面顺带地测试了下,的确也主要做了对应的操作。)

如此我们就回到问题2,主要查看进入overflow和退出overflow时,以及进入main和退出main时,寄存器ebp值的变化。

会溢出的版本下,我们查看call strcpy前和后的ebp的值,如下图所示,我们发现调用strcpy函数的前与后过程中,ebp的值都是418(省略前面的),也就是说,调用strcpy函数过程前后ebp的值是正常的。

那么后续的执行leave指令,按照正常的版本(经过正常版本的验证),那么esp = 418,然后再经过pop ebp后,esp的值变为41c;而ebp的值应该恢复为438;

实际的执行后,esp如预期的发生变化,但是其中ebp的值却没有按照预想中的变化;那么问题只可能出在pop ebp这个语句,也只有一个原因:就是ebp存储的栈中的地址的内容被修改了,也就意味着418地址处的值在函数调用过程中被修改为400,原来应该是438。

那可能出现这种情况的也只有在overflow函数调用中,可能发生这样的情况。根据上述的分析,那我们在栈溢出版本中,在strcpy调用前后查看418处的值,即可证明这点。果然下面的图示正好说明该问题:

执行完strcpy函数后,看倒数最后一行,0xbffff418处的内容被修改为0xbffff400;作为对比,我们来看看非溢出版本的情况:

可以发现最后一行的ebp值没有被修改,因此,不会发生错误。

现在可以确定:ebp的值在溢出的strcpy调用中被修改了,从而导致主函数退出时的问题。那下面的问题是:strcpy是怎么样修改ebp值的?这个问题的解答要深入到strcpy的汇编代码里面,才能得到答案,本文不作探讨,有兴趣的可以再深入研究。

结论与启发:
1. 虽然函数是否可以顺利返回取决于栈上的返回地址,但是此例也让我们看到通过间接地修改ebp的值,也可以达到控制返回地址的目的;只不过这里的修改ebp值不会影响到当前函数的返回,但会影响上一级函数的返回;

2. 虽然对linux下的汇编不熟,但是借鉴visual studio下的代码的熟悉,还是容易读通linux下的汇编的;由此,可以体会的借鉴的价值,而借鉴的前提在于对某些技术的深入;

3. 找问题过程中,采用了对比的手法,比如对比BSD下的上述代码版本,可以按照设想的执行;让我确认上述代码的确存在问题;由此,可以体会对比的价值;

Linux下的栈溢出案例分析-GDB调试操练