转载至：零日竞赛：Google和360如何改变内核漏洞挖掘领域的规矩？ - 嘶吼 RoarTalk – 回归最本质的信息安全,互联网安全新媒体,4hou.com
本文将以Bochspwn、Digtool两款工具为主线，介绍自动化漏洞挖掘工具的最新进展。
虚拟化监控
要做自动化漏洞挖掘工具，首先要考虑如何实现内存监控。2012年，在Bochspwn的技术栈选型上，Google P0团队面临三种选择：
1、修改系统异常处理，利用页面访问权限截取内存引用。该方法对系统内核改动太大，移植很不方便。不过它具备最佳性能优势，并可以在物理硬件层面进行监听。
2、使用轻量级hypervisor去截取内存，侵入性较小，不用对内核做太多修改。但要开发一套具备广泛日志记录功能的hypervisor复杂且耗时。
3、使用CPU仿真虚拟机来运行操作系统，在软件层面监听内存。这样做性能开销非常大，无法测试少数硬件的内核模块；优点是工作量最小、上手最简单快速。
权衡所有优缺点后，P0决定采用第三种方案，使用开源软件Bochs x86仿真器开发了全系统内存监控工具Bochspwn。他们当时表示：“CPU仿真方案具备压倒性的优势”。考虑到那时P0团队应该刚刚筹建，人员不足，这句话大概能理解。
2013年Bochspwn初见成效、发现一大堆Windows内核漏洞后，@j00ru和@gynvael反思，Bochspwn实在太慢太卡了，要给运行时的完整操作系统做分析，使得它很多时候都无法交互。尽管可以对CPU占用再优化，但Bochs本身的低效率让这种优化很难有意义。
另一种选择是，放弃CPU仿真方案，改用Intel和AMD的虚拟化技术来控制操作系统，做轻量级hypervisor。同年8月，@j00ru在BlackHat上公布HyperPwn，一个把操作系统放进hypervisor里作为VMM运行的项目，很遗憾由于在内存处理上碰到难题，这个项目当时没能完成，后来竟没了声音。
@j00ru未竟的项目，在2017年被@PJF（潘剑锋）实现。
@PJF是360冰刃实验室负责人、知名反病毒内核软件冰刃作者，他于2014年开始构思Digtool，使用硬件虚拟化技术（Intel PT）打造漏洞检测框架，2017年初步完成亮相时，同样刷了一大波Windows内核漏洞，并且介绍论文还投中四大国际学术会议之一的USENIX Security。
Digtool漏洞检测部分最大亮点在于：@PJF没有用任何现有虚拟机或仿真器软件方案，而是近乎奇迹地独立实现了一套专用于内存监控的轻量级hypervisor。
他认为现有方案都不够完美，例如Driver Verifier没有源码，AddressSanitizer是编译时工具，Patching异常处理会影响系统稳定且无法移植，Pin、DynamoRIO之类难以在内核态运行，PEMU没有内存监控模块，Xenpwn只能跟踪物理内存地址，Bochspwn性能太差…
独立实现hypervisor层监控的Digtool优势明显，支持闭源软件、对系统稳定性没有损伤、性能极佳、可移植性好，并且可以获得最全面的内存监控数据。@PJF说：“Bochspwn跑一次可能要一两天，而Digtool只需要一两小时。”
漏洞发现
现盘古首席科学家王铁磊曾总结过漏洞挖掘研究现状，他把漏洞发现技术分为主动挖掘和被动发现，主动挖掘有手工分析、动态分析、静态分析三类，其中以模糊测试（fuzz）为代表的动态漏洞挖掘技术已经被业界广泛接受，成为软件安全测试的重要手段。
在Github上搜索fuzz，有八千多个项目，里边有大量知名fuzz软件和案例，但最流行的fuzz软件并不在这里，而是在一个个人网站上。它叫american fuzzy lop（AFL），由全球最有影响力的安全专家之一@lcamtuf 打造，是现在许多二进制白帽子fuzz从入门到精通的必备软件。
比如几个月前，腾讯安全研究员@lcatro 使用AFL和网上开源测试样本对图片处理库ImageMagick进行fuzzing，很快就收获20个CVE漏洞。@lcatro 的内存监控工具是AddressSanitizer，上文提过它的缺点，需要被测软件源码在编译时引入才能工作，对Windows等闭源软件没有价值。
回到Bochspwn上来，作为Google P0神器，它最开始的作用是安全研究员发现某类攻击面或姿势后，在内核里对该类漏洞进行“清扫”（fuzz）。2013年首次亮相时，Bochspwn在Windows内核、驱动程序里找到50个double fetch漏洞，对这类漏洞的宣传科普起到了重要作用。
两年后，字体处理漏洞泛滥现象严重，包括超级木马Duqu、comex版iOS越狱、几次Pwn2own比赛都使用了字体处理零日漏洞，安全会议上随处可见相关讨论。从用户安全角度来考虑，情况非常不利。P0团队希望解决这个问题，他们投入数千台机器，先后三次对Windows内核字体部分进行fuzz，整个过程特别复杂，不同阶段、目标、文件格式需要单独配置/定制，最后一年时间发现了16个字体处理严重漏洞，为Windows字体处理安全改进做出了很大贡献。
字体fuzz轻车熟路后，2016年年底P0又盯上Windows文本编码库Uniscribe。Uniscribe此前鲜有人关注，但跑过一轮Bochspwn后“名声”大涨，爆出29个漏洞。Uniscribe的成果表明，fuzz是一种通用性技术，其大部分组件对不同目标都可以重用。
和战果累累的Bochspwn相比，Digtool稍显稚嫩，它的优势是在通用性、性能、效率上做得更好。
Bochspwn公开信息显示支持识别double fetch、内核堆栈泄漏两类漏洞（可能有所保留），Digtool则支持UNPROBE、TOCTTOU、UAF、OOB、参数未检查、信息泄漏六种漏洞识别，并且很快将支持第七种未初始化堆栈；性能方面前文说过；效率上则是前两方面带来的综合差距，Digtool有着碾压式性能体验，可以在运行正常工作任务的同时监控内存、分析识别漏洞，这是Bochspwn所无法做到的。
8月参加USENIX Security会议前，Digtool牛刀小试，在Windows上发现20个内核漏洞、5款杀毒软件上发现41个驱动漏洞。因为监控和分析组件做得足够好，Digtool甚至不用专门的fuzz，仅靠系统运行任务所产生的代码覆盖也能发现漏洞。
最后
经过五年开发和完善，Bochspwn已经成为漏洞挖掘领域的一面旗帜，它代表“人+机器”模式当前所能达到的最高水准。
Digtool还不够成熟，它需要切实的成果来展示证明自己，而它的潜力显然不止于此，未来将是Bochspwn强有力的挑战者和超越者。
限于篇幅，本文仅介绍了Bochspwn、Digtool的部分模块，以后有机会我们会展开讲讲里边的其它部分。
参考资料
Digtool: A Virtualization-Based Framework for Detecting Kernel
Vulnerabilities（Jianfeng Pan, Guanglu Yan, and Xiaocao Fan, IceSword Lab）
Identifying and Exploiting Windows Kernel Race Conditions via Memory
Access Patterns（Mateusz Jurczyk, Gynvael Coldwind）
A year of Windows kernel font fuzzing #1: the results（Mateusz
Jurczyk of Google Project Zero）
A year of Windows kernel font fuzzing #2: the techniques（Mateusz
Jurczyk of Google Project Zero）
Notes on Windows Uniscribe Fuzzing（Mateusz Jurczyk of
Google Project Zero）
Announcing Bochspwn Reloaded and my REcon Montreal 2017 slides
面向二进制程序的漏洞挖掘关键技术研究（王铁磊）
自动化挖掘 windows内核信息泄漏漏洞（fanxiaocao(@TinySecEx) and @pjf_ of IceSword Lab）
