Fuzz 技术是当下最热门的漏洞检测与挖掘技术之一,著名的工具包括 AFL、libFuzzer、Honggfuzz 等,这些工具已经检测出了超过 16,000 个真实场景下的软件程序和软件库的漏洞。对于程序来说,Fuzzer 需要找到它输入的地方,也就是所谓的注入点;而对于软件库来说,它并不能直接输入,这时候就需要构建一个应用程序 fuzz driver(fuzzharness)来进行模糊测试。而这个程序的质量对编写人员的经验和熟练度有着极高的要求,因此如何创建高效的 fuzz driver 是一个巨大的挑战。
而当下为解决这个问题已经提出了 FUDGE、FUZZGEN 等工具,但其均是在现有的应用程序源码的基础上去构建相应的 fuzz driver,针对的更多的开源 SDK 库的安全,而如果解决闭源 SDK 库的安全问题显得更加重要。然而当下这个问题的难点在于以下两方面:
作者该篇文章主要做出了以下贡献:
图3-1 APICraft 架构总览
输入:目标 SDK 库、相应的 Consumer programs
输出:fuzz driver
Collect: 对使用 SDK 的应?程序进?动态 trace ,收集GUI应?程序的动态行为信息,包括data dependency、control dependency等
Combine: 对收集到的 dependency 解析之后使用多目标优化的遗传算法(Multi-Objective genetic algorithm),构建 fuzz driver
图3-2 APICraft 工作流
由图可见,首先提供包括库的头文件、库的二进制文件等信息;接着经过预处理获取库的元信息、执行trace信息;随后经过 Collect 和 Combine 流程,从而生成 Fuzz Driver。
图3-3 Data Dependency
主要针对错误控制流信息:
使用多目标基因融合算法(a multi-objective genetic algorithm),将Diversity(DIV)、Effectiveness(EFF)、Compactness(COMP)进行融合。
图3-4 APICraft的多?标优化遗传算法
此外通过以下方式提升其稳定性:
实验从多方面进行评估,从而验证系统有效性、先进性。除此之外,通过消融实验分析整个系统组件的有效性。
图4-1 fuzz driver 生成
上表展示了整个 APICraft 流程的中间结果。其中 Trace Size 是所有consumer programs的大小。
图4-2 与人工对比
实验来看, 通过 APICraft 产生的 fuzz driver 在 fuzzing 过程中的覆盖率比 P0 顶尖安全研究员?写的 fuzz driver 实验效果更加卓越。
图4-3 组件有效性
比较 APICraft 与 NO-COMP、NO-DIV、NOEFF ,可以观察到,去除任何一个组件都会导致性能下降。其随着收集的依赖数增多,下降更为明显。
图4-4 真实场景效果
可以看到 APIcraft 在真实场景下的效果仍然较好。
尽管 APICraft 取得了不错的成绩,但是还面临以下局限性。
很赞哦! (119)