一次缓冲区溢出试验的收获

╰+攻爆jí腚メ 2022-09-18 06:52 130阅读 0赞

最近看了不少计算机底层的东西，感觉看汇编代码已经没有明显吃力的感觉，于是就想结合最近的阅读作些小东西，来印证书本上的知识。第一个想到的就是基于栈的缓冲区溢出攻击。  
关于缓冲区溢出攻击的原理，已经看了很多编了， 并不难理解，但是还是自己做个简单的实验来吧，纸上得来终觉浅。  
  
试验环境：Ubuntu 6.10 , Kernel version:2.6.17.10, gcc ：4.1.2 gdb:6.4.90  
  
代码如下：

![None.gif][] \# include <stdio.h>   
![None.gif][]   
![None.gif][]char buf\[\] =  \{  0x01 , 0x02 , 0x03 , 0x04 , 0x05 , 0x06 , 0x07 , 0x08 , 0x00 , 0x00 , 0x0a , 0Xff , 0X0D , 0X0E , 0X0F , 0X10 , 0XE4 , 0X83 , 0X04 , 0X08 , '' \};  
![None.gif][]  
![None.gif][]  
![None.gif][]void hack()  
![None.gif][]\{  
![None.gif][] printf  ( "  You have been hacked.  " );  
![None.gif][]\}  
![None.gif][]  
![None.gif][]void unsafecopy ( const  char  \*  src)  
![None.gif][]\{  
![None.gif][] char dest\[ 8 \];  
![None.gif][] strcpy(dest  , src);  
![None.gif][]\}  
![None.gif][]  
![None.gif][]  
![None.gif][]int main ()  
![None.gif][]\{  
![None.gif][] unsafecopy( buf );  
![None.gif][] printf ( "  I am not hacked .  " );  
![None.gif][] return  1 ;  
![None.gif][]\}  
![None.gif][]

实验目标：通过对buf恰当的赋值，使程序输出“You have been hacked.”  
  
按照书本上得来的知识，思路很简单，利用strcpy()不检查缓冲区长度的漏洞，传递给strcpy一个过长的数据源，从而覆盖属于unsafeco stack frame的返回地址，重写为hack()的地址，从而达到hack的目的。  
  
OK，那么buf应该的长度应该取多少？里面的内容又该如何赋值？ 这需要是用gdb 查看unsafecopy的反汇编代码来进一步确定。

![None.gif][] (gdb) disas unsafecopy  
![None.gif][]Dump of assembler code  for  function  unsafecopy :  
  
 ![None.gif][] 0x080483f8  < unsafecopy \+ 0 >:  push  % ebp  
![None.gif][] 0x080483f9  < unsafecopy \+ 1 >:  mov  % esp ,% ebp  
![None.gif][] 0x080483fb  < unsafecopy \+ 3 >:  sub $ 0x28 ,% esp  
  
![None.gif][] 0x080483fe  < unsafecopy \+ 6 >:  mov  0x8 ( % ebp) ,% eax  
![None.gif][] 0x08048401  < unsafecopy \+ 9 >:  mov  % eax , 0xffffffec ( % ebp)  
  
![None.gif][] 0x08048404 <unsafecopy+12>: mov %gs:0x14,%eax  
![None.gif][]0x0804840a <unsafecopy+18>: mov %eax,0xfffffffc(%ebp)  
![None.gif][]0x0804840d <unsafecopy+21>: xor %eax,% eax  
  
![None.gif][] 0x0804840f  < unsafecopy \+ 23 >:  mov  0xffffffec ( % ebp) ,% eax  
![None.gif][] 0x08048412  < unsafecopy \+ 26 >:  mov  % eax , 0x4 ( % esp)  
![None.gif][] 0x08048416  < unsafecopy \+ 30 >:  lea  0xfffffff4 ( % ebp) ,% eax  
![None.gif][] 0x08048419  < unsafecopy \+ 33 >:  mov  % eax , ( % esp)  
![None.gif][] 0x0804841c  < unsafecopy \+ 36 >:  call  0x804832c  < strcpy@plt >  
  
 ![None.gif][]0x08048421 <unsafecopy+41>: mov 0xfffffffc(%ebp),%eax  
![None.gif][]0x08048424 <unsafecopy+44>: xor %gs:0x14,%eax  
![None.gif][]0x0804842b <unsafecopy+51>: je 0x8048432 <unsafecopy+58>  
![None.gif][]0x0804842d <unsafecopy+53>: call 0x80482fc <\_\_stack\_chk\_fail@plt >  
  
 ![None.gif][] 0x08048432  < unsafecopy \+ 58 >:  leave  
![None.gif][] 0x08048433  < unsafecopy \+ 59 >:  ret

上面的汇编代码并不复杂，从中可以得到的信息有：  
  
1。局部缓冲区dest的位置从0xfffffff4(%ebp)，至0xfffffffc(%ebp)结束，即起始于-0xc(%ebp)，终结于-4(%ebp)，长度为8 bytes。  
2。位置-4(%ebp)处存储％gs:0x14的值，用途后面说明。  
3。返回地址(eip)的存储位置为4(%ebp)。  
4。传入的参数存放位置为8（%ebp)。  
  
由上面的信息，得出的结论是buf的长度为20 bytes——对应于栈中从-0xc(%ebp)至8（%ebp)的长度，且最后4字节应为hack()的地址：考虑到strcpy会执行复制直至在源字符串中遇到'/0'结束符号为止，buf还要在最后加上一个byte存放'/0'。  
  
用gdb查看hack()的入口地址: 0x080483e4  
  
  
于是，看起来这样对buf赋值就可以达到目的了  
char buf\[\]= \{0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0X0c,0X0d,0X0e,0X0f,0X10, 0XE4,0X83,0X04,0X08,'/0'\};  
  
重新编译后执行，结果如下：

![None.gif][] jekyll@ubuntu :~ $  ./ a . out  
![None.gif][] \*\*\*  stack smashing detected  \*\*\*:  ./ a . out terminated  
![None.gif][]忽略

这是怎么回事？前面进行的缓冲区溢出攻击在运行时被检测到了，自动终止了程序的运行。  
  
问题处在何处？问题就出在前面反汇编代码中红色标记的两段程序！  
  
第一段，将gs:0x14的值写入位置-4(%ebp)，特别注意这个位置紧跟自缓冲区之后  
第二段，在strcpy()执行完毕后，读取位置-4(%ebp)处的值，并与%gs:0x14的值进行比较,若不相等，则说明strcpy在执行时发生了越界访问，则跳转至\_\_stack\_chk\_fail@plt处，具体操作我没仔细看，但估计就是在这个跳转后程序被终止。  
  
这时候很自然的反应就是修改buf的赋值，使得strcpy在越界的时候将-4(%ebp)的原值重新写入，这样就能在越界的同时，逃开上述的检查。用gdb查看，可得知%gs:0x14的值为 0xff0a0000，那么，似乎将buf修改如下就可以成功了：  
  
  
  
char buf\[\]= \{0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08, 0x00,0x00,0x0a,0Xff,0X0D,0X0E,0X0F,0X10, 0XE4,0X83,0X04,0X08,'/0'\};  
  
再次编译，执行结果：  
  
jekyll@ubuntu:~$ ./a.out  
I am not hacked .  
  
晕阿，怎么回事，虽然程序没有被强制终止，但也没有执行我所期待的hack()函数，问题又处在何处？  
  
问题还是处在那个可恶的位置-4(%ebp)上，再看一下它的值： 0xff0a0000 ，按照i386架构的数据存储方式，在栈中由低地址至高地址依次为 0x00,0x00,0x0a,0xff 。问题就出在这里的0x00上，这不就是字符串终结符'/0' 嘛！现在明白了，由于buf的中间就不得不混入'/0',使得后面的字符不会被拷贝，因此，我想要达到的缓冲区溢出攻击是不可能实现的。  
  
这样看来，应该是gcc在实现C标准库时，考虑到strcpy的潜在安全隐患，通过这样一种机制来实现对缓冲区溢出攻击的防护。  
  
gcc真是狠啊，搞的我这么一个简答的试验都没法成功。  
  
果然是"纸上得来终觉浅"，理论和现实还是有很大距离的，从这个简单的试验可以看出，想要在现实中利用strcpy（）的漏洞实现缓冲区溢出攻击，并没有看起来这么简单，至少你得有个一个蹩脚的程序员和一个不够狠的编译器配合你。

[None.gif]: /images/20220828/877bc5eece544a4cb32fab199c742445.png