Fuzzing Lab: Enhancing Fuzzing for tmux

Software Security @ EPFL, Spring 2025

Abstract

In this lab, we enhanced the fuzzing efforts for the tmux terminal multiplexer within Google's OSS-Fuzz infrastructure. We first established a baseline by evaluating the line coverage of the existing input-fuzzer harness, both with and without its provided seed corpus, noting comparable initial coverage. Following this, we identified two significant code regions in tmux poorly exercised by the baseline fuzzer. To address these coverage gaps, we developed and evaluated two new targeted fuzzing harnesses, cmd-fuzzer and argument-fuzzer, demonstrating their ability to improve coverage in these previously under-tested areas. As these fuzzing improvements did not uncover new critical vulnerabilities within the project's timeframe, our crash analysis focused on a known historical vulnerability. We developed a proof-of-concept (PoC) for CVE-2020-27347 (a stack-based buffer overflow), analyzed its root cause, discussed the implemented fix, and assessed its security implications.

Project Overview and Goals

This project aimed to apply and enhance fuzzing techniques on the tmux open-source terminal multiplexer, utilizing the OSS-Fuzz framework. The project encompassed several key stages:

1. Baseline Evaluation (Part 1):

   • Understand and evaluate the existing input-fuzzer harness for tmux.
   • Compare its code coverage performance when run with its default seed corpus versus an empty seed corpus.

2. Coverage Gap Analysis (Part 2):

   • Analyze coverage reports from Part 1 to identify significant code regions in tmux not adequately exercised by the input-fuzzer.
   • Focus on argument parsing (arguments.c) and command parsing/execution logic (cmd-parse.c, cmd-*.c modules) as key areas for improvement.

3. Fuzzer Improvement (Part 3):

   • Develop two new, targeted fuzzing harnesses:
     • argument-fuzzer: Specifically designed to test the command-line argument parsing logic in arguments.c.
     • cmd-fuzzer: Designed to test the command parsing and execution pathways, targeting cmd-parse.c and various modules.

Repository Structure

The final submission is organized as follows (within the submission/ directory):

submission/
├── README.md                   # This file
├── part_1/                     # Files for Part 1: Baseline Evaluation
│   ├── oss-fuzz.diff           # Diff for removing seed corpus for input-fuzzer
│   ├── project.diff            # (Likely empty or minor for Part 1)
│   ├── remove_seed_corpus.patch # The actual patch file used
│   ├── report/                 # HTML Coverage reports for input-fuzzer
│   │   ├── w_corpus/
│   │   └── wo_corpus/
│   ├── run.w_corpus.sh         # Script to run input-fuzzer with corpus
│   └── run.wo_corpus.sh        # Script to run input-fuzzer without corpus
├── part_3/                     # Files for Part 3: Fuzzer Improvements
│   ├── coverage_noimprove/     # Baseline coverage (e.g., from input-fuzzer without corpus)
│   │   └── ...
│   ├── improve1/               # Improvement 1: argument-fuzzer
│   │   ├── coverage_improve1/  # Coverage report for argument-fuzzer
│   │   ├── oss-fuzz.diff       # OSS-Fuzz config changes for argument-fuzzer
│   │   ├── project.diff        # Tmux changes for argument-fuzzer (e.g., new .cc, Makefile.am)
│   │   └── run.improve1.sh     # Script to run argument-fuzzer
│   └── improve2/               # Improvement 2: cmd-fuzzer
│       ├── coverage_improve2/  # Coverage report for cmd-fuzzer
│       ├── oss-fuzz.diff       # OSS-Fuzz config changes for cmd-fuzzer
│       ├── project.diff        # Tmux changes for cmd-fuzzer
│       └── run.improve2.sh     # Script to run cmd-fuzzer
├── part_4/                     # Files for Part 4: Crash Analysis (CVE-2020-27347)
│   ├── environment/            # Docker environment for PoC
│   │   ├── Dockerfile
│   │   ├── run_tmux_cve_test.sh # Core PoC test logic
│   │   ├── test_fixed.sh
│   │   └── test_vulnerable.sh
│   └── run.poc.sh              # Script to build Docker image and run PoC tests
└── report.pdf                  # The comprehensive project report

(Note: The scripts/ directory containing _run_fuzz_core.sh is a helper and would be part of the root if this README is at the true project root alongside submission/)

Setup and Usage

All fuzzing campaigns and the CVE PoC reproduction are designed to be run within Docker environments orchestrated by shell scripts.

Setup and Usage

All fuzzing campaigns and the CVE PoC reproduction are designed to be run within Docker environments orchestrated by shell scripts.

Prerequisites:

• Docker installed and running on a Unix-like system.
• bash shell and git client.
• SSH keys configured for [email protected] if the scripts need to clone oss-fuzz (they attempt to clone if oss-fuzz/ is not found in the project root). Alternatively, you can pre-clone https://github.com/google/oss-fuzz.git into the project root.

General Scripting Architecture: The project uses a centralized core script, scripts/_run_fuzz_core.sh (not included in the submission/ directory but part of the overall project structure this README assumes). Individual runner scripts located in submission/part_1/, submission/part_3/improve1/, submission/part_3/improve2/, and submission/part_4/ are responsible for:

1. Setting up the specific test environment by applying run-specific oss-fuzz.diff patches to a clean checkout of the oss-fuzz repository (expected to be at ../../oss-fuzz relative to most runner scripts).
2. Exporting configuration variables (like PROJECT, HARNESS, LABEL, paths to project-specific patches, and output directories).
3. Invoking the _run_fuzz_core.sh script, which then handles:
   • Applying an optional project-level patch (e.g., to add new fuzzer sources to tmux).
   • Building the OSS-Fuzz Docker image (if flagged).
   • Building the specified fuzzer(s) with the chosen sanitizer.
   • Executing the fuzzer for the configured duration (typically 4 hours).
   • Generating and exporting corpus and HTML coverage reports to the designated locations within the submission/ directory structure.

Running the Scripts: It's generally recommended to execute the runner scripts from the project's root directory to ensure correct relative path resolution for oss-fuzz/ and output directories.

1. Part 1: Baseline Evaluation (input-fuzzer) These scripts evaluate the existing input-fuzzer for tmux.

# From the project root directory:
./submission/part_1/run.w_corpus.sh  # Run input-fuzzer with default seed corpus
./submission/part_1/run.wo_corpus.sh # Run input-fuzzer without seed corpus

run.w_corpus.sh uses the default tmux build behavior regarding seeds. run.wo_corpus.sh applies submission/part_1/remove_seed_corpus.patch (via its local oss-fuzz.diff which would call out to this patch or integrate its changes) to the oss-fuzz/projects/tmux/build.sh to ensure no initial seed corpus is used. Coverage reports are exported to submission/part_1/report/w_corpus/ and submission/part_1/report/wo_corpus/ and submission/part_1/report/wo_corpus/ respectively.

2. Part 3: Fuzzer Improvements (input-fuzzer)

• Improvement 1 (argument-fuzzer): Targets arguments.c.

  root@kitploit:~

  # From the project root directory:
  ./submission/part_3/improve1/run.improve1.sh
  

• Improvement 2 (cmd-fuzzer): Targets cmd-parse.c and command execution.

  root@kitploit:~

  # From the project root directory:
  ./submission/part_3/improve2/run.improve2.sh
  

Each run.improveX.sh script applies its local oss-fuzz.diff and sets PROJECT_PATCH_FILE to its local project.diff (which adds the new fuzzer code to tmux and updates Makefile.am). Coverage reports are exported to the respective submission/part_3/improveX/coverage_improveX/ directories. The submission/part_3/coverage_noimprove/ directory contains baseline coverage from Part 1 for comparison.

3. Part 4: CVE-2020-27347 PoC Reproduction

# From the project root directory:
./submission/part_4/run.poc.sh

This script builds a dedicated Docker image (from submission/part_4/environment/Dockerfile) and tests tmux 3.1b (vulnerable) against the patched commit a868bac.

Key Findings and Results

(Detailed explanations, figures, and tables can be found in the full report.pdf)

Part 1 (Baseline - input-fuzzer)

• With default seed corpus: 14.00% line coverage (7281/51997 lines), 24.44% function coverage.
• Without seed corpus: 13.94% line coverage (7248/51997 lines), 24.31% function coverage.
• The impact of the initial seed corpus was minor for the existing input-fuzzer.
• Significant portions of tmux, notably argument parsing (arguments.c), command parsing/execution (cmd-parse.c, cmd-*.c), and client/server logic (client.c, server.c), were largely unexercised (e.g., arguments.c at ~5.8% line coverage).

Part 3 (Fuzzer Improvements)

• argument-fuzzer (targeting arguments.c): Achieved 66.62% line coverage for arguments.c, a substantial increase from the ~5.8% baseline.
• cmd-fuzzer (targeting command parsing & execution): Increased line coverage for cmd-parse.c to 42.58% (from ~27%) and function coverage to 77.78%.
• arguments.c coverage also rose to 45.54% through this fuzzer.
• cmd.c reached 39.14% line coverage.
• Achieved new or significantly improved coverage in various cmd-*.c modules (e.g., cmd-bind-key.c, cmd-set-options.c to 50% function coverage) and key-handling routines (key-string.c to 30% line coverage, key-bindings.c to 6.05% line coverage).

Part 4 (CVE-2020-27347 Analysis)

• Successfully reproduced CVE-2020-27347 (stack buffer overflow in SGR escape sequence parsing) on tmux 3.1b (commit 6a33a12) using the payload \033[::::::7::1:2:3::5:6:7:m.
• Confirmed that tmux commit a868bac (which includes the fix and leads to version 3.1c) was not susceptible to the crash.
• The vulnerability, exploitable by writing a crafted sequence to a pane TTY, leads to Denial of Service and has potential for Arbitrary Code Execution. It's rated high severity (CVSS 7.8).

Challenges Faced

• Ensuring correct tmux startup in a scripted Docker environment, particularly avoiding "not a terminal" errors, required using detached sessions for the CVE PoC.
• Managing the git state (ensuring full clones, clean resets before applying patches) across different test scenarios was critical for reproducible builds of specific tmux versions.
• Developing effective new fuzzing harnesses (argument-fuzzer, cmd-fuzzer) necessitated a good understanding of tmux's internal argument and command processing logic to target specific unexercised code paths.

Future Work

• Further enhance the cmd-fuzzer to cover a wider array of cmd-*.c modules, especially those dealing with complex state interactions like window, layout, or pane manipulations.
• Investigate fuzzing strategies for the tmux client-server communication protocol, potentially involving more complex environment mocking.
• Explore the use of structure-aware fuzzing for the tmux command language, possibly by leveraging grammar definitions from cmd-parse.y to generate more syntactically valid and complex command sequences.

Useful Links

• tmux Project
• OSS-Fuzz
• CVE-2020-27347
• Project Report PDF (Path relative to project root)