中文译名：IFIZZ: 深度状态和高效的故障场景生成来测试物联网固件
作者：刘peiyu
单位：浙江大学
国家： #中国
年份： #2021年
来源： #IEEE_ASE_CCFB 关键字： #fuzzing #故障注入
代码地址：decentL/iFIZZ-ASE21 (github.com)
笔记建立时间： 2023-07-06 10:39
#TODO

摘要

  • 现有模糊测试不能有效的测试物联网设备的错误处理代码
    • 错误处理代码难触发
    • 难以深入错误处理代码路径（因为一触发错误处理代码程序就嘎了）
  • IFIZZ，一个专门设计用于测试基于linux的物联网固件中的错误处理代码的新的错误检测系统。
    • 首先采用基于二进制的自动化方法，通过分析闭源物联网固件中的错误和错误条件来识别实际的运行时错误
    • 然后采用状态感知和有界错误生成来有效地到达深度错误路径

背景

物联网设备中的错误

  • 输入相关错误：由无效输入引起，相对较少
  • 输入无关错误：偶尔的运行时事件（如内存耗尽、硬件故障、网络不可达）引起的输入无关错误更为常见

故障注入用于测试物联网固件的错误处理代码的挑战

  • 如何自动识别与输入无关的错误（基于二进制的自动化识别方法解决）
  • 测试如何深入错误路径（状态感知和有界错误生成解决）

方法

image.png

预定义

image.png

基于二进制文件的自动运行时错误识别

作者在分析了20个EF后，得到EF的两个特征

  • 返回值是error code
  • 与输入无关 基于此作者设计了EF识别算法。
  • 首先扫描汇编代码收集二进制程序中所有函数的的所有返回值（getreturnvalues ()）和caller（getcallers ()）
  • 然后算法检查函数f的caller是否对函数f的返回值进行了check（ischecked ()），如果ischecked则说明该返回值是error code
  • 对得到的error code在函数f中向后搜索找到error code如何生成（也就是检查条件 getcondition ()）
  • 对得到的code condition执行向后的过程间数据流分析，收集codecondition依赖的source，检查这个source是否是程序参数（也就是是否和输入相关），如果不是，则该error code是我们要的。 image.png

状态感知和有界故障场景生成

（这个方法是为了覆盖尽可能多的错误路径、在有限的时间内到达深度错误路径）
作者指出在故障注入的时候会产生两个问题：

  • early crashes：一个RT中有很多error site，触发一个就会导致程序崩溃，如果在RT早期程序就崩溃了，那么后面的error site就覆盖不到了——状态感知解决
  • 遍历生成FS会产生相当多的数量（爆炸）——有界故障生成解决 image.png

状态感知

作者通过将每次的崩溃的error site和site state记录为日志，当在运行时碰到error site时，如果此时的site和state已经记录在日志中，那么就不对这个error site进行故障注入（如line 9）。这样可以避免冗余崩溃，并且深入后续的error site。

有界故障生成

首先，大多数崩溃都是由少量错误引起的，生成具有大量错误的故障场景通常是不必要的。因此，我们提出第一条规则: 故障场景中的最大错误数 (ME)应该是有界的 (算法2中的第2行)。其次，我们还观察到大多数崩溃是由相邻错误引起的。因此，我们提出第二条规则: 在故障场景中，第一个错误和最后一个错误 (MBE)之间的最大距离 (即错误站点的数量)也应该是有界的 (算法2中的第4行)。

实现

image.png

  • error-function analyser：FIRMADYNE对固件解包，IDA脚本分析二进制程序
  • Firmware packer：设置被测对象，使其可以用于测试
  • Fault-scenario generator：编写了一个库函数利用劫持函数来记录崩溃日志和故障注入
  • Runtime monitor：运行测试固件并跟踪运行时进程信息，以获得目标物联网程序及其相应的运行命令（无需源代码）
  • Bug checker：分析崩溃日志以生成崩溃报告，一个IDA脚本

存在的问题和我的疑问

  • 在error function识别的时候存在无法处理间接调用和数据流爆炸的问题
    • 作者指出“一旦数据流证明一个源与输入无关，分析就完成了，而不是不断地分析其他源”，但是实际上这种逻辑并不sound，必须证明所有的源都和输入无关才可以保证该error function是输入无关的 貌似只找到一个源头与输入无关便可，如果非要考虑所有源头，且不说数据流分析爆炸，最后估计一大批function被筛掉，剩下的error function没几个了。但是即便如此，最好的方法还是不断搜索源头，直到找到一个和输入无关，那么最坏情况是O(n)。比较稳妥的操作应该是设置一个阈值。
  • 其实我一直不太清楚（包括在上下文敏感sfi那篇论文中）这个error site sequence（这篇文章称之为runtime trace）中的error site彼此是独立的还是互相有调用顺序的
  • Fault-scenario generator、Runtime monitor如何实现的，要知道本文不需要程序源码
  • “在测试固件映像之前，IFIZZ首先对被测试固件进行动态分析以获得目标程序。总的来说，IFIZZ获得112个供应商特定的程序和509个运行命令来运行这些程序”这是如何实现的
  • 对生成RT的变异策略进行研究!!!