G.O.S.S.I.P 阅读推荐 2022-08-24 LibAFL

现如今，系统安全方向的论文已经展开了激烈的军备竞赛，一篇文章不仅要代码开源，还动辄成千上万行的代码量，今天我们推荐的这篇 论文则更胜一筹，先有开源工具，再顺便写了篇论文，还被 CCS 2022 录用！这就是今天我们为大家推荐的论文——LibAFL: A Framework to Build Modular and Reusable Fuzzers

Fuzzing 研究百花齐放，工具层出不穷，很多都基于 AFL/AFL++ 进行二次开发，互相之间却又不兼容，让引入新特性和验证工作效果非常麻烦，本文作者身为 AFL++ 社区的主要维护者，对目前 fuzzer 界分裂的现状深感不满，认为这不仅是工程问题，更反映了目前对 fuzzer 的实体（entity）缺乏一个标准的定义，于是他提出了如下 9 个实体来定义 modern fuzzer 的组成：

• Input：程序的输入。重点是其在 fuzzer 内部的表现形式，最常见的就是 byte array，不过其不适用于一些特殊场景，比如 grammar fuzzer 会将输入存储为 AST 等结构，在发送给目标程序前才会序列化为字节序列。

• Corpus：输入和其附属元数据的存储。若位于内存中会导致较大的资源消耗，若位于磁盘则方便用户观察 fuzzer 的状态，代价是速度受到磁盘读写的瓶颈制约，主流 fuzzer 大多选择后者。此外，存储时还要区分有助于进化的 interesting testcase 和最终触发 crash 的 solution。

• Scheduler：从 corpus 中选取 testcase 的调度策略。最朴素的即先进先出或随机选择，近年来也有工作利用调度来给 testcase 排优先级或是防止 testcase 爆炸。

• Stage：定义对单个 testcase 进行的操作（action）。在 scheduler 选择了一个 testcase 后，fuzzer 会在其上进行分阶段的操作，比如 AFL 中的 random havoc stage 会对输入进行多种变异操作，许多 fuzzer 都有 minimization phase 以在保持覆盖率的同时减小 testcase，这也是一种 stage。

• Observer：提供一次执行目标程序的信息。从对 fuzzer state 的影响看，observer 的快照应当和执行本身应当是等效的，这样在分布式 fuzzer 或是执行很慢的目标程序上会比较有帮助。覆盖导向型 fuzzer 中常用的 coverage map 就是一种 observer。

• Executor：用 fuzzer 的输入来执行目标程序。不同 fuzzer 在这方面区别可能很大，libFuzzer 这种 in-memory fuzzer 只需调用 harness 函数，Nyx 这种 hypervisor-based fuzzer 则每次执行都要从快照重启整个系统。

• Feedback：将程序执行的结果分类以决定是否将其加入 corpus。大多数情况下 Feedback 和 observer 紧密相连但又有所不同，feedback 通常处理一个或多个 observer 报告的信息来判断 execution 是否 “interesting”，是否是满足条件的 solution，比如可观测的 crash。

• Mutator：从一个或多个输入生成新的 testcase。这部分通常是定制 fuzzer 时最常改动的，不同 mutator 可以组合，往往还和特定的输入类型绑定，比如传统 fuzzer 中常见的是比特级别的变异，比如 bit flip 和 blocks swapping，而 grammar fuzzer 中的 mutator 则可交换 AST 上的节点来进行变异。

• Generator：凭空产生新的输入。有随机生成的，也有 Nautilus 这种基于语法的。

基于上面这许多抽象的定义，作者用 Rust 实现了 LibAFL，有三个主要组成部分：核心组件 LibAFL Core, 在目标程序中运行的 LibAFL Targets，提供编译 wrapper 的 LibAFL CC，除此之外还包含了几个插桩后端（Instrumentation Backends），下图描绘了 LibAFL Core 的架构：

从图中可以看到 LibAFL 的组成部分，除了 State, Fuzzer 和 Events Manager 这三个大模块之外，大部分都一一对应前文所定义的 9 大实体。总之，模块化的设计让 LibAFL 天生具有极强的 Extensibility，基于 Rust 实现，独立于平台和不依赖标准库带来了 Portability，Event Manager 使得多节点并行 fuzz 的 Scalability 成为可能，这便是 LibAFL 设计之初所遵循的三个原则。

实验部分主要是用 LibAFL 实现了各种 fuzzing 技术并评估其在解决不同问题上的效果，这里就不一一展示了，看完只觉得略有些恐怖，LibAFL 就像手术刀一样把所有 fuzz 技术都剖析得清清楚楚，有没有可能，之后所有的 fuzz 工作都需要用 LibAFL 实现一下才能服众？

“日月神教，战无不胜，东方教主，文成武德，千秋万载，一统江湖”

——《笑傲江湖》

在文末作者还介绍了目前的缺陷主要是缺少链接时优化（Link Time Optimization） passes，不能分析整个程序的控制流图，无法实现 directed fuzzing，不过这一特性的支持只是时间问题。未来可以着重关注并实现的强大功能是 concolic tracing API，可以解决传统 concolic fuzzer 中 concolic engine 和 fuzzer 难以协作和伸缩性差的问题。

简要介绍完了论文，我们再来关注一下项目本身一些有趣的点：首先，作者选择用 Rust 实现 LibAFL，并在文中特意强调了零开销抽象带来的好处，无独有偶，在结束不久的的第二届中国 Rust 开发者大会上，陈鹏老师展示了如何用 Rust 从零实现 fuzzer，他发表在 IEEE S&P 2018 的 Angora: Efficient Fuzzing by Principled Search 就是「第一个用 Rust 实现的开源 fuzzer」，详情可见 SHU 开源社区的这篇推文，我们非常期待 Rust 在安全研究中能得到广泛应用。

和其他论文放出的开源代码往往只有作者自己维护的情况不同， LibAFL 从一开始就是 AFL++ 社区的开源项目，如果你感兴趣，就有机会直接贡献代码。本文第三作者Dongjia Zhang（大家可以围观一下作者的邮箱）就在 Google Summer of Code 2021 中为 LibAFL 实现了 AFLFast 和 MOpt 这两种 scheduler，目前已是项目的主要维护者之一，而今年的 Google Summer of Code 则有另一位学生将 Nyx 引入 LibAFL，这可能说明了参与开源和进行研究也是相辅相成的，总有人在论文发到飞起的同时还能让 GitHub 绿点满满，让人不得不佩服。

论文地址：https://www.s3.eurecom.fr/docs/ccs22_fioraldi.pdf

项目地址：https://github.com/AFLplusplus/LibAFL

Artifacts 地址：https://github.com/AFLplusplus/libafl_paper_artifacts

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-08-24 LibAFL