offensive-fuzzing-course skill

SKILL: Week 2: Finding Vulnerabilities Through Fuzzing

Metadata

• Skill Name: fuzzing-course
• Folder: offensive-fuzzing-course
• Source: https://github.com/SnailSploit/offensive-checklist/blob/main/2-fuzzing.md

Description

Week 2 of the exploit development curriculum. Covers fuzzing methodology: target selection, corpus generation, coverage-guided fuzzing with AFL++/libFuzzer, structured fuzzing, and triage/deduplication. Use when setting up fuzz campaigns, selecting harness strategies, or triaging fuzzer output.

Trigger Phrases

Use this skill when the conversation involves any of: fuzzing curriculum, AFL++, libFuzzer, coverage-guided fuzzing, corpus generation, harness, fuzz target, mutation, triage, crash dedup, week 2, exploit dev course

Instructions for Claude

When this skill is active:

1. Load and apply the full methodology below as your operational checklist
2. Follow steps in order unless the user specifies otherwise
3. For each technique, consider applicability to the current target/context
4. Track which checklist items have been completed
5. Suggest next steps based on findings

Full Methodology

Week 2: Finding Vulnerabilities Through Fuzzing

Overview

created by AnotherOne from @Pwn3rzs Telegram channel.

This document is Week 2 of a multi‑week exploit development course, focusing on discovering vulnerabilities through fuzzing techniques and analyzing the crashes to determine exploitability.

Last week we studied vulnerability classes through real-world examples. This week we'll learn to find these vulnerabilities ourselves using fuzzing - the automated technique that has discovered thousands of critical security bugs in production software.

Fuzzing can feel a bit front‑loaded: you may spend time wiring harnesses and running campaigns without immediately finding exciting new bugs, especially on hardened or well‑tested targets. That’s normal, and it's one reason the next week on patch diffing often feels more directly "practical" — many companies already run large fuzzing setups and need people who can understand and exploit the bugs those systems uncover. Still, working through this week is important: it teaches you how fuzzers actually discover real vulnerabilities, so when you later triage crashes or study patches, you'll have a solid intuition for how those bugs were found and how to reproduce them.

Prerequisites

Before starting this week, ensure you have:

• A Linux virtual machine (Ubuntu 24.04 recommended) with at least 8GB RAM and 8 cpu cores
• Basic understanding of C/C++ programming
• Familiarity with command-line tools and debugging (GDB basics)
• Understanding of memory corruption vulnerabilities (from Week 1)

Day 1: Introduction to Fuzzing

• Goal: Understand the fundamentals of fuzzing and get hands-on experience with AFL++.
• Activities:
• Reading: "Fuzzing for Software Security Testing and Quality Assurance" by Ari Takanen(From 1.3.2 to 1.3.8 and 2.4.1 to 2.7.5).
• Online Resource:
• Fuzzing Book by Andreas Zeller - Read "Introduction" and "Fuzzing Basics."
• AFL++ Documentation - Follow the quick start guide.
• Interactive Module to Learn Fuzzing
• Real-World Context:
• Google OSS-Fuzz: Finding 36,000+ bugs across 1,000+ projects
• AFL Success Stories - Real vulnerabilities found by AFL
• Exercise:
• Set up a Linux virtual machine (VM) with the necessary tools installed, including compilers and debuggers

# Setting up AFL++

# Install build dependencies
sudo apt update
sudo apt install -y build-essential gcc-13-plugin-dev cpio python3-dev libcapstone-dev \
    pkg-config libglib2.0-dev libpixman-1-dev automake autoconf python3-pip \
    ninja-build cmake git wget python3.12-venv meson

# Install LLVM (check latest version at https://apt.llvm.org/)
wget https://apt.llvm.org/llvm.sh
chmod +x llvm.sh
sudo ./llvm.sh 19 all

# Verify LLVM installation
clang-19 --version
llvm-config-19 --version

# Install Rust (required for some AFL++ components)
curl --proto '=https' --tlsv1.2 -sSf "https://sh.rustup.rs" | sh
source ~/.cargo/env

# Build and install AFL++
mkdir -p ~/soft && cd ~/soft
git clone --depth 1 https://github.com/AFLplusplus/AFLplusplus.git
cd AFLplusplus
# NOTE: unicorn support might fail(you need to add the env or run ./build_unicorn_support.py and fix issues yourself)
make distrib
sudo make install

# Verify installation
which afl-fuzz
afl-fuzz --version

# Phase 1: Simple crash example
cd ~/ && mkdir -p tuts && cd tuts
git clone --branch main --depth 1 https://github.com/alex-maleno/Fuzzing-Module.git
cd Fuzzing-Module/exercise1 && mkdir -p build && cd build

# Compile with

Success Criteria:

• AFL++ compiles and installs without errors
• Both fuzzing sessions start successfully
• You can see the AFL++ status screen showing paths found, crashes, etc.
• Check out/crashes/ directory for any discovered crashes

Troubleshooting:

• If afl-clang-fast not found: Check /usr/local/bin/ is in PATH
• If compilation fails: Ensure LLVM 19 is properly installed (clang-19 --version)
• If fuzzer doesn't start: Check CPU scaling governor (echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scalinggovernor)

Real-World Impact: AFL++ Finding CVE-2024-47606 (GStreamer)

Background: AFL++ and similar fuzzers are actively used to find vulnerabilities in production software. Let's examine a real case from Week 1.

Case Study - CVE-2024-47606 (GStreamer Signed-to-Unsigned Integer Underflow):

• Discovery Method: Continuous fuzzing campaigns by security researchers using AFL++ on media parsers
• The Bug: GStreamer's qtdemuxparsetheora_extension had a signed integer underflow that became massive unsigned value
• Attack Surface: MP4/MOV files processed automatically by browsers, media players, messaging apps
• Fuzzing Approach:

1. Target: GStreamer's QuickTime demuxer (qtdemux)
2. Seed corpus: Valid MP4 files from public datasets
3. Instrumentation: Compiled with AFL++ and AddressSanitizer
4. Mutation strategy: Structure-aware (understanding MP4 atoms)
5. Result: Heap buffer overflow crash after ~48 hours of fuzzing

Why Fuzzing Found It:

• Rare Input Combination: Required specific Theora extension size values that underflow
• Static Analysis Limitation: Signed-to-unsigned conversion buried in complex parsing logic
• Code Review Miss: Integer arithmetic looked correct without considering negative values
• Automated Testing Gap: Unit tests didn't cover malformed Theora extensions

The Discovery Process:

# 1) Generate a structured MP4 seed corpus (GitHub Security Lab generator)
cd ~/tuts && git clone --depth 1 https://github.com/github/securitylab.git
cd ~/tuts/securitylab/Fuzzing/GStreamer
make
mkdir -p corpus/mp4
./generator -o corpus/mp4

# 2) Build a vulnerable GStreamer (< 1.24.10) with AFL++ + ASan
cd ~/tuts
git clone --branch 1.24.9 --depth 1 https://gitlab.freedesktop.org/gstreamer/gstreamer.git
cd gstreamer
export CC=afl-clang-fast
export CXX=afl-clang-fast++
export CFLAGS="-O1 -g"
export CXXFLAGS="-O1 -g"
sudo apt-get install -y flex bison
# NOTE: this might take a while so you can just build parts of it, not all
meson setup build-afl --buildtype=debug -Db_sanitize=address
ninja -C build-afl -j"$(nproc)"

# 3) Fuzz the QuickTime demuxer pipeline with AFL++
mkdir -p findings
# NOTE: you can fuzz other binaries as well to find bugs
echo core | sudo tee /proc/sys/kernel/core_pattern
afl-fuzz -i ~/tuts/securitylab/Fuzzing/GStreamer/corpus/mp4 \
         -o findings -m none -- \
         ./build-afl/subprojects/gstreamer/tools/gst-launch-1.0 \
         filesrc location=@@ ! qtdemux ! fakesink

# Typical outcome after hours of fuzzing:
#   - ASan crash inside qtdemux_parse_theo

Key Insight: Fuzzing excels at finding edge cases in complex parsers that humans would never manually test. The combination of:

• Coverage-guided mutation (AFL++ exploring new code paths)
• AddressSanitizer (detecting memory corruption immediately)
• Persistent fuzzing (running for days/weeks)

...makes it more effective than manual testing for this vulnerability class.

Key Takeaways

1. Fuzzing finds real vulnerabilities: Not just theoretical crashes, but exploitable bugs in production software
2. Coverage-guided fuzzing is powerful: AFL++ intelligently explores code paths rather than random mutation
3. Sanitizers are essential: ASAN, UBSAN turn subtle bugs into immediate crashes
4. Time matters: Many bugs require hours/days of fuzzing to discover
5. Seed corpus quality affects results: Starting with valid inputs helps reach deeper code paths

Discussion Questions

1. Why did fuzzing find CVE-2024-47606 when code review and unit testing didn't?
2. What advantages does coverage-guided fuzzing have over purely random fuzzing?
3. How do sanitizers (ASAN, UBSAN) enhance fuzzing effectiveness?
4. What types of vulnerabilities are fuzzing best suited to find? What types does it miss?
5. How can seed corpus selection impact fuzzing effectiveness?

Day 2: Continue Fuzzing with AFL++

• Goal: Understand and apply advanced fuzzing techniques.
• Activities:
• Reading: Continue with "Fuzzing for Software Security Testing and Quality Assurance" (From 3.3 to 3.9.8).
• Real-World Examples:
• AFL++ finds CVE-2020-9385 in ZINT Barcode Generator - Stack buffer overflow discovered through fuzzing
• AFL++ Fuzzing in Depth - How to effectively use afl++
• Suricata IDS CVE-2019-16411 - Out-of-bounds read found via fuzzing
• Exercise:
• Experiment with different AFL++ options (for example, dictionary-based fuzzing, persistent mode).
• Running AFL++ with a real-world application like a file format parser to mimic real-world scenarios.
• Optionally, target an image or media parser so you can practice finding heap overflows and out-of-bounds reads similar to the libWebP and GStreamer bugs from Week 1.

# Fuzzing a image parser (dlib imglab)
# NOTE: you can pull older versions to guarantee vulnerable code paths
cd ~/tuts && git clone --depth 1 --branch v19.24.6 https://github.com/davisking/dlib.git
cd dlib/tools/imglab && mkdir -p build && cd build

# Configure sanitizers for better crash detection
export AFL_USE_UBSAN=1
export AFL_USE_ASAN=1
export ASAN_OPTIONS="detect_leaks=1:abort_on_error=1:allow_user_segv_handler=0:handle_abort=1:symbolize=0"

# Install dependencies
sudo apt install -y libx11-dev libavdevice-dev libavfilter-dev libavformat-dev libavcodec-dev \
libswresample-dev libswscale-dev libavutil-dev libjxl-dev libjxl-tools

# Compile with AFL++ and sanitizers
cmake -DCMAKE_C_COMPILER=afl-clang-fast \
      -DDLIB_NO_GUI_SUPPORT=0 \
      -DCMAKE_CXX_COMPILER=afl-clang-fast++ \
      -DCMAKE_CXX_FLAGS="-fsanitize=address,leak,undefined -g" \
      -DCMAKE_C_FLAGS="-fsanitize=address,leak,undefined -g" ..
make -j$(nproc)

# Prepare seed corpus
mkdir -p fuzz/image/in
cp ../../../examples/faces/testing.xml fuzz/image/in/

# TODO: try to improve the fuzzing speed using https://aflplus.plus/docs/fuzzing_in_depth/#i-improve-the-speed
# Run AFL++ in parallel mode (Master + Sla

Expected Outputs:

• AFL++ status screen showing increasing coverage
• Crashes appearing in fuzz/image/out/Master/crashes/ or fuzz/image/out/Slave1/crashes/
• AddressSanitizer reports for memory corruption bugs

What to Look For:

• Crashes with SIGSEGV or SIGABRT signals
• AddressSanitizer reports showing heap buffer overflows, use-after-free, etc.
• Unique crash signatures (different stack traces)

Troubleshooting:

• If compilation fails: Check that all dependencies are installed
• If no crashes found: Let fuzzer run longer (hours/days for real targets)
• If crashes are false positives: Review ASAN options and adjust

Real-World Campaign: Fuzzing Image Parsers

Case Study - CVE-2023-4863 (libWebP Heap Buffer Overflow):

From Week 1, you learned about this critical vulnerability. Let's understand how fuzzing could have (and did) discover similar bugs.

• The Target: libWebP image decoder, used by Chrome, Firefox, and countless applications
• Why It's Fuzzing-Friendly:
• Pure input-to-output: takes file bytes, produces image
• No network/filesystem dependencies
• Deterministic execution
• Complex parsing logic with many edge cases

Fuzzing Campaign Strategy:

# Real-world fuzzing setup for image parsers
cd ~/tuts && git clone --depth 1 --branch 1.0.0 https://chromium.googlesource.com/webm/libwebp

cd libwebp && sudo apt-get -y install gcc make autoconf automake libtool

# Compile with AFL++ and all sanitizers
export CC=afl-clang-fast
export CXX=afl-clang-fast++
export AFL_USE_ASAN=1
export AFL_USE_UBSAN=1
export CFLAGS="-fsanitize=address,undefined -g"
export CXXFLAGS="-fsanitize=address,undefined -g"

./autogen.sh
./configure
make -j$(nproc)

# Create fuzzing harness
cat > fuzz_webp.c << 'EOF'
#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
#include <webp/decode.h>
#include <webp/types.h>

int main(int argc, char **argv) {
    if (argc < 2) return 1;

    FILE *f = fopen(argv[1], "rb");
    if (!f) return 1;

    fseek(f, 0, SEEK_END);
    size_t size = ftell(f);
    fseek(f, 0, SEEK_SET);

    uint8_t *data = malloc(size);
    fread(data, 1, size, f);
    fclose(f);

    // Fuzz target: decode WebP image
    int width, height;
    uint8_t *output = WebPDecodeRGBA(data, size, &width, &height);

    if (output) free(output);
    free(data);
    return 0;
}
EOF

# Compile fuzzing harness
afl-clang-fast -I./src -o fuzz_webp fuz

What Fuzzing Discovered:

In the real CVE-2023-4863 case: