1. Basic Information

Conference: NDSS’18
Author: Marius Muench, Jan Stijohann, Frank Kargl
Affiliation: EURECOM

2. Introduction

本文证实了嵌入式设备上的内存破坏 (Memory Corruptions) 所产生的行为通常是静默的，大大降低了传统动态测试技术的有效性，尤其是模糊测试。

为此，作者分析了几类嵌入式设备中内存破坏所带来的影响的差异，同时，展示了它们对固件分析的影响。并且介绍了一些相对简单的启发式方法，它们可以在分析嵌入式设备期间检测以前无法检测的内存破坏问题。

3. Problem

嵌入式设备上的内存破坏所触发的异常行为不明显，传统动态分析工具难以使用。

4. Design

4.1 Classes of Embedded Devices

• Type-I: General purpose OS-based devices
• Type-II: Embedded OS-based devices (Custom)
  • uClinux，ZephyrOS or VxWorks
• Type-III: Devices without an OS-Abstraction (Monolithic Firmware)
  • Based on Contiki, TinyOS or mbed OS

4.2 Main Challenges of Fuzzing Embedded Devices

• Fault Detection：
  • 嵌入式设备中缺少触发崩溃和异常的机制，使得动态测试难以根据崩溃和异常信息寻找到BUG，即使提供触发崩溃的机制对于崩溃的检测也异常复杂。通常使用以下两种动态检测（探测）方法：
    • Active probing：将特殊请求插入到与设备或其环境的通信中，会影响被测试软件的状态
    • Passive probing：不改变设备状态的情况下获取设备状态信息，观察设备对输入的响应和可见崩溃
• Performance and Scalability：
  • 并行测试技术很难应用到嵌入式测试中
  • 每个测试用例中的设备重启（状态还原）比较耗时
• Instrumentation：已有的动态插桩技术难以应用到：
  • 单用途设备（下图Type-II）
  • 没有操作系统抽象的设备（下图Type-III）

4.3 Experiment Survey

为了研究内存损坏在不同系统中的行为，在不同的系统上触发相同的内存损坏条件，以分析它们会导致可见崩溃，还是导致静默的损坏，结果如下：

注：

• mbed TLS->为嵌入式和桌面系统设计的SSL库
• expat->流行的XML解析器
• √->可观察的内存错误
• ×->没有明显的行为
• malfunc.->继续运行，但返回的数据都是错误的
  结果表明：
• 嵌入式平台提供的功能越少，检测到内存损坏的可能性就越小。对于基于堆的缓冲区溢出和双释放问题，嵌入式Linux（Type I）会继续运行，并在稍后的时间点崩溃
• Type-II和Type-III设备的输入错误很少会触发崩溃，进一步说明在嵌入式系统中，静默内存损坏是及其常见的

4.4 Six different options to mitigation

• Static Instrumentation
  • 需要源码，编译工具连
  • 传统的插桩工具难以应用的嵌入式中
• Binary Rewriting
  • 需要固件镜像，设备
  • 固件反汇编复杂，内存语句，内存边界以及相应的数据结构会在编译中丢失
  • 嵌入式设备内存空间小，留下很少的空间用于插桩
• Physical Re-Hosting
  • 需要源码，编译工具链，不同设备
  • 将源码重新编译成其他类型的设备固件，例如Type-II编译成Type-I
  • 编译器不同，可能导致原类型中的漏洞可能不会被在新类型中触发
• Full Emulation
  • 需要固件镜像，设备仿真器
  • 要求所需的架构以及设备可以被仿真
• Partial Emulation
  • 需要固件镜像，设备
  • 性能以及可扩展性较差
• Hardware-Supported Instrumentation
  • 需要设备以及一些高级的调试特征

4.5 Fault Detection Heuristics

本文实现一组启发式方法，来模拟现有的编译时和运行时技术，借助它们检测固件中的内存崩溃。

• Segment Tracking：
  • 观察所有内存读写，并验证它们是否发生在有效的位置，从而在某种程度上模仿MMU来检测段错误（非法内存访问），
  • 需要trace信息和逆向操作
• Format Specifier Tracking：
  • 验证格式字符串描述在printf()族函数中输入时是否指向一个有效的位置（如果没有动态生成的格式字符串说明符，那么这些有效的位置必须位于只读段中）
  • 不仅需要了解格式处理函数的位置，还需要了解输入其中一个函数和参数顺序时的寄存器状态。通过逆向工程或固件的自动静态分析，可以获得相应函数的位置及其参数顺序。
• Heap Object Tracking：
  • 通过计算分配和回收函数的参数和返回值，并记录堆对象的位置和大小来检测与堆相关的时间和空间错误
  • 依赖于各种信息：已执行的指令、寄存器的状态、内存访问，以及有关分配和释放函数的知识
• Call Stack Tracking：
  • 通过监听所有直接和间接函数调用和返回指令，来识别基于堆栈的内存损坏（覆盖函数返回地址）
  • 嵌入式设备通常是中断驱动的，所以可能导致漏报
• Call Frame Tracking：
  • 调用堆栈跟踪技术的一个更高级的版本，通过跟踪函数调用来定位，然后检查连续内存访问是否交叉堆栈帧，用于检测基于堆栈的粗粒度的缓冲区溢出，不存在漏报
  • 需要识别执行的指令以及寄存器值，以便在函数项上提取堆栈指针值。然后，必须观察内存访问以检测实际的损坏。
• Stack Object Tracking：
  • 可以完成对栈变量越界访问的细粒度检测，使用在调试符号中出现的变量信息（大小和位置），观察在执行过程中的内存读写

注：

• 活性（liveness）检查：在每次模糊测试输入之后，模糊测试器都会收到设备的响应，并评估它是否与预期的行为匹配。当接收到的响应与预期的不同，或者连接超时时，模糊器会报告崩溃并重启目标

4.6 Implementation

使用PANDA替换Avatar的后端仿真器S2E，使用PANDA来模拟固件，并依赖它的插件系统（实现启发式算法）来获得部分或完全模拟固件执行时的实时反馈，并借助Avatar在设备初始化后保存并重放设备状态（在初始化完成后保存设备状态的快照，并重用它来初始化模拟器）。

模糊器使用Boofuzz，它不仅生成和发送变异输入，而且还允许定义目标监视和重置钩子，允许模糊用户定义的通信通道，并为串行和TCP连接提供现成的实现。

5. Evalution

5.1 Fault Detection

注：

• NAT: Native（在实际设备上执行，不使用任何错误检测）
• PE/MF: Partial Emulation with Memory Forwarding，使用PANDA仿真固件+借助I/O转发与物理设备交互
• PE/PM: Partial Emulation with Peripheral Modeling，使用PANDA仿真固件+使用Avatar仿真设备交互行为
• FE: Full Emulation，固件和设备均使用PANDA
• PC：对模糊器插桩，强制以指定概率触发漏洞
  由上图可见，组合启发式（每组中最右边的条）总是成功地检测到所有的损坏，而依赖于活动检查（最左边的条）总是留下大量未检测到的错误

5.2 Performance

由上图可知，在性能方面，

• 使用内存转发的部分仿真（PE/MF）会引入较大的开销。它将模糊测试的速度降低了一个以上的数量级。这种开销是由固件和设备外设之间的通信引入的，这会导致频繁调用Avatar的编排特性
• 使用纯软件仿真，具由最接近于原始物理设备的速度

6. Conclusion or Limitations

本文讨论的解决方案没有在现实场景下进行测试，可能不适用于所有的场景和所有的嵌入式系统设备。

7. Related Work

8. Comments

本文对嵌入式系统和桌面系统中出现内存破坏时的行为进行对比，观察到嵌入式系统对内存异常问题的处理通常是静默的，难以直接使用模糊测试工具。因此，作者提出解决这类问题的启发式方法，综合利用Avatar、PANDA、Bootfuzz等工具的优势完成实验设计和评估。

注：解读如有错误或不当之处，麻烦在评论区批评指正。