OSS-Fuzz - continuous fuzzing for open source software.

fuzzing fuzz-testing oss-fuzz security stability starred-google-repo starred-repo vulnerabilities

Go to file

Mike Aizatsky e16f0a65fa Rename http.options to curl_fuzzer.options		2016-10-28 15:29:04 -07:00
docs	Update new_target.md	2016-10-28 15:26:02 -07:00
infra	[infra] adding zip to the image, since corpus files should be zips	2016-10-28 15:24:34 -07:00
targets	Rename http.options to curl_fuzzer.options	2016-10-28 15:29:04 -07:00
.gitignore	Implement a helper script.	2016-09-01 16:37:12 -07:00
CONTRIBUTING	Create CONTRIBUTING	2016-10-12 13:26:26 -07:00
LICENSE	Create LICENSE	2016-10-03 12:24:25 -07:00
README.md	Update README.md	2016-10-27 14:13:15 -07:00

README.md

oss-fuzz - continuous fuzzing of open source software

Status: Beta. We are preparing the project for the first public release. Documentation and smoothing the process is our main priority.

FAQ | New Target Guide | Reproducing | Targets List

Create New Issue for questions or feedback.

Goals

Oss-fuzz aims to make common open source software more secure by combining modern white-box fuzzing techniques together with scalable distributed execution.

At the first stage of the project we plan to combine libFuzzer with various clang sanitizers. ClusterFuzz provides distributed fuzzer execution environment and reporting.

Background

Fuzz testing is a well-known technique for uncovering certain types of programming errors in software. Many detectable errors (e.g. buffer overruns) have real security implications.

Our previous experience applying libFuzzer to do guided in-process fuzzing of Chrome components has proved very successful.

Process Overview

The following process is used for targets in oss-fuzz:

a target is accepted to oss-fuzz.
oss-fuzz build server build target fuzzers regularly and submits them to ClusterFuzz for execution.
ClusterFuzz continuously executes target fuzzers
when fuzzing uncovers an issue, ClusterFuzz creates an internal testcase.
issues are automatically triaged and filed in the oss-fuzz testcase issue tracker. Example issue. (Why different tracker?)
if the target has a defined process for reporting security issues, we will follow it, otherwise we will cc target engineers on an issue.
engineers fix the issue and land the fix upstream.
fuzzing infrastructure automatically verifies the fix, adds a comment and closes the issue.
after the issue is fixed or after 90 days since reporting has passed, the issue becomes public.

The following table summarizes issue visibility through the process:

Issue State	Visibility
New	oss-fuzz engineers
Reported	oss-fuzz engineers + everyone CC'ed on the bug
Fixed & Verified	public
Lapsed (90 days since report)	public

Accepting New Targets

In order to be accepted to oss-fuzz, an open-source target must have a significant user base and/or be critical to the global IT infrastructure.

To submit a new target to oss-fuzz:

create a pull request with a change to targets/README.md providing the following information:
- target home site and details
- source code repository location
- a link to target security issue reporting process OR
- an e-mail of the engineering contact person to be CCed on issue. This has to be an e-mail with google account that belongs to an established target committer (according to VCS logs). If this is not you or address differs from VCS, an informal e-mail verification will be required. This e-mail will also be publicly listed in our Targets page.
once accepted by an oss-fuzz project member, follow the New Target Guide to write the code.

Bug Disclosure Guidelines

Following Google's standard disclosure policy oss-fuzz will adhere to following disclosure principles:

90-day deadline. After notifying target authors, we will open reported issues in 90 days, or sooner if the fix is released.
Weekends and holidays. If a deadline is due to expire on a weekend or US public holiday, the deadline will be moved to the next normal work day.
Grace period. We will have a 14-day grace period. If a 90-day deadline will expire but upstream engineers let us know before the deadline that a patch is scheduled for release on a specific day within 14 days following the deadline, the public disclosure will be delayed until the availability of the patch.

Documentation

New Target Guide walks through steps necessary to add new targets to oss-fuzz.
Running and Building Fuzzers documents the process for fuzzers that are part of target source code repository.
Running and Building External Fuzzers documents the process for fuzzers that are part of oss-fuzz source code repository.
Targets List lists OSS targets added to oss-fuzz.
Chrome's Efficient Fuzzer Guide while contains some chrome-specifics, is an excellent documentation on making your fuzzer better.