🤔


# AIFORE: Smart Fuzzing Based on Automatic Input Format Reverse Engineering

> 1. 不同输入字段的边界在哪里
> 2. 这些字段属于哪些类型
> 3. 如何利用输入格式知识指导Fuzz

## 作者

## 作者的观点

输入字段的结构和语义由处理他们的基本块来定义而不是输入规范。

## 现有的方法

### 现有输入字段边界识别的方法

现有的输入字段识别有统计分析和动态污点分析将同一个指令处理的字节分组到一个字段分组中。这样的做法存在的问题就是，一条指令可能在循环中处理多个输入字段，并且一个长字段大概率是被多个指令所处理，因为一条指令无法处理超过机器字长的数据。

### 现有的输入字段类型识别方法

现有的解决方案一般依赖于先验知识，例如strcpy的参数类型，但是这种方式需要大量的人工介入并且只能识别程序的变量类型而不是语义类型。

### 现有的利用格式知识指导Fuzz的方法

现有的方案都是针对结构良好的种子分配更多的能量以执行更多的突变，但是大部分方案都是没有字段间关系约束的，无法区分种子质量。

## 作者的方法

### 识别输入字段边界的方法

首先使用动态污点分析来确定每个基本块处理了哪些输入字节，因为单个不可分割的字段可能会被一个基本块中的多个指令处理但是大概率不会被多个基本块处理。根据污点分析结果使用`最小聚类算法`来确定不可分割字段的边界。

### 识别输入字段类型的方法

构建深度学习模型来预测基本块处理输入字段的类型和语义。

### 利用现有的格式知识指导Fuzz的方法

首先选择代码覆盖率显著不同的测试用例，其次选择在模糊测试中测试频率较低的种子。



## 设计架构

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202401181010750.png)

在模糊测试过程中，如果一个种子带来了大于3%的平均覆盖率提升，则将其标记为有价值的种子，而后使用AIFORE分析其格式，并且使用知识模型（提取的字段边界和字段类型知识）进行模糊测试。其中AIFORE使用污点分析构建输入字节和处理字节的基本块之间的映射关系，然后分别调用`Field Boundary Analysis`、`Field Type Classification`、`Fuzzing with Power Scheduling`三个模块。

其中`Field Boundary Analysis`模块主要是将输入分割成为字段；`Field Type Classisfication`模块主要是使用CNN模型预测字段类型信息；最终结合字段边界信息和字段类型信息组成`格式模版（Format Template）`，其为一个pit文件，对于每个字段记录其边界和起始位置、大小、类型。





### 字段边界识别

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202401181044253.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202401181044502.png)



从BB中拆分字段的算法如算法1所示，首先从二进制程序中提取出所有的BB，然后针对二进制程序进行污点分析。利用污点分析出来的污染地址与BB做对应，将其存储在一个字典`BB_to_taint`中，而后针对字典中每一个受污染的BB，收集并合并在一个BB中处理的字节，而后根据BB和BB中受污染的字段来进行分割，针对于连续字节将作为同一个字段进行划分。例如图3中的第四行(18,19)字节将作为一个字段进行分割。

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202401181043257.png)



### 字段类型分类

这里的分类主要是想针对BB分类以提取出字段的语义类型，例如偏移量或者校验和等信息。而不是程序变量类型，例如int或者string。作者将所有字段分为了六种语义

- SIze：此类型的字段主要表示输入文件中一个或多个字段组成的数据块长度。例如ELF文件格式中偏移量为0x28的字段`e_ehsize`表示ELF文件头的大小。
- Enumeration：此类字段只能采取一组有限的有效值，例如在ELF文件格式中的`e_type`字段只能使用ELF格式中定义的七种有效值之一。
- Magic number：幻数。
- String：字符串文字，可以为ASCII、Unicode或者其他编码形式。
- Checksum：校验和，此类字段用于完整性验证，常见于媒体文件、压缩文件、字体格式中。
- Offset：偏移，此类字段用于指示输入中另一个数据块的位置，例如ELF文件格式中偏移为0x20处的`e_shoff`表示节头的偏移量。

作者选用深度学习来使用机器学习以对BB进行字段类型分类，并且使用向前切片以合并对字段的重要操作。

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202401181708679.png)



### Fuzz的能量调度

1. 应该优先针对哪些种子执行格式提取?
2. 如何平衡突变过程中针对不同格式变体的模糊测试？

首先针对初始种子进行分析以构建格式模型，而后在格式模型的指导下针对种子进行变异，如果新突变的种子有价值那么就重新分析其结构。如果Fuzzer长时间内无法获得新的覆盖范围的话，就将Fuzzer的能量分配给那些尚未完全变异的格式。



![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202401191045147.png)

针对不同的字段变异方式也不同，针对每个字节Mutator会将其作为一个整体进行变异，例如Size字段会将其更改为一个合理值而不是位翻转。针对没有格式知识的字节，Mutator将使用AFL中的默认突变方式。

[Paper] AIFORE: Smart Fuzzing Based on Automatic Input Format Reverse Engineering

👍


# 1dFuzz: Reproduce 1-Day Vulnerabilities with Directed Differential Fuzzing


> TCS: 尾随调用序列
>
> 定向差分模糊测试
>
> SecretPatch数据集



## 作者



## 复现1Day的困难

- 如何识别未开源的补丁位置?
  - 现有方案: 根据控制流图比较来定位补丁位置[静态] 根据程序执行轨迹来定位补丁位置[动态] 依靠深度学习提取二进制代码特征[机器学习]
    - 现有方案的缺点: 编译优化会导致二进制文件之间存在差异会影响定位结果、无法区分功能更新和漏洞补丁
- 如何针对补丁生成PoC?
  - 现有方案: 符号执行、定向模糊测试
    - 现有方案缺点: 符号执行无法应用于大型项目中、定向模糊测试很难确定在模糊测试中是否触发漏洞



## 作者提出的方法

经过大规模研究之后发现，大部分补丁都会检查输入有效性，如果输入无效则退出。针对同一个PoC在修补之后的程序当中和未修补的程序当中在修补位置会产生不同的执行跟踪。简单来说就是执行同一个PoC在执行最后的N个函数中执行跟踪是不同的。即TCS[尾随调用序列]不同

- 定位补丁位置的方法: 构建修补之后和未修补二进制程序的调用图并对齐其中的函数，通过静态分析找到具有不同被调用函数的序列的对齐函数，这些对齐的函数将标记为修补函数

- 针对补丁生成PoC的方法: 采用定向模糊测试方案生成PoC，针对修补过后和修补之前的二进制程序进行差异测试，跟踪测试期间两个二进制程序调用的函数序列，并在最后N个函数不同时确定PoC。



## TCS: 尾随调用序列

TCS的理论基础是大部分的补丁修补都如图所示，是针对之前版本的漏洞增加校验，如果校验不通过则退出。这表明，如果为修补前和修补后的二进制程序提供同一个PoC，那么在二进制程序中在补丁之后将会有不同的执行流，即使不知道补丁位置，但是通过执行流仍然可以观察到修补前和修补后的二进制程序在函数调用序列的尾部存在分叉。

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202401170913325.png)

**作者给出定义: TCS，尾随调用序列。在给定程序P和输入I，在程序P退出前的最后N个函数调用表示为TCS(P, I, N)**



### TCS合理性验证

作者通过针对从1999到2018年中所有关于C/C++的漏洞补丁进行统计，确定在此期间的漏洞补丁有71.3%都具有TCS特征。由此验证了TCS合理性。



## 架构设计

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202401171732935.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202401170924315.png)

首先，针对修补前和修补后的二进制程序首先将其从CFG层面将其对齐，然后通过比较函数调用图来定位补丁位置，最后使用定向差分模糊测试来探索补丁位置，并且使用基于TCS的sanitizer来捕获PoC。



### 二进制代码对齐

首先，反汇编二进制程序并识别所有的函数和直接调用，然后根据直接调用关系静态构建函数调用图。其次，利用动态执行收集间接调用关系，在动态执行中对于每个间接调用都在函数调用图上增加一条从调用者到被调用者的边。

针对同一个PoC在常理上除了修补相关的函数，调用的大部分函数都是相似的。也就是说在跟踪中两个执行流具有高度相似的函数序列，可以用于对齐两个调用图中的子图。如此可以依赖跟踪来逐渐对齐两个二进制程序中的函数。



#### 对齐流程

针对在未修补二进制的函数调用图中未匹配到的函数$f$和在修补后的二进制函数调用图中未匹配到函数$f'$ 对其计算相似度

1. 出入度相似度: 当两个函数在调用图中存在相似的出入度时，其更有可能匹配 $score=\frac{min(I_f,I_{f'})}{max(I_f,I_{f'})}+\frac{min(O_f,O_{f'})}{max(O_f,O_{f'})}$ 
2. 函数参数寻址方式相似度: 调用函数有许多种传参方式，1dFuzz记录了各种调用函数时参数的寻址类型 

$score=\frac{\sum min(MC_{addr},MC'_{addr})}{\sum min(MC_{addr}+MC'_{addr})/2}$ 其中$MC_{addr}$表示在修补前函数调用图中使用特定寻址方式的参数数量，$MC'_{addr}$表示在修补后函数调用图中使用特定寻址方式的参数数量

3. Caller相似度: 如果未修补函数调用图中函数$f$有Caller$f_p$，修补之后的函数调用图中函数$f'$有Caller$f'_p$，且$f_p$和$f'_p$在匹配集中，则为函数对$(f_p,f'_p)$加一分 
4. 针对所有函数进行迭代计算相似度，每轮都会更新分数。如果上轮中函数对$(f_p,f'_p)$匹配则本轮中为该函数对加0.5分



### 1dLoc - 补丁定位工具

通过深度优先算法通用遍历对齐之后的每个函数对的CFG中的所有路径，并且收集每个路径上的被调用函数序列，比较这两组调用函数序列检查是否不同，如果一个调用序列中存在另外一个中不存在的函数调用，则将对其的函数标记为候选Patch函数。



### 1dSan - 定向模糊测试辅助工具

主要架构如图所示，为了同时测试修补前和修补后的二进制程序并检查其TCS，使用相同的输入和相同的运行环境测试两个二进制程序。为了效率其并不会记录所有被调用函数的列表，只会记录最后调用的N个函数。其将驻留在Fuzzer中而不是Binary中，其会在测试用例结束之后比较函数列表缓冲区，如果不同则抛出异常。

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202401171706123.png)



### 定向差分模糊测试

- 距离算法: 给定源函数和目标函数的情况下，如果源函数有多个调用站点可以调用到目标函数，则认为源函数更容易进入目标函数。换句话来说，这样的调用者和被调用者之间的距离更短，所以针对调用图中的每个边，统计计算Caller函数中有多少个调用站点可以调用Callee并将其个数表示为$CN$，计算其距离为$1+\frac{1}{2\times CN}$。在计算完函数调用图中每条边的距离之后就可以得到从源函数到目标函数的最短路径距离。

[Paper] 1dFuzz: Reproduce 1-Day Vulnerabilities with Directed Differential Fuzzing

😀



# Profile-Driven System Optimizations for Accelerated Greybox Fuzzing


## 优化方面

- fork server -> persistent mode with efficient state recovery
- OS interaction



## 先前的优化方向

- 优化测试用例的调度
- 优化测试用例的变异
- 优化测试用例的保留



## 为什么选择fork server方向优化

- 传统情况下 AFL和AFL++都运行在fork server模式下 但是分叉子进程需要开销大量时间[复制页表 COW等]

- 如果单纯使用persistent mode往往由于没有恢复初始状态 先前一次的模糊测试往往会影响到后续模糊测试的状态
- 现有提出的snapshot mode 经过测试也会抵消persistent mode带来的速度优势

## 为什么选择OS interaction方向优化

- 现代操作系统为Fuzz提供了许多不必要的操作 占据了许多的时间开销



## 传统fork server优化方法 [Snapshot mode]

- 定制内核 在执行测试用例之前对进程内存进行快照
- 将所有页面设置成为ReadOnly 并且执行COW
- 完成测试用例恢复所有存在修改的页面

## 传统fork server优化方法 [Persistent mode]

- 不需要恢复内存 不需要恢复状态 不需要定制内核
- 但是没有清理状态 导致要求使用Persistent mode需要目标的状态可以自动完全重置 并且不会造成资源泄露并且要求早期的执行不会影响后续的执行
- 在大多数情况下需要人工Patch原本的程序以恢复状态

## fork server优化方法 [Profile-driven State Recovery]

- 采用persistent mode
- 针对Persistent mode中需要重置的资源: 全局变量、内存资源、内核数据结构、文件描述符等
- 针对persistent mode中状态恢复的问题 在分析阶段使用测试用例动态分析目标程序 了解操作了哪些全局变量、环境变量
- 在运行测试用例之前快速重置全局变量和环境变量
- 可以设置为定期运行重置

## OS交互层面优化 [Profile-driven OS Abstraction]

- 大多数情况下执行用例和OS的交互都是进行文件交互 使用VFS来处理对文件的操作 直接将文件读取到内存中以减少文件操作开销
- 管理内存中文件的数据和元数据 避免和IO设备进行交互
- 在用户空间运行所有内容 避免中断和上下文切换
- 只保留与Fuzz相关的功能 删除如日志等与Fuzz无关的操作

- 可以使用独立的VFS来为每个模糊测试实例提供服务 避免文件系统争用
- 可以重置VFS达到快速重置文件描述符的目的

## 影响Fuzzer性能的因素

- Fuzzer的性能取决于算法因素和系统因素
- 算法因素: 
  - 测试用例的调度: 优先对哪些测试用例进行变异和变异多长时间
  - 测试用例的变异: 变异算法
  - 测试用例的评价标准: 代码覆盖率、调度上下文、路径覆盖率
- 系统因素: 系统因素主要影响Fuzzer如何实现Fuzz过程



## 测试IO影响

- 使用ext4文件系统和tmpfs文件系统对比IO开销



## profiling phase 分析阶段

- 针对内存资源: 不需要处理 在Presistent mode执行1000次之后执行一次fork 如此自动回收内存资源
- 针对全局变量: 在分析阶段对测试用例进行动态分析 观察操作了哪些全局变量并记录 在执行测试用例之前重置这些全局变量
  - 随着Fuzz的进行可能会影响新的全局变量: 使用AFL的稳定性指标 观察到稳定性下降就重新执行分析阶段 重新记录影响的全局变量
- 针对环境变量: 使用`setenv`和`unsetenv`获取环境变量
- 针对文件系统: 首先构建一个VFS，检测对应IO文件的属性 如果存在分析阶段没有发现的文件 VFS会将其映射到本地文件系统中
  - 现存文件: 如果在分析阶段 打开或者写入一个现存文件, 对于这样的文件在VFS中创建一个保留文件数据和元数据的副本 其中文件路径在VFS中保持一致
  - 不存在的文件: 如果在分析阶段 打开一个不存在的文件，对于这样的文件在VFS中创建一个空白节点，表示该路径下的文件不存在
  - 新建文件: 忽略新建文件的请求 因为VFS支持新建文件
  - 测试用例: 为测试用例分配共享内存以保存文件 并且方便Fuzzer可以直接访问其进行更新
  - 标准输入/输出: 在VFS中维护一个缓冲器以模拟标准输入
  - Socket: 在VFS中添加一个虚拟文件以充当套接字 其保存在内存中

## 如何检测全局变量变动

- 传统做法: 将全局数据段设置为只读 当写入全局变量时会触发异常以捕获对应全局变量
- 本文做法: 为全局变量添加存储或地址获取操作的检查 

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202312061115492.png)

> 具体是如何实现的扫描全部的全局变量?
>
> 开发了一个llvm插件 以实现在编译器优化之后扫描全局变量

[Paper] Profile-Driven System Optimizations for Accelerated Greybox Fuzzing

😀



### ADVANCED FUZZING UNMASKS ELUSIVE VULNERABILITIES

---



#### Introduction

模糊测试是现代软件保障的主要组成部分，但有些漏洞仍然难以模糊测试。

谷歌的 libwebp 是 Chrome 浏览器和 Safari 浏览器不可或缺的部分，最近因一个严重的安全漏洞而受到关注，该漏洞已被发现在野外被利用。值得注意的是，包括 OSS-Fuzz 在内的谷歌庞大的模糊测试系统并未发现该漏洞。

正如来自 Isosceles 的 Ben Hawkes 所详述的，该漏洞存在于 WebP 的无损压缩方法 VP8L 中。基于预先计算的固定缓冲区大小的内存分配导致了堆缓冲区溢出。

如果有足够的时间和可解路径限制，Fuzzers 通常能够发现这种复杂的内存损坏。然而，这个特定的错误却逃过了之前的模糊测试尝试。

模糊社区和我们都在问这样一个问题：是否有可能通过模糊找到这个特定的漏洞？如果可能，为什么 Google 的 OSS-Fuzz 计划没有发现它？本文试图回答这些问题，并为更好地开展模糊测试活动提供指导。

注：在本文的第一次迭代中，模糊设置发现了 libwebp 漏洞，但这是由于在活动中意外添加了一个已经部分损坏的输入文件作为种子而造成的错误。



#### Step 1: Fuzzing Prep

作为 AFL++ 的主要开发人员，我想了解为什么某些 bug 能够逃过自动化工具的检测，以及我们如何改进工具以提高 bug 的覆盖率。

如果您是模糊测试的新手，不妨先了解一下 AFL++：

>  https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/fuzzing_in_depth.md
>
>  https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/afl-fuzz_approach.md
>
>  https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.cmplog.md
>
>  https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/README.laf-intel.md
>
>  如果没有安装完整的现代 LLVM 编译器和其他必要的构建工具，安装 AFL++ 也很简单（见 https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/INSTALL.md）



为了测试，我们使用了漏洞修复前的 libwebp 版本：

```bash
$ git clone https://chromium.googlesource.com/webm/libwebp
$ cd libwebp
$ git checkout 7ba44f80f3b94fc0138db159afea770ef06532a0
```



我们选择不依赖已有的harness或构建一个新的harness，而是使用库中自带的示例工具，因为我们知道这可以用来触发 bug。假设这些harness的模糊测试范围很窄，这可能是没有发现漏洞的原因。为了优化速度，我们将 forkserver 移到了 dwebp 代码中，就在解析输入之前。最后，我们将 makefile.unix 中的编译器调整为 AFL++。

```diff
diff --git a/examples/dwebp.c b/examples/dwebp.c
index 652de6a6..d41df43d 100644
--- a/examples/dwebp.c
+++ b/examples/dwebp.c
@@ -312,6 +312,10 @@ int main(int argc, const char* argv[]) {
if (quiet) verbose = 0;
+#ifdef __AFL_HAVE_MANUAL_CONTROL
+  __AFL_INIT();
+#endif
+
  {
    VP8StatusCode status= VP8_STATUS_OK;
    size_t data_size = 0;
diff --git a/makefile.unix b/makefile.unix
index 857ea988..83d04a9c 100644
--- a/makefile.unix
+++ b/makefile.unix
@@ -113,7 +113,7 @@ else
  CFLAGS = -O3 -DNDEBUG
endif
CFLAGS += $(EXTRA_FLAGS)
-CC = gcc
+CC = afl-clang-fast
INSTALL = install
GROFF =/usr/bin/groff
COL = /usr/bin/col
```



#### Step 2: Focusing on the Vulnerable Code Path

我们希望 AFL++ 只关注导致这一特定 bug 的代码路径。为此，我们使用了源代码覆盖编译标志（`-fprofile-arcs -ftest-coverage -lgcov--coverage`）。然后，我们使用有问题的 bad.webp 文件运行目标 `examples/dwebp bad.webp -o /dev/null`。

由于崩溃不会生成覆盖文件，因此我们事先还修改了源代码，以强制写入覆盖文件：

```diff
diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
index 45012162..836540fa 100644
--- a/src/dec/vp8l_dec.c
+++ b/src/dec/vp8l_dec.c
@@ -360,6 +360,8 @@ static int ReadHuffmanCode(intalphabet_size, VP8LDecoder* const dec,
  return size;
}
+void __gcov_dump(void);
+
static intReadHuffmanCodes(VP8LDecoder* const dec, int xsize, int ysize,
                           int color_cache_bits, int allow_recursion) {
  int i, j;
@@ -378,6 +380,8 @@ static int ReadHuffmanCodes
(VP8LDecoder*const dec, int xsize, int ysize,
  int* mapping = NULL;
  int ok = 0;
+  __gcov_dump();
+
  if (allow_recursion&& VP8LReadBits(br, 1)) {
    // use meta Huffmancodes.
    const int huffman_precision = VP8LReadBits(br, 3) + 2
```

强制写入覆盖文件后，我们使用实用程序 gcov 来解析和分析生成的覆盖文件。我们确定了涉及崩溃的函数名称，以便只对这些特定函数进行测试，从而更有效地引导模糊器找到漏洞。这样做可以大大加快目标模糊过程。虽然模糊器最终也能找到漏洞，但在这个特定实验中，引导它将节省大量时间。

我们创建了一个名为 libwebp.list 的文件，其中包含与崩溃路径相关的待检测函数名称：

```
fun: CheckSizeArgumentsOverflow
fun: CheckSizeOverflow
fun: DefaultFeatures
fun: GetCPUInfo
fun: GetLE16
fun: GetLE32
fun: main
fun: PrintAnimationWarning
fun: ShiftBytes
fun: VP8InitIo
fun: VP8InitIoInternal
fun: VP8LCheckSignature
fun: VP8LDecodeHeader
fun: VP8LIsEndOfStream
fun: VP8LPrefetchBits
fun: VP8LReadBits
fun: WebPInitCustomIo
fun: WebPInitDecBuffer
fun: WebPInitDecBufferInternal
fun: WebPInitDecoderConfig
fun: WebPMalloc
fun: WebPResetDecParams
fun: WebPSafeCalloc
fun: WebPSafeMalloc
fun: x86CPUInfo
```



#### Step 3: Preparing the code for fuzzing

为了实现彻底的模糊测试，我们需要对覆盖率有不同看法的模糊测试实例--为此，我们使用上下文敏感覆盖率（CTX）和步长为 8 的基于 N 序列的仪器（NGRAM-8）编译了额外的实例。此外，我们还需要有助于解决路径限制的模糊实例，为此我们编译了 CMPLOG 和 COMPCOV 附加实例。

最后，我们添加了一个实例，通过启用 ASAN，可以轻松检测任何类型的内存损坏。

```bash
$ export AFL_LLVM_ALLOWLIST=/full/path/to/libwebp.list
$ for i in cmplog compcov ctx ngram asan; do
	  cp -r libwebp libwebp-$i
 done
$ make -C libwebp -f makefile.unix
$ make AFL_USE_ASAN=1 -C libwebp-asan -f makefile.unix
$ make AFL_LLVM_CMPLOG=1 -C libwebp-cmplog -f makefile.unix
$ make AFL_LLVM_LAF_ALL=1 -C libwebp-compcov -f makefile.unix
$ make AFL_LLVM_INSTRUMENT=CTX -C libwebp-ctx -f makefile.unix
$ make AFL_LLVM_INSTRUMENT=NGRAM-8 -C libwebp-ngram -f makefile.unix
```

请注意，在实际的模糊测试活动中，您可能会添加一个 honggfuzz 实例和一个带有 "value-profile "的 libfuzzer 实例，可能还会添加一个 libafl 和一个协程执行模糊器，如 symcc 和 .TritonDSE。为了不使本文过于复杂，此处省略了这些内容。



#### Step 4: Launching the fuzzing campaign

起初，我们从 libwebp 中收集了一些种子文件，并随机下载了一些文件，将它们放在名为 "seeds"的目录中。为确保模糊器拥有多样化的输入，我们运行了重复数据删除命令：

```bash
$ afl-cmin -i seeds -o inputs
[... output omitted ...]
$ ls -l inputs/
-rw-r--r-- 2 marc 1013  50408 Okt  6 14:15 file_example_WEBP_50kB.webp
-rw-r--r-- 2 marc 1013  71272 Okt  6 14:15 Huey_helicopter_USNS.webp
-rw-rw-r-- 9 marc 1013   4880 Okt  6 14:15 test.webp
-rw-rw-r-- 9 marc 1013 1321542 Okt  6 14:15 test_webp_wasm.webp
-rw-r--r-- 2 marc 1013  81150 Okt  6 14:15 foobar.webp
```

有了五个独特的种子文件，我们就可以开始模糊测试了。我们设置了 8 个不同的 "screen"会话，每个会话都有不同的配置，目的是实现多样化的模糊设置。\

```sh
#!/bin/bash
export AFL_FAST_CAL=1 AFL_IMPORT_FIRST=1 AFL_DISABLE_TRIM=1 AFL_AUTORESUME=1
$*
```



```bash
# A simple MAIN instnace
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-main -M main -- libwebp/examples/dwebp @@ -o /dev/null
# Our ASAN instance to help finding non-crashing memory corruptions
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-asan -S asan -- libwebp-asan/examples/dwebp @@ -o /dev/null
# Our path constraint solving instances
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-cmplog2 -S cmplog2 -l2at -c libwebp-cmplog/examples/dwebp -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-cmplog3 -S cmplog3 -l3a -c libwebp-cmplog/examples/dwebp -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-compcov -S compcov -- libwebp-compcov/examples/dwebp @@ -o /dev/null
# Alternative coverage gathering
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-ngram -S ngram -- libwebp-ngram/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-ctx -S ctx -- libwebp-ctx/examples/dwebp @@ -o /dev/null
# Various instances that fuzz a bit differently to add to the diversity
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-default -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-binexploit -S binexploit -a binary -P exploit -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-binexplore -S binexplore -a binary -P explore -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-ascexploit -S ascexploit -a ascii -P exploit -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-ascexplore -S ascexplore -a ascii -P explore -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-genericexploit -S genericexploit -P exploit -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-genericexplore -S genericexplore -P explore -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-rare -S rare -p rare -- libwebp/examples/dwebp @@ -o /dev/null
screen -dm /data/marc-webp/afl-env.sh afl-fuzz -i input -o output-Z -S Z -Z -- libwebp/examples/dwebp @@ -o /dev/null
```

显然，对 AFL++ 功能的深刻理解和经验是必不可少的。不过，对于那些热衷于深入研究的人来说，https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/fuzzing_in_depth.md 上的文档提供了详尽的见解。

> **Small Tips**
>
> 1. libwebp.list有什么作用
>
>    > 设置 export AFL_LLVM_ALLOWLIST=libwebp.list 将仅插桩内部包含的函数
>
> 2. -l2at
>
>    > -l cmplog_opts - CmpLog configuration values (e.g. "2ATR"):
>    >                    1=small files, 2=larger files (default), 3=all files,
>    >                    A=arithmetic solving, T=transformational solving,
>    >                    X=extreme transform solving, R=random colorization bytes.
>
> 3. -P
>
>    >   -P strategy   - set fix mutation strategy: explore (focus on new coverage),
>    >                      exploit (focus on triggering crashes). You can also set a
>    >                      number of seconds after without any finds it switches to
>    >                      exploit mode, and back on new coverage (default: 1000)
>
> 4. -a
>
>    >   -a            - target input format, "text" or "binary" (default: generic)
>
> 5. -p
>
>    > -p schedule   - power schedules compute a seed's performance score:
>    >                  fast(default), explore, exploit, seek, rare, mmopt, coe, lin
>    >                  quad -- see docs/FAQ.md for more information
>
> 6. -Z
>
>    > -Z            - sequential queue selection instead of weighted random
>
> 7. AFL_FAST_CAL
>
>    > AFL_FAST_CAL: limit the calibration stage to three cycles for speedup
>
> 8. AFL_IMPORT_FIRST
>
>    > AFL_IMPORT_FIRST: sync and import test cases from other fuzzer instances first
>
> 9. AFL_DISABLE_TRIM
>
>    > AFL_DISABLE_TRIM: disable the trimming of test cases
>
> 10. AFL_AUTORESUME
>
>     > AFL_AUTORESUME: resume fuzzing if directory specified by -o already exists

#### Step 5: Profit?

3 天后，我们检查了结果，没有发现崩溃。只有当添加的输入已有 2/3 的所需特殊设置表时，漏洞才会被发现，但此时仍需要约 40 小时才能触发。

分析该漏洞所需的确切表格设置就能发现原因所在：

```c
   // Size of huffman_tables buffer = 654 + 630 + 630 + 630 + 410 = 2954 elements
   // To overflow we "just" exceed this number!
   static uint32_t code_lengths_counts[5][16] = {
       //  1  2  3  4  5  6  7  8  9  10   11  12 13 14 15
       {0, 1, 1, 0, 0, 0, 0, 0, 0, 3, 229, 41,  1, 1, 1, 2},   // size = 654
       {0, 1, 1, 0, 0, 0, 0, 0, 0, 7, 241,  1,  1, 1, 1, 2},   // size = 630
       {0, 1, 1, 0, 0, 0, 0, 0, 0, 7, 241,  1,  1, 1, 1, 2},   // size = 630
       {0, 1, 1, 0, 0, 0, 0, 0, 0, 7, 241,  1,  1, 1, 1, 2},   // size = 630
       {0, 1, 1, 1, 1, 1, 0, 0, 0, 11, 5,   1, 10, 4, 2, 2},   // size = 414
   };
```

模糊器需要找到一个非常特殊的字节组合，才能创建一个大小正确的表来触发这个错误。低于这个数字就不会崩溃，高于这个数字就会检测到无效表并中止处理。

如果存在导致崩溃的特定程序流程，模糊器就能很好地发现这一点。如果需要一个常见的特定值（如 0xffffffffffff），那么模糊器也能很好地找到这个值。

但是，要找到一长串特定值（其中许多值都不是 0、1 或 255）则是一项挑战，因为必须在没有路径约束求解或覆盖率帮助的情况下找到更多这些值，或者在运行时从目标中动态学习值是不可能的。

在这种特定情况下，模糊器需要在没有任何帮助的情况下猜测大约 20 个字节的特定值，这需要数千年的时间（比喻，需要更长的时间）才能随机找到这样的设置。其他机制，如协程求解器，也无法发现此类问题。可能只有证明内存安全性的正式验证方法才有可能发现这一漏洞，但这并不是可以轻易设置和应用的。



#### Lesson Learned

只检测漏洞的执行路径，看看模糊测试是否能找到它，或者它为什么会失败，这种技术对于在短时间内获得这些信息非常有价值。如果没有在步骤 2 中进行的优化，要得出同样的结论可能需要大约 1 个核心年的时间。

这个 libwebp 漏洞提醒我们，模糊测试并非灵丹妙药。有些漏洞无法通过模糊测试发现，有些漏洞则需要模糊测试仪无法生成的触发器或大量数据。

这并不是模糊测试第一次没有发现令人瞩目的漏洞，也不可能发现。

有时是因为线束限制，比如臭名昭著的 heartbeet 漏洞。有时是因为模糊器没有覆盖漏洞类型，比如臭名昭著的 Shellshock 漏洞有时是因为无法触发漏洞条件，如 libwebp 漏洞或 OpenSSL 中使用 punycode 进行证书解析时出现的内存损坏。

手动代码检查、静态分析工具、自动测试和动手安全测试相结合，才能全面识别软件中的漏洞。仅仅依靠模糊测试会让自己陷入失败的境地。



#### Evaluating OSS-Fuzz's Discovery Gap

尽管在 libwebp 项目的 tests/fuzzer/subdirectory 中存在harness，但 OSS-Fuzz 并未发现该漏洞。我们发现，七个线束中有两个（simple_api_fuzzer 和 advanced_api_fuzzer）确实能触发 bad.webp 崩溃：

```bash
$ libwebp/tests/fuzzer/simple_api_fuzzer bad.webp
Reading 236 bytes from bad.webp
=================================================================
==13217==ERROR: AddressSanitizer:heap-buffer-overflow on address
0x626000002f28 at pc 0x555555701767 bp0x7fffffffd1f0 sp 0x7fffffffd1e8
[…]
SUMMARY: AddressSanitizer: heap-buffer-overflow/data/marc-
webp/libwebp/src/utils/huffman_utils.c:59:18 in ReplicateValue
```

它根本没有机会找到触发错误所需的特定设置，所以这不是 OSS-Fuzz 的错。

不过，我们发现 OSS-Fuzz 执行模糊测试的方式存在一些问题，导致模糊测试无法充分发挥潜力：

1. 静态插桩： 最初，我为 AFL++ 集成到 OSS-Fuzz 中实施了一项功能，每次编译代码时都会以不同的方式随机检测代码。这增加了发现新覆盖率和后续错误的概率。然而，由于复杂的原因，谷歌团队取消了这一功能，将模糊测试限制为一组标准的仪器选项。这就限制了 OSS-Fuzz 对覆盖率和路径限制的查看。

2. 语料库同步问题： OSS-Fuzz 使用 ClusterFuzz 来处理实际的模糊工作量。一个实例独立工作，然后将其结果合并到主语料库中。用于合并的方法是 "libfuzzer"，它看到的覆盖率远低于 AFL++，尤其是 AFL++ 的 COMPCOV 等功能，因此每次都会损失 AFL++ 发现的覆盖率的 10-20%。

3. 最后，OSS-Fuzz 以 CI 方式运行 ClusterFuzz，单个实例只运行几个小时，然后终止。对于大型语料库或速度较慢的目标，首先进行校准的智能模糊器的启动时间非常长，留给实际模糊处理的时间很少。

有些错误无法通过基于 CI 的模糊测试有效发现，而是需要长时间的模糊测试，使用不同的技术来解决路径限制问题： CMPLOG、COMPCOV、libfuzzer 的值轮廓，以及中小型项目中的一个或两个协程执行框架，为什么还要使用不同的覆盖选项（如 CTX 和/或 NGRAM），以及并行运行多个不同的实例呢？

[Fuzz] ADVANCED FUZZING UNMASKS ELUSIVE VULNERABILITIES

😅



### Clang-tidy

---



#### Clang-tidy 与 Static Analyzer的对比

|   Clang-tidy   | Static Analyzer |
| :------------: | :-------------: |
| 使用语法树匹配 |  使用符号执行   |
|   使用了AST    |    使用了AST    |

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202311281034099.png)

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202311281034928.png)



#### Clang-tidy开发流程

![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202311281037151.png)



#### 使用手册

```bash
$ bear make # 针对Makefile项目生成compile_command.json
$ cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -G Ninja ../ # 针对Cmake项目生成compile_command.json
$ /home/du4t/Desktop/Project/llvm-project/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
```



#### 开发实例

> 开发手册: https://clang.llvm.org/docs/LibASTMatchersReference.html



首先使用脚手架快速创建相关文件 此时相关文件存在于`/home/du4t/Desktop/Project/llvm-project/clang-tools-extra/clang-tidy/misc`中

```bash
$ cd /home/du4t/Desktop/Project/llvm-project/clang-tools-extra/clang-tidy
$ ./add_new_check.py [module] [name]
```



由于Clang-tidy是基于语法树进行检查的 所以第一步就是要搞清对应检查规则的语法树 这里针对测试用例 检查是否存在`memcpy`的`size`字段过大的问题

```c
#include <stdio.h>
#include <stdlib.h>
#include <strings.h>

int main(int argc, char** argv)
{   
    int len = 0x10000;
    void *p = malloc(0x100);
    void *p1 = malloc(0x100);
    memcpy(p, p1, len);
    while(1){
    	len--;
    } 
}

```



使用Clang生成语法树

```c
$ clang -Xclang -ast-dump -fsyntax-only test.c
```

```bash
|-FunctionDecl 0x55d91ce19350 <test.c:5:1, line:14:1> line:5:5 main 'int (int, char **)'
| |-ParmVarDecl 0x55d91ce191f8 <col:10, col:14> col:14 argc 'int'
| |-ParmVarDecl 0x55d91ce19278 <col:20, col:27> col:27 argv 'char **'
| `-CompoundStmt 0x55d91ce1a050 <line:6:1, line:14:1>
|   |-DeclStmt 0x55d91ce194b8 <line:7:5, col:26>
|   | `-VarDecl 0x55d91ce19418 <col:5, col:16> col:9 used len 'int' cinit
|   |   `-UnaryOperator 0x55d91ce194a0 <col:15, col:16> 'int' prefix '-'
|   |     `-IntegerLiteral 0x55d91ce19480 <col:16> 'int' 2147483647
|   |-DeclStmt 0x55d91ce19610 <line:8:5, col:28>
|   | `-VarDecl 0x55d91ce194e8 <col:5, col:27> col:11 used p 'void *' cinit
|   |   `-CallExpr 0x55d91ce195d0 <col:15, col:27> 'void *'
|   |     |-ImplicitCastExpr 0x55d91ce195b8 <col:15> 'void *(*)(unsigned long)' <FunctionToPointerDecay>
|   |     | `-DeclRefExpr 0x55d91ce19550 <col:15> 'void *(unsigned long)' Function 0x55d91cda4c70 'malloc' 'void *(unsigned long)'
|   |     `-ImplicitCastExpr 0x55d91ce195f8 <col:22> 'unsigned long' <IntegralCast>
|   |       `-IntegerLiteral 0x55d91ce19570 <col:22> 'int' 256
|   |-DeclStmt 0x55d91ce19740 <line:9:5, col:29>
|   | `-VarDecl 0x55d91ce19640 <col:5, col:28> col:11 used p1 'void *' cinit
|   |   `-CallExpr 0x55d91ce19700 <col:16, col:28> 'void *'
|   |     |-ImplicitCastExpr 0x55d91ce196e8 <col:16> 'void *(*)(unsigned long)' <FunctionToPointerDecay>
|   |     | `-DeclRefExpr 0x55d91ce196a8 <col:16> 'void *(unsigned long)' Function 0x55d91cda4c70 'malloc' 'void *(unsigned long)'
|   |     `-ImplicitCastExpr 0x55d91ce19728 <col:23> 'unsigned long' <IntegralCast>
|   |       `-IntegerLiteral 0x55d91ce196c8 <col:23> 'int' 256
|   |-CallExpr 0x55d91ce19f10 <line:10:5, col:22> 'void *'
|   | |-ImplicitCastExpr 0x55d91ce19ef8 <col:5> 'void *(*)(void *, const void *, unsigned long)' <FunctionToPointerDecay>
|   | | `-DeclRefExpr 0x55d91ce19e08 <col:5> 'void *(void *, const void *, unsigned long)' Function 0x55d91ce19bc0 'memcpy' 'void *(void *, const void *, unsigned long)'
|   | |-ImplicitCastExpr 0x55d91ce19f48 <col:12> 'void *' <LValueToRValue>
|   | | `-DeclRefExpr 0x55d91ce19e28 <col:12> 'void *' lvalue Var 0x55d91ce194e8 'p' 'void *'
|   | |-ImplicitCastExpr 0x55d91ce19f78 <col:15> 'const void *' <NoOp>
|   | | `-ImplicitCastExpr 0x55d91ce19f60 <col:15> 'void *' <LValueToRValue>
|   | |   `-DeclRefExpr 0x55d91ce19e48 <col:15> 'void *' lvalue Var 0x55d91ce19640 'p1' 'void *'
|   | `-ImplicitCastExpr 0x55d91ce19fa8 <col:19> 'unsigned long' <IntegralCast>
|   |   `-ImplicitCastExpr 0x55d91ce19f90 <col:19> 'int' <LValueToRValue>
|   |     `-DeclRefExpr 0x55d91ce19e68 <col:19> 'int' lvalue Var 0x55d91ce19418 'len' 'int'
|   `-WhileStmt 0x55d91ce1a030 <line:11:5, line:13:5>
|     |-IntegerLiteral 0x55d91ce19fc0 <line:11:11> 'int' 1
|     `-CompoundStmt 0x55d91ce1a018 <col:13, line:13:5>
|       `-UnaryOperator 0x55d91ce1a000 <line:12:6, col:9> 'int' postfix '--'
|         `-DeclRefExpr 0x55d91ce19fe0 <col:6> 'int' lvalue Var 0x55d91ce19418 'len' 'int'
```



由此得出语法树检查规则

```c
//===--- My_testCheck.cpp - clang-tidy ------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//

#include "My_testCheck.h"
#include "clang/AST/ASTContext.h"
#include "clang/ASTMatchers/ASTMatchFinder.h"

using namespace clang::ast_matchers;

namespace clang {
namespace tidy {
namespace misc {

void My_testCheck::registerMatchers(MatchFinder *Finder) {
  // FIXME: Add matchers.
  Finder->addMatcher(callExpr(callee(functionDecl(hasName("memcpy"))), hasArgument(2, declRefExpr().bind("thirdArg"))).bind("memcpy"), this);
}

void My_testCheck::check(const MatchFinder::MatchResult &Result) {
  // FIXME: Add callback implementation.
  const auto *memcpyCall = Result.Nodes.getNodeAs<CallExpr>("memcpy");
  const auto *thirdArg = Result.Nodes.getNodeAs<DeclRefExpr>("thirdArg");

  if (memcpyCall && thirdArg)
  {
    const VarDecl *Var = dyn_cast<VarDecl>(thirdArg->getFoundDecl());
    if (Var && Var->hasInit() && isa<IntegerLiteral>(Var->getInit()))
    {
      const auto *InitValue = cast<IntegerLiteral>(Var->getInit());
      if (InitValue->getValue().getZExtValue() > 0x1000)
      {
        SourceManager &SM = *Result.SourceManager;
        SourceLocation loc = memcpyCall->getSourceRange().getBegin();
        if (loc.isValid())
        {
          diag(loc, "memcpy call has third argument larger than 0x1000")<<loc;
        }
      }
    }   
  }
}

} // namespace misc
} // namespace tidy
} // namespace clang

```



检查结果如下

```bash
$ /home/du4t/Desktop/Project/llvm-project/build_release/bin/clang-tidy --checks="-*, misc-My_test" ./test.c
```

```bash
/home/du4t/Desktop/Test/test.c:10:5: warning: memcpy call has third argument larger than 0x1000 [misc-My_test]
    memcpy(p, p1, len);
    ^~~~~~
Suppressed 1 warnings (1 with check filters).
```



但是由于是静态检查 只能说检查结果差强人意 下面这个样例就是未检出 还是不如`Static Analyzer` 但是好处是`Clang-tidy`是可以兼容`Static Analyzer`的

```c
#include <stdio.h>
#include <stdlib.h>
#include <strings.h>

int main(int argc, char** argv)
{   
    int len = 0x1;
    void *p = malloc(0x100);
    void *p1 = malloc(0x100);
    len += 0x1000;
    memcpy(p, p1, len);
    while(1){
    	len--;
    } 
}

```



如果是需要扫描一个项目的话 需要针对项目编译的`compile_command.json` 此处就体现出另一个弊端 `Clang-tidy`无法输出一个完整的报告 而`Static Analyzer`可以自己生成报告

```bash
$ bear make # 针对Makefile项目生成compile_command.json
$ cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -G Ninja ../ # 针对Cmake项目生成compile_command.json
$ /home/du4t/Desktop/Project/llvm-project/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
```