如需转载请注明出处，侵权必究。
论文题目：APICraft: Fuzz Driver Generation for Closed-source SDK Libraries
发表会议：Security 2021
本文作者是Cen Zhang，来自南洋理工大学的Liu Yang 教授团队，该团队在网络安全领域的主要研究方向是恶意软件建模、检测、分类和生成等。
现有工作生成fuzzer driver依赖源代码提供接口信息，导致无法在闭源SDK上用它们进行漏洞挖掘。在闭源SDK上自动化生成fuzz driver主要面临两个挑战，1. 只能从库中提取有限的信息；2. API函数之间的语义关系复杂，需要保证语义关系的正确性。
为了解决上述挑战，APICRAFT采用了“收集-整合”的策略。“收集”指用头文件、二进制文件、运行时追踪数据收集API的控制流和数据依赖。“整合”则是指用“多目标遗传算法”在整合API的控制流和数据依赖的同时，生成高质量的fuzz driver。作者实现APICraft后，用此工具发现了142个macOS系统库漏洞，并收获了54个Apple官方致谢。
与对传统的程序模糊测试不同，对一个库进行模糊测试需要一个使用这个库的应用程序（即fuzz driver）来接收fuzzer的输出。在实际漏洞挖掘工作中，fuzz driver往往是由技术能力强的安全分析人员花费大量时间手动编写完成，这使得自动化生成fuzz driver是一个很有价值的工作。
目前fuzz driver的自动化生成技术大多需要使用库程序（称为Consumer Program）的源代码，而在闭源SDK的漏洞挖掘工作中，由于闭源SDK的Consumer program往往也是闭源的，导致现有工作无法支持对闭源SDK进行漏洞挖掘。本文目标则是针对闭源SDK生成fuzz driver。
那么针对闭源SDK是如何构建fuzz driver的呢？接下来将以macOS CoreText库为例介绍。如下图1所示，有两个Consumer Program ，它们一共使用了CoreText库的5个API，标号为1~5。图2（a）是对此简化的调用序列。图2（b）是采用常用的交叉互换方式生成的调用序列，但这个交叉互换的效果不大，因为只是改变了创建font对象的方式，并没有改变font的使用方式。图2（c）才是想要的调用序列，也是本工作的目标。
为了针对闭源SDK自动化生成fuzz driver，作者提出了APICRAFT。核心思路是收集SDK的Consumer Program的运行时的trace，并基于此推导出API 间的控制流和数据依赖，最后再采用“多目标遗传算法”生成高质量的fuzz driver。
图3是APICRAFT的流程图，包含三大阶段：
-
预处理阶段：APICRAFT通过多种分析(头文件分析、静态二进制分析、动态二进制分析)从多个来源提取目标SDK的信息并进行分组。这一步将输出库的元数据和consumer program的动态trace记录。
- 依赖提取：目的是收集数据依赖和控制依赖。数据依赖主要指API函数间的数据依赖。控制依赖则是与API错误处理相关的函数输出。
- 生成fuzz driver：利用多目标遗传算法，将收集到的数据依赖和控制依赖组合成fuzz driver，同时使fuzz driver满足“多样性”、“有效性”、“紧凑性”。
API依赖收集
数据依赖
存在数据依赖的两个API A和B之间的关系为：
-
函数A的返回值（return value）被用做函数B的输入参数
-
函数A的输出参数被用做函数B的输入参数。
收集数据依赖方法核心是通过匹配API函数参数/返回值的类型和值来实现，首先从SDK头文件中提取类型信息，接着对consumer program的API调用进行trace收集，trace收集时会记录下API的参数。
收集完数据依赖后，APICRAFT会推断数据依赖：
-
R1：Dependency-based transition：假如函数A的输出是函数C的输入，函数A的输出是函数D的输入，函数B的输出是函数C的输入，那么函数B的输出是函数D的输入
- R2：Type-based transition：如果函数A的输出类型和函数B的输入类型一样，那么函数A的输出是函数B的输入
- R3：Inter-thread data flow dependency：假如在线程T1上执行的函数A与线程T2上执行的函数B满足数据依赖，且参数类型是指针，那么A与B存在依赖
控制依赖
控制依赖用于fuzz driver的语法检查，获知API函数的输出是否需要进行错误处理以及产生错误的分支。
控制依赖的收集通过对不同类型的函数输出使用不同的策略来完成：
-
如果API函数的输出参数或返回值的规范类型是指针，则生成的模糊驱动程序将始终检查输出值是否为NULL(如果为NULL则立即退出)。
- 如果类型是整数，APICRAFT将尝试定位consumer program错误检查的条件分支，并转储错误检查条件(假设consumer program在良性输入下不会执行错误分支)。
依赖整合
收集了API间的数据依赖和控制依赖后，接下来是整合依赖以生成高质量的fuzz driver。APICRAFT 用三个关键指标衡量fuzz driver的质量：
A.多样性（Diversity）指fuzz driver能够调用足够多样的API使fuzz driver程序行为更丰富。
B. 有效性（Effectiveness）是这三个指标中的唯一一个需要动态反馈信息的指标，其目标是要让生成的fuzz driver的API调用更合法有效。
C. 紧凑性（Compactness）与fuzz driver的API数目相关，目的是去除冗余API调用。
为了使生成的fuzz driver在整合依赖的同时满足上述三个关键指标，APICRAFT提出一个称为“多目标优化”的基于NSGA-II的遗传算法。在此算法中，一个基因代表一个数据依赖，一个染色体对应是一组链接的数据依赖。与经典遗传算法相比，此算法特别的是，其排序策略能够处理多个目标。假设现在只有三个目标，目标得分可以用来建立一个三维坐标系和染色体的点。在坐标系中，一个染色体在最外层意味着没有任何一个染色体在所有目标中都能有比它更高的得分。
算法排序策略分为两个阶段。第一个阶段通过反复选择最外层的染色体，来将染色体分成若干层（也称 帕累托边界）。第二个阶段对每个染色体计算一个分数，并选择分数最高的染色体参加下一轮进化，每个染色体的分数等于其与相邻染色体在坐标系中的距离（成为拥挤度）。当算法迭代到结束时，最后一轮进化的第一个帕累托边界上的所有染色体即是最优染色体。
工具代码实现有两个关键处：
-
仅关注外部程序对SDK API的调用：忽视SDK内部调用逻辑。
- 轻量级动态trace框架：使用Type-II方式而不是Type-I方式的Hook，Type -II 类型的hook能提供精确的函数嵌套级别（图6）。除此之外，通过将hook的代码包装到一个与想要hook的API原型相同的函数中，并设置环境变量来配置操作系统的动态链接器，来实现运行时的轻量级开销。
APICRAFT对macOS上的5个攻击面进行漏洞挖掘，这5个攻击面分别是image，Font，PDF，Audio，RTF。它们对应的macOS consumer program包括Preview，Safari，Messages, Mail, Quicktime Player等。
下图展示了fuzz driver生成过程的中间结果：
由此可以看出：
- APICRAFT 能够在复杂的GUI程序中跟踪数百个目标API函数
- 大部分攻击面含有上万的依赖项，组合依赖项 面临着广阔的搜索空间
- 使用遗传算法生成的Fuzz Driver 在期望的属性上有显著改进
作者还将APICRAFT生成的fuzz driver与研究人员构造的fuzz driver进行对比。下图每个子图中的紫色线都是APICraft生成的fuzz driver在fuzzing时的覆盖率，浅色线则是人工构造的fuzz driver的覆盖率。这些结果表明，在大多数情况下，APICraft生成的fuzz driver明显优于手动编写的对应fuzzer driver。
除了覆盖率指标，作者基于生成的fuzz driver进行漏洞挖掘，结果显示，一共发现了142处漏洞，并收到Apple 公司54个官方致谢，如下所示。
作者提出了APICRAFT，一种针对于闭源SDK自动化生成fuzz driver框架。APICRAFT首先通过动静态分析获取API的trace 记录，接着基于trace记录获取API间的数据依赖和控制依赖，最后再使用多目标优化遗传算法生成满足“多样性”、“有效性”以及“紧凑性”的fuzz driver。在实验环节，作者使用APICRAFT发现了macOS上142处漏洞，获得了Apple公司54个官方致谢。
供稿：卢嘉东
审稿：刘竟诚、邬梦莹、洪赓
排版：边顾
原文始发于微信公众号（复旦白泽战队）：白泽带你读论文｜APICraft
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论