'fuzzing' is a technique where APIs that accept untrusted input are fed random data. For projects written in memory-unsafe languages this can potentially catch buffer overflows and other out-of-bounds errors, for projects written in memory-safe languages it may catch missing error handling and DoS scenarios.

If you have experience with fuzzing tools for various ecosystems, please share them here.

oss-fuzz

website GitHub

Google runs a fuzzing programme that is open to open source projects and supports C/C++, Rust, Go, Python, Java/JVM, and JavaScript code. It relies on project-specific glue code (called 'fuzz targets') that passes the random data to the APIs that accept untrusted input. In their recommended 'ideal configuration' this glue code lives in the projects' code repository. However, many projects are reluctant to add such code - especially Java projects, as the library to integrate with the fuzzing infrastructure has an obscure license and relies on native code via JNI. For this reason the fuzz targets for most Java project live in the oss-fuzz GitHub repository, for example https://github.com/google/oss-fuzz/tree/master/projects/apache-commons-lang.

Once configured, Google periodically runs the targets with various random inputs, and creates issues in their issue tracker (with notifications to configured addresses) on certain error conditions.

Reproducing

The issues created in the oss-fuzz issue tracker contain a 'reproducer' file that is basically the raw input.

Unfortunately it can be rather hard to reproduce the issue in the project's own environment based on that raw input: you have to look at the individual test that filed and essentially reverse-engineer how the reproducer data is converted into inputs. For example, StringSubstitutorInterpolatorFuzzer just does "data.consumeRemainingAsString()" - so the file contents are just a single string. Others, like ImagingJpegFuzzer, have a single binary blob, so you can read the file as a byte array. For more complex ones, like UrlValidator2Fuzzer, are more difficult.

You can also use the rather heavyweight Docker-based oss-fuzz reproducer infrastructure, see https://google.github.io/oss-fuzz/advanced-topics/reproducing/.

Setup for Apache Commons

For the Apache Commons projects, notifications go to the private fuzz-testing@commons.a.o list. When an issue is starred, indicating someone thought it might be a legitimate issue, the notifications also go to security@commons.a.o (this is implemented using some custom logic in our mailinglist configurations).

Commons PMC members can log in to the issue tracker with security@commons.apache.org as username and the password that can be found in the Commons PMC private SVN repo.