1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
---
layout: default
title: FAQ
has_children: true
nav_order: 7
permalink: /faq/
---
# Frequently Asked Questions
- TOC
{:toc}
---
## Where can I learn more about fuzzing?
We recommend reading [libFuzzer tutorial] and the other docs in [google/fuzzing]
repository. These and some other resources are listed on the
[useful links]({{ site.baseurl }}/reference/useful-links/#tutorials) page.
[google/fuzzing]: https://github.com/google/fuzzing/tree/master/docs
[libFuzzer tutorial]: https://github.com/google/fuzzing/blob/master/tutorial/libFuzzerTutorial.md
## What kind of projects are you accepting?
We accept 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!
## How can I find potential fuzz targets in my open source project?
You should look for places in your code that:
- consume un-trusted data from users or from the network.
- consume complex data input or event if it's 'trusted'.
- use an algorithm that has two or more implementations
(to verify their equivalence).
- look for existing fuzz target [examples](https://github.com/google/oss-fuzz/tree/master/projects)
and find similarities.
## My project is not open source. Can I use OSS-Fuzz?
You cannot use OSS-Fuzz, but you can use [ClusterFuzz] which OSS-Fuzz is based
on. ClusterFuzz is an open-source fuzzing infrastructure that you can deploy in
your own environment and run continuously at scale.
OSS-Fuzz is a production instance of ClusterFuzz, plus the code living in
[OSS-Fuzz repository]: build scripts, `project.yaml` files with contacts, etc.
[ClusterFuzz]: https://github.com/google/clusterfuzz
[OSS-Fuzz repository]: https://github.com/google/oss-fuzz
## Why do you use a [different issue tracker](https://bugs.chromium.org/p/oss-fuzz/issues/list) 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](https://github.com/isaacs/github/issues/37) is available.
## Why do you require a Google account for authentication?
Our [ClusterFuzz]({{ site.baseurl }}/further-reading/clusterfuzz) fuzzing
infrastructure and [issue tracker](https://bugs.chromium.org/p/oss-fuzz/issues/list)
require a Google account for authentication. Note that an alternate email
address associated with a Google account does not work due to appengine api
limitations.
## 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]({{ site.baseurl }}/reference/glossary/#fuzz-target)
requires more than **~25 seconds** or more than **2.5GB RAM** to process, we
report this as a timeout or an OOM (out-of-memory) bug
(examples: [timeouts](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=%22Crash+Type%3A+Timeout%22),
[OOMs](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q="Crash+Type%3A+Out-of-memory")).
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]({{ site.baseurl }}/getting-started/new-project-guide#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](http://libfuzzer.info#fuzzer-friendly-build-mode).
Examples: [openssl](https://github.com/openssl/openssl/tree/master/fuzz#reproducing-issues),
[boringssl](https://boringssl.googlesource.com/boringssl/+/HEAD/FUZZING.md#Fuzzer-mode)
- 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]({{ site.baseurl }}/further-reading/clusterfuzz#coverage-reports)
for your target(s) and figure out why some parts of the code are not covered.
## Why are code coverage reports public?
We work with open source projects and try to keep as much information public as
possible. We believe that public code coverage reports do not put users at risk,
as they do not indicate the presence of bugs or lack thereof.
## What happens when I rename a fuzz target ?
If you rename your fuzz targets, the existing bugs for those targets will get
closed and fuzzing will start from scratch from a fresh corpora
(seed corpus only). Similar corpora will get accumulated over time depending on
the number of cpu cycles that original fuzz target has run. If this is not
desirable, make sure to copy the accumulated corpora from the original fuzz
target (instructions to download
[here]({{ site.baseurl }}/advanced-topics/corpora/#downloading-the-corpus)) and
restore it to the new GCS location later (instruction to find the
new location [here]({{ site.baseurl }}/advanced-topics/corpora/#viewing-the-corpus-for-a-fuzz-target)).
## Does OSS-Fuzz support AFL?
OSS-Fuzz *uses* [AFL](http://lcamtuf.coredump.cx/afl/) as one of its
[fuzzing engines]({{ site.baseurl }}/reference/glossary/#fuzzing-engine) but this is an implementation
detail. Just follow the
[ideal integration guide]({{ site.baseurl }}/advanced-topics/ideal-integration/)
and OSS-Fuzz will use all its fuzzing engines on your code.
## Does OSS-Fuzz support Honggfuzz?
OSS-Fuzz (the service) does not use honggfuzz to find bugs.
That is because [ClusterFuzz](https://github.com/google/clusterfuzz)
(the infrastructure OSS-Fuzz runs on) does not support honggfuzz.
However, OSS-Fuzz supports **building** fuzz targets for use with honggfuzz,
similar to the way it supports [AFL](#does-oss-fuzz-support-afl).
Currently OSS-Fuzz builders do builds for libFuzzer, AFL, and honggfuzz.
## What are the specs on your machines?
OSS-Fuzz builders have 32CPU/28.8GB RAM.
Fuzzing machines only have a single core and fuzz targets should not use more
than 2.5GB of RAM.
|
