GreenHouse论文笔记

论文概述

论文题目：Greenhouse: Single-Service Rehosting of Linux-Based Firmware Binaries in User-Space Emulation
又看到了Yan大佬，太牛了QWQ

感觉是个idea很好的paper，将之前一直局限于系统模拟fuzz的范围扩展到了用户模拟，不仅模拟难度会降低，而且开销以及fuzz难度都会降低。

作者收集了7140（数据集没有开源）个固件镜像（来自9个厂商，难以系统模拟起来的），成功模拟2841个固件镜像。通过用户级模拟的方式，可以绕过之前系统模拟的很多挑战，实现用户空间进程级模拟。成功检测到717个Nday漏洞以及26个0day漏洞。

解决问题

现阶段的rehosting方法基本上都依赖于外设无关的全系统模拟，将固件重新打包为标准文件系统格式，然后替换嵌入式内核为定制的rehosting内核，然后使用QEMU启动。
Firmadyne的模拟成功率仅有21%（能访问ip）；FirmAE的模拟成功率有79%，但是几乎半数的目标功能有问题。
作者提出了一个新的思路，其依据为NVD中的数据中过去的IoT漏洞中仅有14%是硬件相关漏洞。因此无需去追求高标准的模拟。因此，作者提出单服务的模拟方法。
作者使用RouterSploit工具来进行N-day漏洞的验证，并使用AFL++工具来实现用户空间的模糊测试。实现了对当前主流工具EQUAFL的200%的性能提升。
针对服务是否模拟成功的判断逻辑进行修正或者进一步检查。分为了模拟失败、部分模拟、完全模拟。

论文贡献

提出了用户空间单服务模拟的方法。
研究了该模拟过程并给出了模拟过程中可能存在的挑战
进行了大规模的评估，2841/7140

论文内容

Rehosting

将模拟的完整程度分为两个部分：

Extraction Fidelity：需要提取固件中的文件以及数据。
Execution Fidelity：是否存在外设接口。是否能够登入web管理页面。提到了两个已有工作的分类方法：
完全模拟，原内核模拟，通用内核模拟，用户模拟，无模拟【Automated Dynamic Firmware Analysis at Scale: A Case Study on Embedded Web Interfaces】
无模拟测试，部分模拟，完全模拟，硬件参与模拟【JetSet】
作者基于以上标准对以往工作进行了总结整理如下：

单服务模拟

作者对于单服务的定义：一个固件中会同时运行多个进程，进程之间会进行信息的交换从而完成整体的功能。我们可以根据数据的关联来建立进程之间的联系，并且定义单服务为一个进程的集合，该集合不会与集合外的进程进行交互通信。最终该服务的结构应该是一个树状结构，根节点为主要进程，其运行会依赖于其他的进程的正常运行。

GreenHouse

概览

包括三个组成部分Runner，Checker，Fixer（还有Extractor，Crawler，不过不重要）：

迭代化模拟（不断循环跟进，即Runn->Check->Fix->Run…）

Runner

通过QEMU-user在docker镜像内执行web server。
使用docker镜像保证迭代过程不会污染文件系统等内容；使用chroot确保路径正确。
Runner支持两个tracinig mode：

部分tracing模式：收集父进程以及所有子进程的系统调用链；
完全tracing模式：收集父进程以及所有子进程的系统调用以及指令内容（所有执行基本块的地址）
Runner启动了web server，等待60s后启动Checker来检查是否成功启动服务。如果没有，Runner则解析其跟踪的日志信息，检查是否存在wait loop，每隔10s调用Checker检查一遍。最终将log信息发送给Fixer。

Checker

检测模拟状态并将结果发送给Fixer，用于决定修复方法
Checker接受品牌名以及可能初始化端口。检测3种服务（HTTP，UPnP，DNS）

Fixer

基于traces和log信息来进行修复。

Exporter

导出docker tar包

模拟评判标准

已有标准：执行trace符合预期；检测到网络功能；无crash
Stage 1: Unpack
提取完整文件系统，查看是否存在/bin/busybox以及/bin/sh
Stage 2: Execute
通过常见文件名匹配识别相关二进制程序。
Stage 3: Connect
与模拟的固件服务进行交互连接。需要目标服务执行其环境变量检查并且bind端口，开启socket通信。
Stage 4: Interact
尽可能提升Execution Fidelity。例如，移除CGI handlers中的CAPTCHA检验。例如通过检查HTTP返回码来检验模拟的Execution Fidelity。

挑战以及解决方案

提出了8个挑战以及对应的“尽力而为”的解决方案

挑战

Miss Paths（R1）

损坏的符号链接，缺少文件、文件夹，缺少库文件。通常，这些文件是在系统初始化启动时产生的。

Runtime Arguments（R2）

一些二进制程序会需要特定的命令行参数

Periphral Access（R3）

服务可能会尝试与硬件接口进行交互，例如访问/dev目录中文件，或者访问特定内存区域(MMIO)

NVRAM Configuration（R4）

存储配置信息

Hard-coded Network Devices（R5）

网络设备可能硬编码了其默认IP地址以及设备名称。如果不存在则可能失败

Multi-Binary Behavior（R6）

初始化时可能还需要启动其他进程通过IPC进行交互获取配置信息。

Environment Checks（R7）

环境检查

Environment Mangling（R8）

破坏环境，有些进程可能会破坏GreenHouse的一些功能，例如可能进行stdout，stderr的重定向，从而导致QEMU-user的日志获取失败。

解决方案

File Setup (I1) - [R1, R3, R7]

使用strace系统调用，通过open,access系统调用来获取缺失的文件。创建空文件。如果发现备份或者位置错误，则将其移动到对应位置。

File Sanitization (I2) - [R3, R7]

外设访问通过/dev/的IO访问来操作，可以提供一个空文件来绕过。可以解决hang的问题。与Costin/FirmAE类似

Boot-up Synchronization (I3) - [R1, R2, R7]

使用FirmAE来进行全系统模拟并提取到其启动数据。即运行时环境，文件以及QEMU日志信息。可以获取到启动产生的文件，命令行参数以及NVRAM的配置信息。

nvram-faker (I4) - [R4]

开源项目。hook了nvram_set等函数，可以获取到所有keys，从而更加全面。并提供了合理的键值对数据集。

Runtime ArgParser (I5) - [R2]

通过品牌以及web server名字来匹配可能的启动参数。

Dummy Network Devices (I6) - [R5]

来自FirmAE。修改QEMU bind syscall来记录bind的地址以及设备名。然后可以配置docker内网卡。

Background Script Plugins (I7) - [R6]

识别依赖进程。

IPv6 Workaround (I8) - [R5]

实现了QEMU-user的IPV6功能

Patching sysinfo() (I9) - [R7]

可能会根据sysinfo信息去关闭服务。

Logging Behavior (I10) - [R8]

修改了QEMU的open, close系统调用，以及trace函数，来保留300-400的文件描述符数值用于log文件。

Patching

可以直接进行patch修改。从而绕过阻塞的代码。文章实现了三种patch策略：过早退出、循环等待、Crash指令
使用angr来构建上下文相关的控制流图。然后可以通过控制流图来识别Premature Exit以及Wait Loop。

过早退出 - [R7, R3]

如果有些检查未满足，则会直接exit。尝试让其跳转到另外一个路径。

循环等待 - [R3, R7]

仅在未检测到网络连接时进行该patch，防止将packet处理逻辑也patch掉

Crash 指令 - [R3]

将会crash的地址进行nop。如果crash地址位于lib库里，则需要通过CFG来patch caller函数
仅在出现segmentation fault时进行。

实验评估

围绕以下四个问题展开：

模拟性能与当前主流系统模拟对比
影响GreenHouse的模拟性能的因素
GreenHouse的模拟程度是否可以满足漏洞挖掘
GreenHouse模拟对于fuzz的性能提升

固件收集

共爬取12943个固件镜像，然后筛除加密以及不完整的，以及不是Linux系统的，不是ARM，MIPS，X86架构的。然后将数据集与FirmAE的数据集（2023年最新版本）合并。最终获取到7140个固件镜像，涉及到1764个设备。是FirmAE（1124）的6.3倍，Costin（1925）的3.7倍。