2016-11-16 17:56:10 +00:00
# Reproducing OSS-Fuzz issues
2016-10-26 16:40:37 +00:00
2016-11-19 01:20:49 +00:00
You've been CC'ed on an OSS-Fuzz issue
2016-11-21 21:32:02 +00:00
([examples](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1& q=Type%3ABug%2CBug-Security)), now what?
2016-11-23 17:47:53 +00:00
Before attempting to fix the bug, you should be able to reliably reproduce it.
2016-10-27 03:48:30 +00:00
2018-05-10 04:12:14 +00:00
## Fuzz target bugs
2016-11-30 18:23:01 +00:00
Every issue has a [reproducer ](glossary.md#reproducer ) (aka "testcase") file attached.
2016-11-21 21:40:43 +00:00
Download it. If the issue is not public, you will need to login using your
[Google account ](https://support.google.com/accounts/answer/176347?hl=en )
2017-10-30 03:02:43 +00:00
([why?](faq.md#why-do-you-require-a-google-account-for-authentication))
2016-11-21 21:40:43 +00:00
that the bug report CCs.
2016-11-19 01:18:02 +00:00
This file contains the bytes that were fed to the [Fuzz Target ](http://libfuzzer.info/#fuzz-target ).
2016-11-23 17:47:53 +00:00
If you have already [integrated ](ideal_integration.md ) the fuzz target with your build and test system,
2016-11-21 21:40:43 +00:00
all you do is run:
2017-01-06 07:34:57 +00:00
```bash
$ ./fuzz_target_binary < testcase_path >
```
2017-01-03 18:47:05 +00:00
2017-01-03 19:02:33 +00:00
If this is a timeout bug, add the < b > < i > -timeout=25< / i > < / b > argument.< br / >
If this is an OOM bug, add the < b > < i > -rss_limit_mb=2048< / i > < / b > argument.< br / >
2017-01-03 18:47:05 +00:00
Read more on how timeouts and OOMs are handed [here ](faq.md#how-do-you-handle-timeouts-and-ooms ).
2016-11-27 02:15:25 +00:00
Depending on the nature of the bug, the fuzz target binary needs to be built with the appropriate [sanitizer ](https://github.com/google/sanitizers )
2016-11-19 01:18:02 +00:00
(e.g. if this is a buffer overflow, with [AddressSanitizer ](http://clang.llvm.org/docs/AddressSanitizer.html )).
2016-11-21 21:21:11 +00:00
If you are not sure how to build the fuzzer using the project's build system,
2016-11-23 17:47:53 +00:00
you may also use Docker ([how?](installing_docker.md), [why? ](faq.md#why-do-you-use-docker )) commands
to replicate the exact build steps used by OSS-Fuzz and then feed the reproducer input to the fuzz target.
2016-10-26 16:40:37 +00:00
2018-05-18 22:03:45 +00:00
## Building using Docker
2018-05-18 21:38:37 +00:00
### Pull the latest Docker images
```bash
$ python infra/helper.py pull_images
```
Docker images get regularly updated with a newer version of build tools, build
configurations, scripts, and other changes. In some cases, a particular issue
can be reproduced only with a fresh image being used.
2018-05-18 22:03:45 +00:00
### Build the image and the fuzzers
2018-05-18 21:38:37 +00:00
2017-01-06 07:34:57 +00:00
```bash
2017-05-10 20:26:15 +00:00
$ python infra/helper.py build_image $PROJECT_NAME
2018-05-10 03:35:57 +00:00
$ python infra/helper.py build_fuzzers --sanitizer < address / memory / undefined > $PROJECT_NAME
2017-01-06 07:34:57 +00:00
```
2016-10-26 18:04:46 +00:00
2018-05-10 04:06:04 +00:00
## Reproducing bugs
2018-05-10 03:35:44 +00:00
```bash
$ python infra/helper.py reproduce $PROJECT_NAME < fuzz_target_name > < testcase_path >
```
2016-11-21 21:25:39 +00:00
2017-02-03 03:02:51 +00:00
E.g. for building [libxml2 ](../projects/libxml2 ) project with UndefinedBehaviorSanitizer instrumentation
and reproduce a crash testcase for a fuzzer named `libxml2_xml_read_memory_fuzzer` , it will be:
2017-01-06 07:34:57 +00:00
```bash
2017-05-10 20:26:15 +00:00
$ python infra/helper.py build_image libxml2
2017-04-03 15:20:11 +00:00
$ python infra/helper.py build_fuzzers --sanitizer undefined libxml2
2017-01-06 07:34:57 +00:00
$ python infra/helper.py reproduce libxml2 libxml2_xml_read_memory_fuzzer ~/Downloads/testcase
```
2018-05-10 03:35:44 +00:00
## Reproduce using local source checkout
2016-10-26 18:04:46 +00:00
2017-01-06 07:34:57 +00:00
```bash
2017-04-03 15:20:11 +00:00
$ python infra/helper.py build_fuzzers --sanitizer < address / memory / undefined > $PROJECT_NAME < source_path >
2017-01-06 07:39:41 +00:00
$ python infra/helper.py reproduce $PROJECT_NAME < fuzz_target_name > < testcase_path >
2017-01-06 07:34:57 +00:00
```
2016-11-19 02:54:10 +00:00
This is essentially the previous command that additionally mounts local sources into the running container.
2018-05-18 21:38:37 +00:00
2016-11-27 02:15:25 +00:00
- *Fix issue*. Write a patch to fix the issue in your local checkout and then use the previous command to verify the fix (i.e. no crash occurred).
2016-11-02 19:43:54 +00:00
[Use gdb ](debugging.md#debugging-fuzzers-with-gdb ) if needed.
2016-11-29 19:14:04 +00:00
- *Submit fix*. Submit the fix in the project's repository. ClusterFuzz will automatically pick up the changes, recheck the testcase and will close the issue (in < 1 day).
2016-11-23 17:47:53 +00:00
- *Improve fuzzing support*. Consider [improving fuzzing support ](ideal_integration.md ) in your project's build and test system.
2018-05-18 21:38:37 +00:00
2018-05-18 22:20:52 +00:00
## Reproducing build failures
2018-05-18 22:03:45 +00:00
Our infrastructure runs some sanity tests to make sure that your build was correctly configured, even if it succeeded. To reproduce these locally, run:
2018-05-18 21:38:37 +00:00
```bash
$ python infra/helper.py build_image $PROJECT_NAME
2018-05-18 22:03:45 +00:00
$ python infra/helper.py build_fuzzers --sanitizer < address / memory / undefined > --engine < libfuzzer / afl / hongfuzz > $PROJECT_NAME
$ python infra/helper.py check_build --sanitizer < address / memory / undefined > --engine < libfuzzer / afl / hongfuzz > $PROJECT_NAME < fuzz_target_name > ```