Home

Awesome

OSS-Fuzz integrated with AFLGo for Patch Testing

  1. Install Docker (Ubuntu 16.04): Follow instructions in Step.1 and Step.2 <a href="https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-16-04" target="_blank">here</a> or <a href="https://docs.docker.com/engine/installation/" target="_blank">here</a>.
  2. Prepare the Docker infrastructure:
# Checkout our integration
git clone https://github.com/aflgo/oss-fuzz.git
OSS=$PWD/oss-fuzz

# Build necessary Docker images. Meanwhile, go have a coffee ☕️
cd oss-fuzz
infra/base-images/all.sh
  1. Let us take the <a href="http://www.darwinsys.com/file/" target="_blank">file</a>-utility as subject and focus on commit <a href="https://github.com/file/file/commit/69928a2" target="_blank">69928a2</a>.
subject=file
commit=69928a2

# Compile the version of file after commit 69928a2
cd $OSS
infra/helper.py build_fuzzers --engine aflgo -c $commit $subject

# Find the compiled binary in the "build" directory. 
ls build/out/$subject/$commit

  1. If the directory $OSS/build/out/$subject/$commit contains the file distance.cfg.txt, the instrumentation was successful. The instrumentation may be unsuccessful i) if the commit changes only non-executable lines (e.g., comments), ii) or if the compilation of that version fails. Sometimes older versions cannot be built.

  2. Let's try to compile the binaries for the 100 most recent code-changing commits of the <a href="http://www.darwinsys.com/file/" target="_blank">file</a>-utility.

# Checkout the subject program
git clone https://github.com/file/file.git
SUBJECT=$PWD/file

# Find 100 most recent code-changing commits
cd $SUBJECT
COMMITS=$(git log --pretty=format:"%h" -- "*.c" | head -n 100)

# Build subject binaries for those commits
# Make sure you have enough cores. Otherwise build in batches.
cd $OSS
for commit in $COMMITS; do 

  # Build in detached mode (-d)
  infra/helper.py build_fuzzers -d --engine aflgo -c $commit $subject
  sleep 10
  
done
  1. Let's start an instance of AFLGo for commit <a href="https://github.com/file/file/commit/69928a2" target="_blank">69928a2</a>.
subject=file
commit=69928a2
testdriver=magic_fuzzer

# Checkout AFLGo
git clone https://github.com/aflgo/aflgo.git
AFLGO=$PWD/aflgo
cd aflgo && make && cd ..

# Prepare seed corpus for file-utility
mkdir in
find $AFLGO/testcases/ -type f -exec cp {} in \;

# Run the fuzzer
# * We set the exponential annealing-based power schedule (-z exp).
# * We set the time-to-exploitation to 45min (-c 45m), assuming the fuzzer is run for about an hour.
$AFLGO/afl-fuzz -S $commit -i in -o out -m none -z exp -c 45m \
       $OSS/build/out/$subject/$commit/$testdriver
  1. Let's run AFLGo on all successfully instrumented commits simultaneously, sharing the same queue. Make sure that you have enough cores. Otherwise, e.g., COMMITS=$(echo "$COMMITS" | head -n$(nproc)).
COMMITS=$(find $OSS/build/out/$subject/* -name "distance*" | grep -v master | rev | cut -d/ -f2 | rev)

for commit in $COMMITS; do 
  $AFLGO/afl-fuzz -S $commit -i in -o out -m none -z exp -c 45m \
         $OSS/build/out/$subject/$commit/$testdriver >/dev/null &
  sleep 2
done
  1. Let's check how our fuzzers are doing. You can kill all instances using pkill afl.
$AFLGO/afl-whatsup out
  1. You can find all subjects that have been integrated into OSS-Fuzz <a href="https://github.com/google/oss-fuzz/tree/master/projects" target="_blank">here</a>. The corresponding repo can often be found in the project's Dockerfile.
ls $OSS/projects
tail $OSS/projects/file/Dockerfile

OSS-Fuzz - Continuous Fuzzing for Open Source Software

Status: Beta. We are now accepting applications from widely-used open source projects.

FAQ | Ideal Fuzzing Integration | New Project Guide | Reproducing Bugs | Projects | Projects Issue Tracker | Glossary

Create New Issue for questions or feedback about OSS-Fuzz.

Introduction

Fuzz testing is a well-known technique for uncovering various kinds of programming errors in software. Many of these detectable errors (e.g. buffer overflow) can have serious security implications.

We successfully deployed guided in-process fuzzing of Chrome components and found hundreds of security vulnerabilities and stability bugs. We now want to share the experience and the service with the open source community.

In cooperation with the Core Infrastructure Initiative, OSS-Fuzz aims to make common open source software more secure and stable by combining modern fuzzing techniques and scalable distributed execution.

At the first stage of the project we use libFuzzer with Sanitizers. More fuzzing engines will be added later. ClusterFuzz provides a distributed fuzzer execution environment and reporting.

Currently OSS-Fuzz supports C and C++ code (other languages supported by LLVM may work too).

Process Overview

diagram

The following process is used for projects in OSS-Fuzz:

<!-- NOTE: this anchor is referenced by oss-fuzz blog post -->

Accepting New Projects

To be accepted to OSS-Fuzz, an open-source project must have a significant user base and/or be critical to the global IT infrastructure. To submit a new project:

Bug Disclosure Guidelines

Following Google's standard disclosure policy OSS-Fuzz will adhere to following disclosure principles:

More Documentation

Build Status

This page gives the latest build logs for each project.

Trophies

This page gives a list of publicly-viewable fixed bugs found by OSS-Fuzz.

References