Re:A Year in the Life of a Compiler Fuzzing Campaign
by genewitch on Friday April 09, 2021 @10:38PM
(#26758468)
so far the only "language" i've fuzzed with AFL is an ANSI-BASIC dialect, and i used the first column from the token documentation to seed the dictionary.
A few words to the wise:
1) If you can fuzz in a VM or container with persistent storage, that's the way to do it. Fuzzing will absolutely hose your host file system (but not from a VM, hopefully.) It can't be "copy on X" sort of "delayed writes" either, because some fuzzing (sandsifter, for instance) will lock the host up. Even when fuzzing in a VM!
1.5) One way i've done it is to export iSCSI drives as the "work" drives and making the OS drive read only - but that was years ago back when "pivot_root" was something i was doing a dozen times a day on various machines.
2) AFL, the original that lcamtuf "finalized" several years ago, had no "out of the box" multicore fuzzing. But it did recognize "multiple fuzzers" in a directory with the M/S modes, and the actual "fuzzer input/output/results" directory could be on a network share. just make sure the "pwd" of the directory you run the fuzzer on the target binary/whatever in is not remotely near that network share. I suck at linux file systems so if there's a clever way to stop a misbehaving userspace binary from clobbering a filesystem, i'm all ears!
3) fuzzing can be very fun to mess around with even if you have no idea what the results mean, how to write a bug report, whatever. on lcamtuf's AFL page there was a demonstration of AFL building some graphics format from scratch, without a dictionary. I think the original seed input was "a\n" as ascii in the file, and that's it. Visualizing how the fuzzer was actually interacting with the file is cool. Seeing the BASIC programs the fuzzer would spit out after a CPU-month of fuzzing was interesting too...
A few words to the wise:
1) If you can fuzz in a VM or container with persistent storage, that's the way to do it. Fuzzing will absolutely hose your host file system (but not from a VM, hopefully.) It can't be "copy on X" sort of "delayed writes" either, because some fuzzing (sandsifter, for instance) will lock the host up. Even when fuzzing in a VM!
1.5) One way i've done it is to export iSCSI drives as the "work" drives and making the OS drive read only - but that was years ago back when "pivot_root" was something i was doing a dozen times a day on various machines.
2) AFL, the original that lcamtuf "finalized" several years ago, had no "out of the box" multicore fuzzing. But it did recognize "multiple fuzzers" in a directory with the M/S modes, and the actual "fuzzer input/output/results" directory could be on a network share. just make sure the "pwd" of the directory you run the fuzzer on the target binary/whatever in is not remotely near that network share. I suck at linux file systems so if there's a clever way to stop a misbehaving userspace binary from clobbering a filesystem, i'm all ears!
3) fuzzing can be very fun to mess around with even if you have no idea what the results mean, how to write a bug report, whatever. on lcamtuf's AFL page there was a demonstration of AFL building some graphics format from scratch, without a dictionary. I think the original seed input was "a\n" as ascii in the file, and that's it. Visualizing how the fuzzer was actually interacting with the file is cool. Seeing the BASIC programs the fuzzer would spit out after a CPU-month of fuzzing was interesting too...