I'm vaguely familiar with fuzzing (sending auto-generated malicious input to an API to see if it fails), but there is a big gap between my level of understanding and the level of this document. How do I fill in the gap?
And why would someone want to do that? To dissuade people from looking into fuzzing? That seems self-defeating (people usually want as many other people working on the tools they use as possible), but maybe I’m being naive and this is a clever long-lead-time cyberwar gambit or something.
It’s not actually the complicated, I assume you understand fuzzing in general? So the problem it can run into is covering the whole program; the classic example is you have some sort of key check or similar condition that is not easy to “guess” so the fuzzer gets stuck there and can’t hit anything useful. What you can do to solve this is to use guided fuzzing, where you give directions as to what the fuzzer should weight more heavily, for example it might want to be more interested in execution flows where it notices that it’s getting further along with execution or modifying some state. This project is using the idea of “if it changes it kernel state it is probably interesting” and the way it measures state is by looking at writes to all the structures in the kernel. It finds these using LLVM, which somewhat infamously uses the getelementpointer instruction in its IR for base pointer+offset operations (and as such is a good way to recognize structure accesses). Note that this doesn’t actually do any fuzzing itself, its job is it just generate a weights file that an actual fuzzer (Google’s syzkaller) can use to guide its efforts.
8 comments
[ 4.6 ms ] story [ 33.0 ms ] thread[0] https://llvm.org/docs/LibFuzzer.html [1] https://github.com/google/syzkaller
https://github.com/google/syzkaller