Registered Report: NSFuzz: Towards Efficient and State-Aware Network Service Fuzzing

相关链接

论文链接

答辩视频

概述

在本文中作者提出

1. 一种基于程序变量来表示服务器状态的方案
2. 一种高效的基于交互的同步机制

---

背景

​ 在进行漏洞挖掘中，模糊测试已经成为了一种主流的漏洞挖掘工具。然而传统的fuzzer都是无状态的，这对于存在状态转换的网络协议模糊测试并不友好，同时，与传统的一些程序相比，网络传输时往往更容易被攻击。在基于状态的协议模糊测试提出之前，针对网络的模糊测试往往采用黑盒的方式，这导致产生的测试用例往往比较随意，并不能到达更深的代码覆盖。随着AFLNET的提出，基于状态的灰盒模糊测试开始越来越普遍的应用到协议模糊测试中。现有的较为优秀的基于状态的灰盒模糊测试包括AFLNET和STATEAFL，AFLNET假定协议在响应信息中存在特定的代码来表示状态，但并非所有协议都满足这一假设，同时仅仅使用响应码来表示状态也会导致对协议的评估并不准确；STATEAFL使用内存状态来表示服务状态，然而在进行状态收集和状态模型推理时需要将程序变量转储到一个分析队列中并对执行后结果进行分析才能实现对状态模型的更新，这也带来了额外的开销。

如上图所示为Bftpd协议，作者提到，网络服务往往会使用一些特定的变量来直接表示协议的状态，因此可以直接使用这样的变量来表示服务器状态。同时，如图中黄色边框所示代码，网络服务往往存在大量的I/O交互，而这部分功能往往由一个代码循环（event loop）来实现，因此，作者提出通过I/O同步机制来给fuzzer一个及时的反馈。基于此，作者提出了两个改进：

• 基于程序变量来表示服务器状态
• 引入I/O同步机制

网络服务包括三个阶段：

• 服务初始化阶段，此阶段网络服务进行初始化操作以及socket端口的创建和网络端口的绑定，进行socket监听直到客户端发起连接请求
• 服务处理阶段，在这一阶段中网络服务工作在一个event loop下，执行客户端发出请求和服务器给出反馈这样一个循环中。直到客户申请断开连接或发生异常。
• 服务清理阶段，在这一阶段服务器清除并释放资源，停止提供服务

协议模糊测试主要集中在第二阶段服务处理阶段。

---

框架设计

​ 为如上图所示为NSFUZZ的整体框架，首先NSFUZZ进行静态分析获取状态变量列表和网络循环事件（用于确定I/O 同步点），执行编译时插装插入相应的信号来支持快速的I/O同步和基于变量的服务器状态跟踪。

静态分析

通过上图的框架结构可知，NSFUZZ使用静态分析来确定Event loop和状态变量列表，并在静态分析时进行插装，其过程如下。

Event loop 识别

在进行静态分析时，主要确定两项内容：event loop 识别和状态变量提取。

在进行event loop识别时，识别事件循环的主要挑战是将其与网络服务程序中的其他循环区分开来，因为在实现中有太多不同的循环。一个典型的例子是在服务初始化阶段。许多服务可能使用文件 I/O 循环来读取配置。此外，事件循环本身也可能包含嵌套循环，这也给静态分析准确识别网络事件循环带来了困难。因此，我们在服务处理阶段跟踪网络 I/O 操作，并通过回溯来区分外部循环，以解决这些问题。

首先，当网络服务完成初始化并进入服务处理阶段时，在与输入相关的系统调用(如 read、 recv、 recvmsg 等)上设置断点。然后 Fuzzer 建立到 SUT (service under test)的套接字连接并发送探测消息。当命中断点时，SUT 保存函数调用堆栈的回溯跟踪。最后，我们将回溯作为静态分析器的辅助输入，以识别网络事件循环。静态分析器首先将服务中包含 I/O 操作的所有循环记录为候选循环，然后从底部(例如，libc start main)扫描回溯调用堆栈，以匹配包含 I/O 循环的第一个函数(外部函数) ，然后将其视为网络事件循环。这是因为在服务处理阶段，回溯只包含网络事件循环中的调用堆栈，而匹配包含 I/O 循环的外部函数也可以避免嵌套循环。

状态变量提取

​ 状态变量在静态分析时进行提取，在进行状态变量提取时，主要根据以下三个启发式规则来进行状态变量提取：

• 由于网络服务中与状态变量相关的操作必然是在网络事件循环中进行执行，因此对状态变量的提取只在网络事件循环中进行静态分析，以减少分析范围
• 静态分析只需要提取那些具有加载和存储操作的变量
• 静态分析只需要保留全局整数变量或用户定义的在存储操作中分配常数值的结构成员

编译时插装

​ 当获取了Event loop和状态变量列表，NSFuzz将会执行两种类型的插装，首先它会在Event loop的入口点插入raise（SIGSTOP）语句，使得被测试的服务可以在每个请求消息被处理之后向模糊器提供一个raise信号反馈，表示它已经准备好接受下一个消息请求。同时为了实时的将状态变量值反馈给fuzzer引擎，NSFuzz在每个状态变量中插装了一个STORE操作，使用被写入的状态变量的值作为key来更新与状态相关的内存共享。其映射方法如下：

首先NSFuzz将每个状态变量的ID值进行hash，接下来将该hash值和写入的当前状态值进行亦或操作（XOR），将XOR后的值作为索引来更新share_state(用于记录状态信息的共享内存)。

Fuzzing Loop

I/O同步

为了提高模糊测试效率，AFL引入了FORKSERVER来进行fork的创建和回收，AFLNET和STATEAFL都是基于AFL来实现的，当执行一个testcase时，他们首先通知 FORK-SERVER 创建一个进程进行模糊处理，然后依次按照手动指定的时间间隔发送每个请求消息，最后等待 FORKSERVER 在服务结束后通过通信管道写入执行结果。而NSFuzz实现了一个NET_FORKSERVER，通过它与反馈信号进行合作从而实现快速I/O同步，从而避免了手动指定的时间等待间隔，如下图所示，每次NSFuzz发送一个请求消息后，NET_FORKSERVER等待raised信号来判断目标是否已经完成了一轮I/O交互或者发生崩溃，并将这些信息发送给fuzzer。

基于状态的模糊测试

​ 当fuzzer接受到来自NET_FORKSERVER的消息处理结果后，它会计算共享状态缓冲区（shared_state)的哈希值，该值可以用于表示SUT的当前状态。因为如果消息导致状态发生改变，则某些状态变量的值必然发生改变，从而导致shared_state缓冲区中的值发生改变，因此fuzzer可以通过共享状态缓冲区的值来记录状态转换序列，以便在每次同步后推断状态转换模型。如下图所示，var1和var2分别表示不同的状态变量，当执行完信息收集后，这些状态变量发生改变导致shared_state发生改变，通过对shared_state缓冲区的值进行hash来记录一个新的状态转换S2。

实验测试

为了测试NSFuzz的性能，作者从以下两个纬度来进行回答：

1. 使用程序变量来表示状态是否会更精确和合理？
2. NSFuzz作为基于状态的模糊测试器，其性能表现如何？

​

​ 带着这两个问题，作者在profuzzbench中选择了以下五个协议，使用当前较为优秀的两个基于状态的fuzzer AFLNET和STATEAFL，以及一个支持网络服务的fuzzer AFLNWE来进行对比。

---

RQ1：

​ NSFuzz在各个协议中找到的状态变量的数量和所用时间如下图所示：

下图为各个fuzzer发现的状态模型中的状态数和边数：

以lightftp为例，TABLE II 显示了NSFuzz找到了一个状态变量Access，在TABLE III中NSFuzz发现了五个状态和12个状态之间的转换，通过手动分析Lightftp的源代码后，发现Access有4个常量来表示客户端用户的不同权限（NOT LOGGED IN,READONLY, CREATENEW, FULL)，同时还包括一个额外的初始化状态，如下图所示：

而从说明NSFuzz可以精确地推测出于状态变量相关的状态和状态转换。另一方面，AFLNET 和 STATEAFL 在相同初始种子的情况下推导出的状态模型在模糊化结束时分别有23个顶点/158条边和11个顶点/47条边。然而，根据我们的手工分析，这些状态模型不能区分客户端用户的不同权限，这可能导致不完整的状态指导。此外，这些模型也难以反映与目标服务的明确关系。因此，在一定程度上，NSFuzz 推断的状态模型比其他工作更加准确和可解释。

RQ2

​ 为了验证NSFuzz的有效性，作者首先评估了各个fuzzer的吞吐量，如下图所示，以AFLNET作为参考，NSFuzz的吞吐量最高能达到50x，尽管AFLNWE也有较高的吞吐量，但是和NSFuzz比较，它的代码分支覆盖却很低（AFLNWE并非基于状态的fuzzer），同时也可以看到NSFuzz的分支覆盖平均性能也优于其他几个fuzzer。

如下图为各个fuzzer的分支覆盖和所用时间，通过对比可以发现NSFuzz能更快的发现更多的边，同时也有更高的边覆盖：

接下来作者还评估了各个fuzzer触发第一个bug所用的时间，如下图所示，可以明显的看到NSFuzz可以更快的触发bug：

相关工作

贡献：

1. 提出了一个基于变量来进行状态表示和使用I/O同步的针对网络服务的fuzzer——NSFuzz
2. 在ProFuzzbench上评估了NSFuzz的性能，证明其使用变量来表示状态模型的精确性和使用I/O同步机制对fuzzer性能的提升的有效性

不足

1. NSFuzz仅支持对C语言编写的协议进行模糊测试
2. 对于使用事件驱动的库来构建服务程序的网络，网络中的Event loop是在库中实现而不是协议代码中，因此使用静态分析来进行插装具有较大的挑战
3. 使用静态分析提取状态变量容易导致结果误报

最后

性

不足

1. NSFuzz仅支持对C语言编写的协议进行模糊测试
2. 对于使用事件驱动的库来构建服务程序的网络，网络中的Event loop是在库中实现而不是协议代码中，因此使用静态分析来进行插装具有较大的挑战
3. 使用静态分析提取状态变量容易导致结果误报

最后

​ 以上为阅读这篇论文的笔记，然而由于本人水平有限，若文中存在一些技术问题说明错误，欢迎评论区留言更正！