论文阅读4.6-4.8

论文题目	论文出处
AURORA: Statistical Crash Analysis for Automated Root Cause Explanation	USENIX 2020
A priority based path searching method for improving hybrid fuzzing	Computers & Security 2021
SymQEMU:Compilation-based symbolic execution for binaries	NDSS 2021

AURORA: Statistical Crash Analysis for Automated Root Cause Explanation

作者 ：Tim Blazytko, Moritz Schlögel, Cornelius Aschermann, Ali Abbasi, Joel Frank, Simon Wörner and Thorsten Holz
第一作者单位：Ruhr-Universität Bochum, Germany

论文概要

  相比已经有成熟的自动化工具的漏洞挖掘，漏洞分析在目前还很依赖于人工。一方面漏洞挖掘生成的crashes很多都是一个root cause引起的，需要对大批的crashes进行一个分类的大动作；另一方面root cause不好分析，程序的崩溃点和漏洞点往往不在一个地方，需要沿着crash文件的执行路径去反推漏洞点在哪里，这个很不容易。
  现有的工作需要花费大量的人力去找到root cause。对于上面讲的第一个方面，一些工具在对crash去重的时候依赖于ASAN、GDB啊这些工具生成的call stack，它并不是一个root cause分一堆，可能会产生好多堆crash，去重去了个寂寞；也有可能会分错。
  这篇论文的方法主要是想给人工分析root cause提供便利，不是说完全自动化地找到root cause，它主要是把引起crash的程序行为都记录下来，借助没有触发crash的输入的程序行为提取出和触发crash相关的关键行为，并且根据某些指标给这些关键行为排个序，这些行为能够帮助分析人员来分析root cause，减轻人工分析的压力。

insight

  这篇论文围绕类型混淆类的漏洞对现有的漏洞分析方法的局限性做了讨论。

1. ASAN能够识别非法内存访问即使这个程序还没有崩。但是类型混淆类的漏洞的漏洞点它是没有内存错误的。
2. 反向污点分析比较依赖数据流信息，通过数据流去反推root cause。但是有时候crash和漏洞点之间没有数据流连接的。

  那么问题就转化成当没有直接数据流连接的时候怎么办。这篇论文认为同一个root cause它可能造成程序在不同的位置崩溃，这个crash没有直接的数据流连接，那我们就生成更多的crashes，总有一个是有数据流连接的。

方法

  基于上述思想，AFL这类的工具提供有crash mode，把一个crash作为变异的对象生成大量新的crashes，这样能够提供更多不同的程序行为，不同的程序行为之间的相似点就可以缩小分析的范围。在此基础上还有grammar-based fuzzer，它能够识别出来强制类型转换操作。

  总体方法:

1. 给定一个crash，用它作为初始测试用例跑AFL的crash mode。生成的测试用例按照是否使程序崩溃分为两组。把crash的输入放到一堆，没有crash的输入放到另一堆。
2. 记录输入的行为，如被修改的寄存器、记录被写访问的内存地址的最大和最小值等。因为引起crash的值通常是最小值或最大值，因此它只记录了最小值和最大值，收集堆栈的地址去测试是否有非法指针。把这些值记录在控制流图中。
3. 基于上一步，对于触发crash和没有触发crash的输入各自提取其固有行为。这些固有行为能够用来预测一个输入是否crash。崩溃的地点离root cause越近的输入它会给高的分数，最后按照分数高低它会给出一个列表供人工分析root cause。
4. 人工分析
   • 根据第三步得到的控制流图以及信息，得到一组指令（崩溃的输入执行，没崩溃的输入没有执行的指令）。
   • 生成三种类型的预测：
     • 控制流预测，就是一个基本块x到基本块y有几条路径。
     • 寄存器以及内存预测。预测寄存器取值的极值。
     • flag预测。记录标志寄存器的值。
   • 这些步骤都是为了计算一个值来预测这个输入能否crash。然后在每个预测崩溃的关键位置设置断点，来看输入触发crash的时序信息，记为execution rank。
   • 最后生成一个和崩溃相关的关键位置的排序，以便人工分析。

A priority based path searching method for improving hybrid fuzzing

Insight

  这篇论文核心的一个观点是混合模糊测试中符号执行不应该只是分配解空间小的路径，而是分配需要它求解并且它容易求解出来的路径。因为存在一些约束条件符号执行花费大量的资源也不一定就能求解成功。因此这篇论文就提出一种评估输入的约束条件求解难度的方法。然后提出了一种新的混合模糊测试输入调度方法。
  这篇论文首先分析了MDPC和DigFuzz的局限性。对于MDPC：
   1. 对每条路径评估fuzzing和concolic execution探索这条路径的难度花销很大。
   2. 没有一个合理的指标去评估fuzzing和concolic execution探索某条路径的难度。
  对于DigFuzz：
  1. 它是从fuzzing的角度去评估它覆盖一条路径的难度，但是concolic execution进行约束求解的开销没有考虑。
  2. 蒙特卡洛模型需要大量的样本来使得它的估计有效。
  因此，这篇论文认为concolic execution应该选择那些容易求解并且重要的路径去探索。

方法

  这篇论文认为在大多数情况下，一条未覆盖路径的约束的求解难度和它的长度有关。然后它通过一系列的实验得出一个结论：在一般情况下，如果两个路径长度相同，那么它们的求解难度也相同。于是可以基于路径长度评估一条路径求解的花销。再结合DigFuzz（他自己提出了一种方法，但本质上和DigFuzz一样）去做路径的demand quantifying。最后结合二者计算出一个路径的分数，用于路径分配。

方法细节

1. 一些定义
   1. 定义了一个树形结构表示控制流依赖
   2. 定义了hard constraint，比起线性约束和非线性约束还存在一些约束对于symbolic execution而言是很难求解的。
   3. 未覆盖路径的长度
   4. 记录覆盖每个路径的输入的数量。
   5. 未覆盖的分支。
2. 通过实验得出一些观察
   1. 不同的程序中同一种类的约束条件的分布是近似的
   2. 求解同一种类约束条件的时间开销是一致的。
   3. 然后它得出的结论是如果两个路径长度相同，那么它们的求解难度也相同。
3. 分数计算方式：
   
   
4. 框架：
   

SymQEMU:Compilation-based symbolic execution for binaries

作者：Sebastian Poeplau，Aur´elien Francillon
出处：NDSS 2021

背景

  二进制层面的符号执行面临性能和架构依赖性之间的trade-off问题，本文想提出兼顾跨架构性、实现复杂度低、性能高的符号执行方法。以下是对现有的方法的讨论：

1. Angr：运行时把目标程序翻译成VEX指令，在VEX指令的基础上进行符号执行。优点：VEX支持的架构它也都支持。
   

2. S2E:用QEMU起一个操作系统，然后连接到KLEE。QEMU负责把目标程序从机器码翻译成TCG，然后再转化成LLVM字节码，然后KLEE在LLVM字节码的基础上进行符号执行。
   

3. QSYM：使用Pin在运行的时候对x86机器码进行插桩，插入符号跟踪，然后进行符号执行，但是它针对X86进行定制化地实现，如果想支持别的架构就很麻烦。
   

4. SymCC：源码层面的一个工具，它就是在编译阶段就把符号执行相关的操作插桩到程序中。
   

Insight

  首先现有的方法在开发实现的时候要进行一个中间语言的翻译，如S2E要把机器码转化成TCG再转化成LLVM字节码给KLEE。第二点，当前的工具都是在测试的时候进行符号的解释、约束收集、求解等。这篇论文直接hook QEMU的二进制翻译机制来直接把符号处理编译进机器码里面。相当于S2E和SymCC的结合。

方法

1. 设计目标
   1. 性能好，能够支撑真实世界的软件。
   2. 不依赖特定平台，或者要支持新的平台很简单。
2. 方法设计
   1. 在目标程序运行时把它转化成一个中间语言。
   2. 在中间语言里进行插桩，插入符号执行相关的操作。
   3. 把中间语言再编译成字节码用于CPU运行和分析。