dee1595fdf
@jonathanmetzman proposed a great idea about saving the machine state just before compiling the fuzz target so that we can compile different fuzz targets from that state later without having to go through the earlier commands. This is particularly beneficial for `OSS-Fuzz-Gen`. This PR is an (incomplete) PoC at that. Ideally, we: 1. [ ] Replace the fuzz target compilation command and all commands after it with no-ops, 2. [x] Save them into a script (e.g., `$SRC/re-run.sh`), and 3. [x] Push the resulting image for later reuse. In this way, we can reuse the image later by swapping the fuzz target source code and executing `$SRC/re-run.sh`. The script in the PR can do 2, but not 1. This might be OK already because steps in 1 are normally at the end, and there is unlikely any check to prevent them, but ideally, we should do 1, too. To test this locally: ```bash python infra/helper.py build_image libiec61850 docker run -ti --entrypoint=/bin/bash gcr.io/oss-fuzz/libiec61850 (in container) compile cat /src/re-run.sh ``` |
||
|---|---|---|
| .allstar | ||
| .clusterfuzzlite | ||
| .github | ||
| docs | ||
| infra | ||
| projects | ||
| tools/vscode-extension | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .pylintrc | ||
| .style.yapf | ||
| CITATION.cff | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
README.md
OSS-Fuzz: Continuous Fuzzing for Open Source Software
Fuzz testing is a well-known technique for uncovering programming errors in software. Many of these detectable errors, like buffer overflow, can have serious security implications. Google has found thousands of security vulnerabilities and stability bugs by deploying guided in-process fuzzing of Chrome components, and we now want to share that service with the open source community.
In cooperation with the Core Infrastructure Initiative and the OpenSSF, OSS-Fuzz aims to make common open source software more secure and stable by combining modern fuzzing techniques with scalable, distributed execution. Projects that do not qualify for OSS-Fuzz (e.g. closed source) can run their own instances of ClusterFuzz or ClusterFuzzLite.
We support the libFuzzer, AFL++, and Honggfuzz fuzzing engines in combination with Sanitizers, as well as ClusterFuzz, a distributed fuzzer execution environment and reporting tool.
Currently, OSS-Fuzz supports C/C++, Rust, Go, Python, Java/JVM, and JavaScript code. Other languages supported by LLVM may work too. OSS-Fuzz supports fuzzing x86_64 and i386 builds.
Overview
Documentation
Read our detailed documentation to learn how to use OSS-Fuzz.
Trophies
As of August 2023, OSS-Fuzz has helped identify and fix over 10,000 vulnerabilities and 36,000 bugs across 1,000 projects.
Blog posts
- 2023-08-16 - AI-Powered Fuzzing: Breaking the Bug Hunting Barrier
- 2023-02-01 - Taking the next step: OSS-Fuzz in 2023
- 2022-09-08 - Fuzzing beyond memory corruption: Finding broader classes of vulnerabilities automatically
- 2021-12-16 - Improving OSS-Fuzz and Jazzer to catch Log4Shell
- 2021-03-10 - Fuzzing Java in OSS-Fuzz
- 2020-12-07 - Improving open source security during the Google summer internship program
- 2020-10-09 - Fuzzing internships for Open Source Software
- 2018-11-06 - A New Chapter for OSS-Fuzz
- 2017-05-08 - OSS-Fuzz: Five months later, and rewarding projects
- 2016-12-01 - Announcing OSS-Fuzz: Continuous fuzzing for open source software