The Chromium Chronicle #9: ClusterFuzz

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

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

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