模糊测试实战课

为什么需要模糊测试

多数内存破坏漏洞——栈溢出、堆溢出、UAF、整数下溢——都藏在解析器、解码器这类处理不可信输入的代码里。单元测试只覆盖合法输入，人工审计在复杂指针运算面前也经常失手。模糊测试用自动化变异加覆盖率反馈，在数小时到数天内找出人类永远不会手动构造的边缘输入组合。

但真正的门槛不在理论：你要为目标写 harness、准备种子语料、配置 sanitizer、解读 ASAN 报告、对崩溃去重，还得忍受跑了很久却毫无发现的沉寂期。这门课程把这些环节拆成一套可执行的 checklist。

技能的核心工作流

• 环境与目标选择：在 Ubuntu 24.04 VM 上装好编译器与调试器，优先选输入驱动输出、无网络依赖的解析器——图像/媒体解码器是典型：字节进、图像出、执行确定。
• 种子语料与字典：语料质量优于数量。用合法 MP4/WebP 文件起步，配合格式感知字典加速到达深层代码路径。
• 覆盖率引导模糊测试：以 AFL++ 为变异引擎，编译期插桩，让 ASAN/UBSAN 把内存破坏立即变成可复现崩溃；并行 fuzzing 让吞吐接近线性扩展。
• 崩溃分诊与去重：按唯一栈签名区分真实 bug 与重复崩溃，再判断可利用性。
• 进程内 fuzzing：用 Google FuzzTest 把现有单元测试改写成 FUZZ_TEST，同一二进制在 CI 里既能跑确定性测试，也能做长时间 fuzz campaign。

课程用 CVE-2024-47606（GStreamer）与 CVE-2023-4863（libWebP）做案例：前者靠持续 fuzzing 撞出有符号整数下溢，后者正是图像解码器模糊测试的典型战果。

适用边界与注意点

• 需要 C/C++、GDB 基础和 Week 1 的内存破坏漏洞知识，8GB RAM、8 核起步。
• Fuzzing 前期投入很重：搭 harness、连跑数天没有崩溃是正常的，真 bug 往往在数小时之后才浮出水面。
• 它擅长解析器类漏洞，对逻辑缺陷、依赖外部状态的漏洞不敏感。
• Fuzzing 产出的是崩溃线索而非漏洞结论：可利用性判断、补丁分析仍需人工完成。
• 8 核机器大约等于 8 倍吞吐，但先把种子语料做精，比单纯堆并行更划算。