5.9 KiB
oss-fuzz
Fuzzing 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 | 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 project 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 project 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 and provide the following information:
- project site and details
- source code repository location
- a link to the project 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 project 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 project 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.