💻 computer science

Triggering and Detecting Exploitable Library Vulnerability from the Client by Directed Greybox Fuzzing

本文提出了名为 LiveFuzz 的新方法，利用基于目标元组的定向灰盒模糊测试技术，无需依赖现成的概念验证（PoC）即可从客户端程序检测第三方库漏洞的可利用性，并通过抽象路径映射和基于风险的自适应变异机制显著提升了漏洞触达效率与覆盖率。

原作者： Yukai Zhao, Menghan Wu, Xing Hu, Shaohua Wang, Meng Luo, Xin Xia

发布于 2026-04-07

📖 1 分钟阅读☕ 轻松阅读

原作者： Yukai Zhao, Menghan Wu, Xing Hu, Shaohua Wang, Meng Luo, Xin Xia

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文介绍了一个名为 LiveFuzz 的新工具，它的任务是帮程序员找出软件中那些“潜伏”的安全漏洞。

为了让你更容易理解，我们可以把整个软件世界想象成一个巨大的物流系统。

1. 背景：为什么会有问题？

想象一下，你开了一家快递公司（这就是客户端程序）。为了送快递，你不需要自己造卡车、自己修路，你直接雇佣了专业的第三方物流公司（这就是第三方库，比如处理图片的库、处理视频的库）。

好处：你不用自己造轮子，效率极高。
风险：如果第三方物流公司的某辆卡车（代码）有个刹车失灵（漏洞），你的快递车只要用了这辆卡车，你的整个公司就可能面临危险。

以前，安全专家想检查这些漏洞，通常需要一张“藏宝图”（PoC，概念验证代码），告诉他们：“嘿，只要把卡车开到那个特定的路口，刹车就会失灵。”
但是，很多时候这张“藏宝图”根本不存在，或者还没被画出来。这就让很多公司不敢轻易更新第三方库，因为怕更新后自己的系统会崩溃，结果就是带着隐患继续运行。

2. LiveFuzz 是怎么工作的？

LiveFuzz 就像是一个超级聪明的“寻宝侦探”。它的目标是在没有“藏宝图”的情况下，主动驾驶你的快递车，去尝试撞开那个失灵的刹车。

它主要用了三个“独门秘籍”：

秘籍一：双目标导航（Target Tuple）

传统方法：以前的侦探只盯着“最终目的地”（漏洞发生的地方）。这就像只盯着终点线，却不管前面的路有多复杂。
LiveFuzz 的做法：它把任务分成了两步。
1. 第一步：先找到你公司内部的“调度员”（客户端函数），看他们有没有把任务派出去。
2. 第二步：再找到第三方物流的“仓库管理员”（库函数），看他们有没有收到任务。
- 比喻：就像侦探不仅盯着“仓库大门”（漏洞点），还盯着“调度室”（调用点）。只有当调度室把车派出去，且车真的开到了仓库，才算有效。这样它就能更精准地规划路线，不会在死胡同里浪费时间。

秘籍二：抽象路径映射（Abstract Path Mapping）—— 拒绝“走捷径”

传统方法的缺陷：以前的侦探有个坏习惯，喜欢选“路程短”的路线。比如，去仓库有两条路：
- 路 A：很短，但只能走到半路。
- 路 B：很长，但能直达仓库。
- 以前的工具会觉得路 A 更“近”，于是拼命测试路 A，结果永远到不了仓库。
LiveFuzz 的做法：它发明了一种“相对进度表”。它不看绝对距离，而是看你完成了整个旅程的百分之多少。
- 比喻：就像跑步比赛。以前只比谁离终点线近（不管你是不是在跑错方向）。LiveFuzz 则看谁跑完了总赛程的 80%。即使路 B 很长，只要它跑完了 80%，侦探就会觉得：“这条路线很有希望！”从而优先测试它。这解决了“路虽长，但能到”的问题。

秘籍三：风险自适应变异（Risk-Based Adaptive Mutation）—— 该粗则粗，该细则细

传统方法的缺陷：以前的侦探在修改输入数据（比如修改快递单上的地址）时，要么“大刀阔斧”（把整段地址都改了），要么“小心翼翼”（只改一个字母）。他们通常随机选择，不管当前走到哪一步。
- 如果车刚出发，大刀阔斧地改地址可能直接让车开进沟里（数据校验失败）。
- 如果车快到了，只改一个字母可能太慢，无法触发刹车失灵。
LiveFuzz 的做法：它会根据车子当前的“风险等级”来调整策略。
- 刚出发时：用“大刀阔斧”的改法，快速探索各种可能性，看看能不能把车开进正确的车道。
- 快接近仓库时：用“精细微调”的改法，专门针对那个刹车失灵的条件（比如把速度从 49 改成 50）进行微调。
- 比喻：就像钓鱼。刚开始撒网要广（粗粒度），鱼快上钩了，就要轻轻提竿（细粒度），不能把鱼吓跑。

3. 效果怎么样？

研究人员找来了 61 个真实的“事故案例”（包含 42 个不同的漏洞），让 LiveFuzz 和其他几个老牌侦探（工具）进行比赛。

结果：
- 找路更多：LiveFuzz 比对手多找到了 37% 到 195% 不等的有效路线。
- 速度更快：触发漏洞的速度平均快了 5 到 7 倍。
- 独家发现：有 3 个 极其隐蔽的漏洞，只有 LiveFuzz 找到了，其他工具完全没反应。

总结

简单来说，LiveFuzz 就是一个不需要“作弊地图”（PoC）就能自动寻找软件漏洞的超级工具。

它通过把长距离的探索任务拆解成两步、用相对进度代替绝对距离、以及根据进度灵活调整测试手段，成功解决了以前工具“只挑近路走”和“乱改数据”的毛病。这让开发者能更早、更准地发现那些隐藏在第三方库里的定时炸弹，从而在更新软件时更有底气。

这是一篇关于利用**定向灰盒模糊测试（Directed Greybox Fuzzing, DGF）**从客户端程序触发并检测第三方库（TPL）漏洞可利用性的论文总结。论文提出了一种名为 LiveFuzz 的新方法。

以下是该论文的详细技术总结：

1. 研究背景与问题 (Problem)

背景：开发者广泛使用第三方库（TPL）来提高开发效率，但这引入了严重的安全风险。如果 TPL 中存在漏洞，可能会传播到依赖它的客户端程序中（例如 Log4Shell 事件）。
现有挑战：
- 更新困难：修复漏洞通常需要更新库，但这涉及大量的代码适配工作，且可能破坏软件生态系统的兼容性，导致开发者倾向于不更新，从而让程序长期暴露在风险中。
- 检测难点：现有的检测方法主要分为两类：
  1. 基于可达性分析：通过调用图（CG）判断漏洞函数是否被调用。缺点是误报率高，无法验证是否满足触发漏洞的具体条件（如参数约束）。
  2. 基于测试生成：生成测试用例来触发漏洞。但这类方法通常依赖概念验证（PoC），而现实中许多漏洞的 PoC 是不可用的。
核心问题：如何在没有 PoC的情况下，从客户端程序出发，利用模糊测试技术有效触发并检测第三方库漏洞的可利用性？
现有 DGF 的局限性：
- 挑战 1：对短路径种子的偏好。现有的 DGF 工具（如 AFLGo）倾向于选择执行路径较短的种子。在跨程序（客户端 + 库）场景中，由于路径爆炸，这导致长路径但能到达关键约束的种子被忽略。
- 挑战 2：过度变异（Excessive Mutation）。现有的变异策略不考虑跨程序的执行阶段。粗粒度的变异容易破坏客户端程序中已满足的约束（如 type >= 0），导致测试用例无法到达库中的漏洞点。

2. 方法论：LiveFuzz (Methodology)

LiveFuzz 是一种基于定向灰盒模糊测试的方法，旨在解决上述跨程序场景下的挑战。其核心架构包含三个模块（如图 2 所示）：

2.1 目标元组构建 (Target Tuple Construction)

创新点：不同于传统 DGF 仅关注单一程序中的目标，LiveFuzz 定义了目标元组 $\langle CT, VT \rangle$ 。
- $VT$ (Vulnerability Targets)：库中漏洞函数的第一个基本块。
- $CT$ (Caller Targets)：客户端中调用库接口函数的“调用者”函数的第一个基本块。
作用：将跨程序的执行路径分解为“客户端执行路径”和“库执行路径”，使得距离计算可以在单一程序上下文中进行，解决了跨程序距离计算的复杂性。

2.2 抽象路径映射 (Abstract Path Mapping, APM)

目的：解决挑战 1，即消除对短路径种子的偏好，公平比较不同可达路径上的种子。
机制：
- 不再单纯依赖绝对距离，而是计算相对执行进度。
- 引入**路径长度（Path Length）**作为上界，将目标距离归一化。
- 利用 $A^*$ 搜索启发式思想 $f(n) = g(n) + h(n)$ ，结合已遍历成本（ $g$ ）和剩余估计成本（ $h$ ）。
- 种子风险（Seed Risk）：通过计算归一化后的相对距离来评估种子触发漏洞的潜力。这使得处于不同长度路径但具有相似相对进度的种子能被公平比较，避免长路径种子被过早丢弃。

2.3 基于风险的自适应变异 (Risk-Based Adaptive Mutation)

目的：解决挑战 2，即过度变异问题。
机制：
- 功率调度（Power Schedule）：根据种子的风险值（Risk）分配变异能量。风险越高，获得的变异机会越多。
- 变异算子调度（Mutation Operator Schedule）：动态调整粗粒度（如插入/删除大块数据）和细粒度（如位翻转、单字节修改）变异算子的比例。
- 策略：
  - 当种子尚未进入库（风险较低）时，更多使用粗粒度算子以探索新路径。
  - 当种子进入库且风险较高（接近漏洞点）时，自动增加细粒度算子的比例，以精细调整输入满足复杂的边界条件，避免破坏已满足的约束。

3. 主要贡献 (Key Contributions)

提出了抽象路径映射机制：通过将执行路径投影到统一的抽象路径上，解决了跨程序场景下对不同长度路径种子的不公平比较问题，消除了对短路径的偏好。
实现了 LiveFuzz 原型：无需 PoC 即可从客户端程序检测库漏洞的可利用性。引入了基于风险的自适应变异策略，平衡了路径探索与逻辑挖掘。
构建了新数据集：收集了包含 61 个真实案例（涉及 7 个库、42 个漏洞）的数据集，涵盖了从客户端触发库漏洞的完整场景，填补了该领域开源数据集的空白。

4. 实验结果 (Results)

实验在 61 个真实案例上进行，对比了 AFLGo、SelectFuzz、WindRanger 和 AFL++ 等基线工具。

路径覆盖能力 (RQ1)：
- LiveFuzz 发现的目标可达路径数量比所有基线工具高出 37% 到 195% 不等。
- 在绝大多数测试用例中，LiveFuzz 在统计上显著优于基线。
漏洞复现能力 (RQ2)：
- 触发速度：LiveFuzz 触发漏洞的平均速度比基线快 4.74x 到 7.08x。
- 触发数量：在 10 次独立运行中，LiveFuzz 触发的漏洞总数最多。
- 独家发现：有 3 个漏洞（CVE-2020-24977, CVE-2021-23215, CVE-2020-11760）仅由 LiveFuzz 成功触发，其他工具均未能触发。
消融实验 (RQ3)：
- 移除目标元组构建、抽象路径映射或变异算子调度任一模块，都会导致触发时间（TTE）增加 2.25x 到 2.43x。
- 即使在没有漏洞描述（无法提供关键函数信息）的情况下，LiveFuzz 的性能依然显著优于最佳基线（TTE 仅增加 1.21x），证明了其核心机制的有效性。

5. 意义与价值 (Significance)

填补技术空白：首次提出在无 PoC 情况下，利用 DGF 从客户端程序检测库漏洞可利用性的完整方案。
提升安全性：帮助开发者更准确地评估是否必须更新第三方库。如果漏洞无法从客户端触发，开发者可以避免不必要的、高风险的库更新；反之，则能优先修复高危漏洞。
方法论创新：提出的“目标元组”和“抽象路径映射”为跨程序（Cross-Program）的模糊测试提供了新的理论视角，解决了传统 DGF 在复杂依赖场景下的路径偏好和变异策略失效问题。
实际影响：通过构建高质量数据集和开源工具，推动了软件供应链安全的研究，特别是在 C/C++ 生态系统中。

总结

LiveFuzz 通过引入目标元组、抽象路径映射和基于风险的自适应变异，成功克服了传统模糊测试在跨程序场景下的局限性。它不仅显著提高了漏洞触发的效率和覆盖率，还解决了在无 PoC 条件下检测库漏洞可利用性的难题，为软件供应链安全提供了强有力的技术支撑。