**Episode 9:** by Adrian Taylor in Mountain View (December, 2019)  

[Previous episodes](https://developer.chrome.com/docs/chromium/chronicle)

You may find you are asked to fix high-priority security bugs discovered by
ClusterFuzz. What is it? Should you take those bugs seriously? How can you
help?

![Fuzzing flow chart](https://developer.chrome.com/static/blog/chromium-chronicle-9/image/fuzzing-flow-chart-f620e3508f9d4.png)

**ClusterFuzz feeds input to Chrome and watches for crashes.** Some of those
Chrome builds have extra checks turned on, for example [AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer),
which looks for memory safety errors.

ClusterFuzz assigns components based on the crash location, and **assigns
severity based on the type of crash and whether it happened in a sandboxed
process**. For example, a heap use-after-free will be high severity, unless
it's in the browser process, in which case it's critical (no sandbox to limit
impact!):

```c++
class Foo {
  Widget* widget;
};

void Foo::Bar() {
  delete widget;
  ...
  widget->Activate();  // Bad in the renderer process, worse in the
                       // browser process. Obviously, real bugs are
                       // more subtle. Usually.
```

ClusterFuzz generates input from fuzzers or from bugs submitted externally.
Some fuzzers are powered by [libFuzzer](https://llvm.org/docs/LibFuzzer.html), which evolves input to
increase code coverage. Some understand the grammar of the input language
converted into `protobufs`. Once ClusterFuzz finds a crash, it will try to
**minimize the input test case and even bisect to find the offending commit**.
It finds a lot...

![](https://developer.chrome.com/static/blog/chromium-chronicle-9/image/7KdI3HXVypDiK7GJZ3Gf.png)

You can help:

- Be paranoid about object lifetimes \& integer overflows.
- Add new fuzzers, especially when you process untrustworthy data or IPC (see links below, often \< 20 lines of code).
- Fix ClusterFuzz-reported bugs: its **severity heuristics can be trusted because
  they're based on real-world exploitability** : Even a [single byte overflow](https://googleprojectzero.blogspot.com/2016/12/chrome-os-exploit-one-byte-overflow-and.html) has led to arbitrary code execution by an attacker.

## Resources

- [Fuzz testing in Chromium](https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/README.md): How to add new fuzzers to ClusterFuzz for new data formats, or just because you want the credit of finding awesome vulns.
- [Chrome Fuzzer Program Update and How-To](https://security.googleblog.com/2019/07/chrome-fuzzer-program-update-and-how-to.html): Fuzzers are also written by external contributors. Hear about their experience and how easy it can be to get started.