🤔

UTOPIA: Automatic Generation of Fuzz Driver using Unit Tests

现有的生成harness的方法

• 从现有的代码库中根据代码推断API有效序列
• 从Example中提取

现存的问题

• 单纯从API来说会跟别的用户代码逻辑混合 需要区分

前人的工作

• 随机从源码中推断API序列
• 动态执行时观察执行序列

前人工作的局限性

• 习惯于从consumer code中推断API
• 对于consumer code中的代码逻辑无法区分 容易从中生成错误的API序列或者生成错误的harness逻辑

提出什么方法

• 从Unit Test中自动提取API序列生成harness
• 提出了一个新概念 Root Definition
  • 根据各种分析链回溯 最根源的变量称为Root

新方法的优点

• 在Unit Test中所有API的调用都是显式的 方便在生成harness时从中提取
• Unit Test与Fuzz的目标是接近的 都是为了测试软件 其目的性可以保证

新方法的目的

• 合成出有效的API调用序列
• 合成出有效的API调用参数

提出的方法面临的困难

• 由于存在继承等复杂代码关系 静态分析存在一定困难
• Unit Test的存在形式是多样的 没有一个固定的规范
  • 使用Clang AST语法树进行分析 针对不同框架开发出不同的解析方式即可
• 如何放宽一些检查 如果太严格会阻碍大部分的变异数据 如果太松会导致许多误报

分析方法

• Def-Use(DU) Chain: 定义使用链分析 关注定义之后的每次使用(主要关注存储)
• Inter-procedural Analysis: 函数间调用分析 主要是继承DU链 或者使用第三方库进行分析
• Output Analysis: 对于输出进行Fuzz是没有收益的 在DU链的基础上根据LLVM IR查看变量是否有load/gep指令 判断是否有输出
• FilePath and AllocSize Analysis: 对FilePath和AllocSize进行Fuzz是没有意义的 一个只会影响打开的文件 一个只会影响分配的内存大小 直接固定关注libc中设计到FilePath和AllocSize的函数即可
• LoopCount Analysis: 分析库内循环计数器 对其Fuzz同样是无意义的 可以避免程序超时。如果在DU链中识别到比较指令，则检测该变量是否为循环退出变量(检测到任何对该变量作用的条件分支 则认为其为LoopCount)
• Array<->Length Analysis: 数组与长度对应变量 通过识别DU链中带有索引访问的gep命令中的变量认为其为Array 当循环中的gep变量且其索引操作数为Array、处在循环之中、循环条件不变 则判断为Length [10 in while(i<10)]

harness合成

• 将某些变量的值(Root) 转化成为Fuzz目标
• 排除条件如下
  • 头文件中或者项目文件之外的Root
  • 编译时确定的常数
  • 带有外部函数的返回或者输入参数的函数
  • 初始化赋值为Null的Root
  • 函数指针参数
  • 依赖于之前分析时忽略的变量
  • 文件属性
• 变异策略
  • 变异文件内容而不是文件路径
  • 限制变异分配内存时的参数大小
  • 限制变异循环变量
  • 对数组Fuzz时 创建一个数组并将Fuzz输入分配给数组的每一个元素
  • 限制Fuzz输入比数组大小小1
• Fuzz循环
  • 设置一个固定入口函数用于调用生成的harness
  • 提取出变量原始值作为种子 方便快速提高覆盖率

效果