HouseFuzz：面向 Linux 固件的服务感知灰盒模糊测试

最新推荐文章于 2026-06-23 21:23:37 发布

原创最新推荐文章于 2026-06-23 21:23:37 发布 · 643 阅读

8 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#linux #运维 #服务器 #安全 #深度学习

漏洞检测同时被 2 个专栏收录

33 篇文章

订阅专栏

动态检测

12 篇文章

订阅专栏

“随着物联网设备的急速普及，Linux驱动的固件广泛部署在路由器、NAS、摄像头等终端中，但这些网络服务中存在的大量漏洞仍是严重的安全隐患。传统固件模糊测试工具在服务识别、模糊反馈收集、语义有效的输入生成三方面存在先天短板，导致探索空间受限与漏报大量漏洞。HOUSEFUZZ是一个“服务感知”的灰盒模糊测试系统，专门针对 Linux-based 固件的多进程服务与定制协议场景进行改进。 ”

📄 论文标题：HouseFuzz: Service-Aware Grey-Box Fuzzing for Vulnerability Detection in Linux-Based Firmware

📅 发表时间： IEEE Symposium on Security and Privacy (SP),2025

🏫 作者单位：复旦大学

⚙️ 开源代码： https://github.com/seclab-fudan/HouseFuzz

01 —

方法介绍

HouseFuzz 的工作聚焦于“固件模糊测试为何长期效果有限”这一核心问题，通过引入服务感知、多进程覆盖收集与协议语义推断，为长期停滞的固件fuzzing 研究提供了新的突破口。下面是对论文核心元信息的快速概览：

🐾 Holistic Service Identification：遍历系统初始化，定位 network-facing、daemon 与 utility 等相关进程，实现更完整的服务模拟和启动命令恢复。
🔀 Multi-Process Fuzzing Framework：基于多进程的覆盖（coverage）汇总与多进程漏洞判定oracle，弥补单进程模糊测试收集视角狭窄的缺陷。
🧩 Service-Protocol Guided Fuzzing（TDG）：引入Token Dependency Graph（TDG）来建模固件定制协议的 token 级语义约束，结合 grammar（CFG）与 TDG 生成语义有效的变异用例。

图 1. 示例漏洞

图 1 展示了 Linux 固件中的一个缓冲区溢出漏洞，触发流程包括四步：

服务初始化：系统启动时自动运行的 ncc 进程启动 mini_httpd，并绑定网络端口等待请求（L24-L26）。
请求发送：攻击者发送恶意数据包以触发mini_httpd（L27-L28）。
请求处理：mini_httpd 的 handle_request() 解析 HTTP 请求，在 L34确认以“.ccp”结尾后，将其通过套接字转发给ncc（L35-L36）。
漏洞触发：ncc 在 L3 收到 IPC 请求后调用 ipc_handler()（L6）。在进行若干检查（L8, L13-L17）后执行到 L19 的漏洞代码，因对输入字符串未做长度校验，导致格式化到 buf 时发生缓冲区溢出。

图 2.方法框架图

小结：HOUSEFUZZ 工作流：系统初始化遍历 → 服务识别 → 多进程模糊测试（覆盖聚合 + 多进程 oracle）→ 在线/离线 TDG 推断 → 协议感知用例生成。

02 —

关键机制

为了实现对固件服务的全面感知与高质量输入生成，HOUSEFUZZ 将系统能力拆解为一系列相互协作的核心模块。从初始化补丁、服务识别，到多进程覆盖收集与协议语义推断，每个模块都围绕“提高仿真保真度、扩大探索空间、生成更有效的测试用例”这三大目标设计。

模块	实现要点	主要作用
初始化（INIT）仿真与异常补丁	基于 QEMU 跟踪系统调用／基本块，定位中断/挂起点并打补丁以推进初始化流程	发现更多在初始化阶段启动但会被传统方法遗漏的服务进程。
网络/守护进程识别	通过 bind/execve 等系统调用参数提取网络通道与命令行，动态回溯 IPC keys 判断守护进程	恢复真实启动参数并确定进程间依赖关系，保证仿真保真性。
多进程覆盖采集（Multi-process Coverage）	为每个进程分配独立 coverage bitmap，按 ELF 可执行体合并比特图，TCE（Test Completion Event）判断跨进程完成时机	用全服务进程覆盖引导变异，避免遗漏需进程间协作触发的路径。
TDG（Token Dependency Graph）推断	离线静态（CFG/数据／控制流分析）+ 在线字符串比较插桩（strcmp）结合，构建 Path/Key/Value 三类 token 及其依赖	生成满足语义约束的高质量测试用例，提高命中率。

03 —

实验结果

论文在真实固件数据集上做了大量对比实验（基线：GREENHOUSE / EQUAFL / Firm-AFL 等），关键结论如下：

🔎 服务发现：在 60 个可提取固件镜像上，HOUSEFUZZ 识别到 311 个 network-facing 进程，远超 FirmAE 的 128 与 GREENHOUSE 的 44，Recall 明显更高（HOUSEFUZZ ≈ 80.4%）。
📈 代码覆盖：在 41 个共同可 fuzz 的服务上，HOUSEFUZZ 平均 edge coverage 为 14,767，对比 GREENHOUSE 的 11,072，提升约 24.8%（统计检验 p < 0.01，效应量 Â12 ≥ 0.71）。
💥 漏洞发现：在相同 41 个服务上，HOUSEFUZZ 共定位 128 唯一漏洞（含 110 个 0-day），而 GREENHOUSE 定位 46（40 个 0-day）——即 HOUSEFUZZ 发现了约 175% 更多的 0-day。总体实验共发现数百个漏洞并获得多项 CVE/CNVD。

工具	#Services（测试集）	Avg. Edge Coverage	#Unique Vulnerabilities
GREENHOUSE	41	11,072	46
HOUSEFUZZ	41	14,767	128

小结：优点：全栈式改进（识别→仿真→多进程反馈→协议语义），在真实固件上效果显著，已实际触达大量 0-day 并完成披露。局限：（1）TCE 检测依赖常见等待系统调用（如 select/poll），需要工程扩展以支持其它模型；（2）TDG 离线静态分析与在线插桩都有误报/漏报风险；（3）多进程收集带来显著时间/内存开销。

📌 总结

HOUSEFUZZ 将“服务感知”理念带入固件灰盒模糊测试：通过完整的初始化遍历发现更多服务、用多进程覆盖引导探索、并用 TDG 把握定制协议的语义约束，从而在真实固件上实现了显著的代码覆盖与漏洞发现能力提升。这套设计对于想在制造商固件或嵌入式设备领域落地自动化漏洞挖掘的团队，具有很强的实用价值与工程参考意义。