用碰撞时会爆炸的油箱去制造汽车可不是一个好主意，所以汽车厂商都不会在他们的产品中使用有这样的部件。软件厂商可以从中汲取教训，并用于解决他们自己内部的安全炸弹：缓冲区溢出。

　　Gartner公司的研究指出，缓冲区溢出是程序的最常见的。不幸的是，尽管在1999年就已经得出了这项研究成果，这一安全漏洞问题却没有得到多少改善。往往一个漏洞刚刚修复，不到一个星期，新的漏洞就又出现了。

　　溢出发生在程序试图存储比分配的内存容量更多的数据。多出的数据会溢出到邻近的内存区域，覆盖掉已经存储在那里的数据和指令。不怀好意的黑客们已经能十分熟练地利用这种溢出方式把他们自己的代码植入到计算机程序中，从而有效地劫持计算机。

　　如果在存储数据之前没有检测该数据块大小的代码，溢出同样也会发生。在一些编程语言中，溢出很难或几乎不可能发生，因为它们能自动扩大内存空间来接收到来的数据。而包括C语言在内的一些其他语言，溢出几乎则不可避免，它们通常都缺乏任何自动检测容量大小的机制，并会十分乐意地向5磅的内存区中塞入“10磅的数据”。

　　如果程序员不对溢出条件作专门的测试，这样的缺陷就会出现在应用软件之中。开发时限带来的压力更加重了这一问题：问题往往不是被开发人员或测试人员发现，而是在数以百万计最终用户那里才被发现。

　　这些溢出问题有多么普遍呢？一些软件供应商是比其他人更恶劣的违规者？这可能正如您所预测，因为不同的公司在编写自己的应用软件时，使用的是不同的编程标准。那么这个问题是变得好了呢，还是变得更糟了？

　　一份IT安全公司Secunia对咨询建议数据库的期望报告，可以为溢出问题的地位提供一个评估。这篇报告的评估标准包括：严重的漏洞攻击，远程利用和毁坏（服务的允许和拒绝、敏感信息或系统信息的暴露、系统劫持、ID欺骗，操纵数据、权限升级、安全旁路或系统访问）。

　　非常明显，由溢出而引发的漏洞攻击是很广泛的。2002年9月至2004年3月的调查报告中显示，三分之一的漏洞攻击与溢出相关（ 224/659 ） 。在这段时间内，每个月至少有4个与溢出有关的咨询，而其中的一些月份则达到了26个，平均每个月有11个。

　　不仅仅小型的、资源紧缺的公司目前正为这一问题而烦恼。相反，产品中严重的溢出问题更加困扰着许多大型的、知名的软件供应商。

　　各厂商出现的漏洞中，由于溢出导致的漏洞数各有不同。苹果、Opera、甲骨文、赛门铁克和雅虎所出现的几乎所有的警告都与溢出有关。而思科、微软和Sun则只有不到一半的警告与溢出有关。当然，这样差异可以有很多不同的解释方式。也许后者是更擅长于在代码中避免发生溢出，也许前者更有效地消除了所有其他类型的漏洞。