今日目标

今天细看了一下 narnia2（不知道这是什么的小伙伴看我前篇），是个栈溢出的练习。所以，Buffer Overflow，BoF，是今天的主题。这篇文章的标题是基础的基础，我们会把基于栈的溢出深入再深入地探讨一下。网上由很多关于栈溢出地基础例子和文章，想必大家也看过很多了。

带着下面几个问题，我们开始这篇 BoF 基础的基础。无论大家能不能回答这几个问题，看下去，总有一些新的收获。

BoF 的前世今生大家了解多少？BoF 有多少种类型？
都说栈溢出，首先，为什么你的程序会有栈？
漏洞叫做栈溢出，EBP，EIP，或者 BP，IP 是寄存器，一个在内存，一个在 CPU，为什么那些文章总说 EBP 和 EIP 会被覆盖，难道栈溢出还能溢出到 CPU ？
那些文章都提到 nop （\x90），nop 到底是什么？为什么要用 nop？

深入 BoF

我们先了解一下 BoF 的一小段历史，BoF 的种类，以及计算机科学家在与 BoF 做长达 20 余年的抗争之后，已经做出过哪些努力。

BoF 的前世今生

早在上世纪的 70 年代，BoF 就已经被发现和记载了。BoF 的可能性被出版在 Computer Security Technology Planning Study 这本书刊。我还在亚马逊找到了这本书，这价格就搞笑了 😂

在这里插入图片描述

言归正传。到 1988 年的时候，才出现有史以来第一次 BoF 的漏洞利用。当时有一个病毒叫做 Moris Worm，它利用几种计算机软件的漏洞在互联网传播，BoF 就是漏洞之一。

这之后，两个重大的蠕虫病毒，Code Red worm 和 SQL Slammer Worm 分别对微软的 IIS 5.0 服务器和 MSSQL Server 2000 进行了攻击。

看来，微软的产品真的不怎么安全。为了加强安全，微软在 2012 年发布了一篇文章，标题为 Security Development Lifecycle (SDL) Banned Function Calls，禁止使用一系列 C 和 C++ 的不安全方法。这是后话。

另外，大家熟知的 XBOX，PS2， Wii 等主机平台的破解，靠的都是某个类型的 BoF。

BoF 的产生，很多时候是程序员在写程序的过程中，使用了本身没有边界自测能力的函数或方法，这类函数或者方法，被称为 Unbounded Functions（暂且意译成无边界函数/方法），因为程序员无法判断什么时候这些方法会停止读取或者写入内存。因此，如果没有很好的手动的边界检测代码，直接使用这些无边界方法，后果就是 BoF。

BoF 的种类

BoF，Buffer Overflow 是所有溢出漏洞的统称。我们这篇文章在实践环节要讨论的，是基于栈的溢出（Stack Overflow）。我们来看一下 BoF 具体有哪些类型。

栈溢出 Stack Overflow，基于栈的溢出，利用不安全方法，通过写入指定长度的数据到栈空间，从而做到对程序跳转地址的控制，执行恶意代码
堆溢出 Heap Overflow，基于堆的溢出，高级话题，我都不知道怎么总结，以后碰到的时候再做特定的深入
整数溢出 Integer Overflow，将 long 这样的整数存入 int 型的变量，造成的溢出
字符编码溢出 Unicode Overflow，将 Unicode 字符存入 ASCII 类型的变量，造成的溢出

不同的溢出，使用的技巧各不相同。

BoF 的应对策略

科学家以及硬件制造商已经就 BoF 出台了多项管控政策。我们在这里做一下简单的介绍。

Memory Canary Value
Canary 是金丝雀，让我想起了 Android 中检测内存泄漏的工具叫 LeakCanary。为什么都喜欢用这个词？可能跟历史上用金丝雀在煤矿矿井中检测瓦斯泄露有关。说明金丝雀对于危险有一种警示的作用。
因为大多数 BoF 攻击使用的方式是覆盖栈中的数据，所以 Memory Canary 的大致原理，就是栈中的某个位置，放入一段固定的数据。如果这段固定的数据被修改过，那么就判定程序收到了攻击，程序员可以采取相应的错误处理，退出程序。但是，Canary Value 无法完全解决问题，因为某些情况是，其值是可猜测的，有一些固定的字符，降低了 Canary Value 的熵（理解为随机性）。因此，攻击者只需要耐心尝试并找到 Canary Value，重新写入一样的值，即可绕过其保护机制。
NX & DEP
BoF 攻击中，恶意代码会被植入到栈中或者内存的某一位置，让 CPU 去执行。因此，在硬件层面，NX（Linux）和 DEP（WIndows）允许操作系统标识某一内存区域（尤其是栈）为 non-executable，意思是非执行区域，那么 CPU 就不会去执行这块内存区域的任何指令。但问题是，不是所有的程序都认这一点。有些程序，就是要把指令放到栈中去执行，而且还是很重要的程序。所以，这种情况还是给攻击者留下了漏洞。攻击者找到这些知名的必须在栈中执行指令的程序，利用他们固定的方法 return 地址，来执行恶意操作。这样的技巧，被称为 Return-Oriented Programming（ROP）。
ASLR
为了解决上述 ROP 的问题，Address Space Layout Randomization (ASLR) 诞生。ASLR 可以随机指令在内存中的地址，让 ROP 无法找到准确的指令位置，从而防止攻击。又但是，ASLR 有同样的问题，不是所有的程序都很好的支持 ASLR，并且，ASLR 有时候还会愚蠢地将随机的地址保存到特定的位置，又给攻击者留下了操作空间。

所以，要完全应对 BoF，光靠这些保护机制是不够的。写程序的是人，重点还是如何正确理解方法的能力和限制，如何在代码中使用安全的库，如何到位地进行边界检测等，才是防御 BoF 的更有效的策略。

为什么程序会有栈？

了解历史总是枯燥的，但是时间会告诉你，好处多多。现在我们开始回答文首提出的问题。

为什么我们的程序会有栈？

关于什么是栈，这里不做讲解了。大家自行查阅相关的资料。

如果你问我，所有程序都有栈吗？我不能 100% 肯定，但是我可以肯定的是，有用的程序一定有栈。

我们可以从栈的作用来推断，只要程序中包含变量，栈就一定存在。

因此，我们今天主题，栈溢出，就有了根基。有栈，有无边界函数/方法的使用，栈溢出就发生了。

为什么 EBP 和 EIP 会在 BoF 中被覆盖？

话题越来越有意思了。

要回答这个问题，我们要明白上一个问题里为程序分配的栈中，有些什么东西。

栈帧（Stack Frame）以及方法调用

代码以及 Debug 的示意图都是来自 narnia2 程序。

当一个方法被调用的时候，一个栈帧会被创建并存入栈空间。这个栈帧，包含本次方法调用必要的参数，以及局部变量。一个栈帧，用 EBP 存储基地址（也叫栈帧地址，Frame Pointer），用 ESP 存储栈中数据的内存地址（称为 Stack Pointer）。

我们来看一下，在汇编中整个方法调用的流程骨架。我们不能看 GDB 给我们的汇编指令，因为根据反汇编出来的指令第一条是 push ebp，意思是 ebp 是在栈底，但是事实并非如此。所以，我们用 GDB 单步调试，查看内存中的内容，才能清楚看见方法调用的时候，栈中发生了什么。

我们可以用 GDB 查看 narnia2 程序的汇编指令，然后在 main <+0>, <+1>, <+3>, <+6>, <+81>, <+82> 这 6 行处打上断点（打断点用 b *<内存地址>）。

然后运行程序。如下图，会停在第一行断点处。

在这里插入图片描述

大家头脑中要清楚，目前，第一行汇编指令 push ebp 还没有执行。我们查看一下栈帧的情况。

神奇的事情发生了，我们的栈底，已经有了一个 eip，这个 eip 中的数据是 0xf7e2a286，也就是执行本条指令之前的指令的内存地址。我们的 main 方法调用结束之后，eip 将回到这个地址。

在这里插入图片描述

我们查看一下寄存器信息。

可以看到 esp 已经被初始化位栈底的地址，ebp 的值是 0x0。

在这里插入图片描述

为了确认我们的栈底确实保存了一个 eip，我们查看栈空间的内容。不用太多，查看 40 个字节即可。

可以看到，确实如 i frame 命令所示，在 0xffffd63c 的栈底的位置上，有一个 0xf7e2a286，是当前方法结束调用之后要返回的内存地址。

在这里插入图片描述

我们继续程序，到下一个断点。

在这里插入图片描述

当前，第一行指令 push ebp 已经执行。我们再看一下栈帧的情况。

在这里插入图片描述

栈中多了一个 ebp，被保存在 0xffffd638。

我们查看一下寄存器情况。

因为 push ebp，可以看到 esp 的值减去了 4 个字节（之前处于 0xffffd63c）。

在这里插入图片描述

我们再看一下内存情况。

ebp 的值为 0，因此，红框中的 4 个字节，就是保存下来的 ebp。可以看到，ebp 前面存放的是上一步 eip 的值。

在这里插入图片描述

我们继续程序。

在这里插入图片描述

当前，mov esp, ebp 指令执行完毕。我们看一下栈帧的情况。

可以看到，当 ebp 中有值之后，Arglist 和 Locals 都显示位于 0xffffd638。这是方法的参数，以及局部变量。

在这里插入图片描述

我们看一下寄存器的情况。

esp 的值被写入 epb，因此两个寄存器的值相等。

在这里插入图片描述

我们继续程序。

在这里插入图片描述

当前，add esp,0xffffff80 执行完毕。关于为什么是 add 而不是 sub，看这里。add esp, 0xffffff80 等于 sub esp, 0x8。大家也可以查看寄存器之后做下计算，当前指令分配了 128 字节空间给 buf 变量。

当前指令执行完毕之后，栈帧没有发生改变。

我们查看寄存器情况。

在这里插入图片描述

esp 的值变成 0xffffd5b8，与之前（0xffffd638）相差 128 个字节，也就是所说的分配给 buf 变量的空间。

我们继续程序，让程序执行中间的所有操作。

当前，我们停在 leave 指令上。我们先看一下各个方面的情况。

栈帧，没有变化。

在这里插入图片描述

寄存器，esp，ebp 没有变化。

在这里插入图片描述

查看栈空间。从 esp 指向的 0xffffd5b8 位置开始，写入了 128 个 A（0x41），一直写到 0xffffd637 的内存位置上。0xffffd638 的位置上，是之前保存的 ebp，值为 0x0。0xffffd63c 的位置上，保存的是之前 eip 的值。这是程序正常运行，没有溢出的情况下的栈空间情况。

在这里插入图片描述

我们继续程序。

在这里插入图片描述

当前，leave 指令执行完毕。我们看做了些什么操作。

首先，第一步操作是将上一步中的 ebp 的值（0xffffd638）写入到 esp，然后 pop ebp 将之前保存在栈中的 ebp 出栈。

可以看到栈帧中，ebp 不在栈空间。

在这里插入图片描述

另外，寄存器的情况，esp 指向了 0xffffd63c（0xffffd638 写入进去，再加上一个 pop 指令 + 4）。

在这里插入图片描述

再看一下内存空间的情况。

回到了第一步的情况，栈中只有一个之前 eip 的值。

在这里插入图片描述

好了，最后执行程序，栈底的整个 eip 的值写回 eip，CPU 回到这个地址继续执行任务。

方法调用小结：

初始化 esp，该 esp 的值为第 2 步中 eip 的保存地址
调用当前方法之前的 eip 的值，保存在栈底最为当前方法结束调用之后的要返回的地址
ebp 入栈
将当前 esp 的值写入 ebp，ebp 即指向栈底地址
分配空间给局部变量
执行方法中的指令
要退出方法之前，将 ebp 中的值写入 esp，销毁分配给局部变量的空间，然后 pop ebp，当前 esp 指向最初保存上一个 eip 的地址
执行 ret，pop eip，回到保存的 eip 的地址继续执行任务，栈销毁

矛盾
我在写这个小结的时候是有疑问的。之前在 DEBUG 程序的时候，确实显示 eip 被保存在栈帧中（i frame），栈帧有代表着整个栈。意味着第一步的时候，那个 0xffffd63c 应该是栈底地址。但是，我看的资料中又都说，EBP 指向的地址，才是栈底地址，所有的栈中寻址，都是相对于 EBP 而言，而这个 EBP 的地址，是在 push ebp 指令之后，由 mov ebp,esp 指令写入的，值为 0xffffd638。这就是我的矛盾，到底哪个是栈底地址？大家也一起考虑一下这个问题。

方法调用的前三行，

在这里插入图片描述

push ebp
mov ebp,esp
sub esp, %n ; n 是局部变量的空间

被称为函数序言（Function Prologue），任何方法的调用，在汇编形式中都以这三行指令开始（第三行可能是 sub esp, 0x8）。

好了，整个方法调用分析结束。

现在可以回答前面提出的问题，为什么 EBP 和 EIP 会被覆盖？

并不是因为溢出会到 CPU，这是玩笑。是因为 EBP 和 EIP 会在方法调用的时候被保存到栈空间。一旦缓冲区被溢出，那么势必会写入到保存的 EBP 和 EIP 中。

矛盾2
由此分析，EBP 和 EIP 肯定是在栈空间保存的，不然栈溢出不会覆盖掉 EIP 的值。但是哪个是栈底地址，还是无法确定。

我们知道了这个栈空间一共是 136 个字节，我们写给程序 128 个 A之后，4 个 B 将写入到保存的 EBP，4 个 C 将写入到保存的 EIP。

在这里插入图片描述

而这个保存的 EBP，在方法调用小结中的第 7 步，leave 汇编指令执行之后，pop 回 EBP 寄存器，所以大家在 gdb 或者 immunity debugger 中会看到程序崩溃之后，ebp 的值是 0x42。

在这里插入图片描述

而保存的 eip，也会在方法调用小结中的第 8 步，ret 汇编指令执行之后，pop 回 EIP 寄存器。由于 EIP 指向的地址应该是一个 CPU 可以执行的保存指令的内存地址，我们可以看一下在 0x43434343 这个地址上有什么。

在这里插入图片描述

触碰到了系统保留的内存空间，或者该内存空间上是 CPU 无法识别的指令（CPU 不区分数据或指令，EIP 指向的就是指令），就崩溃。所以为什么我们要做的是，将最后 4 个字节的 "C"，指向一个我们自己栈空间的地址，跳回去执行我们的 shellcode，程序就不会崩溃。

NOP

我们来回答第三个问题。

首先我们看一下什么是 NOP？

NOP，机器码 \x90，CPU 在遇到 NOP 的时候，什么操作都不会做（另一种说法是，会做没有实际影响的操作，比如不会改变寄存器的值等），直接跳到下一个地址继续执行指令。

接着我们看一下 NOP 的作用。

NOP 帮助攻击者NOP 在 BoF 中的使用简化了内存计算的过程，如果没有 NOP，我们就要计算出 shellcode 所在的精确的内存位置。但是有了 NOP，我们只需要将大片的栈空间填上 NOP，加上我们的 shellcode，那么最后控制 EIP 跳回的地址，只需要在第一片 NOP 中的任意位置即可。

当然，在简单的栈溢出中，这样的优势表现不明显，等以后遇到困难的逆向，需要计算内存偏移的时候，NOP 的优势就显现了。

另外，NOP 还有一种给 CPU 热身一样的作用。我并没有找到关于这个资料，所以只能自己根据代码行为来推断。比如在 narnia2 的情况下，至少需要 29 个 NOP 填充在 shellcode 之前，才能成功拿到 shell。

在这里插入图片描述

最后，因为 BoF 的攻击模式已经众所周知，所以现在好的杀软，都会针对 NOP 进行检测。但同时，安全研究员也在积极探索，找出 NOP 的替代指令（任意不会让 CPU 崩溃并且执行之后没有副作用的指令都可以作为 NOP 的替代）。

总结

BoF 的历史，发展轨迹，以及当前已有的应对策略，如 Canary Value，检测栈数据是否被串改；如Linux 下的 NX，Windows 下的 DEP，保护栈空间不被执行；还有 ASLR，随机化指令地址
方法调用的时候，EIP 和 EBP 寄存器中的值会被保存到栈空间，在方法调用之后，会被 pop 回相应的寄存器，因此，缓冲区溢出覆盖了栈中的 EIP 和 EBP，最后就会覆盖掉寄存器的值
NOP 可以为漏洞利用时的内存计算提供便利，同时也有让 CPU 最好执行 shellcode 准备的作用；\x90 机器码不是唯一的 NOP，任何不会让 CPU 崩溃且没有执行副作用的机器码，都可以作为 NOP 的替代指令，绕过杀软的扫描

参考链接：

0x03-逆向-BoF基础的基础

目录

今日目标

深入 BoF

BoF 的前世今生

BoF 的种类

BoF 的应对策略

为什么程序会有栈？

为什么 EBP 和 EIP 会在 BoF 中被覆盖？

栈帧（Stack Frame）以及方法调用

NOP

总结