Orion: Fuzzing Workflow Automation

Orion: Fuzzing Workflow Automation

Speakers: Max Bazalii, Marius Fleischer

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=NbWDhk-9k_k

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Max%20Bazalii%20Marius%20Fleischer%20-%20Orion%20fuzzing%20workflow%20automation.pdf

Overview

Orion is a fuzzing workflow automation platform developed by Max Bazalii and Marius Fleischer at NVIDIA's offensive security team. Presented at DEF CON 33, the talk addresses a persistent pain point in vulnerability research: while coverage-guided fuzzers like AFL++ and libFuzzer are powerful tools, the surrounding workflow—harness creation, corpus management, crash triage, deduplication, root cause analysis, and fix generation—is laborious, manual, and difficult to scale. Orion automates this entire pipeline using a combination of static analysis, dynamic instrumentation, and LLM-assisted code generation and analysis.

The talk presents Orion as an end-to-end system: a researcher defines a target, and Orion handles harness creation (with AI assistance), fuzzing infrastructure deployment, crash collection, deduplication, root cause analysis, and even automated generation of candidate patches. The system has been used internally at NVIDIA to fuzz GPU drivers and related components, and the presentation includes real vulnerability findings as validation.

Background

▶ Watch: Orion framework: architecture and design goals (0:02)

The Fuzzing Workflow Problem

Coverage-guided fuzzing is the most productive automated vulnerability discovery technique available today. Tools like AFL++, libFuzzer, and HonggFuzz instrument target binaries to measure code coverage and use evolutionary mutation algorithms to maximize coverage, which empirically correlates with finding new code paths and therefore new vulnerabilities.

However, fuzzing effectively in practice requires significant manual effort:

1. Harness writing: A fuzzing harness is a small program that takes a fuzzer-provided input and feeds it to the target in a way that exercises the desired attack surface. Writing a good harness requires understanding the target's API, input format, and state requirements. This is often the primary bottleneck.

1. Corpus management: Seeding the fuzzer with representative inputs and managing the corpus as it grows requires ongoing attention.

1. Infrastructure management: Running fuzzers at scale requires distributed compute infrastructure—cloud VMs, job scheduling, and crash reporting systems.

1. Crash triage: A fuzzer running for days produces thousands of crashes. Most are duplicates. Manual triage to identify unique root causes is slow and tedious.

1. Root cause analysis: Determining whether a crash is exploitable, and why, requires deep technical analysis.

1. Reporting and remediation: Documenting findings and generating patches for confirmed vulnerabilities is additional manual work.

Orion's goal is to automate as much of this workflow as possible, reducing the skill and time required to achieve high-coverage fuzzing of a new target.

The AI-Assisted Security Research Context

The talk situates Orion within a broader trend of applying LLMs (large language models) to security research tasks. Prior work has shown that LLMs can generate fuzzing harnesses with varying quality, assist in vulnerability analysis, and suggest code fixes. Orion's contribution is integrating these AI capabilities into a cohesive workflow system with the guardrails and feedback loops needed for production security research use.

Key Findings

▶ Watch: Corpus management and seed generation automation (0:54)

Automated harness generation is the highest-leverage automation point. Orion's evaluation found that harness creation was the single biggest time cost in the fuzzing workflow. By using LLMs (specifically, large coding models) to generate harness candidates from API documentation, header files, and example code, Orion reduced harness creation time by an estimated 60-70% in internal testing. Generated harnesses are not always correct on the first attempt—Orion includes a compile-and-run feedback loop that re-prompts the LLM with error messages until a harness compiles and runs successfully.

LLM-assisted crash deduplication outperforms stack hash methods. Traditional crash deduplication uses the call stack hash of the crashing frame—crashes with the same stack are considered duplicates. This has well-known limitations (different code paths can produce the same crash frame; one root cause can produce many unique stack hashes). Orion supplements stack hashing with LLM analysis of the crash context, grouping crashes by their likely root cause even when the stack traces differ.

Root cause analysis with LLM guidance accelerates triage. Given a crash and the associated code context (source or decompiled representation), Orion queries an LLM for an analysis of the crash's likely cause and exploitability. This provides a first-pass assessment that helps researchers prioritize which crashes to investigate deeply.

Automated patch generation. For some crash categories (null pointer dereferences, simple buffer overruns with clear bounds), Orion generates candidate patches. These are not production-ready fixes, but they provide a starting point and demonstrate to the engineering team the expected scope of the fix.

System finds real vulnerabilities at scale. The speakers presented findings from internal NVIDIA fuzzing campaigns using Orion, including vulnerabilities in GPU driver components. While specific CVE details were not fully disclosed in the public talk, the system's output demonstrated real-world applicability in a complex, safety-critical codebase.

Technical Deep Dive

▶ Watch: Coverage-guided fuzzing optimization in Orion (1:01)

Orion System Architecture

Orion is structured as a pipeline with the following stages:

1. Target Ingestion

The researcher provides a target specification: a library or executable, optional source code or headers, and a description of the attack surface. Orion performs static analysis using a combination of static analysis tools (e.g., CodeQL queries, custom LLVM passes) to identify candidate fuzzing entry points—exported functions, parsers, network handlers.

2. Harness Generation

For each identified entry point, Orion constructs a prompt containing:

• The function signature and type information.
• Surrounding code context (callsite examples, related API usage).
• Any available documentation.
• A system prompt that instructs the LLM on how to write a fuzzing harness (proper use of fuzzer-provided data, avoiding UB in the harness itself, handling initialization/teardown).

The LLM produces a harness candidate in C/C++. Orion attempts to compile it, captures compiler errors, and re-prompts with the error context until the harness compiles cleanly. It then runs the harness briefly to verify it doesn't crash immediately (a common issue with generated harnesses that misuse the target API).

3. Fuzzing Execution

Validated harnesses are deployed to fuzzing workers. Orion supports multiple backends: local parallelism (using AFL++'s parallel mode), cloud-based VM scaling, and container-based deployments. Fuzzing jobs are scheduled and monitored centrally, with coverage metrics and crash rates reported in a dashboard.

4. Crash Collection and Deduplication

Crashes are collected and stored with their triggering inputs. Deduplication runs in two passes:

• Pass 1: Stack hash deduplication—crashes with identical or near-identical crash stacks are grouped.
• Pass 2: LLM deduplication—remaining crash groups are analyzed by an LLM to identify cases where different stacks represent the same root cause (e.g., different call paths to the same vulnerable code).

5. Root Cause Analysis

For each unique crash group, Orion generates a root cause analysis report. This includes:

• The crash type (segfault, heap corruption, assertion failure, etc.).
• The crash address and memory layout (if available from ASAN/MSAN reports).
• LLM-generated analysis of the likely cause: what memory access or state condition triggered the crash, and what the likely vulnerability class is (OOB read/write, UAF, integer overflow, etc.).
• An exploitability assessment (informational, with caveats).

6. Patch Suggestion

For crashes that the LLM classifies with high confidence as a specific vulnerability type, Orion generates a candidate patch (a git diff-style code modification). The patch is presented as a suggestion for human review, not applied automatically.

LLM Integration Details

Orion uses a coding-focused LLM (the specific model was not disclosed but described as a large commercial coding model). The system uses structured prompts with chain-of-thought formatting to improve output quality. Key prompt engineering techniques mentioned:

• Including compilation errors verbatim in re-prompting to give the model precise feedback.
• Asking the model to "reason step by step" about the API usage before generating code.
• Constraining the output format to avoid non-compilable markdown fencing or commentary.

The feedback loop (generate → compile → reprompt with errors) typically converges within 3-5 iterations for most harnesses.

Challenges and Limitations

The speakers are candid about Orion's limitations:

• Complex stateful targets (e.g., network protocol parsers that require multi-message state setup) remain difficult to harness automatically. LLM-generated harnesses for these targets often miss the required initialization sequences.
• LLM hallucinations in root cause analysis are a real concern—the system's analysis should be treated as a hypothesis to be validated, not a ground truth.
• Patch quality degrades for non-trivial vulnerability patterns. Automated patches are useful only for the simplest vulnerability classes.
• Coverage of targets without source code is lower—the harness generation pipeline benefits significantly from having type information and API documentation.

Demo / Proof of Concept

▶ Watch: Results: bugs found using Orion in the wild (8:17)

The talk demonstrates Orion on a real target:

• The harness generation flow is shown for a library function, including the LLM conversation and compilation feedback loop.
• A crash found by the fuzzer is shown being automatically triaged, with the LLM root cause analysis output displayed.
• The dashboard showing multiple concurrent fuzzing jobs, coverage curves, and crash counts is presented.
• A candidate patch generated by Orion for a null-pointer dereference is shown alongside the actual fix from the engineering team—demonstrating alignment between the automated suggestion and the human-written fix.

Defensive Implications

▶ Watch: Live demo: Orion finding bugs in a real target (10:39)

For vulnerability researchers:

• Orion-style automation makes previously expert-only fuzzing workflows accessible to a broader team. Organizations that struggle to hire experienced fuzzing researchers can use automation to scale their output.
• The LLM-assisted triage capability addresses the "ocean of crashes" problem that often blocks researchers from reaching useful conclusions in large fuzzing campaigns.

For software development teams:

• The integration of fuzzing with LLM-assisted patching creates a path toward more complete "find and fix" automation in the SDL (Security Development Lifecycle).
• Harness generation automation lowers the barrier to continuous fuzzing—teams can fuzz new code as it is written, not just as a periodic security audit.

For the fuzzing ecosystem:

• The talk represents a data point in the ongoing maturation of AI-assisted security tooling. The key insight is that AI provides the most value at the boundaries of the fuzzing workflow (harness generation, crash analysis) rather than in the core fuzzer itself (where existing tools are already highly optimized).

Key Takeaways

1. The biggest bottleneck in production fuzzing is not the fuzzer itself but the surrounding workflow—Orion demonstrates that this workflow is substantially automatable.
2. LLM-assisted harness generation with compile-and-run feedback loops produces usable harnesses significantly faster than manual authorship for well-documented targets.
3. LLM crash deduplication and root cause analysis complement (not replace) traditional stack-hash methods, particularly for identifying shared root causes across different crash traces.
4. Automated patch suggestions, while limited in scope, provide a practical acceleration for human engineers triaging fuzzer output.
5. AI-assisted fuzzing tools like Orion will compress the time between "target identified" and "vulnerabilities found"—with implications for both offensive security timelines and the urgency of deploying continuous fuzzing in SDL processes.

About the Speaker(s)

▶ Watch: CI/CD integration for continuous fuzzing pipelines (16:14)

Max Bazalii leads the offensive security team at NVIDIA, focusing on GPU driver vulnerability research using AI-assisted methods, formal methods, and general security research. He has deep experience with Apple platform security, having developed iOS and watchOS jailbreaks—including presenting the first Apple Watch jailbreak at DEF CON 25 and contributing to the discovery of the first Pegasus spyware iOS exploit chain. Marius Fleischer is a security engineer on NVIDIA's offensive security team for DRIVE OS (the automotive/autonomous vehicle platform), focusing on applying AI to security challenges. Before NVIDIA, he was a PhD researcher at UC Santa Barbara's security lab under Giovanni Vigna and Christopher Kruegel, working on automated vulnerability discovery for operating systems.