Make fuzzing good and easy
With !890 (merged) librsvg now includes two minimal fuzzers:
- One based on cargo-afl, courtesy of @Eijebong in #469 (closed).
- One based on cargo-fuzz.
None of these are meant to be run in the CI, just by interested people. However, they are pretty bare-bones and don't have things like a proper corpus.
I am not a fuzzing expert, so I'd love people's input on these:
- What sort of corpus do we need? Can we just take the test suite's extensive list of SVGs and pass them to the fuzzer? Would it be better to remove redundant info, or does mutation/reduction take care of that automatically?
- Do we need a dictionary for afl++? I tried using its
-x
option to pass afl's own dictionaries for SVG/CSS, but it complains that dictionary files have a maximum of 128 bytes each, and the SVG/CSS dictionaries are several KB. Do we need to split them into a bunch of little files? Or build a patched afl? - I'd like an easy to use script, because both cargo-afl and cargo-fuzz have way too many knobs.
- Do we need to build all of librsvg's dependencies with asan/ubsan/etc?
- I think afl++ supports things like radamsa. This has produced REALLY GOOD crashes in the past; can we use that apart from the default mutator?
An easy script
Basically rsvg-fuzz --num-cores 10
or whatever that I can leave running for a few days for peace of mind. #469 (closed) has a script based on tmux; this is another idea that someone suggested on Mastodon, and uses afl-whatsup
plus watch
to monitor things.
The afl documentation mentions that it is quite taxing on I/O systems and SSDs. Can we have the script create a tmpfs as a RAM disk for that automatically?
The big guns
@Google-Autofuzz you expressed interest in #469 (closed). Is some of the above things that you would be able to do?
Why no fuzzing until now?
... basically, I've been afraid that Cairo was way too easy to crash when given coordinates or things like stroke-width that were outside its supported range. Now that Cairo 1.17 has checks on that (it didn't before), things seem a lot more stable. I tried all the fuzzing-related examples that were filed here, and none of them could crash the latest librsvg. This was definitely not the case about two years ago, for example.