Template repository for the Fuzzing Competition
- Fork this template repo (keep it private to avoid integrity disputes)
- Give
dylanjwolffaccess to your Github repository - Fill out the Google Form
- Make changes to your fuzzer (include all new files/dependencies in the Dockerfile) -- DO NOT change the name of
fuzzer.py - Check that the CI job passes for your changes
- Cut a
tar.gzrelease on Github to have it included in the next benchmarking run
https://nus-fuzzing-hackathon-2024.github.io/
Please make sure to enable the CI job to check that your fuzzer is working properly:
- On the forked repo Github web interface, navigate to:
Settings → Actions → General → Workflow Permissions - Select “Read and write permissions”, then click “Save”
- Verify CI job is enabled by making a small commit (such as changing the team name in the README.md file)
We are using Python 3.10 in the evaluation environment.
Install all Python package dependencies needed by the Fuzzing Book baseline fuzzer with:
pip install -r requirements.txt
You may want to do this in a Python virtual environment to avoid global dependency conflicts.
The fuzzer expects a file named bug.py to be in the same directory as the fuzzer file (fuzzer.py).
DO NOT RENAME THE FUZZER FILE -- the competition infrastructure will run python fuzzer.py to start your fuzzer.
The bug.py file will have two functions: an entrypoint that is fuzzed by the fuzzer and get_initial_corpus function which returns a list of initial inputs for the fuzzer.
Several example bugs are included in the examples directory.
To run the fuzzer on an example bug, copy e.g. examples/1/bug.py to the base directory of this repository before running the fuzzer with the command above.
I.e.:
cp examples/1/bug.py .
python fuzzer.py
Whether or not the bug has been triggered will be detected by the competition infrastructure; no need to implement a special exception handler or detection mechanism yourself. In these examples, finding the bug is indicated by the fuzzer exiting with a particular exit code (219). The detection method will be different in the competition, so don't search the program for a particular exit code etc. to find the bug location.
Below are some sample ideas for fuzzer implementations (not exhaustive!). Entries marked with a '†' are options we believe will be more straightforward to implement.
Coverage Feedback
- Be Sensitive and Collaborative: Analyzing Impact of Coverage Metrics in Greybox Fuzzing (Many good options in this paper!) †
Mutation Strategy
- MOPT: Optimize Mutation Scheduling for Fuzzers †
- FairFuzz: A Targeted Mutation Strategy for Increasing Greybox Fuzz Testing Coverage
Comparison Instrumentation and Branch Distance
- REDQUEEN: Fuzzing with Input-to-State Correspondence †
- Laf-Intel: Circumventing Fuzzing Roadblocks with Compiler Transformations †
Gradient Descent Fuzzing
- Angora: Efficient Fuzzing by Principled Search (Section 3.4)
Taint Analysis or Dataflow Guided Fuzzing
Inference-Based:
Propagation-Based:
The Fuzzing Book gives an intro and some scaffolding code for dataflow analysis, but we are not interested in command injection specifically for the competition micro-benchmarks. You would instead need to find a way to leverage dataflow analysis to cover additional conditional branches within the benchmark programs.
Concolic Execution (White Box Fuzzing / Dynamic Symbolic Execution)
Improve the Fuzzing Book white box fuzzer!
Hybrid Fuzzing
Combine the fuzzing book implementations of Concolic and Greybox fuzzers!