Fuzzing templates in docker?

[Charlie Eriksen]

An idea just came up on IRC:

[07:40] <yrp> the real solution is to cowboy up and patch your program

[07:40] <yrp> (i know its not you who wants this)

[07:41] <yrp> (but that would be an appropriate response imo)

[07:41] <yrp> esp. with afl, because it mostly presume source code access

[07:42] <bnagy> yeah

[07:42] <bnagy> I think "file needs a certain extension" is legit though

[07:43] <yrp> I mean, Id still say just patch it =p, but Im used to hacking up targets I guess

[07:43] <bnagy> hm

[07:44] <bnagy> ok you convinced me :P

--- next day---

[12:47] <d33tah> yrp: i wish we had a spot that aggregated this kind of patches for open source projects - so that I could pull somebody's afl-fuzz work, add my idea for an input test case and continue your fuzzing

[12:47] <d33tah> i'm discussing it with Hanno Böck righ tnow

[12:49] <d33tah> (the author of fuzzing-project.org)

[12:51] <d33tah> also i wish that i could in some cases just add a repository for projects already built with afl-fuzz instrumentation add ASAN

[13:03] <Chadk> Somebody needs to put together some good infrastructure solution to utilize docker for fuzzing. I.e. docker files to spin up afl and some project

[13:03] <Chadk> Which syncs the progress data to a central location and such

[13:03] <Chadk> Just to avoid the nastyness of dependencies and such

[13:47] <d33tah> Chadk: could you describe this idea on afl-users mailing list?

I think the idea would be that a set of scripts could be created that would spin up a docker instance like:

1. Pull all dependencies for the program and AFL

2. Download source

3. Compile it as needed for AFL(With patches, persistent, etc)

4. Push test cases specified by the user into the instance

5. Start running AFL

6. Push state to the outside host on a regular basis to allow for resuming and such

This would have some benefits:

- Makes it easy to share templates for how to fuzz specific programs. If people have a lot of spare hardware sitting around but not the time to set everything up, this would make it easy to pull a template and go fuzzing

- It would solve dependency problems if you're fuzzing multiple programs on the same system

- Could make it really easy to fuzz different versions of a program

So if this is something people are already doing or want an idea to do something that seems like it could be cool, here you go!

[Phil Ames]

This is kind of like https://github.com/ozzyjohnson/docker-afl/blob/master/Dockerfile right?

(it doesn't push state to an external host, but in general, seems to fit most of the bill of what you're looking to do).

 

--
You received this message because you are subscribed to the Google Groups "afl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to afl-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Charlie Eriksen]

Yeah, something like that. One would just need to extract a base image with AFL and such, a consistent way to extract the data(Though the approach of simply mounting a directory like in Ozzy's case works too), and then just for everybody to adopt this approach and share docker files for different program. :-)

[Doug Birdwell]

I have used docker successfully with AFL and my network modifications (see my separate post), but did not go as far as writing scripts to automate the process.  (I was learning how to do this as I went along.)  Some suggestions:

- Don't compile sources for AFL or the target within docker (or at least within the docker containers you plan to use for fuzzing) if you plan to parallelize.  To do this, you need a docker image with the appropriate development environment, which is significantly bigger than a minimal image (about 2x in the trials I did).  (A reason for compiling within a container is compilation for a different target environment than implemented by your host.)  You can compile/build on the host (or one of them) used for the docker containers, create a directory that has just the binaries you need (afl-fuzz, target, ...), and map that directory to the docker containers.  There are advantages to using static linking with this approach; otherwise, you may need to install additional packages within the image used for your containers. For example, use a command such as "docker run -d -v /tmp/afldir:/tmp/afldir ubuntu/latest [command]" to share a directory tree ("volume" in docker).  The same approach can be used to share information between the containers (e.g., parallel fuzzing).

- I suggest using Ubuntu, Debian, etc, rather than CentOS /Red Hat.  While either environment works, my experience was docker's use of file storage (for images & containers) was more efficient in the former.  If others attempt this with CentOS/RedHat I would be interested in hearing their about experiences.  (Note also that SELinux can get in the way when using docker, but that can be turned off, assume you have other ways to protect the host.)

- When building or choosing your host environment, especially for machines that have a lot of cores, either allocate sufficient space for /var or use one of the methods documented on the web to move docker's storage space for containers & images out of /var -- especially on CentOS, etc.  The storage requirement is specific to what you are attempting, so experimentation is necessary.

I used docker because I was fuzzing a network server and was not able to easily modify the server's code to change its port assignments.  Docker allowed me to run multiple afl-fuzz + network server target containers on the same host while avoiding port conflicts.  In this application docker was extremely useful.  The alternative was to use multiple hosts or multiple VMs, both with much greater overhead.

Others' mileage will probably vary.