The Chromium Chronicle: ClusterFuzz
Episode 9: December, 2019
by Adrian Taylor in Mountain View
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?
ClusterFuzz feeds input to Chrome and watches for crashes. Some of those Chrome builds have extra checks turned on, for example 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!):
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, 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...
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 has led to arbitrary code execution by an attacker.
Resources
- Fuzz testing in Chromium: 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: Fuzzers are also written by external contributors. Hear about their experience and how easy it can be to get started.