Fuzzing Crash to Exploit: A Practical Guide

TL;DR

When a fuzzer finds a crash, it doesn’t automatically mean you have an exploitable vulnerability. This guide explains how to investigate crashes from fuzzing to determine if they can be turned into real attacks. We’ll cover basic debugging, identifying the root cause, and assessing exploitability.

1. Crash Triage & Initial Information

1. Reproduce the crash: The first step is always confirming you can reliably trigger the crash with the same input that the fuzzer used. Save this input!
2. Gather Context: Note down everything about the crash:
   • The fuzzer used (e.g., AFL, LibFuzzer).
   • The target program and version.
   • Operating system and architecture (e.g., Linux x86-64).
   • Compiler and flags used to build the target.
3. Crash Report Analysis: Examine the crash report generated by your OS.
   • Linux: Use tools like gdb or lldb with core dumps.
   • Windows: Use WinDbg or Visual Studio’s debugger.

2. Debugging the Crash

Debugging helps you understand *why* the crash happened.

1. Run in a Debugger: Start your target program within a debugger (gdb is common on Linux).
2. Load the Core Dump: If available, load the core dump file.

   gdb ./target_program /path/to/core.dump

3. Set a Breakpoint: Set a breakpoint at the crashing instruction (identified from the crash report).
4. Run with Input: Run the program with the input that caused the crash.

   run <input_file>

5. Step Through Code: Step through the code line by line to see what’s happening leading up to the crash. Pay attention to variable values and function calls.
6. Identify the Crash Point: Pinpoint the exact line of code causing the crash (e.g., a null pointer dereference, out-of-bounds array access).

3. Root Cause Analysis

Understanding *why* the code crashed is crucial.

1. Common Crash Types:
   • Null Pointer Dereference: Trying to access memory at address 0.
   • Buffer Overflow/Underflow: Writing or reading beyond allocated buffer boundaries.
   • Heap Corruption: Damage to the program’s dynamic memory allocation.
   • Integer Overflow/Underflow: Arithmetic operations resulting in values outside expected ranges.
   • Use-After-Free: Accessing memory that has already been freed.
2. Code Review: Carefully examine the code around the crash point. Look for potential vulnerabilities like unchecked input validation, incorrect boundary checks, or flawed logic.

4. Assessing Exploitability

Not all crashes are exploitable. This step determines if you can control program execution.

1. Control of Execution: Can the crash be used to redirect program flow to attacker-controlled code?
2. Memory Corruption Control: If it’s a memory corruption bug, can you overwrite important data (e.g., return addresses on the stack)?
3. Stack vs Heap: Stack overflows are generally easier to exploit than heap corruptions.
4. Mitigations: Consider if security mitigations like ASLR (Address Space Layout Randomization) and DEP/NX (Data Execution Prevention) are enabled.
   • ASLR makes it harder to predict memory addresses.
   • DEP/NX prevents code execution from data sections of memory.
5. Exploit Techniques: Consider potential exploit techniques:
   • Return-Oriented Programming (ROP): Useful when DEP/NX is enabled.
   • Shellcode Injection: Possible if DEP/NX is disabled and you can overwrite the stack.
   • Heap Spraying: Used to reliably place shellcode in memory for heap overflows.

5. Further Investigation

If exploitability seems possible, proceed with more detailed analysis.

1. Disassembly: Use a disassembler (e.g., objdump, IDA Pro) to examine the machine code around the crash point.
2. Dynamic Analysis Tools: Use tools like Valgrind or AddressSanitizer to confirm memory errors and identify potential vulnerabilities.

   valgrind --leak-check=full ./target_program <input_file>

3. Prototype Exploit: Attempt to create a simple proof-of-concept exploit. This will help you understand the challenges and feasibility of exploiting the vulnerability.