🤔



# File Hijacking Vulnerability: The Elephant in the Room



## 作者

- Chendong Yu - 中国科学院信息工程研究所 - 
- Yang Xiao - 中国科学院信息工程研究所 - 
- Jie Lu - 中国科学院计算技术研究所 - 
- Yuekang Li - 新南威尔士大学 - 
- Yeting Li - 中国科学院信息工程研究所 - 
- Lian Li - 中国科学院计算技术研究所 - 



## 文件劫持漏洞

> 文件劫持漏洞: 这是一种使攻击者能够通过操纵文件内容或文件路径来破坏安全边界的漏洞



> 攻击要求
>
> - 漏洞软件必须通过敏感操作与被劫持的文件或目录发生交互
> - 攻击者必须能够劫持某些文件或目录



### 案例分析



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

1. Bob创建路径`c:\.git\` 
2. Alice在其家目录`C:\User\Alice\`中调用`git log`
3. `git`如果没有在当前目录内找到`.git`会自动向父文件夹内寻找 此时找到`C:\.git\`
4. 如果Bob在`C:\.git\`内设置了`githooks`则会导致Alice执行Bob的任意代码

> Q1: githooks?
>
> 官方提供的一部分Hook函数 用于在git相关操作之后可以快速执行某些命令



### Empirical Study

- 被劫持文件的来源是什么?
- 哪些类型的操作是危险的漏洞触发操作?
- 当在软件生命周期(安装，卸载，…)何时可以触发文件劫持漏洞?



被劫持的文件有两种来源，现有技术主要侧重于检测第一个来源的漏洞。

- 脆弱程序创建的权限较弱的文件，允许攻击者对其进行操作，占全部漏洞的10.1%(27个)
- 攻击者创建的文件，通过特定的搜索策略被脆弱程序遇到。占绝大多数(89.9%，241个)。

> 当没有提供绝对文件路径时，操作系统或程序通常使用不同的文件搜索策略来定位目标文件。通常，这些搜索策略可能会返回具有弱权限的目录，从而允许攻击者植入恶意文件。在我们的调查中，我们确定了5种搜索策略，它们可能返回具有弱权限的目录。
>
> - 路径搜索顺序(3.4%): 在Windows系统中，当执行命令时，系统首先尝试在当前工作目录(CWD)中找到被调用的可执行文件，然后再搜索PATH环境变量中定义的路径。当CWD的权限较弱时，这种策略会带来安全风险。以Github Cli[19]中的漏洞为例。在执行gh命令时，CLI客户端将尝试在CWD中找到可执行文件git.exe。一旦CWD(例如，C:\ProgramData)具有弱权限，攻击者就可以在该目录中放置恶意可执行文件git.exe。
> - Windows下的Linux路径(4.5%): 具体来说，当Windows系统上不存在Linux路径时，系统会从`C:\`目录搜索。由于`C:\`在默认情况下是可写的，这使得攻击者可以轻松地植入恶意文件。以CVE-2019-5443[11]为例。curl程序读取默认配置文件`/usr/local/ssl/openssl.cnf`。在windows操作系统中，此文件不存在，系统会搜索配置文件`C:\usr\local\ssl\openssl.cnf`。由于路径`C:\`具有弱权限，攻击者可以轻松劫持文件并控制引擎配置，从而导致任意代码执行。
> - 未被包裹的路径(17.1%): 未被包裹的路径是指没有加引号的文件路径。当未加引号的路径包含空格或特殊字符时，Windows系统将截断该路径并使用截断的路径搜索该文件。例如，在CVE-2020-13884[14]中，Citrix Workspace程序调用CreateProcess API以不加引号的路径`C:\ProgramData\Citrix\Citrix Workspace 1911\TrolleyExpress.exe`执行文件TrolleyExpress.exe。但是，Windows系统使用空格截断路径并使用路径`C:\ProgramData\Citrix\Citrix.exe`搜索文件，有效地加载文件`Citrix.exe`而不是`TrolleyExpress.exe`。由于路径`C:\ProgramData\Citrix`具有弱权限，攻击者可以劫持`Citrix.exe`，从而导致权限升级。
> - 符号链接(19.4%): 当访问符号链接时，操作系统按照该链接来定位目标文件或目录。CVE-2022-39845就是这样一个例子，它会导致任意目录删除。具体来说，三星Kies的卸载程序试图删除一个不存在的目录`C:\ProgramData\Samsung\DeviceProfile\Cache`。由于攻击者可以拥有对`C:\ProgramData\Samsung`的写权限，因此攻击者可以针对任意目录(例如C:\)创建符号链接`C:\ProgramData\Samsung\DeviceProfile\Cache`。因此，卸载程序将删除`C:\`中的所有文件。
> - 动态链接库(45.5%): 在搜索动态库的过程中，操作系统在搜索目录中查找这些库。但是，如果在此搜索过程中遇到具有弱权限的目录，则可能会允许攻击者劫持要加载的动态库。DLL劫持是近年来备受关注的问题，我们研究的现有漏洞大多是由DLL劫持引起的。



并非所有被劫持文件的访问都可能导致漏洞。例如，查询文件大小之类的操作通常是安全的。通过我们的研究，我们确定了六种可能导致漏洞的操作类型。

- 移动(1.1%)/创建(8.2%)/删除(10.1%): 这三种类型的操作是危险的，如CVE-2022-39845所述。这种对被劫持的符号链接的操作可能导致数据丢失和文件完整性的破坏。
- 读取(7.1%): 程序通常从配置文件中读取不同的设置，这很容易受到文件劫持攻击。例如，攻击者可能篡改配置文件中的数据库连接字符串，从而将后续查询重定向到恶意数据库。或者，攻击者可以在配置文件中插入有害的文件路径，欺骗程序执行恶意代码。
- 进程创建(28.4%): 进程创建涉及创建一个新进程来执行文件，如果文件可以被劫持，则可能导致任意代码执行。例如，在安装过程中，程序可能首先从互联网下载安装文件，然后启动下载的文件来启动安装过程。劫持下载的文件可以欺骗程序执行任意命令。
- 镜像加载(45.1%): 镜像加载是指加载动态加载的库，即在Windows和Linux上分别加载DLL和SO文件。被劫持的库可能导致任意的代码执行。

> 读取操作会导致更多的FHVuln，并带来比我们想象的更高的风险。这些发现来自于新型的FHVuln，因此无法从现有的FHVuln中观察到。此外，我们对Windows和类unix系统中的FHVuln进行了详细的讨论，确定了它们广泛发生背后的原因，并讨论了减轻它们的责任。我们的发现为未来研究改进检测工具和开发针对FHVulns的有效防御提供了有价值的见解。



文件劫持漏洞可以在软件生命周期的任何阶段触发，大多数漏洞是在软件程序启动阶段触发的。目前还没有一种技术能够处理软件生命周期中的每个阶段来检测fhvuln。

- 安装(17.2%): 安装阶段通常包括检查系统需求、复制文件、设置配置等操作。例如，安装过程经常从安装介质(例如，下载的包)复制文件到硬盘驱动器上的指定位置。值得注意的是，安装过程通常需要较高的权限，这个阶段的文件劫持漏洞特别危险:攻击者可以在安装过程中劫持文件以获得较高的权限。
- 卸载(4.5%): 卸载时触发的漏洞都涉及符号链接。卸载软件时，卸载过程将从系统中删除与该软件相关的所有文件(例如，可执行文件和配置文件)。正如CVE-2022-39845中所讨论的，卸载过程可能会遵循劫持的符号链接删除任意目录，导致数据丢失和系统损坏。
- 升级(1.9%)/修复(3.7%): 例如用较新的或正确的版本替换现有的软件版本。这两个阶段分别触发了5个和10个漏洞。
- 启动(62.3%): 当启动一个程序时，程序通常会执行一系列任务来初始化执行环境，包括定位可执行文件、加载动态库、读取配置设置等。以上所有任务都可能受到文件劫持攻击。
- 使用(10.4%): 使用阶段的操作是特定于程序的，根据程序提供的功能，它们可能会因不同的软件程序而发生重大变化。例如，当用户编辑和保存文档时，文本编辑器可以创建、修改和删除文件。类似地，电子邮件客户端可以在下载和存储电子邮件时创建和删除文件。



## 作者的方法

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

- 事件跟踪生成器在每个阶段执行目标程序并记录执行的文件操作跟踪。
- FHVuln检测器检查每个执行跟踪，如果跟踪对被劫持的文件执行危险操作，将报告FHVuln。
- 路径池维护者收集事件跟踪中遇到的文件，并将它们放入路径池中。在此步骤中，JERRY还检查该文件是引用普通文件还是引用目录。
- 路径劫持者试图劫持并创建路径池中的每个文件。路径劫持者充当没有管理员/根权限的攻击者来模仿劫持行为。由于新的文件是由路径劫持者创建的，事件跟踪生成器再次被触发以发现更多的执行痕迹。这个迭代过程不断重复，直到到达一个不遇到新文件的固定点。

[Paper] File Hijacking Vulnerability: The Elephant in the Room

🤔



# FISHFUZZ: Catch Deeper Bugs by Throwing Larger Nets



## 作者



## 目前的做法

目前定向灰盒测试的做法是

- 距离算法 -> 在较大的数据集中 由于种子-目标距离被分解成为单个标量 以此为指导可能会导致失真
- 定常优先级 -> 定常优先级可能会导致一直探索某些已经充分探索的区域



## 作者的做法

- 新的距离算法 -> 为每个目标设置一个距离度量 而不是所有目标的平均
- 动态目标排序 可以自动丢弃目标
- 队列剔除算法

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

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



### 动态优先级

作者为每个目标设置一个三元组$(hit\_frequency, reached, triggered)$

- $hit\_frequency$表示命中次数
- $reached$表示是否到达目标区域
- $triggered$表示是否触发crash

Fuzzer优先选择$hit\_frequency$较少的目标进行fuzz



### 距离算法

因为基本块距离算法针对每个目标都进行计算的话 会导致计算开销过大 所以作者选用的计算方法是计算目标和函数之间的距离。 

作者首先测算所有函数之间的静态距离 而后保存成静态距离图



作者为每个函数对$(f_i,f)$分配了一个权重$weight$ 

- $weight$表示种子从入口函数$f_i$到被调用函数$f$经过的条件边的最小数量
- 条件边的最小数量由函数$dbb(m_a, m_b)$计算 即基本块$m_a$到基本块$m_b$的距离



$weight(f_i, f) = \begin{cases} \min dbb(m,m_f) \quad if\exist m_f\in f_i \\ \infty \quad\quad\quad\quad\quad\quad\quad otherwise \end{cases}$

其中基本块$m$是函数$f_i$的起始基本块 基本块$m_f$是函数$f_i$中调用函数$f$的基本块 如果$f_i$调用了$f$ 则权重$weight$为基本块$m$和基本块$m_f$​之间的最小距离 否则为无穷



两个函数之间的距离的定义如下 其中$sp(f_a, f_b)$是使用Dijikstra算法的$f_a$和$f_b$之间的最短距离

$dff(f_a, f_b) = \sum_{f_i \in sp(f_a,f_b)} weight(f_i, f_{i+1}) $



种子到函数$f$之间距离的定义如下

$dsf(s,f) = \begin{cases} min_{f_s \in \xi(s) }dff(f_s, f) \quad if\quad f\notin \xi(s) \\ 0 \quad\quad\quad\quad\quad\quad\quad\quad\quad otherwise\end{cases}$





### Inter-function Exploration Phase (函数间探索阶段)

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

在这个阶段，FISHFUZZ选择种子来最大化包含未触发目标的已达到的功能。该阶段的剔除算法如算法1所示。具体来说，给定一个种子队列和一组来自目标程序的函数，FISHFUZZ为每个包含目标的未探索函数设置最接近的种子的preferred = 1(第6行)。在将受青睐的种子提交给程序后，FISHFUZZ更新已探索函数列表并重复该过程。getClosestSeedToFun通过种子函数距离(§3.2)找到最接近函数f的种子s。如果多个种子与f的距离相等，我们会选择执行时间最短的那个。



### Exploitation Phase (利用阶段)

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



> Q1: 作者全文没有提到target是如何注入进去的?
>
> 作者通过SanitizerCoveragePCGRARD.so 针对源代码的bc进行插桩 然后将所有插桩位置记录下来作为target



## 缺点

1. 直接使用Sanitizer的标签作为target 显然缺少漏洞导向的指向性
2. 没有指标显示是否覆盖到target

[Paper] FISHFUZZ: Catch Deeper Bugs by Throwing Larger Nets

👍



# Arbiter：Bridging the Static and Dynamic Divide in Vulnerability Discovery on Binary Programs

## 作者

- Jayakrishna Vadayath - 亚利桑那州立大学 - 
- Moritz Eckert - 法国工程师学校 - 二进制安全
- Kyle Zeng - 亚利桑那州立大学 - 二进制安全
- Nicolaas Weideman - 南加州大学 - 程序修复
- Gokulkrishna Praveen Menon - 亚利桑那州立大学 
- Yanick Fratantonio - Cisco Systems Inc - 漏洞挖掘
- Davide Balzarotti - 法国工程师学校 - 模糊测试、机器学习
- Adam Doupé - 亚利桑那州立大学 - 模糊测试、WEB安全、内核安全
- Tiffany Bao - 亚利桑那州立大学 - 模糊测试、WEB安全、内核安全
- Ruoyu Wang - 亚利桑那州立大学 - 原清华团队
- Christophe Hauser - 南加州大学- 机器学习
- Yan Shoshitaishvili - 亚利桑那州立大学 - 模糊测试、WEB安全、内核安全



## 问题

目前静态分析和动态分析都具有各自的优点和缺点，但是在各自不擅长的领域几乎没有作用。

- 动态执行: 可以快速进行测试、误报率低；但是针对深层代码或者存在多个约束的代码效果很差
- 静态分析: 可以人工审查深层漏洞；但是缺少有效识别漏洞的工具和精度

> Q1: 即使结合了动态执行和静态分析，又能怎么用来挖漏洞呢?
>
> 作者总结了几种漏洞的属性，静态快速扫描特征，然后指定source点和sink点调用符号执行进行测试，如果使用符号执行验证目标路径可达则确定为漏洞。



## 作者的思路

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

首先定义了三种漏洞属性，为静态分析和动态分析提供结合的接口

> 1. 数据流敏感漏洞。对数据流敏感的漏洞可以通过推理source点和sink点之间的数据流来发现。请注意，数据流敏感漏洞的范围严格大于污染型漏洞，污染型漏洞仅包括因未对受污染的用户输入进行清理而导致的漏洞。这些可以通过静态技术实现，具有典型的精度限制，但也允许对数据流进行额外的动态验证以提高精度。
> 2. 易于识别的source或者sink。在漏洞发现过程中，source点决定数据流跟踪的开始，sink点决定数据流跟踪的终止。识别许多漏洞类别的source和sink需要整个二进制文件的精确别名信息，众所周知，这是极其昂贵且不可扩展的。例如，如果source被定义为“从文件 /tmp/secret 读取的任何数据”，则识别所有输入源将需要正确分析打开文件的每个函数和系统调用的参数，以及文件指针、文件描述符的传播，以及相关的数据结构。相反，有些sources或sinks，可以通过检查计算成本低且可扩展的分析生成的工件来识别(例如CFG)。这种sink的一个例子是“库函数 malloc() 的所有调用点”。通过这种类型的source和sink，将程序从source到sink切片是一种经过充分研究的静态技术。尽管通常在静态分析的背景下考虑此属性，但这些切片可以通过动态技术进行处理。这允许动态技术（例如 DSE）对切片过程中的过度近似进行推理，修复此类过度近似，并提高整体系统精度。
> 3. 控制流决定的别名。跟踪数据流几乎总是涉及恢复别名信息，这需要对目标进行昂贵的全二进制分析。然而，我们观察到，许多漏洞合并的数据流根本不涉及指针解引用，或者当它们这样做时，指针总是可以被解析为由控制流确定的一个对象(例如，通过堆栈指针访问的局部变量)。我们认为这种别名的情况是由控制流决定的，这是我们的目标漏洞的先决条件。从静态方面来看，这个属性允许ARBITER自适应地在CFG上前进或后退，而不必担心由不正确的别名信息引起的不精确。从动态方面来看，它极大地简化了由于缺乏动态初始化而导致的别名问题。



> Q2: 单纯这三个属性怎么对接静态分析和动态分析?
>
> 1. 数据流敏感漏洞
>    - 静态分析: 静态分析可以识别程序中的数据流路径，从潜在的输入源（如用户输入）到潜在的漏洞汇（如不安全的函数调用）。静态分析工具可以构建数据依赖图（DDG），并分析数据如何在程序中流动。
>    - 动态分析：动态分析，特别是动态符号执行（DSE），可以用来验证静态分析发现的数据流路径是否在实际执行中确实存在。DSE可以模拟程序的执行，检查数据流是否满足特定的漏洞条件
> 2. 易于识别的source或者sink
>    - 静态分析：静态分析可以利用程序的控制流图（CFG）来识别源和汇。例如，可以识别所有调用特定函数（如`malloc`）的点作为源，或者识别所有可能受到用户输入影响的函数作为汇。
>    - 动态分析：在动态分析中，可以针对这些易于识别的源和汇执行测试用例，以观察数据如何在程序执行过程中流动。这有助于验证静态分析的结果，并发现可能的漏洞触发点。
> 3. 控制流决定的别名
>    - 静态分析：静态分析中，可以利用控制流信息来限制别名分析的范围，因为许多漏洞涉及的数据流不涉及复杂的指针操作。这允许静态分析在不完全解决别名问题的情况下，仍然能够准确地识别潜在的漏洞。
>    - 动态分析：在动态分析中，可以利用控制流信息来简化别名问题。例如，如果一个指针总是指向由控制流确定的特定内存区域，那么在动态执行时可以为这个指针分配一个隔离的内存区域，从而避免复杂的别名问题。



> Q3: 作者提出了一个叫做Vulnerability Description(VD)的概念，具体这个东西是怎么组成的?
>
> VD其实是由漏洞的特征来编写的，简单来说其包含指定的sink点，source点和满足何种条件时确定为漏洞



> Q4: 其中的source和sink点是怎么确定的?
>
> 由VD中的sink和source指定的



> Q5: 哪些工作体现了静态分析，哪些工作体现了动态分析
>
> 首先是sink和source的识别，使用静态分析快速识别sink和source点，然后调用动态符号执行验证是否有可控数据从source点到达sink点



> Q6: 如何实现sink点和source点的静态跟踪? 针对作者说的不使用源代码仅使用二进制程序?
>
> 作者提出了一种静态数据流跟踪的方法`SymDFT`。给定任何起点(通常是函数的开始)，SymDFT以上下文敏感和路径敏感的方式静态地模拟基本块，并对寄存器、内存(作为覆盖全局区域、堆栈和堆的平面内存模型)、系统调用、以及对文件描述符的访问(这捕获了对文件和网络套接字的访问)。
>
> - 遍历策略。在函数级别上，SymDFT按拓扑顺序遍历函数内部的基本块，从而确保始终在访问所有前一个块之后访问一个块。一旦遇到对被调用方的调用，SymDFT将分析被调用方函数，并使用返回的抽象状态在返回站点继续分析。‘
> - 分支策略。在每个分支点，它分叉抽象状态并遵循所有分支，无论分支可行性如何:随着仿真的进行，SymDFT收集符号路径预测(即符号约束)，但它不评估这些约束的可满足性。
> - 状态合并策略。在同一二进制地址的抽象状态被立即合并，其中每个状态被分配一个合并标签，具体和符号表达式被合并成一个if-then-else表达式的形式，合并标签作为条件。
> - 终止策略。为了确保分析终止，SymDFT采用了激进的终止策略:(1)当调用深度超过2个函数时，SymDFT不分析被调用方，而是伪造一个抽象的返回值;(2)每个循环最多访问3次。这种激进的终止策略以降低可靠性和精确性为代价换取了可伸缩性。
>
> 而后根据CFG在其中识别出source点和sink点并且根据此生成数据流图，在数据流图上对source和sink的追踪很简单就是直接寻找子图即可。



> Q7: 作者一直提到欠约束的符号执行(USCE)，这个到底是欠缺哪一部分的约束？
>
> 这里提到的欠约束的符号执行，实际上是一种对符号执行条件要求的弱化，因为如果通过符号执行的方法得到一条从输入到sink点的路径代价是巨大的，所以如果我们选择从中间某个函数开始进行模拟，可以减少一部分的代价，当然这里减少代价是一部分，并且由于前面的静态分析获得的信息不完整的原因而选择欠约束的符号执行，其可以针对某个函数开始符号执行，其将所有未知值（即条件不足无法推断其值的参数）视作欠约束的变量，针对欠约束变量在源码中不同的使用方法给予不同的约束。



> Q8: 别名问题是什么东西
>
> 其实就是两个指针指向同一个地址，这两个指针就称为别名，在汇编层面对于这个别名问题的辨别存在巨大困难。



## 解决了什么问题

作者提到其认为的最大贡献是弥补的静态分析和动态分析之间的空缺，其将静态分析和动态分析链接起来，使用静态分析来指引动态分析的过程，其中的感觉这个VD和漏洞模板是可以替代Checker的功能的。使用特定的漏洞模板来指引Fuzz过程是否能做到?

## 仍然存在什么问题

很显然，程序只能解决作者提到的PC漏洞，即

1. **数据流敏感性**：这类漏洞可以通过分析数据流来发现，即从输入源到漏洞汇的数据流动。这些漏洞可以通过静态技术分析，同时也可以利用动态技术来提高精确度。
2. **易于识别的源或汇**：对于许多漏洞类别，源和汇可以通过检查程序的控制流图（CFG）等静态分析技术来识别。这种属性允许使用静态技术来确定程序中潜在的漏洞点，并且可以通过动态技术进一步验证。
3. **控制流决定的别名**：许多漏洞涉及的数据流不涉及指针解引用，或者当它们涉及时，指针总是可以解析为由控制流确定的一个对象。这种属性允许在静态分析中忽略复杂的别名问题，同时在动态分析中简化了别名问题的处理。

例如未初始化漏洞就无法通过Arbiter检测



## 复现流程

```bash
$ git clone https://github.com/jkrshnmenon/arbiter.git
$ python setup.py build && python setup.py install
$ mkdir test
$ ./vuln_templates/run_arbiter.py -f examples/cve-vuln_templates/vd_cve-2018-10388.py -t examples/cve-binaries/cve-2018-10388 -l test/log/ -j test/json/
```

[Paper] Arbiter：Bridging the Static and Dynamic Divide in Vulnerability Discovery on Binary Programs

🤔



# ARCUS: Symbolic Root Cause Analysis of Exploits in Production Systems
## 作者

- Carter Yagemann - 佐治亚理工学院 - 漏洞检测、成因分析
- Matthew Pruett - 佐治亚理工学院研究所 - 漏洞检测
- Simon P. Chung - 佐治亚理工学院 - 漏洞检测
- Kennon Bittick - 佐治亚理工学院研究所 
- Brendan Saltaformaggio - 佐治亚理工学院 - 漏洞检测、Web方向
- Wenke Lee - 佐治亚理工学院研究所 - Fuzz

> **VulChecker: Graph-based Vulnerability Localization in Source Code**



## 思路

作者针对漏洞的RCA和修复提出了一种新思路，即利用Intel PT技术，来监控程序的错误的控制流，一旦程序被打上错误标记，ARCUS会将其捕捉并发向分析系统。分析系统会利用快照将错误流重建然后根据一系列模板发现冲突点确定漏洞根本成因。主要的检测思路是，在重建快照之后，将攻击者可以控制的参数更改为符号值，然后进行执行观察符号值的传播，一旦符号值污染到关键参数则确定漏洞触发，而后向前寻找符号值是怎么传进来的，在哪里产生的，以确定漏洞根本成因。

基本定位流程为：

1. 识别成为符号的代码指针：符号值向后传播即可
2. 识别污染其成为符号值的基本块：生成控制流依赖图CDG来定位
3. 寻找控制污染块执行的基本块
4. 测试附加约束是否可以修复漏洞

### 堆栈溢出的检测思路

堆栈溢出根本特征是控制流劫持，在重建快照之后，沿着攻击者执行路径进行重建中间状态时观察PC是否被污染成为符号值即可。在发现PC被污染成为符号值之后即确定存在堆栈溢出。从这一点开始，模块查看先前的状态以确定是什么导致符号数据进入PC。由于劫持只能发生在间接控制流传输时，因此先前的状态必须执行以返回、间接调用或间接跳转结束的基本块

**控制流被污染 + 之前的基本块为返回、间接调用或间接跳转结束的基本块**

### 整数溢出检测思路

**操作可能溢出 = 标记溢出的寄存器 + 寄存器传播到另外一个函数时 确定发生整数溢出**



### UAF和Double Free检测思路

**内部针对所有的malloc和free维护一个bin并且记录大小，一旦违背操作规则则发生UAF和Double Free**



### 格式化字符串检测思路

**如果违背指向格式字符串的指针是具体的，且驻留在只读存储器中/字符串的内容是完全具体的/所有附加参数都指向映射的内存地址则为格式化字符串漏洞**

[Paper] ARCUS: Symbolic Root Cause Analysis of Exploits in Production Systems

🤔



# BENZENE: A Practical Root Cause Analysis System with an Under-Constrained State Mutation



## 作者

- Younggi Park - 高丽大学、国防部
- Hwiwon Lee - 高丽大学、国防部
- Jinho Jung - 国防部
- Hyungjoon Koo - 成均馆大学
- Huy Kang Kim - 高丽大学



## 现有的RCA方案

- 基于AURORA的统计学方案
  - 缺点：用于崩溃探索的Fuzz技术不足以有效的收集RCA中适当的非崩溃行为；trace非常耗时
- ARCUS 预制规范模板的符号执行及崩溃重放
  - 缺点：无法解决符号执行带来的路径爆炸和约束求解的问题；不能预定义所有漏洞类型



## 理论基础

崩溃必须满足每个崩溃触发条件。也就是说，崩溃的存在必须满足一组条件（即谓词）才能产生给定的崩溃，这意味着如果集合中的任何谓词已被否定，则不会发生崩溃，并且正常行为与崩溃行下的一个或多个谓词相矛盾。

我们假设目标程序（P）的行为对于给定的输入 I 具有明确的执行路径（即确定性）。我们将 P 中的漏洞表示为 V。然后可能有多个 I 因 V 而触发崩溃，每次崩溃的执行路径是唯一的。

## 提取RCA的思路

1. 从所有谓词中提取出普通崩溃谓词
2. 从普通崩溃谓词中提取出根本成因

## 作者的思路

本质上和AURORA类似，只是引入了一种`运行时直接状态突变的欠约束状态突变方案`来实现崩溃探索

- 为了解决目前针对崩溃样例和非崩溃样例获取的难题，作者引入了状态突变来有效地收集与给定崩溃相关的不同行为
- 为了解决从大量普通崩溃谓词中定位根本成因的难题，作者去除了比较过程，选择用行为相似度定位根本成因

> 状态突变：这是一种针对 RCA 量身定制的突变技术，可在运行时突变目标程序状态。该技术背后的关键思想是，导致崩溃的输入的一部分最终存储在处理器寄存器或进程存储器中。
>
> ![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202402210011766.png)
>
> > Q1. 这样做状态空间不是更大了么，如何快速缩小状态空间?
> >
> > 我们采用三种突变策略来使我们的技术实用且稳健（§6.2）。令执行的指令为$i\in\Omega$，其中$\Omega$表示某个程序中的所有指令。现在我们在执行指令$(i)$的那一刻定义一个状态为$S_i(R,M)$，其中寄存器和存储器的当前状态分别表示为$R$和$M$。为了描述状态突变$(T)$，我们定义两个属性：1个类型：$t\in\{opr,mem\}$，其中$opr$和$mem$表示要从中进行突变的源操作数或内存，以及 2 个值：$v \in Z_n = \{x|x\in所有可表示的n位整数\}$然后，状态突变可以正式写为$T_i(t,v,v'):S_i(R,M)\rightarrow S'_i(R',M')$ 其中状态转换是用值 $v$到$v′$ 类型$(t)$。例如，图 4 中 i := lea esi, [rax+rax*4] 上的状态突变可以写为 $T_i(rax, 0, 255): S_i(R,M)\rightarrow S'_i(R',M')$注意，BENZENE 仅关注源操作数中的值突变，因为目标操作数中的值由其源自动确定。
> >
> > - 突变总结：在高层次抽象来看上，BENZENE类似于 LibFuzzer和内存中模糊测试，我们通过分叉创建新进程来探索函数级别的程序行为。一旦提取了这些目标函数，我们就会以每个函数固定次数的迭代来重复状态突变。在每次迭代中，我们选择一个突变目标 Si(R,M)。当达到突变目标（Si）时，我们执行状态突变（Ti），相应地修改程序的当前状态。突变后，我们继续该过程直到终止并监视（非）崩溃。请注意，改变程序状态会使其容易发生意外崩溃；因此，我们设计了相关的突变策略。
> >
> > - 函数级Fork：由于程序中有大量指令，我们需要缩小状态突变的位置范围。为了解决这个问题，我们采用函数的粒度来进行突变过程（ 例如图 7 中的 Foo()）。具体来说，我们提取了与崩溃站点无效内存访问相关的函数列表。这可以在动态二进制分析期间使用函数信息和崩溃起源来执行（§5）。一旦确定了目标函数（例如 10 分钟），我们就为每个目标函数迭代一个状态突变 (F)；即，1 在目标函数内选择状态突变 Ti : S → S′（即 i ∈ F），2 执行指令，3 监视突变结果（即崩溃或非崩溃）。对于每次迭代，该过程都会在目标函数的入口处分叉。
> > - 变异目标的选择：对于目标函数的每个分叉过程，我们必须选择一个状态 Si(R,M) 作为突变候选。尽管我们将突变范围限制在目标函数内，但仍然存在突变目标选择问题。对于目标函数的每个分叉过程，我们必须选择一个状态 Si(R,M) 作为突变候选。尽管我们将突变范围限制在目标函数内，但函数内仍然存在大量指令。为了解决这个问题，我们将指令缩小到引用外部值（来自函数边界外部）的指令选择池（即 i ∈ P，P ⊂ F）。背后的直觉是某个函数的行为可以由外部值（例如参数或全局变量）决定；因此，改变它们可以帮助产生理想的行为。我们利用 DFG (§5) 来识别在二进制级别使用此类外部值的指令。考虑图 7 中的 inst2，其中 inst2 的传入边为 (rcx, inst1)。影响值（即 rcx 中的值）源自外部函数（例如调用者）。由于inst2采用外部引用值，因此我们选择Sinst2（R，M）作为P中的突变目标。相比之下，数据流来自inst2的inst3可以从P中排除，因为rax依赖于rcx。值得注意的是，我们的方法与调用约定（即子例程如何从调用者那里获取参数的方案，例如 stdcall、cdecl 或 fastcall）无关，因为我们检查值是否来自寄存器或具有函数边界的记忆。
> >
> > ![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202402231058756.png)
> >
> > - Bag of Values: 由于其固有的不稳定性，欠约束的状态突变很容易导致不期望的无效崩溃。我们仔细的观察启发式地揭示了经常触发此类无效崩溃的两种主要情况：改变引用用户定义的数据类型（例如结构）的指针和改变具有不同范围的约束变量（例如枚举类型、数组索引）。为了处理这两种情况，我们维护一个Bag of Value (BoV) λ，以指导进一步的突变。该袋子在内部收集每个 Si(R,M) 的一组观察值（根据指令从源）。因此，可以从 Ti(t, v, v') 的 (即 v' ∈ λ) 中选择突变候选者 (v')。该策略背后的直觉是，共享相同数据流的值很可能具有相同的数据类型。这有助于观察可接受的行为，而不必担心二进制文件上的复杂类型推断。然而，它提供了在可接受的时间限制内覆盖大突变空间的机会。我们通过回溯 DFG 中的传入边（即，直到 DFG 中具有单个源边的点）（例如图 7 中的 3），从执行指令的存储值中培养每 S 的 BoV。 BoV 感兴趣的是一个特殊的值，它可以进入一个分支（例如，来自 cmp rax 的 0x40，0x40），使我们能够有效地收集非崩溃行为，例如模糊测试中的先前工作[76]、[111]、[ 124]。如果 BoV 超过预定义的大小（例如 1024），BENZENE 会进行随机抽样。使用 BoV，BENZENE 生成随机值 (RV)，为每个突变周期从 BoV 或 RV 中概率选择一个值（例如 50%）。请注意，我们禁用了 ASLR，因为每个突变的内存布局在突变期间必须保持一致。
>
> 
>
> > Q2. 直接更改状态空间按理来说是存在可能没有对应输入的，没有对应输入获取到的崩溃或者非崩溃谓词就是没有意义的？
> >
> > 人们可能会提出确保这种状态突变的行为有效性的问题，因为强制修改程序的中间状态通常会导致后续执行无效（例如，无法到达的状态）。然而，与模糊测试相比，我们的状态突变不需要推理输入的验证，而是利用突变本身来获得非崩溃行为。在这方面，我们的突变技术被称为欠约束状态突变，它是从欠约束符号执行中借用的。也就是说，即使存在不可行状态，非崩溃行为也是不满足崩溃条件的（副）产品，这可以帮助寻找根本原因（即崩溃条件）的候选谓词。举例来说，图 1 中第 4 行中 im1->sx 从 0xfff 到 0x0 的突变会导致非崩溃，因为它不包含崩溃条件下的谓词之一 [im1->sx > 0x0]。尽管此突变通过引导无法到达的分支（即，没有循环的转义）而导致不可行的执行，但其行为对于获取 RCA 的谓词很有用。我们在第 6.3 节中详细阐述了在约束不足的状态突变下崩溃行为的有效性。
> >
> > ![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202402210046908.png)
> >
> > 虽然我们的欠约束状态突变技术主要集中于收集非崩溃行为，但有必要收集最小的崩溃行为集，因为我们利用了 AURORA 谓词合成的方法（等式 1）。然而，与可以确认其有效性的非崩溃行为相比，很难确定由状态突变引起的崩溃是否与原始崩溃相关联。例如，如果最初表示特定指针的目标被突变为无效整数（例如 0x1），则崩溃（与错误无关）将毫无意义。这种无效的崩溃通过在方程 1 中引入大量噪声而显着阻碍了准确崩溃条件的合成。基于先前的反向执行分类技术 [78]、[79]、[121]，我们将某个崩溃分类为同一类别，如果遵循相同的数据流。然而，为每次崩溃执行构建 DFG 的成本很高，开销也很大。为了解决这个问题，我们设计了一种崩溃分类技术，可以将具有给定崩溃（即根本原因）的执行与具有无效状态突变的执行区分开来，同时产生较低的开销。该技术需要满足以下两个条件：1 由状态突变触发的崩溃站点（即地址）与初始崩溃相同，2 执行与崩溃起源相关的指令。如果状态突变的崩溃满足上述条件，我们记录此行为；否则，我们将丢弃它。显然，我们的方法可能会通过仅考虑 V 导致的所有可能崩溃的子集来合成过度近似的崩溃条件；然而，CR 仍将与子集一起保留。换句话说，CR 必须满足非崩溃不能满足的崩溃（一部分）。
>
> 
>
> > Q3. 
> >
> > 





> 行为相似度：这种方法的关键见解是，在常见的崩溃情况下，非崩溃行为必须与一个或多个谓词相矛盾。我们的方法基于以下事实：给定崩溃和非崩溃之间的代码覆盖率越接近，就越有可能通过与崩溃中的谓词相矛盾来揭示 V 的根本原因。例如，表 1 列出了四种非崩溃行为（#1-4），每种行为至少与 C* 中的一个谓词（即灰色单元格）相矛盾。在这种情况下，与第一个非崩溃输入 (#1) 相矛盾的谓词 (p1) 最有可能成为 CVE2019-6977 的根本原因，因为 #1 是最接近初始崩溃（即 IC）的行为。利用主成分分析来计算非崩溃行为的相似度得分
>
> ![](https://blogdownload.oss-cn-hangzhou.aliyuncs.com/202402210020054.png)





## 整体框架结构



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

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

BENZENE 首先构建一个矩阵来描述每个收集到的行为的边缘覆盖范围，然后计算初始崩溃和非崩溃行为的覆盖范围之间的相似性得分。接下来，BENZENE 合成基于非崩溃行为描述崩溃条件的谓词。最后，BENZENE 使用崩溃条件的综合和每个非崩溃行为的相似性分数对导致给定崩溃的所有谓词进行排名。

欠约束状态变异可能会造成许多无意义的崩溃，所以归类有意义的崩溃至关重要。如果一个崩溃由状态突变触发的崩溃站点（即地址）与初始崩溃相同且执行与崩溃起源相关的指令。如果状态突变的崩溃满足上述条件，我们记录此行为；否则，我们将丢弃它。

- 边缘覆盖矩阵：与 AFL类似，我们利用广泛采用的边缘覆盖图来衡量模糊技术的性能。 BENZENE 在 64 KB 大小的地图上记录每个收集的行为的边缘覆盖信息（即基本块之间发生的转换）。地图随着迭代突变而不断更新。通过n种不同的行为，我们可以获得n（行）×64 KB（列）大小的边缘覆盖矩阵。一个值得注意的副作用是，具有非崩溃行为的执行的覆盖图将保持更新，直到程序终止，而具有崩溃行为的执行则不会。这不可避免地会导致用于比较的覆盖图之间存在显着差异，这阻碍了我们寻找与原始崩溃类似的非崩溃行为的主要目标。为了缓解这个问题，我们利用一个观察点来通知我们何时停止更新覆盖图。准确地说，观察点监视崩溃起源之一（第 6.3 节）；一旦执行了崩溃触发的指令（来自给定的崩溃），覆盖图更新将被暂停以供后续执行。
- 基于 PCA 的相似度。为了减少边缘覆盖矩阵的维度，我们应用 PCA为每个收集的行为获得紧凑的覆盖图（图 8 中的 1）。然后，我们计算非崩溃行为的覆盖范围与初始崩溃之间的欧几里德距离（即 L2 范数）。 BENZENE 通过相似性分数（图 8 中的 2）确定具有某种非崩溃行为的执行与原始崩溃行为的执行有多接近：即距离越小，分数越接近。这种相似性评分允许对所有收集到的接近初始崩溃执行的非崩溃行为进行优先级排序。