Buffer Overflow 是一个老掉牙的安全问题，C/C++ 的年纪有多大，Buffer Overflow 的年纪也有多大。简单来说，产生缓冲区溢出漏洞(Buffer Overflow)的原因，就是程序把过量的数据放在Buffer中，导致溢出。例如程序把20 个字节的数据，写入在一个只有10 个字节的Buffer 中，当然会导致溢出，既然原理那么简单，那我们现在还有Buffer Overflow 的问题吗？

 

    从Mitre CWE 的数据中，我们看到Buffer Overflow每年的数字都差不多，每年报告的数字都在300-400左右，并没有明显减少的迹象。证明Buffer Overflow 虽然“老”，但它所带来的破坏并没有减低。Buffer Overflow没有减少的原因有很多，但大概可以归纳为以下因由。

    1. 安全开发培训工作不够
    小型的开发团队大多没有内部的安全开发培训，所以在很大程度上完全依赖开发人员本身的能力，以及源自大学的培训。虽然一些高等院校在近年大多加强了信息安全专业的课程，但有关应用层、编写安全代码方面的安全知识等，仍然明显短缺。而大型企业内的开发部门，虽然投放在培训的经费上比较充裕，但在如何编写安全代码上，仍显十分不足。笔者在一家外资安全顾问公司工作，所接触的客户都已经是比较大型的企业，但几乎没有一家客户能做到系统地为新入职员工提供全面的安全开发培训。
    2. 安全编码规范及政策缺乏
    安全编码规范可以说是安全培训的兄弟，培训做得不好，那安全编码规范工作也不会好哪去。而当培训工作“可能”会侧重安全漏洞（不要做什么），安全编码规范肯定要以正确编程为主要目的（要做什么）。以Buffer Overflow 为例，安全编码规范应有以下要求：
    •  那些API在企业内被禁止
    •  要传一个可擦写的buffer 时，界面要同时提供buffer 大小
    •  当要做输入检查时，应该用哪一个常规表达式的链接库 (Regular Expression Library)

    3.Buffer Overflow 可以很复杂
    以下的程序片断是libPNG在2004 年1.2.5版本的一个Buffer Overflow 漏洞，由于依赖libPNG的程序很多，所以当时这个漏洞也导致很多程序需要安装补丁。但其实这个漏洞比较难找，有丰富经验的编程人员也不一定可以找出来。因为乍一看，程序好像是已检查Buffer 大小，所以好像没有问题。

 

    从libPNG这个例子我们可见，要防止Buffer Overflow的出现，肯定不能单靠编程人员本身的经验，以及编码规范。当然，培训及编码规范都很重要，这两方面工作做得好，已经能够帮助开发团队减少约80%的Buffer Overflow 问题，但余下的20% 则要靠安全测试去找出来。
    4.  测试不够
    有别于以往的单元测试 (Unit Test) 及功能测试 (Functional Test) ，应用层的安全测试主要分为两种技术：动态及静态。
    （1）动态技术方面，主是把程序运行起来，然后输不同的攻击输入码，看看程序还能否正常操作。这种技术在Web的应用上特别流行，在找寻Buffer Overflow 上，动态测试主要是用Fuzzing工具，名字不同，但原理相通。动态测试的好处是简单易用，不需源码，所以可以交由测试部门进行（如有测试部门的话）。就笔者接触到少数进行Fuzzing的企业来说，几乎都是由测试部门进行测试。缺点方面，受操作方式所限，Fuzz工具通常是只能用来测试网络端的服务器程序，以及小部分命令行的程序，其他如COM组件，DLL等则十分罕见。另外，由于Fuzz主要通过产生随机数据为攻击码，所以没办法保证测试完整，一般做法是测试1至2个星期，即使没有找到安全漏洞亦会停止。另外，由于Fuzz找出来的漏洞没有提供相关的源码数据，所以往往要花一点时间才能找出问题的根源。
    （2）静态技术方面，一般是进行自动化的源码检查。源码检查工具不需要执行程序代码，只需模拟执行时的状况就可以找出问题。源码检查的历史其实十分悠久，但一直都没有广泛被使用，只是在近5年有技术突破，而渐渐流行。在Buffer Overflow 方面，源码检查的工具是透过追踪buffer的生成、使用及释放的周期，来检查buffer有没有被过量的数据超载。静态测试的最大好处是可以跟整个开发流程整合，例如可以把之前提到的安全编码规范，放在源码检查的规则当中，就可以确保开发人员确实跟随规范开发程序。当然，好的源码检查工具都不单只可以找出Buffer Overflow 的漏洞，而是可以找出数十种，以致数百种的安全漏洞，有些甚至可以找出常见的编码错误，所以好的源码检查工具能够提升整个开发团队的能力。

 

 

    Buffer Overflow 只是众多编程漏洞的其中一类，不管是那一种编程漏洞，解决的方法还是离不开People、Process、Technology、也就是人员培训、规范/政策、测试流程、自动化工具等。其实近五年，整体的应用层安全已经成熟了很多，市场上不断有新的技术、工具出现，不同的SDL管理流程亦已被广泛讨论，开发人员的安全意识亦不断提高，可惜的是，大部分的企业在安全开发上，裹足不前，仍然没有正视安全问题。可能，这个才是Buffer Overflow这个古老的咒语能够“历久不衰”的真正原因。