oss-fuzz/README.md

129 lines
6.0 KiB
Markdown
Raw Normal View History

2016-10-27 21:13:15 +00:00
# oss-fuzz - continuous fuzzing of open source software
2016-09-14 16:44:10 +00:00
2016-10-25 21:36:24 +00:00
> *Status*: Beta. We are preparing the project for the first public release. Documentation and smoothing the process is our main priority.
2016-09-14 16:44:10 +00:00
2016-10-25 23:36:29 +00:00
[FAQ](docs/faq.md)
2016-10-26 18:16:30 +00:00
| [New Target Guide](docs/new_target.md)
2016-10-26 18:49:53 +00:00
| [Reproducing](docs/reproducing.md)
2016-10-25 23:52:27 +00:00
| [Targets List](targets/README.md)
2016-11-04 23:03:00 +00:00
| [Targets issue tracker](https://bugs.chromium.org/p/oss-fuzz/issues/list)
2016-10-17 19:59:36 +00:00
2016-10-25 21:36:06 +00:00
[Create New Issue](https://github.com/google/oss-fuzz/issues/new) for questions or feedback.
2016-10-25 21:33:39 +00:00
2016-10-25 21:31:45 +00:00
## Goals
Oss-fuzz aims to make common open source software more secure by
combining modern white-box fuzzing techniques together with scalable
2016-10-26 01:21:41 +00:00
distributed execution.
2016-10-25 21:31:45 +00:00
At the first stage of the project we plan to combine
[libFuzzer](http://llvm.org/docs/LibFuzzer.html) with various `clang`
[sanitizers](https://github.com/google/sanitizers).
[ClusterFuzz](https://blog.chromium.org/2012/04/fuzzing-for-security.html)
provides distributed fuzzer execution environment and reporting.
## Background
[Fuzz testing](https://en.wikipedia.org/wiki/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](http://llvm.org/docs/LibFuzzer.html)
to do [guided in-process fuzzing of Chrome components](https://security.googleblog.com/2016/08/guided-in-process-fuzzing-of-chrome.html)
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
2016-10-25 21:49:25 +00:00
tracker](https://bugs.chromium.org/p/oss-fuzz/issues/list).
[Example issue](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9).
2016-10-25 23:40:47 +00:00
([Why different tracker?](docs/faq.md#why-do-you-use-a-different-issue-tracker-for-reportig-bugs-in-fuzz-targets))
2016-10-27 21:05:31 +00:00
- if the target has a defined process for reporting security issues,
2016-10-25 21:59:45 +00:00
we will follow it, otherwise we will cc target engineers on an issue.
- engineers fix the issue and land the fix upstream.
2016-10-25 21:31:45 +00:00
- fuzzing infrastructure automatically verifies the fix, adds a comment and
closes the issue.
2016-11-14 19:33:25 +00:00
- after 7 days has passed since the issue is fixed or after 90 days since reporting has passed, the issue
2016-10-25 21:31:45 +00:00
becomes *public*.
2016-10-25 21:49:25 +00:00
The following table summarizes issue visibility through the process:
| Issue State | Visibility |
|----------|------------|
| New | oss-fuzz engineers |
2016-10-26 01:24:42 +00:00
| Reported | oss-fuzz engineers + everyone CC'ed on the bug |
2016-10-25 21:49:25 +00:00
| Fixed & Verified | public |
| Lapsed (90 days since report) | public |
2016-10-25 21:31:45 +00:00
## Accepting New Targets
2016-10-27 21:05:31 +00:00
In order to be accepted to oss-fuzz, an open-source target must
2016-10-26 01:34:38 +00:00
have a significant user base and/or be critical to the global IT infrastructure.
2016-10-25 21:31:45 +00:00
To submit a new target to oss-fuzz:
2016-10-26 18:47:04 +00:00
- create a pull request with a change to [targets/README.md](targets/README.md) providing the following information:
2016-10-27 21:05:31 +00:00
* target home site and details
2016-10-25 21:31:45 +00:00
* source code repository location
2016-10-27 21:05:31 +00:00
* a link to target security issue reporting process *OR*
2016-10-25 21:31:45 +00:00
* an e-mail of the engineering contact person to be CCed on issue. This
2016-10-25 21:58:44 +00:00
has to be an e-mail with google account that belongs to an
2016-10-27 21:05:31 +00:00
established target committer (according to VCS logs).
2016-10-25 22:01:11 +00:00
If this is not you or address differs from VCS, an informal e-mail verification will be required.
2016-10-25 23:52:27 +00:00
This e-mail will also be publicly listed in our [Targets](targets/README.md)
2016-10-25 21:31:45 +00:00
page.
2016-10-25 23:36:29 +00:00
- once accepted by an oss-fuzz project member, follow the [New Target Guide](docs/new_target.md)
2016-10-25 21:31:45 +00:00
to write the code.
2016-10-26 01:39:20 +00:00
## Bug Disclosure Guidelines
2016-10-25 21:31:45 +00:00
Following Google's standard [disclosure policy](https://googleprojectzero.blogspot.com/2015/02/feedback-and-data-driven-updates-to.html)
oss-fuzz will adhere to following disclosure principles:
2016-10-25 23:36:29 +00:00
- **90-day deadline**. After notifying target authors, we will open reported
2016-10-25 21:31:45 +00:00
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
2016-10-25 23:36:29 +00:00
will expire but upstream engineers let us know before the deadline that a
2016-10-25 21:31:45 +00:00
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.
2016-09-14 16:44:10 +00:00
## Documentation
2016-10-25 23:36:29 +00:00
* [New Target Guide](docs/new_target.md) walks through steps necessary to add new targets to oss-fuzz.
2016-09-27 18:59:07 +00:00
* [Running and Building Fuzzers](docs/building_running_fuzzers.md) documents the process for fuzzers that are
2016-10-27 21:05:31 +00:00
*part of target* source code repository.
2016-09-27 18:59:07 +00:00
* [Running and Building External Fuzzers](docs/building_running_fuzzers_external.md) documents the process for fuzzers that are
*part of oss-fuzz* source code repository.
* [Fuzzer execution environment](docs/fuzzer_environment.md) documents the
environment under which your fuzzers will be run.
2016-10-25 23:52:27 +00:00
* [Targets List](targets/README.md) lists OSS targets added to oss-fuzz.
2016-10-19 17:53:00 +00:00
* [Chrome's Efficient Fuzzer Guide](https://chromium.googlesource.com/chromium/src/testing/libfuzzer/+/HEAD/efficient_fuzzer.md)
while contains some chrome-specifics, is an excellent documentation on making your fuzzer better.
2016-09-14 16:44:10 +00:00
2016-10-08 01:28:27 +00:00
## Build status
[This page](https://oss-fuzz-build-logs.storage.googleapis.com/status.html)
gives the latest build logs for each target.
2016-10-08 01:28:27 +00:00
2016-10-26 03:44:34 +00:00
## Trophies
2016-10-06 21:02:52 +00:00
2016-10-26 03:44:34 +00:00
[This page](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=status%3AFixed%2CVerified+Type%3ABug%2CBug-Security+-component%3AInfra+)
gives a list of publically viewable (fixed) bugs found by oss-fuzz.
2016-10-06 21:02:52 +00:00
2016-09-14 16:44:10 +00:00
## References
2016-10-17 23:40:10 +00:00
* [libFuzzer documentation](http://libfuzzer.info)
* [libFuzzer tutorial](http://tutorial.libfuzzer.info)
2016-10-19 17:52:02 +00:00
* [Chromium Fuzzing Page](https://chromium.googlesource.com/chromium/src/testing/libfuzzer/)
2016-09-14 16:44:10 +00:00