原文标题：APICraft: Fuzz Driver Generation for Closed-source SDK Libraries

原文作者：Cen Zhang, Xingwei Lin, Yuekang Li, et al.

原文链接：https://www.usenix.org/system/files/sec21-zhang-cen.pdf

原文来源：USENIX Security’21

笔记作者：NING

笔记小编：bight@SecQuan

1 背景介绍

Fuzz 技术是当下最热门的漏洞检测与挖掘技术之一，著名的工具包括 AFL、libFuzzer、Honggfuzz 等，这些工具已经检测出了超过 16,000 个真实场景下的软件程序和软件库的漏洞。对于程序来说，Fuzzer 需要找到它输入的地方，也就是所谓的注入点；而对于软件库来说，它并不能直接输入，这时候就需要构建一个应用程序 fuzz driver（fuzzharness）来进行模糊测试。而这个程序的质量对编写人员的经验和熟练度有着极高的要求，因此如何创建高效的 fuzz driver 是一个巨大的挑战。

而当下为解决这个问题已经提出了 FUDGE、FUZZGEN 等工具，但其均是在现有的应用程序源码的基础上去构建相应的 fuzz driver，针对的更多的开源 SDK 库的安全，而如果解决闭源 SDK 库的安全问题显得更加重要。然而当下这个问题的难点在于以下两方面：

• 从库中提取的信息十分有限
• API函数之间的语义关心十分复杂

2 论文主要贡献

作者该篇文章主要做出了以下贡献：

• 以闭源 SDK 的 fuzz driver 生成作为关键问题，提出了Collect-Combine 的方法。
• 提出第一个自动化 fuzz driver 生成框架——APICraft
• 评估了 MacOS SDK，并发现了 142 个之前未知的漏洞

3 系统架构

输入：目标 SDK 库、相应的 Consumer programs

输出：fuzz driver

Collect： 对使用 SDK 的应⽤程序进⾏动态 trace ，收集GUI应⽤程序的动态行为信息，包括data dependency、control dependency等

Combine： 对收集到的 dependency 解析之后使用多目标优化的遗传算法（Multi-Objective genetic algorithm），构建 fuzz driver

3.1 工作流

由图可见，首先提供包括库的头文件、库的二进制文件等信息；接着经过预处理获取库的元信息、执行trace信息；随后经过 Collect 和 Combine 流程，从而生成 Fuzz Driver。

3.2 Collect

Data Dependency

Control Dependency

主要针对错误控制流信息：

• 函数的指针式输出 — Naive 空指针检查
• 函数的整数型输出 — 基于污点的分析，提取其检查条件

3.2 Combine

使用多目标基因融合算法（a multi-objective genetic algorithm），将Diversity（DIV）、Effectiveness（EFF）、Compactness（COMP）进行融合。

此外通过以下方式提升其稳定性：

• 稳定测试 — 在3-5个不同的输入下进行烟雾测试
• 错误控制 — 从控制依赖产生

4 评估实验

实验从多方面进行评估，从而验证系统有效性、先进性。除此之外，通过消融实验分析整个系统组件的有效性。

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 在真实场景下的效果仍然较好。

5 总结与展望

尽管 APICraft 取得了不错的成绩，但是还面临以下局限性。

• fuzz driver 质量取决于 trace 的质量
• 缺失的依赖可能造成假阳性和假阴性
• 无法查出并发错误和逻辑错误
• 只支持 C 或 C-style 的SDK API