🤔



# Automatic Library Fuzzing through API Relation Evolvement

## 作者


## 传统方案

- 提取所有的API列表，然后对其进行排列组合 -> 随机性大，可能不符合API的调用规范导致误报率高
- 提取所有的API列表，然后按照Example进行组合 -> 随机性小，误报率小，但是无法称称多样化的API调用序列

目前的研究方案具体可以归结到两个问题

- 如何组合API调用序列覆盖广域的程序空间
- 如何满足API之间的调用规范合成合法的调用序列来解决测试中的因为API调用序列不当而导致的误报

## 作者的方案

- 为了解决隐式API调用规范的问题提出了`关系学习阶段`，即通过更改API调用顺序观察执行状态的变化来推断API关系。而后根据程序状态的变化(崩溃/非崩溃)将API加入到一个APIGraph的动态图结构中
- 根据经验设置了一套崩溃原因库，可以根据程序反馈分析出程序崩溃是因为API调用中不合理的参数还是错误的API调用顺序

### API误用的定义  

作者将API误用定义为了两种漏洞模式——`API调用不规范导致的未定义行为(UB)`和`API库中由于开发者的疏忽导致的漏洞`

- `API调用不规范` 对应的测试工具的多样性指标 即测试工具会生成大量的调用序列而不仅仅依靠案例代码
- `API漏洞`对应测试工具的准确性指标 即测试工具会组合出大量的合法调用序列而仅测试API内部的漏洞


### 方法论

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



#### APIGraph构建

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

文中所有的API调用序列都是基于APIGraph为基础进行合成的，APIGraph本身是一个有向图结构。其基础结构为

- Node: 一个Node和一个函数一一对应，其具体由函数名和参数类型所定义
  - Parameters: 参数类型和属性
  - Constraints: 
    - Value-Set Constraints: 指具有特定值的参数(CONSTANT、Range、Random、Length、FILEIO)
    - Dependency Constraints: 指在该节点上存在APIGraph的边
  - SeedSpace: 存储键值对，其中键位在此节点崩溃的libLang种子，值是从键中学习到的对于API关系
- Edge: 涉及到数据依赖关系的时候，APIGraph会存在一条边用以链接Node之间的Parameters；当涉及到控制流关系时，APIGraph将会存在一条边链接两个Node
  - Control-Flow Edge: 两个Node之间存在控制流关系
  - Def-Use Edge: 存在显式数据依赖关系。其中目标Node使用由源Node的返回值或者参数定义的参数
  - Valid Edge: 存在隐式的数据依赖关系。即源Node的存在对于目标Node是必须的
  - Invalid Edge: 存在隐式的数据依赖关系。即源Node的存在将导致目标Node的未定义行为



APIGraph的构建过程分为两类

- 存在ConsumerCode(Test Unit): 识别其中的API，而后利用FuzzGen相似的技术对API向后切片来进行数据流分析，根据数据的特性为API参数分配不同的属性(CONSTANT、Range、Random、Length、FILEIO)，如果子啊数据流分析中遇到指针或者结构体将执行`Anderson的Points-to分析`来分析相关字段
- 不存在ConsumerCode：将直接匹配参数和返回值类型构建`Def-Use Edge`，对于设计到的参数均分配`DEPENDENT`属性，并且仅对适用的参数分配`FILEIO`其余都为`Random`

> Q1: 本文中提到的Seed是什么?
>
> 其实就是API调用序列，每个API调用序列组成一个Seed
>
> ![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202502162145481.png)



> Q2: Anderson的Points-to分析是什么?
>
> https://www.zhihu.com/question/528991938



> Q3: Seed是如何生成的(API调用序列是如何生成的)?
>
> - Consumer Code: 从Root Node开始执行深度优先搜索
> - APIGraph: 从APIGraph中随机选择一个Node（不能是Def-use Edge或者Valid Edge的目标），而后进行多轮Node插入



> Q4: Seed和APIGraph的生成顺序似乎存在逻辑问题? APIGraph中使用到了Liblang Seed，但是Liblang Seed是由APIGraph生成的?
>
> SeedSpace中的Seed和Liblang Seed中的Seed不是一个东西，其中SeedSpace在后文中可以看出是指某一个参数值的范围
>
> 而Liblang Seed指的就是API调用序列



#### Liblang Seed Mutation

NEXZZER将会在Liblang Seed(API调用序列)上随机执行`type-aware argument mutation`(参数类型感知突变)或者`sequence-aware mutation`(序列感知突变)

- type-aware argument mutation: 根据之前对每个参数分配到的属性进行对应方式的变异(CONSTANT、Range、Random、Length、FILEIO)
- sequence-aware mutation: 因为存在APIGraph的关系，可以分辨出Node之间的关系，便可以执行Node Insertion和Node Deletion操作
  - Node Insertion: 随机选择一个位置，插入一个API(不能引入Invalid Edge)，需要为现有的参数和Node保留所有的Def-use Edge和Valid Edge
  - Node Deletion: 删除一个Node和所有其Def-use Edge和Valid Edge相关联的Node

[Paper] Automatic Library Fuzzing through API Relation  Evolvement

🤔



# A Comprehensive Study of the Capabilities of Large Language Models for Vulnerability Detection



## 作者

- Benjamin Steenhoek -  爱荷华州立大学 - 漏洞检测
- Md Mahbubur Rahman - 爱荷华州立大学 - 机器学习
- Monoshi Kumar Roy - 爱荷华州立大学
- Mirza Sanjida Alam - 爱荷华州立大学
- Earl T. Barr - 伦敦大学学院 - 自动修复
- Wei Le - 爱荷华州立大学 - 机器学习





## Question

**Q1: 基于LLM的漏洞检测最有效和最无效的Prompt是什么?**

**Q2: 最先进的LLM在漏洞检测方面的表现如何?**

**Q3: LLM在解释漏洞时会犯哪些类型的错误?**

**Q4: LLM在定位漏洞方面与开发人员相比如何?**





### Q1: 对于LLM的漏洞检测最有效和最无效的Prompt是什么?



**zero-shot**

```prompt
System: I want you to act as a vulnerability detection system
User: Quesetion: Is the following function buggy? Please answer Yes or No. / Is the following function vulnerable? / Does the following function contain one of the following bug types? CWE-190: Integer Overflow [\n] Answer:

```



**n-shot**

> 作者经过验证认为6-shot效果最好

n-shot涉及到示例的选择问题，作者提供了三种设计: 随机选择的示例、与目标示例具有相似向量的示例、与目标示例成对的负示例

作者提出了prompt的组合形式为

- **Prompt based on random**: 随机挑选案例作为上下文中的示例

- **Prompt based on embedding similarity**: 将相似度高的案例作为上下文中的示例
- **Prompt based on contrastive pairs**: 将成对的相反案例作为上下文中的示例
- **Prompt based on COT from CVE**: 将CVE描述作为思维链
- **Prompt based on COT from static analysis**: 将静态扫描结果作为思维链

![image-20250108174302459](C:\Users\Du4t\AppData\Roaming\Typora\typora-user-images\image-20250108174302459.png)

结果最出乎意料的是，最好的Prompt是**zero-shot**和**Prompt based on random**



### Q2: 最先进的LLM在漏洞检测方面的表现如何?

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

总体来说不及预期，最好的也在0.63。在大多数情况下LLM都无法区分有缺陷的版本和修复之后的版本



### Q3: LLM在解释漏洞时会犯哪些类型的错误?

- 代码理解错误: LLM对有关编程语言的语义或代码结构的错误推断，包括对于代码功能的推断。[ 当代码存在对于指针的检查时，LLM错误的认为指针是在未经检查的情况下访问的 ]
- 常识错误: LLM对程序、环境或者代码的约定作出了错误假设。[ LLM可能会认为某变量为负时会发生错误，但是该变量根据定义是非负的 ]
- 逻辑错误: LLM产生逻辑矛盾或产生逻辑不正确的声明。[ LLM正确的识别变量x经过检查，但是产生“由于变量x未经检查，所以存在漏洞”的推断 ]
- 幻觉

[Paper] A Comprehensive Study of the Capabilities of Large Language Models for Vulnerability Detection

👍



# Prompt Fuzzing for Fuzz Driver Generation



## 作者

- Yunlong Lyu - 腾讯安全大数据实验室 - 原Hopper团队
- Yuxuan Xie - 腾讯安全大数据实验室 - 原Hopper团队 - LLM方向
- Peng Chen - 腾讯安全大数据实验室 - 原Hopper团队 - 模糊测试方向



## 现有方案

现有的自动生成Harness的方案通常有两种技术路线

- 通过源代码构建: 从源代码库中提取API使用代码和规范进行合成
- 动态构建: 从进程的执行轨迹中提取API调用序列并进行合成

但是目前的缺点也很明显，如果使用源代码构建的技术路线的话会存在大量的误报和生成失败的案例；而使用动态构建的方案其API的输入空间仅仅就被限制到了执行过程中可达的函数，显然缩小了输入空间。



## 作者思路

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

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

整体框架如图所示，其实还是使用传统LLM的方式使用prompt让其生成Harness，但是其引入了三种新的后端处理思路来将LLM生成的错误harness进行剔除。

- Compile Validation: 这个是最直接的，直接将编译错误的harness剔除
- Fuzzing Validation: 通过将harness使用Sanitizer等技术编译成为二进制并进行Fuzz，如果Sanitizer对二进制报错则将其剔除。因为harness大概率存在API误用等问题
- Coverage Validation: 这个是和Fuzzing Validation结合的，在模糊测试当中也有可能存在部分API误用是Sanitizer检测不出来的，所以作者引入了覆盖率检验的方式，通过检验覆盖率在模糊测试中是否正常增长来判断harness行为是否正常。

> 同时在`Fuzzing Validation`阶段还会通过Fuzz结果收集增加覆盖率的样本，作为以后Fuzz的初始输入用例



在经过三轮验证之后的harness会将API调用序列收集到库中，而后其借鉴了`模糊测试`的思想，通过变异算子来对API序列进行变异以提升harness效果。

- $Insert(C,A)$：将一个API函数$A$添加到调用序列$C$中
- $Replacement(C,A,B)$：使用API函数$B$替换调用序列$C$中的API函数$A$
- $Crossover(C,S)$: 将调用序列$C$和调用序列$S$合并成为一个新的调用序列



## 总结

很直接和简单的思路，似乎传统方案也可以按照这个技术路线来做?

[Paper] Prompt Fuzzing for Fuzz Driver Generation

🤔



# FOX: Coverage-guided Fuzzing as Online Stochastic Control



## 作者

- Dongdong She - 香港大学 - 漏洞挖掘、模糊测试
- Adam Storek - 哥伦比亚大学 - 
- Yuchong Xie - 香港大学 - 模糊测试
- Seoyoung Kweon - 哥伦比亚大学 - 
- Prashast Srivastava - 哥伦比亚大学 - 模糊测试
- Suman Jana - 哥伦比亚大学 - 机器学习、漏洞检测、模糊测试



## 传统方案

**Scheduler**: 传统覆盖率引导的模糊测试采用较为粗粒度的反馈(覆盖率反馈)选择进一步突变的样本，这种做法严重依赖先前产生的提升覆盖率的种子。随着模糊测试的进行，该调度方法往往会退化成为循环方法。

- 数据流引导的模糊测试: 先前有研究提出了反馈粒度更为精细的数据流引导的模糊测试，但是其往往会带来语料库爆炸的问题。



**Mutator**: 目前的Mutator和程序分支是无关的，其独立于分支逻辑执行随机突变，很显然存在盲目性。

- 污点分析: 虽然污点分析提供了分支定制的突变操作，但是其开销是无法接受的



总结来说，目前虽然**Fuzzer = Scheduler + Mutator**，但是当前的Fuzzer往往都是将其拆分为两个目标不同、数据交换很少的独立实体。



## 作者的方法论

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

覆盖率引导的模糊测试可以定义为一个**在线优化**问题，其目的是最大化目标程序的边缘覆盖率。

对于任意一个目标程序$P$，其输入样例长度为$M$；在每次模糊迭代$i$中，Fuzzer会从当前种子库$S_i$中选择一个种子$S_i[u_i]$，其中$u_i$为所选种子的索引。然后Fuzzer针对样本$S_i[u_i]$ 应用变异器$mut(\cdot)$ 生成新的输入$x$，而后程序将该变异输入执行并使用函数$cov(x,S_i)$来计算变异输入$x$和种子语料$S_i$实现的代码覆盖率提升。根据覆盖率结果Fuzzer会选择是否将输入样本$x$输入到语料库$S_i$中以生成语料库$S_{s+1}$，其目的可以总结为最大化$K$个阶段的代码覆盖率

可以形式化表示为: $Maximize\sum^K_{i=1}[cov(mut(S_i[u_i]),S_i)]$

> Q1: 啥是在线优化问题?
>
> 在线优化问题是机器学习中的一个概念，在线学习代表了一系列机器学习算法，特点是每来一个样本就能训练，能够根据线上反馈数据，实时快速地进行模型调整，使得模型及时反映线上的变化，提高线上预测的准确率。相比之下，传统的批处理方式需要一次性收集所有数据，新数据到来时重新训练的代价也很大，因而更新周期较长，可扩展性不高。

如此以来就将模糊测试的覆盖率提升问题转化为一个**最优控制问题**，在最优控制问题中主要目标是在给定状态空间和控制空间的情况下找到最优控制策略。在目前的模糊测试方案中，状态空间可以定义为Fuzzer在每个阶段的状态，即当前的语料库$S_i$；而控制空间则对应于Fuzzer作出的选择，例如选择样本进行突变。

**状态空间**: Fuzzer 在任何给定阶段的所有可能的配置或者状态，简单来说就是第$i$阶段的语料库信息，用$S_i$来表示

**控制空间**: 包括所有可能影响系统行为的决策，简单来说就是在每个阶段选择哪一个种子，用种子语料$S_i$中的索引$u_i$表示

综上，由于Mutator的随机性质，Fuzzing过程是动态随机的，从形式上看，作者将动态步骤定义如下

$x \leftarrow mut(S_i[u_i]) \\ g_i = E[cov(x,S_i)] \\ S_{i+1} \leftarrow update(S_i, x, g_i) $

**目标函数**: 目标函数定义了系统的目标或预期结果，简单来说其目标是使得$K$个阶段的预期总覆盖最大，形式化表示为$Maximize\sum^K_{i=1}g_i$

**制约因素**: 系统需要满足的限制条件，简单来说就是总执行时间(每个阶段$t_i$的执行时间总和)不得超过Fuzzing处理活动的总时间预算$T$，形式化表示为$\sum^K_{i=1}t_i\le T $



从形式上讲，$cov(x,S_i)$可以建模为一个随机变量，该变量计算在阶段$i$中有多少个未被覆盖的条件分支被针对输入$x$的随机突变操作而翻转；故作者提出了一个指示函数$cov_b(x,S_i)$其结果是一个布尔值，如果在阶段$i$中条件分支$b$因为输入$x$而翻转则结果为$1$，反之为$0$。由此可以得出函数$cov$的数学期望为$g_i=\sum_{b\in B_i}E[cov_b(x,S_i)]$。

通过形式化某分支$b$翻转的概率为$Pr(b\ flips | mut(S_i[u_i]))$ 而 $x \leftarrow mut(S_i[u_i])$，所以可以结合上述公式推到出$g_i=\sum_{b\in B_i}Pr(b\ flips |mut(S_i[u_i]))$ 



而后为了能够估计$Pr(b\ flips |mut(S_i[u_i])$ 的值，作者引入了**forontier node**和**horizon node**的概念，作者将CFG视作$G=(N,E)$其中$N$为一组基本块，$E$表示这些基本块之间的控制流转换，在给定一个语料库$S$的前提下，可以根据代码覆盖率信息将$N$分类为一组未访问的节点$U$和一组访问过的节点$V$

形式化表示为$V=\{n|n\in N,S.cov(n)=1\} \\ U=\{n|n \in N , S.cov(n)=0\}$ ，其中$S.cov$表示在语料库中是否到达节点$n$；作者将**forontier node**定义为一组已访问的节点，并且其主导所有未访问的节点 [这不就是前驱结点么..] $F = \{v|(v,u)\in E,v\in V, u \in U\}$

> Q2: 啥啥啥?
>
> 这里借鉴了文章`Effective Seed Scheduling for Fuzzing with Graph Centrality Analysis`的概念，但是没看懂

为了通过**forontier node**来反应覆盖率，作者只关注和条件跳转相关联的**forontier node**，即**forontier branch**。第$i$个阶段的**forontier branch**用$FB_i$来表示。假设第$i$个阶段的**forontier node**都涉及到对谓词$Q_b$的判断，谓词根据关系$f_b(x)\ R_b\ 0$来判断真假，其中$R_b$表示条件类型$(<,\le,>,\ge,=,\ne)$，x表示输入用例。翻转分支则表示找到一个输入$x'$，其是得$Q_b(f_b(x')) \ne Q_b(f_b(x))$，也就是说使条件的真假翻转。如果通过对Fuzzer的改造，使得Fuzzer在Fuzz过程中可以感知到每个**forontier branch** $b\in FB_i$的二元组$(Q_b(f_b(x),R_b))$，如此便可以定义分支距离算法

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

FOX: Coverage-guided Fuzzing as Online Stochastic Control

🤔



# CAMFuzz: Explainable Fuzzing with Local Interpretation



## 作者



## 核心思想

目前主流的研究思路是解锁未覆盖到的代码块，但是作者认为并不是所有未解锁的代码块都是有用的；同时对于需要解锁的代码块进行分析目前的主流方案是符号执行或者是数据流分析，但是目前的符号执行或者数据流分析仍然存在许多的问题；同时机器学习方案在模糊测试中存在不稳定或模型训练时间过长的问题。

针对上述问题，作者提出了一种名为CAMFuzz的新型解决方案，其利用了可解释人工智能和程序理解能力来分析首先需要解锁程序中的哪些代码块，应该优先变异哪些字节来到达目标区域，并且应该怎么变异。



## 整体框架

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

- Training: 目标是能够训练处一个模拟程序行为的模型，给定一个种子输入，模型就可以预测代码覆盖图。作者选择使用**分类模型**实现这个目标，最后使用一个GAP层来替代最后一个卷积层后的全连接层
- Local Explanation: 使用GAP层来定位输入中的对象，而后让其来帮助我们进行解释；直观上来讲，我们已经训练了一个从输入到程序代码块的映射，我们给出一个目标代码块，`Local Explanation`模块应该给出与该代码块所相关的字节位置
- Magic Value Identification



### Training



**Data preprocess**

作者选择的训练数据为`原始种子文件`和`覆盖率图`

针对`原始种子文件`，首先找到最大的种子而后将其他种子使用`\x00`填充到目标大小；而后将所有种子文件输入到目标程序中获取覆盖率图。通常来说Fuzzer输出的种子是不平衡的[即大部分种子覆盖到大部分都能覆盖到的代码块，只有少量种子可以覆盖到稀有代码块]，所以为了解决这种种子不平衡的问题，作者在获得覆盖率图后会对种子队列进行剪枝以平衡种子。



**model**

作者使用CNN模型来将种子映射到覆盖率图，在理想情况中给定一个训练好的模型$f$和一个输入$(x_1,x_2,...,x_n)$，这个模型可以预测一个代码块$cov_i$能否被覆盖。但是针对该模型作者做了三个改动

- 使用GAP层而不是全连接层
- 将最后一个卷积层所产生的特征图的形状设置为128
- 为了解决代码块数量过多的情况，作者设计了一种分段训练算法

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





**Local interpretaion**

作者引用了一种名为*CAM*的本地解释技术，其背后思想是

- 使用GAP层替代全连接层
- 利用 GAP 后面的最后一个卷积层生成的特征图中的部分信息和 GAP 生成的权重来生成定位信息

作者最后只生成了大小为128的热力图，其给出的解释是如果保持特征图的形状和原始输入相同会有大量的卷积运算从而拖累模型训练进度。



**Node selection**