2017-06-15 14:04:03
阅读：383次
点赞(0)
收藏
来源： intel.com
作者：lfty89
翻译：lfty89
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
前言
在代码中寻找漏洞已成为网络攻防之间博弈的一部分，网络防御方需要尽可能地定位和修补所有可能的系统漏洞，而攻击方通常只需找到一处正确的切入点便可获得胜利。因此，相对于进攻方，防御方通常需要准备更加有效的工具以应对这场较量。
fuzzing（模糊测试）是一种采取向系统发送随机输入（通过一些随机生成器产生的）的方式来定位漏洞的通用技术。通常来讲，由于测试目的不明等原因，直接采取blind fuzzing的方式在实际应用中的效率并不高。但对于防御方而言，在实际应用场景中可以额外借鉴系统源代码、攻击背景等有效信息，并借助静态分析、符号执行（symbolic execution）等方式有效地开展fuzzing测试，最终将系统崩溃、bug等问题溯源到源代码的具体位置并对其进行修复。
Intel的Excite项目通过使用一种结合符号执行、fuzzing和concrete测试的方法在敏感代码中寻找漏洞。项目组发现，将符号和具体化技术进行有效搭配后，其执行效率高于单用其中任何一种技术。自2015年项目启动以来，Exite已经进行了多次成果展示（如USENIX Workshop on Offensive Technologies (WOOT) 2015[1] and ZeroNights 2016[2]），目前已成为一款自动化挖掘BIOS漏洞的有效工具。Excite是一种结合多种技术的自动化工作流，具体包括：通过结合一种动态选择性符号执行技术（dynamic selective symbolic execution）和fuzzing来生成测试用例；利用Wind River*Simics*虚拟平台以dump与平台相关的数据和代码；针对发现的安全问题以重放测试等方式进行检测和研究；通过评估代码覆盖率以准备下一次的测试用例。
图1描述了Excite为符号执行、fuzzing以及虚拟平台这三种技术结合的交集。
目标：系统管理模式
目前，Excite项目研究正在重点分析系统管理模式（SMM：System Management Mode）中的系统管理中断（SMI：System Management Interrupt，被用于UEFI BIOS中）处理程序上。鉴于近年来针对BIOS的攻击逐渐增多，Intel也采取了代码开发纲要[3]、安全设计纲要[4]、代码复检和静态分析等方式逐步提高BIOS的安全性。Excite凭借着自动化测试生成等特性横空出世，意味着BIOS的安全技术领域又新增一名成员。在Intel处理器中，SMM是权限最高的执行状态（可将SMM看作运行在Ring -2层，操作系统在Ring 0层，而应用程序在Ring 3层），这也导致其成为rootkit藏匿的绝佳位置。操作系统自身并不清楚SMM在何时运行，更不能检测和阻止SMM代码的执行，因此，从平台的整体而言，SMM的安全问题至关重要。
SMM使用的代码和数据存放于系统管理存储器（SMRAM： System Management RAM）中，后者是系统RAM的一部分，只是被分配给SMM使用，同时也受到处理器相关机制的保护。要进入SMM的执行上下文，通常需要平台的一些特定事件来触发SMI调用。
发生SMI后，一个通信缓存（Communications Buffer）被用于传递来自外界的参数，该通信缓存被存储在正常的RAM中，并且假定随时可能被攻击者控制，因此，SMI处理程序必须非常谨慎地检验通信缓存中存放的数据，以防止被攻击者利用。
因为SMI处理程序能够访问机器的任意一块内存，在安全防护的角度上看，它们也更加危险。针对这个问题，UEFI BIOS中有一个组件表（sets up table）专门定义SMI处理程序能够访问哪些内存，同时不能访问哪些内存。
SMM是UEFI BIOS的一部分，正因如此，它并不是一个静态组件。在系统启动的过程中，BIOS会往SMRAM中以动态的方式加载SMM的驱动和相关的SMI处理程序，一旦安装完成，SMRAM被处理器以设置锁比特位的方式锁定。
在SMM中应用Excite
目前，Excite计划捕获UEFI SMI处理程序中的两个非常“恶意”的安全问题：在外部调用SMRAM以及访问禁止的内存区域。为达成该目标，Excite工具集以图2的方式组合了多种技术：
首先以标准化的方式构建UEFI BIOS，完成构建后将其加载到一个Simics虚拟平台中并启动。Simics能够模拟真实的Intel平台，从而让UEFI运行为真实环境准备的所有代码。
在SMM驱动初始化到SMRAM锁定之前的阶段，SIMICS dump了一份用于符号执行的SMRAM镜像。该方法的好处在于，其dump出来的数据包括了SMM模块的初始化状态，从而避免了额外开发一个SMM复杂模型的工作。
接下来开始生成测试框架（test harness）。在该阶段，Excite通过扫描SMRAM来获取所有的模块注册信息和处理程序，并针对每个处理程序，生成一个用来调用CRETE符号执行引擎的测试框架。CRETE不需要源码，直接作用于二进制文件，当其工作时，每一个测试框架都会将SMRAM映射到应用程序空间中。此外，整个通信缓存（comm buffer）作为符号执行过程的起点被符号化标记。
CRETE在执行的过程中会遍历每一个SMI处理程序的行为，并为获取到的每一个路径生成一个测试用例。效率上，CRETE能够为一个处理程序提供数以千计的测试用例，每一个测试用例都包含了来自通信缓存的数据集。生成的测试用例在Simics上执行，其功能还包括收集代码覆盖率、非法内存访问、非法调用等数据。
符号分析和生成测试用例
符号执行是一个能够系统化遍历一个程序执行全部过程的强大技术，主要采取符号输入的方式来执行一个程序。在执行的过程中，符号执行引擎（symbolic execution engine）会逐渐形成了一个针对输入符号的约束集（set of constraints），如果在执行中遇到一个取决于符号变量值的程序分支时，符号执行引擎会生成两个新的约束集，分别对应两个分支。执行到程序过程的末尾时，符号执行引擎会将所有的约束集发给约束解析器（constraint solver），后者生成实际的输入数据，并接着程序过程继续执行。整个分析过程会持续执行直到遍历完程序的全部执行过程，或者满足测试者设置的终止条件。
Excite使用CRETE作为其符号执行引擎，后者是波兰国立大学的一个开源项目。Excite的测试框架通过调用CRETE提供的资源（如crete_make_symbolic(var,size,name)）符号化函数的输入数据或者特定的内存区域，以开展符号执行工作。CRETE会从程序的入口地址处分析内存快照，并为程序的全部执行过程生成测试用例，测试用例包含了函数的实体输入数据。
在使用CRETE的过程中我们发现，一些输入数据会导致SMI处理程序崩溃，这个问题和我们在使用Simics时发现的问题都会作为将来的研究工作。
Excite是如何使用Simics虚拟平台的
在研究的过程中我们需要精准地观测SMRAM，同时还能够跳转到内存的任意位置以运行测试用例，这些需求是物理硬件无法满足的，而这也是我们使用虚拟平台的原因。如前文所述，我们选择Simics主要有以下三个目的：
能够运行UEFI的整个启动过程，以获取SMRAM建立的上下文内容。我们通过Simics的检查点功能（checkpoint）来保存目标机器的内存、寄存器、设备状态等全部信息；
能狗在初始化安装完成后访问SMRAM内存，并将dump下来的数据提供给Excite；
能够运行测试用例；
Simics通过加载启动后保存的检查点来执行测试用例以获取UEFI在启动后的状态，该测试用例非常逼真地构建了处理器和内存的状态，包括将通信缓存中指定的内容复制到相关内存中，以及在寄存器（R8和R9）中构建指针和范围值。
处理器的指令指针（RIP）被设置成指向程序代码的入口点，以直接跳转至SMI处理程序。SMI的中断程序会通过一个调度程序并且最终会在测试初始化时完成相同的工作。这里我们假定SMI调度程序是可信的，同时通过这种方式，测试流程可以被一种简单的方式追踪。
Simics在测试用例运行后，会激活执行跟踪器（Exect：Execution Tracer）模块。Exect监控测试用例的执行过程，重点检测SMRAM的外部调用和非法内存空间访问（如UEFI启动服务内存），如果发现了相关的非法操作，则向UEFI的开发人员提供一份BUG报告。
此外，Exect同时也负责代码覆盖率信息的搜集工作。通过参考代码覆盖率，我们可以随时掌握有多少SMI代码已经被测试过，或者更多的测试是否增加了代码覆盖率。
Fuzzing测试
为提高代码覆盖率，我们在测试用例中使用了类似于AFL fuzzer[5]的模糊测试，后者先改变测试用例中通信缓存中的输入数据，然后在Simics中再次运行测试用例，并保存提高了代码覆盖率的测试用例。符号执行方式有自身的局限性，一是不能完全生成所有的测试用例；二是其仅局限于操作通信缓存，无法处理通信缓存之外的状态，相比较而言，模糊测试能够生成更多的测试用例。图3描述了符号执行和模糊测试是如何结合并生成更好的测试用例。
代码覆盖率结果
通过查看图5所示的代码覆盖率结果，我们会发现结合符号执行与模糊测试的方法提供了更高的代码覆盖率。
发现问题后的提示与报告
当一个BUG被发现后，它会被具体化（因为UEFI的代码也作为测试的一部分被运行），同时会在源码中以错误提示的方式被显示，但与一般的静态分析方法不同，这种错误提示通常与一个特定系统状态下的一行代码相关联。
在调试一个程序问题的时候，通常会对一个非法访问或标注的指令进行完整堆栈跟踪分析利用SMRAM dump出来的二进制文件，其汇编代码可以在windows Driver Kit[6] (WDK)以及一些项目数据库文件（如*.pdb）的帮助下还原其C代码。借助于源码，我们可以直接在代码中定位问题的具体所在，如图6所示。
在虚拟平台上调试一个BUG通常比在物理平台上要容易得多：虚拟平台自身剔除了物理设备的诸多限制，如内存锁保护等机制，从而让我们能够以更深更广的视角研究系统；在没有调试环境的情况下，我们仍然能够很好地观察恶意代码的执行过程；重放执行技术使我们能够不断观察可控的执行过程。Wind River的白皮书[7]对虚拟化技术在网络安全中的应用做了更为深入的讨论。
通过并行测试以优化执行时间
在面对大量的测试用例时，采取并行测试的方式会极大地缩短整个测试周期。例如，假定一个处理程序有20000个测试用例需要运行，总的时间耗费（包括生成用例、在Simics上运行、进行模糊测试等）估计会超过10个小时，如果有10个处理程序的话，时间耗费将达到4天以上。但实际上，所有的处理程序都将以并行的方式进行测试，而属于同一个处理程序的测试用例同样也可以并行执行。图7展示了并行测试在整个测试过程的应用情况。
总结
Excite项目，通过将不同的技术、方法和工具整合到一个集成工作流中，最后得到了一个以前任何单一技术都无法企及的结果。Excite利用虚拟平台独特的优势，将数据流导向符号执行并生成测试用例，最终又回到虚拟平台运行测试用例，执行行为检测，同时在模糊测试的协助下扩展了测试用例空间。Excite自推出以来已发现了一些与系统平台相关的安全问题，我们相信在未来其必将促进和加强网络安全防御力量的建设。
参考文献
[1] https://www.usenix.org/conference/woot15/workshop-program/presentation/Bazhaniuk [2] https://2016.zeronights.ru/wp-content/uploads/2016/12/1_3_Excite_Project_ZN.pdf [3] https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20White%20papers [4] https://software.intel.com/en-us/blogs/2017/06/06/finding-bios-vulnerabilities-with-excite [5] http://lcamtuf.coredump.cx/afl/ [6] https://msdn.microsoft.com/en-us/library/windows/hardware/ff560092(v=vs.85).aspx [7] http://events.windriver.com/wrcd01/wrcm/2016/08/WP-cybersecurity-and-secure-deployments.pdf
本文由 安全客 翻译，转载请注明“转自安全客”，并附上链接。
原文链接：https://software.intel.com/en-us/blogs/2017/06/06/finding-bios-vulnerabilities-with-excite