15 KiB

Raw Blame History

Setting up a New Project

Prerequisites

Integrate one or more Fuzz Targets with the project you want to fuzz.
Examples: boringssl, SQLite, s2n, openssl, FreeType, re2, harfbuzz, pcre2, ffmpeg.
Install Docker. (Why Docker?)

Overview

To add a new OSS project to OSS-Fuzz, you need a project subdirectory inside the projects/ directory in OSS-Fuzz repository. Example: boringssl project is located in projects/boringssl.

The project directory needs to contain the following three configuration files:

projects/<project_name>/project.yaml - provides metadata about the project.
projects/<project_name>/Dockerfile - defines the container environment with information on dependencies needed to build the project and its fuzz targets.
projects/<project_name>/build.sh - build script that executes inside the container and generates project build.

To automatically create a new directory for your project and generate templated versions of these configuration files, run the following set of commands:

$ cd /path/to/oss-fuzz
$ export PROJECT_NAME=<project_name>
$ python infra/helper.py generate $PROJECT_NAME

It is preferred to keep and maintain fuzz targets in your own source code repository. If this is not possible due to various reasons, you can store them inside the OSS-Fuzz's project directory created above.

project.yaml

This file stores the metadata about your project. The following attributes are supported:

homepage

Project's homepage.

primary_contact, auto_ccs

Primary contact and CCs list. These people get access to ClusterFuzz which includes crash reports, fuzzer statistics, etc and are auto-cced on newly filed bugs in OSS-Fuzz tracker.

sanitizers (optional)

List of sanitizers to use. By default, it will use the default list of supported sanitizers (currently - "address", "undefined").

If your project does not build with a particular sanitizer configuration and you need some time fixing it, then you can use this option to override the defaults temporarily. E.g. For disabling UndefinedBehaviourSanitizer build, then you can just specify all supported sanitizers, except "undefined".

MemorySanitizer ("memory") is also supported, but is not enabled by default due to likelihood of false positives. For this to work, ensure that your project's runtime dependencies are listed in this file. You may opt-in by adding "memory" to this list.

If you want to test a particular sanitizer (e.g. memory) and see what crashes it generates without filing them in the issue tracker, you can set the experimental flag. The crashes can be accessed on ClusterFuzz homepage. Example:

sanitizers:
 - address
 - memory:
    experimental: True
 - undefined

Example: boringssl.

help_url

Link to a custom help URL in bug reports instead of the default OSS-Fuzz guide to reproducing crashes. This can be useful if you assign bugs to members of your project unfamiliar with OSS-Fuzz or if they should follow a different workflow for reproducing and fixing bugs than standard one outlined in the reproducing guide.

Example: skia.

experimental

A boolean (either True or False) that indicates whether this project is in evaluation mode. This allows a project to be fuzzed and generate crash findings, but not file them in the issue tracker. The crashes can be accessed on ClusterFuzz homepage. This should be only used if you are not a maintainer of the project and have less confidence in the efficacy of your fuzz targets. Example:

homepage: "{project_homepage}"
primary_contact: "{primary_contact}"
auto_ccs:
  - "{auto_cc_1}"
  - "{auto_cc_2}"
sanitizers:
  - address
  - memory
  - undefined
help_url: "{help_url}"  
experimental: True

Dockerfile

This file defines the Docker image definition. This is where the build.sh script will be executed in. It is very simple for most projects:

FROM gcr.io/oss-fuzz-base/base-builder    # base image with clang toolchain
MAINTAINER YOUR_EMAIL                     # maintainer for this file
RUN apt-get update && apt-get install -y ... # install required packages to build your project
RUN git clone <git_url> <checkout_dir>    # checkout all sources needed to build your project
WORKDIR <checkout_dir>                    # current directory for build script
COPY build.sh fuzzer.cc $SRC/             # copy build script and other fuzzer files in src dir

Expat example: expat/Dockerfile

In the above example, the git clone will check out the source to $SRC/<checkout_dir>.

build.sh

This file describes how to build binaries for fuzz targets in your project. The script will be executed within the image built from Dockerfile.

In general, this script will need to:

Build the project using your build system with correct compiler and its flags provided as environment variables (see below).
Build the fuzz targets, linking your project's build and libFuzzer. Resulting binaries should be placed in $OUT.

Note:

Please don't assume that the fuzzing engine is libFuzzer and hardcode in your build scripts. We generate builds for both libFuzzer and AFL fuzzing engine configurations. So, link the fuzzing engine using $LIB_FUZZING_ENGINE, see example below.
Please make sure that the binary names for your fuzz targets contain only alphanumeric characters, underscore(_) or dash(-). Otherwise, they won't run on our infrastructure.

For expat, this looks like this:

#!/bin/bash -eu

./buildconf.sh
# configure scripts usually use correct environment variables.
./configure

make clean
make -j$(nproc) all

$CXX $CXXFLAGS -std=c++11 -Ilib/ \
    $SRC/parse_fuzzer.cc -o $OUT/parse_fuzzer \
    $LIB_FUZZING_ENGINE .libs/libexpat.a

cp $SRC/*.dict $SRC/*.options $OUT/

build.sh Script Environment

When build.sh script is executed, the following locations are available within the image:

Location	Env	Description
`/out/`	`$OUT`	Directory to store build artifacts (fuzz targets, dictionaries, options files, seed corpus archives).
`/src/`	`$SRC`	Directory to checkout source files
`/work/`	`$WORK`	Directory for storing intermediate files

While files layout is fixed within a container, the environment variables are provided to be able to write retargetable scripts.

Requirements

Only binaries without any extension will be accepted as targets. Extensions are reserved for other artifacts like .dict, etc.

You must use the special compiler flags needed to build your project and fuzz targets. These flags are provided in the following environment variables:

Env Variable	Description
`$CC`, `$CXX`, `$CCC`	The C and C++ compiler binaries.
`$CFLAGS`, `$CXXFLAGS`	C and C++ compiler flags.
`$LIB_FUZZING_ENGINE`	C++ compiler argument to link fuzz target against the prebuilt engine library (e.g. libFuzzer).

You must use $CXX as a linker, even if your project is written in pure C.

Most well-crafted build scripts will automatically use these variables. If not, pass them manually to the build tool.

See Provided Environment Variables section in base-builder image documentation for more details.

Disk space restrictions

Our builders have a disk size of 70GB (this includes space taken up by the OS). Builds must keep peak disk usage below this.

In addition to this, please keep the size of the build (everything copied to $OUT) small (<10GB uncompressed) -- this will need be repeatedly transferred and unzipped during fuzzing and run on VMs with limited disk space.

Fuzzer execution environment

This page gives information about the environment that your fuzz targets will run on ClusterFuzz, and the assumptions that you can make.

Testing locally

Use the helper script to build docker image and fuzz targets.

$ cd /path/to/oss-fuzz
$ python infra/helper.py build_image $PROJECT_NAME
$ python infra/helper.py build_fuzzers --sanitizer <address/memory/undefined> $PROJECT_NAME

This should place the built binaries into /path/to/oss-fuzz/build/out/$PROJECT_NAME directory on your machine (and $OUT in the container).

Note: You must run these fuzz target binaries inside the base-runner docker container to make sure that they work properly:

$ python infra/helper.py check_build $PROJECT_NAME

Please fix any failures pointed by the check_build command above. To test changes against a particular fuzz target, run using:

$ python infra/helper.py run_fuzzer $PROJECT_NAME <fuzz_target>

If everything works locally, then it should also work on our automated builders and ClusterFuzz. If it fails, check out this entry.

It's recommended to look at code coverage as a sanity check to make sure that fuzz target gets to the code you expect.

$ python infra/helper.py build_fuzzers --sanitizer coverage $PROJECT_NAME
$ python infra/helper.py coverage $PROJECT_NAME <fuzz_target>

Note: Currently, we only support AddressSanitizer (address) and UndefinedBehaviorSanitizer (undefined) configurations. MemorySanitizer is in development mode and not recommended for use. Make sure to test each of the supported build configurations with the above commands (build_fuzzers -> run_fuzzer -> coverage).

Debugging Problems

Debugging document lists ways to debug your build scripts or fuzz targets in case you run into problems.

Custom libFuzzer options for ClusterFuzz

By default, ClusterFuzz will run your fuzzer without any options. You can specify custom options by creating a my_fuzzer.options file next to a my_fuzzer executable in $OUT:

[libfuzzer]
close_fd_mask = 3
only_ascii = 1

List of available options. Use of max_len is not recommended as other fuzzing engines may not support that option. Instead, if you need to strictly enforce the input length limit, add a sanity check to the beginning of your fuzz target:

if (size < kMinInputLength || size > kMaxInputLength)
  return 0;

For out of tree fuzz targets, you will likely add options file using docker's COPY directive and will copy it into output in build script. (example: woff2).

Seed Corpus

OSS-Fuzz uses evolutionary fuzzing algorithms. Supplying seed corpus consisting of good sample inputs is one of the best ways to improve fuzz target's coverage.

To provide a corpus for my_fuzzer, put my_fuzzer_seed_corpus.zip file next to the fuzz target's binary in $OUT during the build. Individual files in this archive will be used as starting inputs for mutations. You can store the corpus next to source files, generate during build or fetch it using curl or any other tool of your choice. (example: boringssl).

Seed corpus files will be used for cross-mutations and portions of them might appear in bug reports or be used for further security research. It is important that corpus has an appropriate and consistent license.

Dictionaries

Dictionaries hugely improve fuzzing efficiency for inputs with lots of similar sequences of bytes. libFuzzer documentation

Put your dict file in $OUT. If the dict filename is the same as your target binary name (i.e. %fuzz_target%.dict), it will be automatically used. If the name is different (e.g. because it is shared by several targets), specify this in .options file:

[libfuzzer]
dict = dictionary_name.dict

It is common for several fuzz targets to reuse the same dictionary if they are fuzzing very similar inputs. (example: expat).

Checking in to OSS-Fuzz repository

Fork OSS-Fuzz, commit and push to the fork, and then create a pull request with your change! Follow the Forking Project guide if you are new to contributing via GitHub.

Copyright headers

Please include copyright headers for all files checked in to oss-fuzz:

# Copyright 2018 Google Inc.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
################################################################################

If you are porting a fuzz target from Chromium, keep the original Chromium license header.

The end

Once your change is merged, your project and fuzz targets should be automatically built and run on ClusterFuzz after a short while (< 1 day)!

Check your project's build status here.

Use ClusterFuzz web interface here to checkout the following items:

Crashes generated
Code coverage statistics
Fuzzer statistics
Fuzzer performance analyzer (linked from fuzzer statistics)

15 KiB Raw Blame History