🤔



# Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions

## 作者
- XINYI HOU - 华中科技大学 - LLM
- YANJIE ZHAO - 华中科技大学 - LLM、Fuzz
- SHENAO WANG - 华中科技大学 - LLM、漏洞检测
- HAOYU WANG - 华中科技大学


## 什么是MCP?
随着Function Calling功能的完善，越来越多的LLM服务商为了拓展自己LLM的能力开发出了基于自己LLM的工具集，但是这些工具往往存在着`限于固定LLM，固定API，固定的身份验证方式`等问题，可移植性差。

针对上述问题Anthropic推出了MCP框架，简单来说其规范了一种LLM插件的开发模式，通过规范接口来达到LLM插件可移植的目的

## MCP的核心架构
![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/20250503201825.png)

- MCP Host: MCP Host是一个 AI 应用程序，它提供在运行 MCP Client时执行基于 AI 的任务的环境。它集成了交互式工具和数据，以实现与外部服务的顺畅通信。示例包括用于 AI 辅助内容创建的 Claude Desktop、用于代码完成和软件开发的 AI 驱动的 IDE Cursor，以及用作执行复杂任务的自主系统的 AI 代理。MCP Host托管 MCP Clent并确保与外部 MCP 服务器的通信。
- MCP Client: 发起请求的中介，负责MCP Host和MCP Server之间的通信。
- MCP Server: 核心组件，主要负责提供tools, resources, prompts

[Paper] Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions

🤔



# 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)