2b5577e25e
The `detect_stack_use_after_return=1` option in `ASAN_OPTIONS` set by the runner seemed to cause the fuzzer to not pick up any coverage. I'm not quite sure why this happens. Any guidance would be appreciated. The fuzzer seems stuck with this flag set: `python infra/helper.py run_fuzzer --corpus-dir ../corpus_xst_json/ xs xst_jsonparse -- seed=1` ``` INFO: seed corpus: files: 1728 min: 1b max: 131336b total: 336638b rss: 92Mb #64 pulse cov: 322 ft: 323 corp: 1/1b exec/s: 32 rss: 92Mb #128 pulse cov: 322 ft: 323 corp: 1/1b exec/s: 25 rss: 92Mb #256 pulse cov: 322 ft: 324 corp: 2/8b exec/s: 23 rss: 93Mb #512 pulse cov: 322 ft: 324 corp: 2/8b exec/s: 22 rss: 93Mb #1024 pulse cov: 322 ft: 324 corp: 2/8b exec/s: 22 rss: 93Mb ``` However disabling it seems to make progress, with the same command (note same seed and corpus). After rebuilding image with `detect_stack_use_after_return` disabled: `python infra/helper.py run_fuzzer --corpus-dir ../corpus_xst_json/ xs xst_jsonparse -- seed=1` ``` INFO: seed corpus: files: 1728 min: 1b max: 131336b total: 336638b rss: 92Mb #64 pulse cov: 485 ft: 500 corp: 29/55b exec/s: 32 rss: 93Mb #128 pulse cov: 574 ft: 673 corp: 70/239b exec/s: 25 rss: 93Mb #256 pulse cov: 749 ft: 1060 corp: 132/707b exec/s: 23 rss: 93Mb #512 pulse cov: 834 ft: 1560 corp: 214/1767b exec/s: 22 rss: 93Mb #1024 pulse cov: 953 ft: 2344 corp: 353/5213b exec/s: 22 rss: 93Mb ``` Setting `detect_stack_use_after_return=0` fixed it -- local runs picked up coverage with seed corpus, and even a couple of crashes. Until I work around this it would be preferable to gain some coverage, even if we don't detect `stack-use-after-return` for now. |
||
|---|---|---|
| .allstar | ||
| .github | ||
| docs | ||
| infra | ||
| projects | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .pylintrc | ||
| .style.yapf | ||
| 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 and Java/JVM 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 July 2022, OSS-Fuzz has found over 40,500 bugs in 650 open source projects.
Blog posts
- 2016-12-01 - Announcing OSS-Fuzz: Continuous fuzzing for open source software
- 2017-05-08 - OSS-Fuzz: Five months later, and rewarding projects
- 2018-11-06 - A New Chapter for OSS-Fuzz
- 2020-10-09 - Fuzzing internships for Open Source Software
- 2020-12-07 - Improving open source security during the Google summer internship program