💻 computer science

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

This paper presents LiveFuzz, a directed greybox fuzzing approach that detects exploitable library vulnerabilities from client programs without relying on proof-of-concepts by utilizing a target tuple, an abstract path mapping mechanism, and risk-based adaptive mutation to improve path reachability and vulnerability exposure speed.

Original authors: Yukai Zhao, Menghan Wu, Xing Hu, Shaohua Wang, Meng Luo, Xin Xia

Published 2026-04-07

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Yukai Zhao, Menghan Wu, Xing Hu, Shaohua Wang, Meng Luo, Xin Xia

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you own a massive, high-tech factory (your Client Program). To make your products faster and cheaper, you hire subcontractors to build specific parts for you. These subcontractors are Third-Party Libraries. They are great, but sometimes they have hidden flaws or broken machinery (Vulnerabilities) in their workshops.

The big problem? You don't own the subcontractors' factories. You can't just walk in and fix their broken machines. You have to send them instructions (inputs) from your factory to see if their machines actually break when you use them.

The Old Way: The "Guess and Check" Fuzzing

Traditionally, security researchers tried to find these broken machines using a method called Fuzzing. Imagine throwing thousands of random rocks at the factory wall to see if a window breaks.

Directed Greybox Fuzzing (DGF) is a smarter version: You have a map of the factory and you try to throw rocks specifically at a known weak spot.
The Catch: To do this effectively, you usually need a "Proof-of-Concept" (PoC). Think of a PoC as a cheat sheet or a blueprint that says, "If you push this specific button on the subcontractor's machine, it will explode."
The Reality: Often, these cheat sheets don't exist. The vulnerability is known, but nobody has figured out exactly how to trigger it from your specific factory setup. Without the cheat sheet, the old fuzzers get lost, throwing rocks at the wrong walls and missing the explosion entirely.

The New Solution: LiveFuzz

The authors of this paper built a new tool called LiveFuzz. Think of it as a smart, adaptive delivery driver who doesn't need a cheat sheet to find the broken machine.

Here is how LiveFuzz works, using simple analogies:

1. The "Two-Stop" GPS (Target Tuple)

In the old days, the driver only knew the final destination (the broken machine in the library). But the journey is complex: you have to drive through your factory first, then cross a bridge, and then enter the library.

LiveFuzz's Trick: It creates a Two-Stop GPS.
- Stop A: The specific door in your factory where the request leaves.
- Stop B: The broken machine in the library.
By tracking both stops, the driver knows exactly how far they are from the goal at every step, even if they are still inside your factory. This prevents the driver from getting confused by the complex layout of the two different buildings.

2. The "Fair Race" Map (Abstract Path Mapping)

Imagine three runners (seeds) trying to reach the broken machine.

Runner A takes a short, direct path but gets stuck at a dead end.
Runner B takes a slightly longer path and gets close.
Runner C takes a very long, winding path but is actually on the only route that leads to the explosion.
The Problem: Old fuzzers are impatient. They see Runner C is far away and say, "Too far! Let's focus on Runner B." They ignore Runner C, even though Runner C is the only one who can win.
LiveFuzz's Fix: It uses a Fair Race Map. Instead of measuring just "distance," it measures "progress relative to the path." It realizes that Runner C is actually very close to the finish line for their specific route. It stops ignoring the long paths and gives Runner C a boost, ensuring no potential explosion is missed just because the path was long.

3. The "Precision Hammer" (Risk-Based Adaptive Mutation)

Once the driver gets close to the broken machine, they need to hit it.

Old Method: The driver swings a giant sledgehammer (coarse mutation). This might break the door, but it also smashes the walls, destroying the path and making the driver start over.
LiveFuzz's Method: It assesses the Risk. If the driver is very close to the explosion, it switches to a scalpel (fine-grained mutation). It makes tiny, precise adjustments to the input (like turning a screw a fraction of a millimeter) to trigger the explosion without breaking the path. If the driver is far away, it uses the sledgehammer to explore new areas.

Why This Matters

The researchers tested LiveFuzz on 61 real-world scenarios involving popular software libraries (like those used in video processing, image handling, and networking).

The Result: LiveFuzz found more broken machines and found them much faster (up to 7 times faster) than the best existing tools.
The Big Win: In three cases, the old tools gave up completely, but LiveFuzz found the exploit. It did this without needing the cheat sheet (PoC).

Summary

LiveFuzz is like a super-smart delivery driver who:

Knows exactly where the dangerous machine is, even if it's in a different building.
Doesn't give up on long, winding routes just because they look far away.
Switches from a sledgehammer to a scalpel depending on how close they are to the target.

This allows developers to know if their software is actually in danger from a library bug, so they can decide whether to update it or not, without wasting time on false alarms or missing real threats.

1. Problem Statement

Software developers frequently rely on Third-Party Libraries (TPLs) to improve productivity, but vulnerabilities in these libraries can propagate to client programs. While updating libraries is a common mitigation strategy, it is often avoided due to the high cost of code adaptation and the risk of introducing new conflicts. Consequently, developers need to know if a specific library vulnerability is exploitable from a specific client program before deciding to update.

Existing approaches face two main limitations:

Reachability Analysis: Static analysis (e.g., call graphs) often produces false positives because it cannot verify if the necessary conditions to trigger the vulnerability are met.
Test-Based Approaches: Current methods generate tests to trigger vulnerabilities but heavily rely on Proof-of-Concepts (PoCs). Since PoCs are often unavailable for many vulnerabilities, these methods have limited applicability.

The core challenge is to detect the exploitability of library vulnerabilities from client programs without PoCs using Directed Greybox Fuzzing (DGF). This involves a "cross-program" scenario (Client + Library) which introduces two specific challenges:

Challenge 1: Seed Preference for Shorter Paths: Existing DGF tools (like AFLGo) prefer seeds executing on shorter paths. In cross-program scenarios, this bias causes the fuzzer to ignore longer, valid execution paths that might be the only route to a specific vulnerability.
Challenge 2: Excessive Mutation: Inputs must pass client-side parsing before reaching the library. Standard mutation strategies often apply coarse-grained changes that break client-side constraints, causing the input to never reach the library layer.

2. Methodology: LiveFuzz

The authors propose LiveFuzz, a DGF-based approach designed to bridge the gap between client and library code without PoCs. It consists of three core modules:

A. Target Tuple Construction

To handle the cross-program nature, LiveFuzz defines a Target Tuple $\langle CT, VT \rangle$ :

Caller Targets (CT): The first basic blocks of client functions that invoke the library.
Vulnerability Targets (VT): The first basic blocks of the vulnerable functions within the library.
This tuple allows the fuzzer to calculate distances within a unified context, treating the client and library as a single execution flow for distance calculation purposes.

B. Abstract Path Mapping (APM)

To solve the "Shorter Path Preference" challenge, LiveFuzz introduces a mechanism to fairly compare seeds on different execution paths.

Concept: Instead of using absolute distance, it calculates Seed Risk based on relative execution progress.
Mechanism: It normalizes the distance to the target by the estimated length of the reachable path (inspired by the $A^*$ heuristic $f(n) = g(n) + h(n)$ ).
Result: This allows the fuzzer to recognize that a seed on a longer path might be closer to the target relative to that path's length than a seed on a shorter path, preventing the fuzzer from discarding valid long-path seeds.

C. Risk-Based Adaptive Mutation

To solve the "Excessive Mutation" challenge, LiveFuzz dynamically adjusts mutation strategies based on the seed's risk.

Power Schedule: Allocates more execution time (power) to seeds with higher risk (closer to the target).
Mutation Operator Schedule:
- Low Risk (Client-only): Uses more coarse-grained operators (e.g., inserting/deleting large blocks) to explore new paths and break out of client-side constraints.
- High Risk (Library-reached): Shifts to fine-grained operators (e.g., bit flipping, byte increment) to fine-tune inputs and trigger deep logic flaws in the library.
Key Function Enhancement: If vulnerability descriptions are available, LiveFuzz can identify "key functions" and assign them importance scores to further guide the fuzzer.

3. Key Contributions

Novel Abstract Path Mapping: A mechanism to project execution paths onto a unified abstract path, enabling fair comparison of seeds across different reachable paths and mitigating the bias toward shorter paths.
Risk-Based Adaptive Mutation: A strategy that dynamically selects mutation operators (coarse vs. fine-grained) based on the seed's risk level, balancing path exploration with deep logic exploitation.
Cross-Program DGF Extension: The first approach to extend DGF to cross-program scenarios (Client + Library) without relying on PoCs, utilizing a Target Tuple to manage inter-layer dependencies.
New Dataset: Construction of a dataset containing 61 real-world cases involving 42 vulnerabilities across 7 libraries, specifically curated to test client-to-library exploitability.

4. Experimental Results

The authors evaluated LiveFuzz against baselines including AFLGo, SelectFuzz, WindRanger, and AFL++ using the new dataset.

Path Coverage (RQ1): LiveFuzz discovered significantly more target-reachable paths than all baselines.
- Improvements ranged from 37% to 195% more paths compared to baselines (e.g., 195% more than SelectFuzz-CT).
- It successfully covered paths that other tools missed due to the "shorter path" bias.
Vulnerability Reproduction (RQ2): LiveFuzz significantly accelerated the time-to-expose (TTE) vulnerabilities.
- Achieved average speedups of 4.74x to 7.08x compared to baselines.
- Triggered 3 vulnerabilities exclusively that no other tool could trigger within the 24-hour window.
- Triggered a total of 56 more vulnerabilities than the best-performing baseline (AFLGo-CT).
Ablation Study (RQ3): Removing any of the three core modules (Target Tuple, APM, or Adaptive Mutation) resulted in a 2.25x to 2.43x increase in TTE, confirming that each component is essential. Even without key function information (simulating missing descriptions), LiveFuzz remained 4.06x faster than the best baseline.

5. Significance

Practical Security: LiveFuzz provides a practical solution for developers to assess whether a specific library update is necessary for their client application, reducing unnecessary refactoring and supply chain risks.
Methodological Advance: It addresses fundamental limitations in Directed Greybox Fuzzing regarding cross-program analysis and path bias, offering a new paradigm for testing complex software ecosystems.
PoC Independence: By removing the dependency on PoCs, LiveFuzz can be applied to a much wider range of vulnerabilities where exploit code is not publicly available.

In summary, LiveFuzz represents a significant step forward in automated vulnerability detection, effectively bridging the gap between client applications and their underlying library dependencies to identify exploitable risks with high efficiency and accuracy.