Thanks for the kind words, it is much appreciated. It's just a standard Debian 7 x86_64 VM running under ESXi. I'm not using any kind of sandbox or jail or chroot environment as the VM is disposable and another one can be spun up in seconds if necessary. So far, I haven't had any issues with AFL deciding to run something like rm -rf on anything important. As far as how I'm running AFL with bash, it's pretty simple:
afl-fuzz -i input -o output ~/bash/bash @@ The above will run one instance, but sometimes I run multiple instances against the same input (ESXi box is a 6 core Xeon w/ 12 threads), so those command lines (one per terminal) would be something like this: afl-fuzz -M bashfuzz1 -o output ~/bash/bash @@ afl-fuzz -S bashfuzz2 -o output ~/bash/bash @@ afl-fuzz -S bashfuzz3 -o output ~/bash/bash @@ afl-fuzz -S bashfuzz4 -o output ~/bash/bash @@ I just feed it a few scraps of whatever I can find by dropping it into the input directory and just let it run. Now this setup will just fuzz input from the command line, sort of like running millions of bash -c with random stuff. If you want to fuzz environmental variables or anything like that, I believe lcamtuf has a pretty basic bash harness that ships with AFL. There are instances where it'll run for days with no problem, but sometimes AFL gets obnoxious and I notice the load values of the VM are around 10000 either due to a fork bomb or thousands of instances of bash starting but never exiting in which case I just power cycle the VM and start over. Definitely not something you want to do on a production machine or a machine that is running anything important. I've only had to power cycle ESXi once in 6 months and that was due to an intermittent disk issue which I solved by upgrading to a better RAID card. There might be a better way to do this, but so far, the success rate for finding crashers is pretty good. I used the same method to find a couple of security bugs in OpenSSL (CVE-2015-0208, CVE-2015-0288), one in PHP (CVE-2014-9427) and one in pngcrush (CVE-2015-2158). I'm also learning as I go, for example, when I first started this adventure late last year, I couldn't tell you what a null ptr deref looked like in Valgrind and I couldn't explain what was happening in a stack trace (I'm not much of a coder), but now, I'm doing a bit better. Anyways, if you have any other questions or comments, feel free to send them my way. On Sat, Sep 19, 2015 at 11:33 PM, Eduardo A. Bustamante López < dual...@gmail.com> wrote: > On Sat, Sep 19, 2015 at 11:17:33PM -0500, Brian Carpenter wrote: > > I found another null ptr deref and segfault. This only seems to affect > bash > > 4.4.0 as 4.2.37(1)-release and 4.2.37(1)-release only return a 'bad > > substitution' error message. > > Hey Brian, > > I just wanted to step in and say: you're doing an awesome job! Could you > do a > write up on the specific setup you're using to run afl with bash? Do you > use > any kind of jail/sandbox to avoid bugs which could affect the system? > > This is amazing. > > -- > Eduardo Bustamante > http://dualbus.me/ >
