1、前 言我知道“人类和鱼类能够和平共处“ 。-George W. Bush, 2000 年 9 月 29 日简介模糊测试的概念至少已经流传了 20 年，但是直到最近才引起广泛的关注。安全漏洞困扰了许多流行的客户端应用程序，包括 Microsoft 的 Internet Explorer、Word 和 Excel，它们中的许多漏洞在 2006 年通过模糊测试技术被发现。模糊测试技术的有效应用产生了许多新的工具和日益广泛的影响。本书是第一部公开发表的关于这一主题的专著，这一尴尬事实同时也预示着未来人们将会对模糊测试有更浓厚的兴趣。多年来，我们参与了许多有关安全漏洞的研究工作，并且在日常工作中使用了各
2、种不同的模糊测试技术，从不成熟的、凭借个人嗜好的项目到高端的商业产品，都用到过模糊测试。每一位作者都曾参与开发过自用版本的和公开发行版本的模糊器。这本书凝聚了我们以往的实践经验和正在进行的研究项目所花费的心血，我们希望读者能够从中获益。目标读者安全性领域的书籍和文章通常由这一领域的研究者所写，以方便该领域的其它研究者参考。我们坚信，只要安全性领域的研究小组把解决安全性问题视为其唯一责任，那么安全性问题的数量和严重程度就会随着时间的推移而继续增长。因此，我们付出巨大的努力以使本书能够服务于更多的读者，既包括模糊测试的新手也包括早已对本领域有所了解的读者。假设我们只是将开发完成的应用程序提交给一个
3、安全小组，然后让他们在产品发布之前对其进行一个快速审核，相信这样的过程能够产生安全的应用程序显然是不现实的。当开发者或 QA 组的组员说：“ 安全根本不是问题- 我们有个安全小组关心这件事呢“ ，如此这般，日子就会一天一天的过去。安全性必须被融入软件开发生命周期(SDLC)，而不是到了最后才草率处理。让开发组和 QA 组把注意力集中在安全性问题上可能是个离谱的要求，特别是对那些以往没有这么做的开发组和 QA 组来说尤其如此。我们认为模糊测试是一种独一无二的安全漏洞发掘方法学，由于它能够被高度自动化，因此学习和掌握这种方法学的读者可以相当广泛。我们希望经验丰富的安全领域的研究者可从本书获得有价值
4、的东西，同样希望开发人员和 QA 人员从中获益。模糊测试可以并且应该是任何完整 SDLC 的一部分，不仅在测试阶段需要考虑，在开发阶段也同样需要考虑。缺陷被发现得越及时，修补缺陷的成本就越低。预备知识模糊测试是一个广泛的主题。尽管本书中会介绍一些不专属于模糊测试的背景内容，但是我们仍然假设读者应该拥有这一领域的预备知识。在学习本书之前，读者至少应该对程序设计和计算机网络有一定的基本了解。模糊测试是关于自动化安全测试的，这本书的内容自然要包括如何构造自动工具。我们有目的地选择了多种编程语言来完成这个任务。语言的选择是根据具体任务的，这也说明了模糊测试可以用多种方法实现。当然，没有必要一一罗列所用
5、到的所有编程语言的背景知识，但是介绍一两种语言无疑会帮助读者从这些章节中获益。本书自始至终都贯穿着对各种安全漏洞的详细描述并讨论如何通过模糊测试来识别这些漏洞。然而，定义或剖析安全漏洞本身的性质并不是本书的目标。一些优秀的书籍是专门讨论这一主题的。如果需要寻找一部关于软件安全漏洞的初级读本，可以参看 Greg Hoglund 、Gray McGraw 所著的 Exploiting Software和 Jack Koziol、David Litchfiel 等的Shellcoders Handbook ，它们都是极好的参考读物。学习方法如何最好地利用本书，这取决于读者的背景和目的。如果你是一位模
6、糊测试的初学者，我们推荐你按顺序逐章消化理解，因为本书的内容进行了有目的的编排，前面先介绍一些必要的背景信息，随后转入高级主题。反之，如果你已经在使用各种模糊测试工具方面花费了一些时间，那么请不要犹豫，可以直接进入感兴趣的主题，因为本书的不同逻辑章节的划分大致上是相互独立的。本书的第一部分主要介绍不同的、具体的模糊测试类型，这些模糊测试类型将在随后的章节中逐一讨论。如果读者对模糊测试比较陌生，可以考虑把这一部分作为必读章节。模糊测试可以被作为多种目标下的安全性测试方法学，不过这些目标下的方法学都遵循相同的基本原则。在第一部分，我们试图将模糊测试定义为一种安全漏洞发掘方法学并详细介绍相关的知识，
7、不考虑这种方法学运用于何种目的。第二部分关注模糊测试的各种相关应用目标。每种目标的介绍跨越了两到三章。最前面的一章介绍每类目标的背景信息，随后的章节集中介绍这些目标下的模糊测试自动化，详细阐述如何针对这种目标构造模糊器。当认为有必要分别介绍 Windows 平台和 Unix 平台下的模糊器工具时，这两个主题分别安排在有关自动化的两章。例如，以第 11 章“文件格式模糊测试“ 为例，该章详细描述有关模糊文件分析器的内容，第 12 章“ 文件格式模糊测试：Unix 平台上的自动化测试“ 则深入介绍基于 Unix 的文件模糊器的实用程序设计，第 13章“ 文件格式模糊测试：Windows 平台上的自
8、动化测试“讲解运行在 Windows 环境中的文件格式模糊器如何构造。第三部分讨论模糊测试领域的高级主题。对于那些已经牢固掌握模糊测试背景知识的读者，可以直接跳入第三部分，不过大部分读者很可能需要先了解第一部分和第二部分，然后再学习第三部分。第三部分关注的是近年来浮现出的新技术，这些技术刚刚得到实施，但是未来将成为安全漏洞发掘的高级工具可以利用的模糊测试技术。最后，在第四部分，我们将总结学习过本书后所得到的收获，然后深入洞察未来的发展方向。尽管模糊测试并不是一个新概念，但是这一领域仍然有足够的发展空间，并且我们希望本书将为未来的研究空间注入一丝灵感。少许幽默写书是一件严肃认真的工作，尤其是对诸
9、如模糊测试这样的复杂主题。这就是说，我们希望尽量给随后的读者(实际上这些人可能比写书的人更重要) 带来一些乐趣，同时也尽最大的努力让写作的过程更愉快。出于这样的考虑，我们决定在每一章的开头引用美国第43 届总统 George W. Bush (别名 Dubya)的一段话。不论你的政治倾向或信仰是什么，没人能够否定 Bush 先生在过去几年中所炮制出的一些引文，这些引文甚至能够写满一年的日历！我们从中挑选了一些最喜欢的引文与读者分享，希望读者和我们得到同样的快乐。读完本书后，读者会发现模糊测试可以被应用于各种不同的目标，显然也可以应用到对英语的模糊测试。关于封面有时，安全漏洞经常被称为“鱼“(例
10、如，可以参看 DailyDave 安全性邮件列表中关于“The L Word & Fish“的提示线索) 。这是一个有用的类比，在讨论安全性和安全漏洞时可以被应用到这个问题的各个方面。这一领域的研究者可以被比作钓鱼者。对应用程序的汇编代码实施逆向工程、逐行分析查找安全漏洞，这样的人可被比作“深海钓鱼者“ 。同许多其它的审核手段相比，模糊测试充其量只是海面搜索，并且通常只对“容易抓的鱼“ 更有效。此外，大灰熊是一个著名的“ 模糊动物“ ，当然也是强大的动物。这些场景组合在一起，就构成了本书的封面，其中有一个模糊的动物，正在捕捉一条鱼，后者代表一个安全漏洞。配套站点：WWW.FUZZING.ORG
11、站点 fuzzing.org 绝对是本书不可分割的一部分，并不仅仅起到补充资源的作用。除了包含本书出版后的勘误表外，该站点还是书中所有源代码和工具的一个中央资源仓库。经过一段时间的努力，我们打算让 fuzzing.org 从一个以图书为中心的资源站点发成为模糊测试这一学科的资源、工具和信息的有价值的社区。我们欢迎你们提出反馈信息，以帮助我们让该站点成为一个有价值的、开放的知识库。目录作者序译者序前 言第一部分第 1 章 安全漏洞发掘方法学1.1 白盒测试1.1.1 源代码评审1.1.2 工具和自动化1.1.3 优点和缺点1.2 黑盒测试1.2.1 人工测试1.2.2 自动测试或模糊测试1.2.
12、3 优点和缺点1.3 灰盒测试1.3.1 二进制审核1.3.2 自动化的二进制审核1.3.3 优点和缺点1.4 小结1.5 脚注第 2 章 什么是模糊测试2.1 模糊测试的定义2.2 模糊测试的历史2.3 模糊测试阶段2.4 模糊测试的局限性和期望2.4.1 访问控制缺陷2.4.2 设计逻辑不良2.4.3 后门2.4.4 内存破坏2.4.5 多阶段安全漏洞2.5 小结第 3 章 模糊测试方法和模糊器类型3.1 模糊测试方法3.1.1 预先生成测试用例3.1.2 随机方法3.1.3 协议变异人工测试3.1.4 变异或强制性测试3.1.5 自动协议生成测试3.2 模糊器类型3.2.1 本地模糊器3
13、.2.2 远程模糊器3.2.3 内存模糊器3.2.4 模糊器框架3.3 小结第 4 章 数据表示和分析4.1 什么是协议4.2 协议域4.3 简单文本协议4.4 二进制协议4.5 网络协议4.6 文件格式4.7 常见的协议元素4.7.1 名字-值对4.7.2 块标识符4.7.3 块长度4.7.4 校验和4.8 小结第 5 章 有效模糊测试的需求5.1 可重现性和文档记录5.2 可重用性5.3 过程状态和过程深度5.4 跟踪、代码覆盖和度量5.5 错误检测5.6 资源约束5.7 小结第二部分第 6 章 自动化测试和测试数据生成6.1 自动化测试的价值6.2 有用的工具和库6.2.1ETHEREA
14、L /WIRESHARK 6.2.2LIBDASM 和 LIBDISASM 6.2.3LIBNET /LIBNETNT 6.2.4LIBPCAP 6.2.5METRO PACKET LIBRARY 6.2.6PTRACE6.2.7PYTHON EXTENSIONS6.3 编程语言的选择6.4 测试数据生成和模糊启发式6.4.1 整型值6.4.2 字符串重复6.4.3 字段分隔符6.4.4 格式化字符串6.4.5 字符翻译6.4.6 目录遍历6.5 小结第 7 章 环境变量和参数的模糊测试71 本地化模糊测试介绍711 命令行参数712 环境变量72 本地化模糊测试准则73 寻找目标程序74 本
15、地化模糊测试方法75 枚举环境变量76 自动化的环境变量测试77 检测问题78 小结 第 8 章 环境变量和参数的模糊测试：自动化8.1 iFUZZ 本地化模糊器的特性8.2 iFUZZ 的开发8.3 iFUZZ 的开发语言8.4 实例研究8.5 益处和改进的余地8.6 小结第 9 章 Web 应用程序和服务器模糊测试9.1 什么是 Web 应用程序模糊测试9.2 目标应用9.3 测试方法9.3.1 建立目标环境9.3.2 输入9.4 漏洞9.5 异常检测9.6 小结第 10 章 Web 应用程序和服务器的模糊测试：自动化10.1 Web 应用模糊器10.2 WebFuzz 的特性10.2.1
16、 请求10.2.2 模糊变量10.2.3 响应10.3 必要的背景知识10.3.1 识别请求10.3.2 漏洞检测10.4 WebFuzz 的开发10.4.1 开发方法10.4.2 开发语言的选择10.4.3 设计10.5 实例研究10.5.1 目录遍历10.5.2 溢出10.5.3 SQL 注入10.5.4 XSS 脚本10.6 益处和改进的余地10.7 小结第 11 章 文件格式模糊测试11.1 目标应用11.2 方法11.2.1 强制性或基于变异的模糊测试11.2.2 智能强制性或基于生成的模糊测试11.3 输入11.4 漏洞11.4.1 拒绝服务11.4.2 整数处理问题11.4.3
17、简单的栈和堆溢出11.4.4 逻辑错误11.4.5 格式化字符串11.4.6 竞争条件11.5 漏洞检测11.6 小结 第 12 章 文件格式模糊测试：UNIX 平台上的自动化测试12.1 NOTSPIKEFILE 和 SPIKEFILE12.2 开发方法12.2.1 异常检测引擎12.2.2 异常报告（异常检测）12.2.3 核心模糊测试引擎12.3 有意义的代码片段12.3.1 通常感兴趣的 UNIX 信号12.3.2 不太感兴趣的 UNIX 信号12.4 僵死进程12.5 使用的注意事项12.5.1 ADOBE ACROBAT12.5.2 REALNETWORKS REALPLAYRE1
18、2.6 实例研究：REALPLAYER REALPIX 格式化字符串漏洞12.7 语言12.8 小结第 13 章 文件格式模糊测试：Windows 平台上的自动化测试13.1 Windows 文件格式漏洞13.2 FileFuzz 的特性13.2.1 创建文件13.2.2 应用程序执行13.2.3 异常检测13.2.4 保存的审核13.3 必要的背景知识13.4 FileFuzz 的开发13.4.1 开发方法13.4.2 开发语言的选择13.4.3 设计13.5 实例研究13.6 益处和改进的余地13.7 小结第 14 章 网络协议模糊测试14.1 什么是网络协议模糊测试14.2 目标应用14
19、.2.1APPLEGATE14.2.2 网络层14.2.3 传输层14.2.4 会话层14.2.5 表示层14.2.6 应用层14.3 测试方法14.3.1 强制性或基于变异的模糊测试14.3.2 智能强制性模糊测试和基于生成的模糊测试14.3.3 修改的客户端变异模糊测试14.4 错误检测14.4.1 人工方法（基于调试器）14.4.2 自动化方法（基于代理）14.4.3 其它方法14.5 小结第 15 章 网络协议模糊测试：UNIX 平台上的自动化测试15.1 使用 SPIKE 进行模糊测试15.1.1 选择测试目标15.1.2 协议逆向工程15.2 SPIKE 10115.2.1 模糊测
20、试引擎15.2.2 通用的基于行的 TCP 模糊器15.3 基于块的协议建模15.4 SPIKE 的额外特性15.4.1 特定于协议的模糊器15.4.2 特定于协议的模糊测试脚本15.4.3 通用的基于脚本的模糊器15.5 编写 SPIKE NMAP 模糊器脚本15.6 小结第 16 章 网络协议模糊测试：Windows 平台上的自动化测试16.1 ProtoFuzz 的特性16.1.1 包结构16.1.2 捕获数据16.1.3 解析数据16.1.4 模糊变量16.1.5 发送数据16.2 必要的背景知识16.2.1 错误检测16.2.2 协议驱动程序16.3 ProtoFuzz 的开发16.
21、3.1 开发语言的选择16.3.2 包捕获库16.3.3 设计16.4 实例研究16.5 益处和改进的余地16.6 小结第 17 章 Web 浏览器模糊测试17.1 什么是 Web 浏览器模糊测试17.2 目标17.3 方法17.3.1 测试方法17.3.2 输入17.4 漏洞17.5 错误检测17.6 小结第 18 章 Web 浏览器的模糊测试：自动化18.1 组件对象模型的背景知识18.1.1 在 Nutshell 中的发展历史18.1.2 对象和接口18.1.3 ActiveX18.2 模糊器的开发18.2.1 枚举可加载的 ActiveX 控件18.2.2 属性，方法，参数和类型18.
22、2.3 模糊测试和监视18.3 小结第 19 章 内存数据的模糊测试19.1 内存数据模糊测试的概念及实施该测试的原因19.2 必需的背景知识19.3 究竟什么是内存数据模糊测试19.4 目标19.5 方法：变异循环插入19.6 方法：快照恢复变异19.7 测试速度和处理深度19.8 错误检测19.9 小结第 20 章 内存数据的模糊测试：自动化20.1 所需要的特性集20.2 开发语言的选择20.3 Windows 调试 API20.4 将其整合在一起20.4.1 如何实现在特定点将“钩子 “植入目标进程的需求20.4.2 如何来处理进程快照和恢复20.4.3 如何来选择植入钩子的点20.4
23、.4 如何对目标内存空间进行定位和变异20.5 你的新的最好的朋友 PYDBG20.6 一个构想的示例20.7 小结第三部分第 21 章 模糊测试框架21.1 模糊测试框架的概念21.2 现有框架21.2.1 ANTIPARSER21.2.2 DFUZ21.2.3 SPIKE21.2.4 PEACH21.2.5 通用模糊器（General Purpose Fuzzer）21.2.6 AUTODAF?21.3 定制模糊器的实例研究：SHOCKWAVE FLASH21.3.1 SWF 文件的建模21.3.2 生成有效的数据21.3.3 对环境进行模糊测试21.3.4 测试方法21.4 模糊测试框架
24、 SULLEY21.4.1 SULLEY 目录结构21.4.2 数据表示21.4.3 会话21.4.421.4.5 一个完整的实例分析21.5 小结第 22 章 自动化协议解析22.1 模糊测试存在的问题是什么22.2 启发式技术22.2.1 代理模糊测试22.2.2 改进的代理模糊测试22.2.3 反汇编启发式规则22.3 生物信息学22.4 遗传算法22.5 小结第 23 章 模糊器跟踪23.1 我们究竟想要跟踪什么23.2 二进制代码可视化和基本块23.2.1 CFG23.2.2 CFG 示例23.3 构造一个模糊器跟踪器23.3.1 刻画目标特征23.3.2 跟踪23.3.3 交叉引用
25、23.4 对一个代码覆盖工具的分析23.4.1 PSTALKER 设计概览23.4.2 数据源23.4.3 数据探查23.4.4 数据捕获23.4.5 局限性23.4.6 数据存储23.5 实例研究23.5.1 测试策略23.5.2 测试方法23.6 益处和改进的余地23.7 小结第 24 章 智能故障检测24.1 基本的错误检测方法24.2 我们所要搜索的内容24.3 选择模糊值时的注意事项24.4 自动化的调试器监视24.4.1 一个基本的调试器监视器24.4.2 一个更加高级的调试器监视器24.5 24.6 动态二进制插装24.7 小结第四部分第 25 章 汲取的教训25.1 软件开发生
26、命周期25.1.1 分析25.1.2 设计25.1.3 编码25.1.4 测试25.1.5 维护25.1.6 在 SDLC 中实现模糊测试25.2 开发者25.3 QA 研究者25.4 安全问题研究者25.5 小结第 26 章 展望26.1 商业工具26.1.1 安全性测试工具 beSTORM26.1.2 BREAKINGPOINT 系统 BPS100026.1.3 CODENOMICON26.1.4 GLEG PROTOVER PROFESSIONAL26.1.5 安全性测试工具 MU-400026.1.6 SECURITY INNOVATION HOLODECK26.2 发现漏洞的混合方法
27、26.3 集成的测试平台26.4 小结作者序安全漏洞是研究安全问题的生命线。无论是执行渗透测试、评价新产品还是审核关键构件的源代码- 安全漏洞都驱动着我们的决策、让我们有理由花费时间，并且很多年来一直影响着我们的选择。源代码审核是一种白盒测试技术，这是一种很长时间以来都流行的软件产品安全漏洞检测方法。这种方法需要审核者了解编程概念和产品功能的每一个细节，深入洞察产品的运行环境。除此之外，源代码审核还有一个显而易见的缺陷-必须首先要获得产品的源代码。幸运的是，除了白盒技术外，我们还可以使用不需要访问源代码的黑盒技术。模糊测试就是黑盒技术中的一种可选的方法，这种方法对于发掘那些用审核方法无法发现的
28、产品关键安全漏洞方面被证明是成功的。模糊测试是这样的一个过程：向产品有意识地输入无效数据以期望触发错误条件或引起产品的故障。这些错误条件可以指导我们找出那些可挖掘的安全漏洞。模糊测试没有实际的执行规则。它是一种技术，测试的结果是这种技术的成功性的唯一度量。任意一个给定的产品都可能接受无限的输入。模糊测试技术旨在预测产品中可能存在的编程错误以及什么样的输入可能会触发错误。正因为如此，与其说它是一门科学，不如说它是一种技术。模糊测试可以简单到就是随意敲打键盘来输入随机数据。我的一个朋友有个 3 岁的儿子，它就是用这么简单的手段发现了 Mac SO X 操作系统的屏幕界面锁定功能中的一个漏洞。我的朋
29、友锁定了屏幕界面然后到厨房找酒喝。当他回来的时候，他的儿子已经设法成功地解除了锁定，并且打开了浏览器，所用的方法正是随意敲打键盘。过去的几年里，我用模糊测试技术和模糊工具在大量的软件中发现了数百个漏洞。2003 年 12 月，我编写了一个简单的程序向一个远程服务发送随机 UDP 包流。结果这个程序发现了 Microsoft WINS 服务器的两个新的漏洞。该程序后来又帮助我在其它产品中找出了少量的缺陷。最后的结果证明，用简单的随机 UPD 包流能够发现计算机协会的多个产品中的漏洞，包括 Norton Ghost 管理服务和 OS X 操作系统的一个公共服务。模糊器对发现网络协议以及其它的许多产
30、品都有效。在 2006 年的第一季度，我精心设计了 3 个不同的浏览器模糊工具，结果发现了多种浏览器中的缺陷。2006 年第二季度，我又编写了一个 Active X 模糊器(AxMan)，仅在 Microsoft 的产品中就发现了超过 100 个缺陷。这些缺陷许多都是在“Month of Browser Bugs“项目中形成的，结果导致该项目组又进一步开发了“Metasploit“框架中的模块。在最初开发 AxMan 后的接近一年的时间里，我还利用模糊测试发现了 AxMan 本身所包含的一些漏洞。模糊器真是一个能够不断赐予我们新礼物的工具。本书是一部真正让我们有理由相信模糊测试是一门技术的专著
31、。书中所介绍的内容涵盖了对新产品执行模糊测试以及创建有效的模糊工具所需要的全部知识。有效模糊测试的关键在于明确对什么样的产品使用什么样的测试数据，以及需要什么工具来操纵、监控和管理模糊测试过程。本书的作者是模糊测试技术的先锋，在阐明模糊测试的复杂过程方面作出了卓越贡献。第 1 章 安全漏洞发掘方法学“Internet 高速公路将会越来越少么？“-George W. Bush, Concord, N. H., 2004 年 8 月 5 日如果询问任何一位有成就的安全领域的研究者，问他如何发现漏洞，很可能会得到一大堆答案。为什么？因为可用于安全性测试的方法太多，每种方法都有自己的优点和缺点。没有一
32、种方法是绝对正确的，也没有一种方法能够揭示一个给定目标下所有可能的漏洞。在较高的层次上，有三种主要的方法用来发现安全漏洞：白盒测试、黑盒测试和灰盒测试。这些方法之间的差别是由测试者可得到的资源决定的。白盒测试是一个极端，它需要对所有资源进行充分地访问。这包括访问源代码、设计规约，甚至有可能还要访问程序员本人。黑盒测试是另一个极端，它几乎不需要知道软件的内部细节，很大程度上带有盲目测试的味道。远程 Web 应用的 Pen 测试是黑盒测试的一个好例子，它不需要访问程序源码。位于两个极端中间的是灰盒测试，它的定义因询问的人的不同而不同。就我们的应用目的而言，灰盒测试需要访问编译后得到的二进制代码，或
33、许还要访问一些基本的文档。本章将考察漏洞发掘的各种不同的高层和低层方法，起点是白盒测试，你以前可能听说过这种方法也被称为玻璃、透明或半透明测试。之后我们再定义黑盒测试和灰盒测试，模糊测试可能就属于后两者。我们将阐述每种方法的利弊，这些方法的利弊将成为本书后面介绍模糊测试时所需要的背景知识。模糊测试只是漏洞发掘的一种方法，了解其它可选的实用方法也是相当重要的。1.1 白盒测试作为一种测试方法学，模糊测试(fuzzing)主要属于黑盒测试和灰盒测试领域。尽管如此，我们还是要考察另一种软件开发人员可选的漏洞发掘方法，即白盒测试(whit box testing)。1.1.1 源代码评审源代码评审既可
34、以人工完成也可以在自动化工具的辅助下完成。假设计算机程序通常包含数万到数十万行代码，那么单纯的人工评审一般情况下是不可行的。自动化工具是一个宝贵的资源，它能够减少长时间对着代码行阅读而带来的繁重任务，但是自动化工具只能识别出可能的漏洞或可疑的代码片段。检测出的问题是否有效，仍然需要人工分析。让源代码分析工具产生有用的结果，必须要克服许多障碍。对这些复杂问题的剖析已经超出了本书的范围，让我们考虑如下的一个 C 程序代码段，这段程序只是简单地将文本“test“拷贝到一个 10 字节的字符数组。代码下面，考虑同样的代码示例，该段代码示例经过了修改，允许用户的输入被拷贝到字符数组。代码上面的两段代码都
35、使用了 strcpy()例程将数据拷贝到一个基于栈的缓冲区。在 C/C+编程中，一般不推荐使用 strcpy()库函数，因为它缺少对目的缓冲区的边界检查。因此，如果程序员不小心自己编写代码而增加了边界检查代码，便可能会发生缓冲区溢出，从而将数据置于目的容器的边界之外。第一个代码例子不会发生缓冲区溢出，因为字符串“test“(包括后跟的 null 终止标记)的长度总是固定值，因此小于目标缓冲区的 10 字节。第二个例子中的场景中可能会也可能不会发生缓冲区溢出，这要取决于用户在命令行中输入的参数数据长度。这里的关键问题是用户是否能够控制输入给有可能发生漏洞的函数的参数长度。一次彻底的代码评审可能会
36、将 strcpy()所在的一行标记为“可能产生漏洞“。尽管如此，还是需要跟踪该函数的实际输入参数，以理解可被人为利用的执行条件是否真正存在。这并不是说源代码评审对安全领域的研究者不是一个有价值的技术工具。源代码评审应该在可获得代码的任何时候进行。然而，是否要进行源代码评审取决于你的角色和观点，通常人们不需要在如此细节的层次上访问被测对象。人们经常不正确地假设白盒测试是比黑盒测试更有效的方法。对软件的何种审视能够比访问源代码更好、更精确呢？不过无论如何都不要忘记，对源代码来说，你看到的东西并不一定是实际执行的东西。软件构建过程在从源代码到汇编代码的转换中可能会发生很大的改变。因为这个原因和其它的
37、原因，不能说一种测试方法就一定比另一种测试方法更好。它们仅仅是不同的方法，通常会揭示不同类型的漏洞。为了达到充分覆盖的目的，有必要结合多种测试方法。微软源代码泄露为了说明源代码评审未必一定优于黑盒测试，让我们考虑和分析发生在 2004 年月的一个事件。在没有事先告戒的情况下，有传闻说 Microsoft Windows NT 4.0 和 Windows 2000 操作系统提供的部分源代码文档被传播到互联网上。Microsoft 后来确认这些文档是真实的操作系统代码。许多公司当时感到极度紧张，因为这一泄露事件将导致上述两个操作系统产生大量的安全漏洞。但是他们所担心的事情没有发生。事实上，直到今天
38、，只有很少的安全漏洞被归因于当时的源代码泄露。其中的一个安全漏洞是 CVE-2004-0566，其具体细节是当操作系统在处理位图文件时会产生一个整数值溢出 1。有趣的是，Microsoft 否认这个安全漏洞的发现，声称其所属的软件公司在一次内部审核中早已经发现了这个问题。为什么我们没有发现大量的安全漏洞？不是说源代码评审可以发现一切吗？事实是源代码评审尽管是应用程序或操作系统安全性审核的一个重要部分，但是由于代码的规模和复杂性，源代码评审难以充分地进行。此外，反汇编分析技术也可以发现大部分源代码中的问题。例如，让我们考察一下 TinyKRNL3 和 ReactOS4 项目，它们的目的都是为应用
39、软件提供与 Microsoft Windows 内核及其操作系统的兼容性。这些项目的开发者并没有访问Microsoft 的内核源代码，但是仍然能够在一定程度上创建项目，提供一个兼容 Windows 的环境。在审核 Windows 操作系统时，不大可能会直接访问 Windows 源码，相反，上述项目的源代码可以被作为解释 Windows 汇编代码的指南。1.1.2 工具和自动化源代码分析工具一般可以分为三类-编译时检查器、源代码浏览器或自动源代码审核工具。编译时检查器在源代码编译时查找漏洞。此类工具通常与编译器集成在一起，但是主要查找与安全性有关的问题而不是应用程序的功能问题。Microsoft
40、 Visual C+的/analyze编译选项是一个编译时检查器的例子。Microsoft 还提供了 PREfast for Drivers6，它能够检测针对驱动程序开发的不同类型的漏洞，而编译器可能检测不到这些漏洞。源代码浏览器是专门设计用于辅助人工检查和评审源代码的软件工具。这类工具允许评审者执行代码的高级搜索、枚举代码以及在代码的交叉引用位置之间导航。例如，一位评审者可能会使用这样的工具来定位所有 strcpy()调用的位置，力图识别可能的缓冲区溢出漏洞。Cscope7 和 Linux Cross-Reference8 是当前流行的源代码浏览器。源代码自动审核工具用于扫描源代码以及自动识
41、别可能的关注区域。同大多数安全性工具一样，源代码自动审核工具既有商业工具也有开源的自由软件解决方案。除此之外，此类工具倾向于关注具体的编程语言，因此如果目标软件使用了不同的编程语言的话，可能需要多种源代码自动审核工具。在商业软件工具方面，有来自Fortify6、Coverity10、KlockWork11、Gramma Tech12 和其它供应商的产品。一些流行的自由软件工具列于表 1.1，其中包括它们审核的语言以及支持的平台。表 1.1 源代码审核的自由软件工具名称 语言 平台 下载RATS(Rough Auditing C、C+、PerUNIX、Win32http:/ for Securi
42、ty)l、PHP、Python本表中其余内容同原文，全部不需要翻译。重要的是要记住，没有任何自动化工具能够完全替代有经验的安全研究员的技能。它们只不过是工具，能够将繁重的分析源代码的任务进行流水化和自动完成，有助于节省时间和解决一些问题。这些工具生成的报告仍然必须由具备经验的分析员评审，以识别出伪问题，也需要有开发人的员评审以实际实施问题的修复。例如，下面的一段代码输出是由Rough Auditing Tool for Security(RATS)自动生成的，被分析的代码是本章前面所举的存在安全漏洞隐患的程序示例。分析结果可以表明这样一个事实：该段程序使用了固定长度缓冲区并且对 strcpy(
43、)的使用可能是不安全的。但是，分析结果没有肯定地说确实存在一个漏洞，只是提醒用户注意存在可能不安全的代码区域，但是该区域是否真的不安全，则需要由他( 她 )决定。代码1.1.3 优点和缺点如同前面提到的，发现安全漏洞不存在唯一正确的方法学。那么如何选择一种合适的方法学呢？当然，有时的决策是由我们自己确定的。例如，如果我们不能访问目标软件的源代码，那么就不可能进行白盒测试。这对大部分安全研究者和用户都是一样的，尤其是那些购买了 Windows 环境的商业软件的人来说。那么白盒测试有什么优点呢？覆盖能力：由于白盒测试能够获得所有源代码，因此代码评审允许完全的覆盖。所有可能的代码路径都可以被审核，以
44、发现可能的漏洞。当然，这个过程也可能导致误报的出现，因为一些代码路径可能在代码执行的时候不可达。代码评审并不总是可行的。即使能够执行代码评审，也应该和其它漏洞发掘方法学结合使用。源代码分析有下面一些缺点：复杂性：源代码分析工具是不完善的，有可能报告出伪问题。因此，这类工具产生的错误报告并不是游戏的结束。这些结果必须经过有经验的程序员的评审，以识别出那些能够合理代表安全性漏洞的问题。重要的软件项目典型地要包含数十万行代码，工具所产生的报告可能相当冗长并且需要大量的时间阅读。可用性：由于白盒测试能够获得所有源代码，因此代码评审允许完全的覆盖。尽管许多 UNIX 项目是开放源代码的，并且允许源代码被
45、评审，但是这种情况在 Win32 环境下比较罕见，对于商业软件这种情况则通常不存在。如果不能访问源代码，那么白盒测试则根本不能作为一个测试选项。1.2 黑盒测试黑盒测试意味着只能了解外部观察到的东西。作为终端用户，可以控制输入，从一个黑盒子的一端提供输入，从盒子的另一端观察输出结果，但是并不知道被控目标的内部工作细节。在远程访问 Web 应用和 Web 服务时这种情形最常见。我们可以采用超文本置标语言(HTML)或可扩展置标语言(XML) 请求的形式产生输入并观察生成的 Web 页面或返回值，但是并不知道幕后发生了什么。让我们考虑另一个例子。假设你在某个时候购买了一个应用软件，例如 Micro
46、soft Office，通常你只能得到一个经过编译后得到的二进制程序，并不能得到用于构建这个应用程序的源代码。在这种情况下，你的观点将决定测试方法的盒子的颜色。如果你不打算采用逆向工程技术，那么黑盒测试是有效的。反之，就应该采用灰盒测试方法，灰盒测试将在下一节讨论。1.2.1 人工测试仍然以 Web 应用为例，人工测试可能要包括使用一个标准的 Web 浏览器来浏览一个Web 站点的层次结构，同时冗长乏味地在所观察到的感兴趣的区域输入可能导致危险的各种输入数据。在审核的最初阶段，这个技术可能只是被零星地应用，例如，通过给各种各样的参数增加引用，以期望揭示出 SQL 注入漏洞。在没有自动化工具辅助
47、的情况下通过人工测试应用程序来查找漏洞，这通常并不是一个可行的方法(除非公司雇佣了一大批实习生 )。这种方法能够带来益处的场景是它被用于扫除(sweeping)多个应用程序中的类似的一个漏洞时。当多个程序员在不同的项目中犯了相同的错误时，就需要利用这种扫除技术。例如，在一个专门的 LDAP(Lightweight Directory Access Protocol)服务器中发现了一个缓冲区溢出，并且通过测试其它 LDAP 服务器发现同样的安全漏洞。如果我们假设程序之间经常共享代码或者同一个程序员参加过多个开发项目，那么这种情况就并非不经常出现。扫除技术CreateProcess()是 Micr
48、osoft Windows 应用程序编程接口(API)提供的一个函数。正如它的名字所暗示的那样，CreateProcess() 将发起运行一个新进程及其主线程 13。该函数的原型是如下定义的：代码如果 lpApplicationName 参数被赋予一个 NULL 值，那么被发起执行的进程将是lpCommandLine 参数中第一个空白符号分隔之后的值，这是人们都知道并且记录在文档中的该函数的行为。考虑下面的例子中对 CreateProcess()函数的调用：代码在上情形下，CreateProcess() 函数将试图反复发起每一个空格符之后的值所代表的进程：代码这种尝试会一直进行，直到发现了一个
49、可执行文件的名字或者所有的选择都已经被穷尽。因此，如果一个可执行文件 program.exe 位于 C:路径下，带有类似上述结构中对CreateProcess()不安全调用的应用程序将会执行该 program.exe 程序。这为攻击者提供了一个便利的机会，他们会试图让实际要执行的程序不可达并执行另外一个程序。2005 年 10 月发布的一个安全性咨询报告中列举了好几个流行的应用程序中采用了不安全的 CareateProcess()调用。这些问题的发现得益于一次成功的但是却非常简单的扫除技术实践。如果你想要利用该扫除技术发现相同的安全漏洞，那么可以拷贝和重新命名一个简单的应用程序，例如 notepad.exe，然后将它置于 c:路径下。然后正常使用计算机。如果先前拷贝的这个应用程序突然在预期之外被执行了，那么就很可能发现了一个因不安全调用 CreateProcess()而引起的漏洞。1.2.2 自动测试或模糊测试模糊测试在很大程度上是一种强制性的技术，因此它缺乏“优雅性“ ，它的目标是简单加有效。模糊测试这个术语将在第 2 章“什么是模糊测试 “中详细定义和解释。简单地说，模糊测试包括把能够想到的所有东西都抛给被测目标然后
