Fuzzing is effective if either:
If you have an API to be fuzzed, make a simple libfuzzer fuzzer for just that API, to get the speed required to explore its attack surface. If however we want to fuzz a larger, more complex set of Chromium code, we usually need an entire browser process environment around us. The browser process takes seconds to start, preventing coverage guided fuzzing from being effective.
We now have an experimental ‘in process fuzz test’ framework which attempts to:
chrome/test/in_process_fuzz_test.gni
InProcessFuzzTest
. This must override the Fuzz
method. You‘ll find that your base class inherits from the full browser test infrastructure, so you can do anything you’d do in a normal Chrome browser test.cc
file, also use the macro REGISTER_IN_PROCESS_FUZZER
to declare that this is the one and only such fuzzer in your executable.These cases can be run either with libfuzzer or centipede.
For libfuzzer, provide gn arguments use_sanitizer_coverage = true
, use_libfuzzer = true
, is_component_build = false
and is_asan = true
(other permutations may work).
This will give you a single binary you can run like this: my_fuzzer /tmp/corpus -rss_limit_mb=81920
However, you'll more likely want to use centipede which has an out-of-process co-ordinator.
To use centipede, specify use_centipede = true
instead of use_libfuzzer = true
. You should also build the centipede
target as well as your fuzzer. You'll then want to run centipede using some command like:
mkdir wd && ASAN_OPTIONS=detect_odr_violation=0 out/ASAN/centipede --binary=out/ASAN/html_in_process_fuzz_tests --workdir=wd --shmem_size_mb 4096 --rss_limit_mb 0 --batch_size 100 --log_features_shards 2 --exit_on_crash 1