5.4 KiB
Frequently Asked Questions
What kind of projects are you accepting?
We are currently in a beta status, and still working out issues in our service. At this point, we can only commit to supporting established projects that have a critical impact on infrastructure and user security. We will consider each request on a case-by-case basis, but some things we keep in mind are:
- Exposure to remote attacks (e.g. libraries that are used to process untrusted input)
- Number of users/other projects depending on this project.
We hope to relax this requirement in the future though, so keep an eye out even if we are not able to accept your project at this time!
Why do you use a different issue tracker for reporting bugs in OSS projects?
Security access control is important for the kind of issues that OSS-Fuzz detects. We will reconsider the Github issue tracker once the access control feature is available.
Why do you require an e-mail associated with a Google account?
The issue tracker uses Google accounts for authentication. Note that any e-mail address can be associated with a Google account.
Why do you use Docker?
Building fuzzers requires building your project with a fresh Clang compiler and special compiler flags. An easy-to-use Docker image is provided to simplify toolchain distribution. This also simplifies our support for a variety of Linux distributions and provides a reproducible and secure environment for fuzzer building and execution.
How do you handle timeouts and OOMs?
If a single input to a fuzz target requires more than ~25 seconds or more than 2GB RAM to process, we report this as a timeout or an OOM (out-of-memory) bug (examples: timeouts, OOMs). This may or may not be considered as a real bug by the project owners, but nevertheless we treat all timeouts and OOMs as bugs since they significantly reduce the efficiency of fuzzing.
Remember that fuzzing is executed with AddressSanitizer or other sanitizers which introduces a certain overhead in RAM and CPU.
We currently do not have a good way to deduplicate timeout or OOM bugs. So, we report only one timeout and only one OOM bug per fuzz target. Once that bug is fixed, we will file another one, and so on.
Currently we do not offer ways to change the memory and time limits.
Can I launch an additional process (e.g. a daemon) from my fuzz target?
No. In order to get all the benefits of in-process, coverage-guided fuzz testing, it is required to run everything inside a single process. Any child processes created outside the main process introduces heavy launch overhead and is not monitored for code coverage.
Another rule of thumb is: "the smaller fuzz target is, the better it is". It is expected that your project will have many fuzz targets to test different components, instead of a single fuzz target trying to cover everything. Think of fuzz target as a unit test, though it is much more powerful since it helps to test millions of data permutations rather than just one.
What if my fuzz target finds a bug in another project (dependency) ?
Every bug report has a crash stack-trace that shows where the crash happened. Using that, you can debug the root cause and see which category the bug falls in:
- If this is a bug is due to an incorrect usage of the dependent project's API in your project, then you need to fix your usage to call the API correctly.
- If this is a real bug in the dependent project, then you should CC the maintainers of that project on the bug. Once cced, they will get automatic access to all the information necessary to reproduce the issue. If this project is maintained in OSS-Fuzz, you can search for contacts in the respective project.yaml file.
What if my fuzzer does not find anything?
If your fuzz target is running for many days and does not find bugs or new coverage, it may mean several things:
- We've covered all reachable code. In order to cover more code we need more fuzz targets.
- The seed corpus is not good enough and the fuzzing engine(s) are not able to go deeper based on the existing seeds. Need to add more seeds.
- There is some crypto/crc stuff in the code that will prevent any fuzzing engine from going deeper, in which case the crypto should be disabled in fuzzing mode. Examples: openssl, boringssl
- It is also possible that the fuzzer is running too slow (you may check the speed of your targets at https://oss-fuzz.com/)
In either case, look at the coverage reports for your target(s) and figure out why some parts of the code are not covered.
Does OSS-Fuzz support AFL?
OSS-Fuzz uses AFL as one of its fuzzing engines but this is an implementation detail. Just follow the ideal integration guide and OSS-Fuzz will use all its fuzzing engines on your code.