导致缓冲区溢出的常见 C 和 C++ 错误从根本上讲，在程序将数据读入或复制到缓冲区中的任何时候，它需要在复制 之前检查是否有足够的空间。能够容易看出来的异常就不可能会发生 ―― 但是程序通常会随时间而变更，从而使得不可能成为可能。
遗憾的是，C 和 C++ 附带的大量危险函数（或普遍使用的库）甚至连这点（指检查空间）也无法做到。程序对这些函数的任何使用都是一个警告信号，因为除非慎重地使用它们，否则它们就会成为程序缺陷。您不需要记住这些函数的列表；我的真正目的是说明这个问题是多么普遍。这些函数包括 strcpy(3)、strcat(3)、sprintf(3) （及其同类 vsprintf(3) ）和 gets(3) 。 scanf() 函数集（ scanf(3)、fscanf(3)、sscanf(3)、vscanf(3)、vsscanf(3) 和 vfscanf(3) ）可能会导致问题，因为使用一个没有定义最大长度的格式是很容易的（当读取不受信任的输入时，使用格式“%s”总是一个错误）。
其他危险的函数包括 realpath(3)、getopt(3)、getpass(3)、streadd(3)、strecpy(3) 和 strtrns(3) 。 从理论上讲， snprintf() 应该是相对安全的 ―― 在现代 GNU/Linux 系统中的确是这样。但是非常老的 UNIX 和 Linux 系统没有实现 snprintf() 所应该实现的保护机制。
Microsoft 的库中还有在相应平台上导致同类问题的其他函数（这些函数包括 wcscpy()、_tcscpy()、_mbscpy()、wcscat()、_tcscat()、_mbscat() 和 CopyMemory() ）。注意，如果使用 Microsoft 的 MultiByteToWideChar() 函数，还存在一个常见的危险错误 ―― 该函数需要一个最大尺寸作为字符数目，但是程序员经常将该尺寸以字节计（更普遍的需要），结果导致缓冲区溢出缺陷。
另一个问题是 C 和 C++ 对整数具有非常弱的类型检查，一般不会检测操作这些整数的问题。由于它们要求程序员手工做所有的问题检测工作，因此以某种可被利用的方式不正确地操作那些整数是很容易的。特别是，当您需要跟踪缓冲区长度或读取某个内容的长度时，通常就是这种情况。但是如果使用一个有符号的值来存储这个长度值会发生什么情况呢 ―― 攻击者会使它“成为负值”，然后把该数据解释为一个实际上很大的正值吗？当数字值在不同的尺寸之间转换时，攻击者会利用这个操作吗？数值溢出可被利用吗？ 有时处理整数的方式会导致程序缺陷。
防止缓冲区溢出的新技术当然，要让程序员 不犯常见错误是很难的，而让程序（以及程序员）改为使用另一种语言通常更为困难。那么为何不让底层系统自动保护程序避免这些问题呢？最起码，避免 stack-smashing 攻击是一件好事，因为 stack-smashing 攻击是特别容易做到的。
一般来说，更改底层系统以避免常见的安全问题是一个极好的想法，我们在本文后面也会遇到这个主题。事实证明存在许多可用的防御措施，而一些最受欢迎的措施可分组为以下类别：
- 基于探测方法（canary）的防御。这包括 StackGuard（由 Immunix 所使用）、ProPolice（由 OpenBSD 所使用）和 Microsoft 的 /GS 选项。
- 非执行的堆栈防御。这包括 Solar Designer 的 non-exec 补丁（由 OpenWall 所使用）和 exec shield（由 Red Hat/Fedora 所使用）。
- 其他方法。这包括 libsafe（由 Mandrake 所使用）和堆栈分割方法。
遗憾的是，迄今所见的所有方法都具有弱点，因此它们不是万能药，但是它们会提供一些帮助。
基于探测方法的防御研究人员 Crispen Cowan 创建了一个称为 StackGuard 的有趣方法。Stackguard 修改 C 编译器（gcc），以便将一个“探测”值插入到返回地址的前面。“探测仪”就像煤矿中的探测仪：它在某个地方出故障时发出警告。在任何函数返回之前，它执行检查以确保探测值没有改变。如果攻击者改写返回地址（作为 stack-smashing 攻击的一部分），探测仪的值或许就会改变，系统内就会相应地中止。这是一种有用的方法，不过要注意这种方法无法防止缓冲区溢出改写其他值（攻击者仍然能够利用这些值来攻击系统）。人们也曾扩展这种方法来保护其他值（比如堆上的值）。Stackguard（以及其他防御措施）由 Immunix 所使用。
IBM 的 stack-smashing 保护程序（ssp，起初名为 ProPolice）是 StackGuard 的方法的一种变化形式。像 StackGuard 一样，ssp 使用一个修改过的编译器在函数调用中插入一个探测仪以检测堆栈溢出。然而，它给这种基本的思路添加了一些有趣的变化。 它对存储局部变量的位置进行重新排序，并复制函数参数中的指针，以便它们也在任何数组之前。这样增强了ssp 的保护能力；它意味着缓冲区溢出不会修改指针值（否则能够控制指针的攻击者就能使用指针来控制程序保存数据的位置）。默认情况下，它不会检测所有函数，而只是检测确实需要保护的函数（主要是使用字符数组的函数）。从理论上讲，这样会稍微削弱保护能力，但是这种默认行为改进了性能，同时仍然能够防止大多数问题。考虑到实用的因素，它们以独立于体系结构的方式使用 gcc 来实现它们的方法，从而使其更易于运用。从 2003 年 5 月的发布版本开始，广受赞誉的 OpenBSD（它重点关注安全性）在他们的整个发行套件中使用了 ssp（也称为 ProPolice）。
Microsoft 基于 StackGuard 的成果，添加了一个编译器标记（/GS）来实现其 C 编译器中的探测仪。
非执行的堆栈防御另一种方法首先使得在堆栈上执行代码变得不可能。 遗憾的是，x86 处理器（最常见的处理器）的内存保护机制无法容易地支持这点；通常，如果一个内存页是可读的，它就是可执行的。一个名叫 Solar Designer 的开发人员想出了一种内核和处理器机制的聪明组合，为 Linux 内核创建了一个“非执行的堆栈补丁”；有了这个补丁，堆栈上的程序就不再能够像通常的那样在 x86 上运行。 事实证明在有些情况下，可执行程序 需要在堆栈上；这包括信号处理和跳板代码（trampoline）处理。trampoline 是有时由编译器（比如 GNAT Ada 编译器）生成的奇妙结构，用以支持像嵌套子例程之类的结构。Solar Designer 还解决了如何在防止攻击的同时使这些特殊情况不受影响的问题。
Linux 中实现这个目的的最初补丁在 1998 年被 Linus Torvalds 拒绝，这是因为一个有趣的原因。即使不能将代码放到堆栈上，攻击者也可以利用缓冲区溢出来使程序“返回”某个现有的子例程（比如 C 库中的某个子例程），从而进行攻击。简而言之，仅只是拥有非可执行的堆栈是不足够的。
一段时间之后，人们又想出了一种防止该问题的新思路：将所有可执行代码转移到一个称为“ASCII 保护（ASCII armor）”区域的内存区。要理解这是如何工作的，就必须知道攻击者通常不能使用一般的缓冲区溢出攻击来插入 ASCII NUL 字符（0)这个事实。 这意味着攻击者会发现，要使一个程序返回包含 0 的地址是很困难的。由于这个事实，将所有可执行代码转移到包含 0 的地址就会使得攻击该程序困难多了。
具有这个属性的最大连续内存范围是从 0 到 0x01010100 的一组内存地址，因此它们就被命名为 ASCII 保护区域（还有具有此属性的其他地址，但它们是分散的）。与非可执行的堆栈相结合，这种方法就相当有价值了：非可执行的堆栈阻止攻击者发送可执行代码，而 ASCII 保护内存使得攻击者难于通过利用现有代码来绕过非可执行堆栈。这样将保护程序代码避免堆栈、缓冲区和函数指针溢出，而且全都不需重新编译。
然而，ASCII 保护内存并不适用于所有程序；大程序也许无法装入 ASCII 保护内存区域（因此这种保护是不完美的），而且有时攻击者 能够将 0 插入目的地址。 此外，有些实现不支持跳板代码，因此可能必须对需要这种保护的程序禁用该特性。Red Hat 的 Ingo Molnar 在他的“exec-shield”补丁中实现了这种思想，该补丁由 Fedora 核心（可从 Red Hat 获得它的免费版本）所使用。最新版本的 OpenWall GNU/Linux (OWL)使用了 Solar Designer 提供的这种方法的实现（请参阅 以获得指向这些版本的链接）。
其他方法还有其他许多方法。一种方法就是使标准库对攻击更具抵抗力。Lucent Technologies 开发了 Libsafe，这是多个标准 C 库函数的包装，也就是像 strcpy() 这样已知的对 stack-smashing 攻击很脆弱的函数。Libsafe 是在 LGPL 下授予许可证的开放源代码软件。那些函数的 libsafe 版本执行相关的检查，确保数组改写不会超出堆栈桢。然而，这种方法仅保护那些特定的函数，而不是从总体上防止堆栈溢出缺陷，并且它仅保护堆栈，而不保护堆栈中的局部变量。它们的最初实现使用了 LD_PRELOAD ，而这可能与其他程序产生冲突。Linux 的 Mandrake 发行套件（从 7.1 版开始）包括了 libsafe。
另一种方法称为“分割控制和数据堆栈”―― 基本的思路是将堆栈分割为两个堆栈，一个用于存储控制信息（比如“返回”地址），另一个用于控制其他所有数据。Xu et al. 在 gcc 中实现了这种方法，StackShield 在汇编程序中实现了这种方法。这样使得操纵返回地址困难多了，但它不会阻止改变调用函数的数据的缓冲区溢出攻击。
事实上还有其他方法，包括随机化可执行程序的位置；Crispen 的“PointGuard”将这种探测仪思想引申到了堆中，等等。如何保护当今的计算机现在已成了一项活跃的研究任务。
一般保护是不足够的如此多不同的方法意味着什么呢？对用户来说，好的一面在于大量创新的方法正在试验之中；长期看来，这种“竞争”会更容易看出哪种方法最好。而且，这种多样性还使得攻击者躲避所有这些方法更加困难。然而，这种多样性也意味着开发人员需要 避免编写会干扰其中任何一种方法的代码。这在实践上是很容易的；只要不编写对堆栈桢执行低级操作或对堆栈的布局作假设的代码就行了。即使不存在这些方法，这也是一个很好的建议。
操作系统供应商需要参与进来就相当明显了：至少挑选一种方法，并使用它。缓冲区溢出是第一号的问题，这些方法中最好的方法通常能够减轻发行套件中几乎半数已知缺陷的影响。可以证明，不管是基于探测仪的方法更好，还是基于非可执行堆栈的方法更好，它们都具有各自的优点。可以将它们结合起来使用，但是少数方法不支持这样使用，因为附加的性能损失使得这样做不值得。我并没有其他意思，至少就这些方法本身而言是这样；libsafe 和分割控制及数据堆栈的方法在它们所提供的保护方面都具有局限性。当然，最糟糕的解决办法就是根本不对这个第一号的缺陷提供保护。还没有实现一种方法的软件供应商需要立即计划这样做。从 2004 年开始，用户应该开始避免使用这样的操作系统，即它们至少没有对缓冲区溢出提供某种自动保护机制。
然而，没有哪种方法允许开发人员忽略缓冲区溢出。所有这些方法都能够被攻击者破坏。 攻击者也许能够通过改变函数中其他数据的值来利用缓冲区溢出；没有哪种方法能够防止这点。如果能够插入某些难于创建的值（比如 NUL 字符），那么这其中的许多方法都能被攻击者绕开；随着多媒体和压缩数据变得更加普遍，攻击者绕开这些方法就更容易了。从根本上讲，所有这些方法都能减轻从程序接管攻击到拒绝服务攻击的缓冲区溢出攻击所带来的破坏。遗憾的是，随着计算机系统在更多关键场合的使用，即使拒绝服务通常也是不可接受的。因而，尽管发行套件应该至少包括一种适当的防御方法，并且开发人员应该使用（而不是反对）那些方法，但是开发人员仍然需要最初就编写无缺陷的软件。 |
