什么是模糊测试（1）
在主流字典中压根就找不到模糊测试（fuzzing）这个术语。这个术语有很多别名，而且对某些读者来说可能是一个全新的词汇。模糊测试是一个宽泛的研究领域，在软件安全分析方面，目前模糊测试是一种令人激动的方法。本书将会深入研究不同模糊测试方法的目标和各个方面。但在此之前，我们需要先给这个术语下个定义，探究模糊测试的历史，审视模糊测试的每个阶段，并讨论模糊测试的局限性。2.1模糊测试的定义
在字典中很可能根本找不到fuzzing这个词，更不用说根据字典的定义来在安全研究领域中定义这个术语了。模糊测试这个术语最早出现在Wisconsin-Madison大学的一个研究项目中，此后，该术语被用来描述软件测试的一个方法体系。在学术界，与模糊测试最为接近的术语是边界值分析 （Boundary value analysis, BVA）。边界值分析方法是一种黑盒测试方法，该方法根据应用的合法和非法输入区间，选择落在区间边界附近的值作为输入值来进行测试。边界值分析方法能够帮助确保应用的错误处理机制能准确地接受所有合法输入值，并能准确地过滤掉所有非法输入值。模糊测试与边界值分析方法很类似，不同的是，我们在使用模糊测试方法时，不仅仅只关注边界值，同时还会关心任何能够触发未定义或是不安全行为的输入。
在本书中，我们将模糊测试定义为“通过向应用提供非预期的输入并监控输出中的异常来发现软件中的故障（faults）的方法”。典型而言，模糊测试利用自动化或是半自动化的方法重复地向应用提供输入。显然，上述定义相当宽泛，但这个定义阐明了模糊测试的基本概念。用于模糊测试的模糊测试器（fuzzer）分为两类：一类是基于变异（mutation-based）的模糊测试器，这一类测试器通过对已有的数据样本进行变异来创建测试用例；而另一类是基于生成（generation-based）的模糊测试器，该类测试器为被测系统使用的协议或是文件格式建模，基于模型生成输入并据此创建测试用例。这两种模糊测试器各有其优缺点。在第3章“模糊测试方法与模糊测试器类型”中，我们将会更多的谈论不同种类的模糊测试方法，以及这些方法的好处和问题。
如果你是模糊测试的新手，可以将模糊测试类比成如何闯进一所房子。假设你不幸丢了工作，不得不以犯罪为生，现在你想要破门进入一所房子。如果采用纯白盒测试的方法，你需要在破门前得到房子的所有相关信息，包括房子的蓝图（blueprints），房子的锁的生产厂家、房子的建筑材料等。显然，白盒测试放在这种情况下有独特的好处，但也并非万无一失。应用白盒测试方法，你需要对房子进行静态分析而不是进行运行时（实际进入房子时）检查。例如，通过静态分析你发现这所房子起居室的侧面窗户有一个漏洞，可以把窗户打碎进入房子。但你肯定没办法预见到你进入后的事情，也许当你进入以后，发现愤怒的房主正在屋里拿着枪等着你。另外，你可以采用黑盒测试方法来进入这所房子。采用黑盒测试方法，你可以在黑暗的掩护下接近房子，悄悄测试所有的门和窗户，向房子内窥视以决定最好的突破口。但是，如果你最终选择使用模糊测试方法进入这所房子，你可以既不用研究房子的蓝图、也不用手工尝试所有那些锁，只需要选择一种武器并让进入房子的过程完全自动化——这就是强制安全漏洞发现方法的威力！
2.2模糊测试的历史
有据可查的最早的模糊测试概念可以追溯到1989年。1989年，Barton Miller教授（Miller教授被大多数人认为是“模糊测试之父”）在他的高级操作系统课程中使用了一个原始的模糊测试器，用于测试UNIX应用的鲁棒性（robustness） 。该模糊测试器的目标并不是评估系统的安全性，而是用于评估系统的代码质量和可靠性。虽然该项研究中也提及了一些安全性的考虑，但在测试中并没有对setuid应用的安全性进行特别的关注。1995年，在一个扩大的UNIX工具和操作系统集合上重复了该测试。1995年的研究表明，应用的整体可靠性得到了提高，但仍然存在“显著的失效率（siginificant rates of failure）”。
Miller的团队使用的模糊测试方法非常粗糙：如果某个输入导致应用崩溃或是挂起，意味着测试失败，否则就意味着测试成功。Miller的小组使用的模糊测试器只是纯粹地遵循黑盒测试方法，向被测应用发送随机生成的字符串或是字符。以现在的观点来看，这种方式实在是过于简陋，但别忘了，那时甚至还没有模糊测试的概念。
大约在1999年，Oulu大学开始创建PROTOS测试套件。PROTOS测试套件首先分析协议规范，然后生成违反协议或是看上去不能被具体的协议实现正确处理的数据包。遵循这种方式，许多PROTOS测试套件被开发了出来。虽然开发这些测试套件的开销很大，但这些测试套件一旦被创建，就可以针对不同厂家的产品来重复运行。PROTOS测试套件是一个混合应用白盒测试和黑盒测试的例子，通过这种方式发现了大量软件故障，因此这一事件被当成是模糊测试发展过程中的重要里程碑。
2002年微软为PROTOS提供了资金支持 ，2003年PROTOS小组的成员成立了Codenomicon公司，该公司致力于设计和生产商业的模糊测试套件。直到今天，该公司的产品仍然基于Oulu测试套件，当然，还包含了图形用户界面，用户支持，通过“体检”（health-checking）方式发现软件故障的能力，以及其他一些功能 。关于Codenomicon的更多信息，以及其他的商业模糊测试解决方案将在第26章“展望”中进行描述。
随着PORTOS在2002年逐渐成熟，Dave Aitel以GPL协议方式发布了一个开源的名为SPIKE的模糊测试器 。该模糊测试器实现了一种基于块（block-based）的方法 ，用于测试基于网络的应用程序。SPIKE比Miller的模糊测试器更先进，特别是具有描述可变长数据块的能力。除了可以像Miller的模糊测试器一样产生随机数据作为输入外，SPIKE自身还带有一个库，库中包含了一些数据，这些数据有较大的可能让写得不好的应用发生故障。此外，SPIKE内置了一些预定义的函数，这些函数可以帮助生成常见的协议数据及各种格式数据。另外，SPIKE还包括了对Sun RPC和Microsoft RPC这两种通信技术的支持，而这两种通信技术在过去一直是导致许多安全漏洞的核心原因。SPIKE是第一个允许用户以较小代价创建自己的模糊测试器的项目，这一点使它成为了模糊测试发展史上的一个重要里程碑。在第21章“模糊测试框架”中我们会多次提到SPIKE。
在发布SPIKE的同时，Aitel还发布了名为sharefuzz的本地UNIX模糊测试器。与Miller的模糊测试器不同，sharefuzz通过修改环境变量的值而不是修改命令行参数的值来发现安全漏洞。Sharefuzz采用了一种有用的技巧来支持模糊测试过程。这种技巧是使用共享库（shared libraries）钩住（hook）那些返回环境变量值的函数，强制这些函数调用返回比实际环境变量值长得多的字符串值，由此发现缓冲区溢出的安全漏洞。
SPIKE发布之后，模糊测试领域又出现了一些新的创新。这些新的创新均以某种实现了特定模糊方法的工具形式出现。2004年，Michal Zalewski（又名 lcamtuf）将模糊测试导入Web浏览器测试并发布了mangleme工具 。Mangleme工具是一个通用网关界面（Common Gateway Interface, CGI）程序，它持续产生不正常的HTML文件，并强制浏览器反复刷新来加载这些HTML文件。随后，其他一些面向Web浏览器的模糊测试器很快相继面世。H. D. Moore 和Aviv Raff 开发了Hamachi工具 ，该工具用来对浏览器解析动态HTML（Dynamic HTML. DHTML）的功能进行模糊测试。后来，这两个人又与Matt Murphy和Thierry Zoller合作开发了对浏览器解析重叠样式表（cascading style sheet）功能进行模糊测试的工具，工具名为CSSDIE 。
2004年，文件模糊测试开始兴起。那一年微软发布了MS04-28安全公告，该公告详细描述了JPEG文件处理引擎中的一个缓冲区溢出漏洞 。虽然这不是第一个被发现的文件格式导致的安全漏洞，但由于不少流行的微软应用都使用了这段有安全性问题的代码，这个问题还是引起了广泛关注。文件格式导致的安全漏洞同样为网络保护提出了挑战。随后几年相当数量的有文件格式导致的类似安全漏洞纷纷出现，但简单地将可能存在安全漏洞的文件格式拒于网络之外是并不现实。拿互联网来说，图像和媒体文件的传输占掉了互联网传输的大部分带宽。如果Web上不再有图像，Web还能有多大的吸引力？另外，这之后不久就有人发现微软的Office中也存在由于文件格式导致的安全漏洞——而这些Office文件类型对任何企业都非常关键，因此不可能依靠将这些格式的文件拒之门外的方法保证网络安全。在这种情况下，文件格式安全漏洞成为了基于变异的模糊测试方法的主要目标，由于已经有了一些导致安全漏洞的文件格式样本，因此可以一边让快速连续发生变异，一边监控被测应用的输出以找到安全漏洞。本书作者在2005年 美国黑帽大会 （Black Hat USA Briefing）上做了一个报告，发布了一系列基于变异和基于生成的文件格式模糊测试工具，其中包括FileFuzz，SPIKEfile和notSPIKEfile 。
2005年，一个名为Mu Security的公司开始开发一种硬件模糊测试工具，该工具用于让网络中传输的协议数据发生变异 ，这一工具的出现与日渐高涨的模糊测试潮流相吻合。不断增多的商业模糊测试方案开始出现，与此同时，自由的模糊测试技术变革也随之出现。另外，包含了对模糊测试感兴趣的开发者和安全研究员的社区也逐步扩大，一个明显的证据是社区成员们创建了一个邮件列表 ，该列表由Gadi Evron维护。只有时间可以见证接下来还有多少激动人心的创新在等着我们。
ActiveX模糊测试在2006年开始流行，在2006年David Zimmer发布了COMRaider，H. D. Moore发布了AxMan 。这两个工具都面向可在Internet Explorer浏览器中被Web应用使用的ActiveX控件。由于使用ActiveX控件的Web应用具有庞大的用户群，因此，如果控件中存在可被远程利用的安全漏洞，这些安全漏洞将会带来巨大的风险。ActiveX控件本身包含了接口描述、函数原型、以及控件中的成员变量，因此是极好的模糊测试对象，非常适合对其进行智能的自动化测试。ActiveX控件的模糊测试和浏览器模糊测试作为一个整体，将在第17章“Web浏览器的模糊测试”及第18章“Web浏览器的自动化模糊测试”中进行详细描述。
尽管模糊测试的发展史上还存在其他一些里程碑和工具，但本章到目前为止的介绍已经足够为读者描绘出模糊测试的发展路线图了。图2.1展示了模糊测试的发展历史。
图2.1模糊测试的发展历史
尽管模糊测试到目前为止已经取得了一些成果，但模糊测试技术仍然处于婴儿阶段。模糊测试方面的主要工具仍然是较小的项目，由小团队、甚至是一名程序员进行维护。直到最近几年才有创业公司进入该商业领域。这些发展让人们对模糊测试成为一个独立的领域充满了信心。随着模糊测试研究方面投入的增加，模糊测试在未来若干年内将有许多革新出现，并能达到新的里程碑。
在下一节中，我们将会讨论一次完整的模糊测试审计过程中的各个阶段。
——————本文节选自《模糊测试——强制发掘安全漏洞的利器》
页:
[1]
