Rust and Go directed fuzzing with LibAFL-DiFuzz

summary

The gist

Directed fuzzing for Rust and Go applications is introduced through a novel approach utilizing LibAFL-DiFuzz, which addresses the need for precise testing solutions beyond traditional coverage-guided

In short

This work introduces LibAFL-DiFuzz, a novel method for directed fuzzing Rust and Go applications. It uses advanced preprocessing, compiler customizations, and graph construction tailored to each language to guide fuzzers effectively. The resulting tools significantly outperform existing fuzzer benchmarks when measured by Time to Exposure (TTE).

Key concepts

LibAFL-DiFuzz: A new directed fuzzing approach that prepares programs for testing. It involves static analysis to find target sequences, custom compiler modifications for Rust, and graph construction using SSA IR for Go code. This method provides precise guidance to the fuzzer.
Enhanced Target Sequences (ETS): These are lists of basic blocks leading to specific target points in a program. They are obtained through static analysis and include computed context weights. ETS feedback is then used to guide the fuzzing process, telling the fuzzer which code paths are most important.
SSA IR for Go: Go uses SSA (Static Single Assignment) Intermediate Representation instead of LLVM IR. The paper describes a method to build Call Graphs (CGs) and Control Flow Graphs (CFGs) from this SSA IR. This allows the tool to gather unified debug information necessary for effective graph construction in Go.

Terminology used across episodes

Reinforcement Learning (RL) — explained in 24 episodes
Retrieval-Augmented Generation (RAG) — explained in 16 episodes
Interpretability — explained in 15 episodes
Sample Complexity — explained in 15 episodes
Federated Learning — explained in 14 episodes
Generalization — explained in 13 episodes

This episode discusses

The paper

Rust and Go directed fuzzing with LibAFL-DiFuzz · Read on arXiv

Ivannikov Institute for System Programming of the Russian Academy of Sciences · Lomonosov Moscow State University

In modern SSDLC, program analysis and automated testing are essential for minimizing vulnerabilities before software release, with fuzzing being a fast and widely used dynamic testing method. However, traditional coverage-guided fuzzing may be less effective in specific tasks like verifying static analysis reports or reproducing crashes, while directed fuzzing, focusing on targeted program locations using proximity metrics, proves to be more effective. Some of the earliest directed fuzzers are, for example, AFLGo and BEACON, which use different proximity metric approaches. Although most automated testing tools focus on C/C++ code, the growing popularity of Rust and Go causes the need for precise and efficient testing solutions for these languages. This work expands the applicability of directed fuzzing beyond traditional analysis of C/C++ software. We present a novel approach to directed greybox fuzzing tailored specifically for Rust and Go applications. We introduce advanced preprocessing techniques, rustc compiler customizations, and elaborate graph construction and instrumentation methods to enable effective targeting of specific program locations. Our implemented fuzzing tools, based on LibAFL-DiFuzz backend, demonstrate competitive advantages compared to popular existing fuzzers like afl. rs, cargo-fuzz, and go-fuzz. According to TTE (Time to Exposure) experiments, Rust-LibAFL-DiFuzz outperforms other tools by the best TTE result. Some stability issues can be explained by different mutation approaches. Go-LibAFL-DiFuzz outperforms its opponent by the best and, in the majority of cases, by average result, having two cases with orders of magnitude difference. These results prove better efficiency and accuracy of our approach.

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: Today's paper: "Rust and Go directed fuzzing with LibAFL-DiFuzz".

Elias: Directed fuzzing for Rust and Go applications is introduced through a novel approach utilizing LibAFL-DiFuzz, which addresses the need for precise testing solutions beyond traditional coverage-guided methods.

Nadia: First, who's behind it and why it matters.

Title and authors: Nadia: We’ve covered the setup, and now we need to look at what they actually propose in "Rust and Go directed fuzzing with LibAFL-DiFuzz." They're essentially introducing a unified system for directing fuzzing efforts into these two major compiled languages.

Elias: The core idea revolves around enabling this directed fuzzing by adding specific preprocessing steps, like using rustc compiler customization for Rust, and creating a combined approach to graph construction with correct debug information based on AST and SSA IR for Go code.

Priya: I’m looking at the methodology described in the paper, and it seems they are building tools from scratch using different underlying language representations—LLVM IR for Rust and SSA IR for Go—to get that accurate feedback.

Nadia: Right, Priya, so they’re not just slapping an existing fuzzer onto these languages; they’re modifying the compilation process itself to feed the fuzzer better information.

Elias: They also mention their feedback instrumentors that work directly on the source code of Go programs, which is a significant detail when you're dealing with an intermediate representation like SSA IR.

Priya: That level of instrumentation suggests they are going deep into how those languages handle control flow to ensure the fuzzer gets meaningful guidance for those specific target points.

The paper's summary: Nadia: So, summarizing what the paper presents, they propose a four-step process for LibAFL-DiFuzz: static analysis to get enhanced target sequences called ETS, followed by implementing ETS feedback through target program instrumentation and SanCov instrumentation for coverage.

Elias: That sequence sounds like it’s designed to first pinpoint where we want to test, then instrument the code around those specific areas, and finally add coverage tracking.

Priya: The mention of linking with the libforkserver library which contains all the required utilities adds another layer to how this framework is set up for actual execution during fuzzing.

Nadia: And for Rust specifically, they adapt DiFuzz-Rust to use LLVM IR and debug information from LLVM passes to build Call Graphs and Control Flow Graphs.

Elias: Meanwhile, the Go approach is quite different; they implement a DiFuzz-Go library to construct graphs using native Go libraries like go/ast, go/ssa, and go/cfg for both Call Graph construction and CFGs.

Priya: It sounds like the paper is showing that you can successfully bridge these two very different compilation and representation models—LLVM for Rust and SSA IR for Go—into one directed fuzzing pipeline.

The paper's improvements: Nadia: The authors highlight several specific improvements they made, particularly in how they handle the language-specific challenges, like modifying rustc to create libafl rustc.

Elias: And for Go, their combined approach to graph construction is a notable improvement because it uses SSA IR first to build the Call Graph and then builds CFGs for each function to collect unified debug information.

Priya: I’m interested in the source code level instrumentation they use for Go, like inserting high-level commands such as InstrumentETS(ID) and SancovGuard(ID) using go/ast.

Nadia: That direct source code manipulation for Go seems very powerful because it allows them to inject feedback precisely where they need it based on the ETS IDs they calculated earlier.

Elias: The authors also emphasize that their tools are evaluated against existing fuzzers, and the results show Rust-LibAFL-DiFuzz outperforms other tools by the best TTE result.

Priya: While those TTE results are impressive for speed, I want to ask what those metrics actually tell us about the quality of the coverage feedback they get compared to simply running a long, traditional coverage run.

Conclusion: Nadia: So, wrapping up the "Rust and Go directed fuzzing with LibAFL-DiFuzz" paper, we see they’ve successfully implemented tools for both languages using tailored techniques for preprocessing and instrumentation.

Elias: The authors conclude that their implementation of the Rust and Go directed fuzzing tools based on the LibAFL-DiFuzz backend provides a strong performance baseline compared to established competitors like afl.rs, cargo-fuzz, and gofuzz.

Priya: I think what stands out is that they managed to tackle the differing IRs—LLVM versus SSA IR—and produce tools that are both functional and relatively fast in terms of exposure time.

Nadia: It’s a solid piece of work because it shows a viable path for applying this directed testing strategy to these popular languages outside of just C/C++.

Elias: And the implication is that we can now expect more precise and efficient testing solutions when we start looking at critical components written in Rust or Go.

Priya: For the privacy researchers among us, this means if you're fuzzing infrastructure that handles sensitive data, having a tool that targets specific logic paths directly could uncover subtle leaks much faster than general coverage tools allow.

Nadia: We’ve seen a lot of excitement about this paper because it shows how to make targeted testing practical and fast for these systems.

More episodes

← Home