code to fuzz network clients and servers

[Doug Birdwell]

I have created the attached patch for AFL 1.86b (which should work for 1.85b and 1.84b, too) that implements fuzzing input data to a target across a network socket (on the same host).  I submitted an earlier version of this code to Michal, but since there are folks on the list who appear to be keenly interested in this - and, frankly, because I would appreciate any feedback that I can use to improve this capability - I am posting my current version here.  (Michal, the version I emailed you fuzzed only servers - programs that expect to receive queries from other programs and then respond.  This version also implements fuzzing of clients - programs that send a query to a server and then expect a response - and cleans up a couple of things in the earlier version.  You can safely ignore the earlier version and examine this one.)

Please consider this code DRAFT -- it has not undergone review outside of my organization for inclusion in an AFL release.  (It is reasonably large, so I expect that review will take some time.)  To use it, I suggest starting with a clean copy of AFL 1.86b before applying the patch.  Other modifications may interfere with this patch. While I have done quite a lot of testing and am reasonably satisfied that the code works as advertised, this code is provided as is -- by using it, you accept the risk.

The code supports both TCP and UDP protocols, across both IPv4 and IPv6 (meaning you can force IPv4 or IPv6).  I have only tested it on Linux (Ubuntu 15.04), so I am very interested in hearing about problems people encounter on other operating systems.

The patch includes updates to the documentation in the README file that describe the new command line switches for network fuzzing (-N, -L, and -D).  The usage() code in afl-fuzz.c is also updated to display brief information about network fuzzing.  Only afl-fuzz.c and README are patched.  (In particular, afl-showmap.c, afl-tmin.c, and afl-cmin, which also run the target, do not yet know how to do network fuzzing.)

As an example of fuzzing a networked server, I used the following command line to fuzz the sshd server from the OpenSSH project (while in the project's directory):

~/NetBeansProjects/afl-fuzz/afl-fuzz -i ./testcases -o ./findings -t 30+ -D 10 -Ntcp://::1:2222 `pwd`/sshd -D -d -f `pwd`/sshd_config_noprivsep

This first required creating the host keys and a special configuration file that turned off privilege separation and changed the port to 2222, in addition to building the executables using afl-gcc.  Modifications to sshd are also necessary so that it will exit after processing its first client.

The following command allows me to fuzz the ssh network client; note the extra "-L" option:

~/NetBeansProjects/afl-fuzz/afl-fuzz -i ./testcases -o ./findings -t 20+ -D 7 -L -Ntcp://::1:2222 `pwd`/ssh -l bogus -p 2222 ::1

Both commands use IPv6 network addresses.  This can be changed to IPv4 by changing "::1" to "127.0.0.1" everywhere the string occurs.  The time out parameter (-t) and delay parameter (-D) will be specific to the host processor's performance.

A few notes:

The code to fuzz network servers reuses sockets and ports, so it doesn't consume a lot of ports (unless multiple executions of the target do - which can happen).  That's not generally possible when fuzzing network clients -- running a client a lot of times will usually allocate a lot of ephemeral ports (which take a while to time out with TCP).  The very recent Linux kernel I used handled this gracefully by scavenging ports rather than running out.  There's no guarantee that other operating systems will do this, and running out of available ports is probably a bad thing.

Because fuzzing network clients involves a 2-step transaction, when you use ^C to exit afl-fuzz both the afl-fuzz process an a target process may get stuck (with the target process in a zombie state).  When this occurs, use "ps -aux|grep afl" to find the afl-fuzz process and kill it with "kill -9 PID".  That should also destroy the zombie process.

Some network clients can be fuzzed using the "server mode" (no -L switch on the afl-fuzz command line).  It just depends.

Note that one can not have two processes running under the same kernel that utilize the same port and protocol (UDP or TCP) at the same time without doing some extra work (using containers or virtual machines).  Therefore, if you want to run multiple afl-fuzz processes on a multi-core host, you will either have to ensure that multiple instances of afl-fuzz (and of the target process) use different port numbers -- or use containers or virtual machines to avoid port conflicts.

Finally, you will probably have to modify server codes to cause them to exit after processing their first client.  Otherwise, all runs will time out,

There is additional information in the (patched) README file.

Doug Birdwell

[Jacek Wielemborek]

W dniu 17.08.2015 o 21:45, Doug Birdwell pisze:

Hello Doug,

Sorry for the late reply! I kept meaning to give your patch a try but it
took me a while to actually find a test case where it would be more
convenient that Preeny for me. I ended up applying this patch to 1.94b
and trying to fuzz "forgottenserver" Tibia MMO server and I failed.
Here's what I tried:

# strace -f -o strace.log afl-fuzz -t 10000 -m none -D 6000 -i i -o o
-Ntcp://127.0.0.1:7172 ./tfs 2>&1
afl-fuzz 1.94b by <lca...@google.com>
[+] You have 8 CPU cores and 2 runnable tasks (utilization: 25%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[*] Checking core_pattern...
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'i'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:1'...
[*] Spinning up the fork server...
[+] All right - fork server is up.

[-] SYSTEM ERROR : Attempt to bind socket to source address & port
failed (TCP case)
Stop location : network_send(), afl-fuzz.c:2189
OS message : Address already in use

After that, "tfs" hangs forever - port 7272 was free before TFS used it.
I attach strace.log.gz and the patch I applied to make TFS die after a
connection closes. Server's source code can be found here:

https://github.com/otland/forgottenserver

Any ideas what is going on?

Cheers,
d33tah

[Stephen Shkardoon]

There are some behaviours around binding sockets in Linux where if you require to rebind to a socket that's been previously used in the last ~30 seconds, you need to use SO_REUSEADDR. At least, that's what I figured when I had similiar issues - http://unix.stackexchange.com/questions/162010/what-are-the-semantics-of-getting-a-eaddrinuse-when-no-listening-socket-is-bound

Could you be running into this same issue?

--
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.

[Jacek Wielemborek]

W dniu 20.09.2015 o 22:14, Stephen Shkardoon pisze:

> There are some behaviours around binding sockets in Linux where if you
> require to rebind to a socket that's been previously used in the last ~30
> seconds, you need to use SO_REUSEADDR. At least, that's what I figured when
> I had similiar issues -
> http://unix.stackexchange.com/questions/162010/what-are-the-semantics-of-getting-a-eaddrinuse-when-no-listening-socket-is-bound
> Could you be running into this same issue?

Provided that I'm reading the strace log correctly, that's not the case:

$ zcat strace.log.gz | grep -i setsockopt -B1
9675 connect(6, {sa_family=AF_LOCAL,
sun_path="/var/run/mysqld/mysqld.sock"}, 110) = 0
9675 setsockopt(6, SOL_SOCKET, SO_RCVTIMEO,
"\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
9675 setsockopt(6, SOL_SOCKET, SO_SNDTIMEO,
"\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
9675 setsockopt(6, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation
not supported)
9675 setsockopt(6, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
--
9675 connect(8, {sa_family=AF_LOCAL,
sun_path="/var/run/mysqld/mysqld.sock"}, 110) = 0
9675 setsockopt(8, SOL_SOCKET, SO_RCVTIMEO,
"\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
9675 setsockopt(8, SOL_SOCKET, SO_SNDTIMEO,
"\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
9675 mprotect(0x7f1120021000, 4096, PROT_READ|PROT_WRITE) = 0
9675 setsockopt(8, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation
not supported)
9675 setsockopt(8, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
--
9675 epoll_ctl(4, EPOLL_CTL_ADD, 9,
{EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLET, {u32=551181616,
u64=139711542353200}}) = 0
9675 setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
--
9675 listen(9, 128) = 0
9675 setsockopt(9, SOL_TCP, TCP_NODELAY, [1], 4) = 0
--
9675 epoll_ctl(4, EPOLL_CTL_ADD, 10,
{EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLET, {u32=551180272,
u64=139711542351856}}) = 0
9675 setsockopt(10, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
--
9675 listen(10, 128) = 0
9675 setsockopt(10, SOL_TCP, TCP_NODELAY, [1], 4) = 0
--
9672 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 9
9672 setsockopt(9, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
--
9680 connect(6, {sa_family=AF_LOCAL,
sun_path="/var/run/mysqld/mysqld.sock"}, 110) = 0
9680 setsockopt(6, SOL_SOCKET, SO_RCVTIMEO,
"\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
9680 setsockopt(6, SOL_SOCKET, SO_SNDTIMEO,
"\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
9680 setsockopt(6, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation
not supported)
9680 setsockopt(6, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
--
9680 connect(8, {sa_family=AF_LOCAL,
sun_path="/var/run/mysqld/mysqld.sock"}, 110) = 0
9680 setsockopt(8, SOL_SOCKET, SO_RCVTIMEO,
"\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
9680 setsockopt(8, SOL_SOCKET, SO_SNDTIMEO,
"\2003\341\1\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
9680 mprotect(0x7f1120021000, 4096, PROT_READ|PROT_WRITE) = 0
9680 setsockopt(8, SOL_IP, IP_TOS, [8], 4) = -1 EOPNOTSUPP (Operation
not supported)
9680 setsockopt(8, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
--
9680 epoll_ctl(4, EPOLL_CTL_ADD, 9,
{EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLET, {u32=551111232,
u64=139711542282816}}) = 0
9680 setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
--
9680 listen(9, 128) = 0
9680 setsockopt(9, SOL_TCP, TCP_NODELAY, [1], 4) = 0
--
9680 epoll_ctl(4, EPOLL_CTL_ADD, 10,
{EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP|EPOLLET, {u32=551070832,
u64=139711542242416}}) = 0
9680 setsockopt(10, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
--
9680 listen(10, 128) = 0
9680 setsockopt(10, SOL_TCP, TCP_NODELAY, [1], 4) = 0
--
9672 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 9
9672 setsockopt(9, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0

[Doug Birdwell]

Jacek,

I'll take a look, probably tomorrow or Tuesday.  I have not tried it with the more recent versions of afl - the most recent I used was 1.86b - so it's possible there is a conflict.  Port 7172 or 7272?  One thing that stands out is the -t and -D values - these are in msec, so these are 10 and 6 seconds.  -t 10 -D 6 would probably be sufficient unless tfs takes a long time to start up.  If you really need a delay (-D) of 6 seconds fuzzing will take forever because that is the time delay afl-fuzz waits for the target to start up and get ready to receive traffic.  The values you used, however, would not cause this error message.

Doug

[Doug Birdwell]

The code has the flags set to reuse sockets & ports, as you see from the trace.

Doug

[Jacek Wielemborek]

W dniu 20.09.2015 o 22:29, Doug Birdwell pisze:

> Jacek,
>
> I'll take a look, probably tomorrow or Tuesday. I have not tried it with
> the more recent versions of afl - the most recent I used was 1.86b - so
> it's possible there is a conflict. Port 7172 or 7272? One thing that
> stands out is the -t and -D values - these are in msec, so these are 10 and
> 6 seconds. -t 10 -D 6 would probably be sufficient unless tfs takes a long
> time to start up. If you really need a delay (-D) of 6 seconds fuzzing
> will take forever because that is the time delay afl-fuzz waits for the
> target to start up and get ready to receive traffic. The values you used,
> however, would not cause this error message.
>
> Doug

I am aware that it would take forever to fuzz - I just wanted to rule
the timing out for the time being. The server actually takes a few
seconds to start up, I plan to speed it up later.

The port is 7172 - I just double-checked it.

[Jacek Wielemborek]

W dniu 17.08.2015 o 21:45, Doug Birdwell pisze:

Hello Doug,

This time I tried to use my afl-sid to build and fuzz phantomjs. There
were some problems with building it, so I uploaded the package to
afl-sid-repo [1]. Here's the command I used and its output - after this
line, I got no further responses:

# /afl-1.94b/afl-fuzz -i i -o o -m none -L -Ntcp://::1:2222 ./phantomjs
`pwd`/test.script

afl-fuzz 1.94b by <lca...@google.com>
[+] You have 8 CPU cores and 2 runnable tasks (utilization: 25%).

[+] Try parallel jobs - see docs/parallel_fuzzing.txt.

[*] Checking core_pattern...
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
[*] Scanning 'i'...
[+] No auto-generated dictionary tokens to reuse.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:1'...
[*] Spinning up the fork server...
[+] All right - fork server is up.

I attach a sample test script and server response - outside of afl-fuzz
they result in phantomjs returning quite quickly. Any ideas on what
might be going on?

Let me know if you'd like any help with getting my Docker image use this
phantomjs package.

Cheers,
d33tah

[Doug Birdwell]

Jacek,

I looked through the strace and can tell what happened - but not precisely why (yet).  Afl-fuzz ran tfs twice, once as process 9675 and the second time as process 9680.  Afl-fuzz connected to tfs process 9675 and sent the fuzzed packet, but tfs 9675 terminated without explicitly closing file descriptor 10 (corresponding to the listen on socket 7172), depending on the OS to do so during clean up.  (It also apparently never read from socket 7172, which is a bit odd -- but I may have missed this.  tfs is using non-blocking reads -- and it is using an old-style way to set them up using ioctl(fd, FIONBIO,...) -- which apparently has known problems.)  The clean-up by the OS apparently did not happen - and this may have been due to the 30 second timeout and/or data being in transit - and the OS did not allow the afl-fuzz network_send() code to reuse the socket.  It would be interesting to specify a delay of about a minute with the -D parameter and see what happens. 

Afl-fuzz started a new instance of tfs as process 9680 using its fork server, which also listened to socket 7172, but afl-fuzz (in network_send() - my code) attempts to reuse its sending socket to avoid consuming the pool of available non-privileged sockets, and could not bind to it because the connection to 9675 was still in a final wait state (I think - you could check this with "netstat -n | grep 7172").  Process 9680 hangs because its handshake with afl-fuzz doesn't complete.

I believe the simplest way to "fix" this issue is to add an explicit close() on the file descriptor corresponding to socket 7172 - but things are a bit complicated because you also need to do this when termination occurs due to the target's timeout (imposed by afl-fuzz).  From a quick look at your patch, this is also buried in the C++ class the code uses (from boost??).  Another approach, which I will probably experiment with - but probably not until at least the weekend - is to try a modified version of network_send() that does not reuse the sending socket number. (See the code immediately after "/* This is not the first time; reuse send side info in N_myaddr. */" in network_send().)  However, while that may "solve" this particular problem, it may cause other problems because afl-fuzz + the networking code can consume the non-privileged socket pool very rapidly when using TCP.  The newest kernels have kept up nicely for UDP by reclaiming used sockets in my tests, but other kernels may have problems -- and the 30 second wait in the TCP exit states can cause severe problems if sockets are not reused.

Please let me know which Linux flavor and kernel you are using, too.  I have done all of my testing using Ubuntu 14.04 and 15.04 with the latest available kernels, and other versions may behave differently.  I will keep looking at this, but it may take me a bit of time to track things down because I'm in the middle of another project at present.

Thanks,
Doug

[Jacek Wielemborek]

W dniu 22.09.2015 o 18:36, Doug Birdwell pisze:

> Please let me know which Linux flavor and kernel you are using, too. I
> have done all of my testing using Ubuntu 14.04 and 15.04 with the latest
> available kernels, and other versions may behave differently. I will keep
> looking at this, but it may take me a bit of time to track things down
> because I'm in the middle of another project at present.
>
> Thanks,
> Doug

Hello Doug,

Thanks for a detailed response! Hacking the TFS networking code might be
pretty difficult because of a dependency on boost::asio, which is a
library I don't really know.

I'm using Fedora 21 with Linux 4.1.6-100.fc21.x86_64 as a Docker host.
The tests were ran on Debian Sid inside of my d33tah/afl-sid Docker
container. Let me know if you need any more info.

Cheers,
d33tah

[Jacek Wielemborek]

W dniu 17.08.2015 o 21:45, Doug Birdwell pisze:

> I have created the attached patch for AFL 1.86b

Hello Doug,

I finally took the time to read your patch and have a few
comments/questions:

1. In "void network_setup_listener(void) {", instead of checking if
N_results is non-null to start a big chunk of indented code, check for
otherwise and FATAL() immediately. IMHO it's more readable because it's
one brace less to match visually. Same for "if (N_myaddr_valid != 0)
return" later. Note that this pattern repeats in network_send.

2. Should "setsockopt(N_fd, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT"
really be fatal? I guess that since this socket is taken, we can
probably continue.

3. Network_listen is quite long, perhaps it would make sense to split it
by TCP/UDP?

4. afl-fuzz.c functions are mostly static - perhaps those should be made
so as well?

5. "Note that this code assumes that the entire buffer can be sent in a
single packet. If it can not (giant packet), the user may be doing
something wrong." - perhaps this should be mentioned in README?

6. Missing spaces after commas:

while ((currreadlen =
recv(client_fd,recvbuf,MAXRECVBUFSIZE,MSG_DONTWAIT)) > 0);

7. network_send contains an anonymous block. Why was it added?

8. Thanks for showing me sendfile(), I didn't know about this one!

9. if ((N_fuzz_client?network_listen():network_send()) == -1) {

This could use a bit of whitespace.

10. if (N_option_specified) {

The added code below is rather lengthy and main() is already quite long
- perhaps it would make sense to move this code to a separate routine?

11. How difficult would it be to base Unix socket support on this code?
Would it be faster than TCP?

12. This patch introduced almost 1k new lines of code and four new major
execution paths (TCP/UDP, client/server). Perhaps a tiny sanity test in
the Makefile would be a good idea?

13. "a special wrapper (such as could be implemented using LD_PRELOAD)
can be used to remap each target's port to a different value"

Have you perhaps written one? If so, could you share it?

Cheers,
d33tah

[Doug Birdwell]

Jacek (all others: a new patch file to add network support to afl-1.94b is attached),

I have some news for you re tfs / forgottenserver:  afl-fuzz/network worked for me under Ubuntu.  Any ideas on what could be different between Ubuntu & Debian that would cause failure on Debian? (I used a Ubuntu VM rather than your container b/c I wanted to capture and look at the network data with Wireshark, and rather than install a bunch of stuff, I took the easy way out and cloned my VM.)  I will also try building it under your Docker container, but my starting point there will be building and running my tests.  If that doesn't pass, it will be much easier to spot the problem.

THANK YOU for your detailed review of my network code!  I haven't started editing it yet, but will take care of most of the comments -- the big changes will need to wait (lack of time at present).  Re test codes, I have test codes but did not integrate them into the project; most of the targets I built are mods of some of Kerrisk's example codes from "The Linux Programming Interface" (Affero GPL 3), and I don't want to stick them in the afl-fuzz distribution.

Details on my fuzzing of forgottenserver:

uname -a
Linux ubuntu 3.19.0-30-generic #34-Ubuntu SMP Fri Oct 2 22:08:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

tfs/forgotten server built from sources downloaded today and patched with the patch file you supplied.

afl-fuzz 1.94b patched with my networking code - I have attached a patch file for this, since there are a couple of places in the 1.94b docs that conflicted with the old patch.  None of the conflicts that I saw were in executable code.

The version of libboost is 1.55.0 (some of the packages are listed as either 1.55.0.2 and 1.55.0+dfsg-3ubuntu2).  I don't know boost, but perhaps something was recently patched, since we suspected this might be the issue.  I suspect the issue is the tfs end of the connection doesn't exit correctly, and the connection ends up in the TIME_WAIT state, preventing a 2nd connection to the next instance of tfs.

To help, I've attached the strace.log and wireshark capture files, along with a screenshot.  ./tfs is slow -- about 16 executions / second - but that was expected.

I haven't tried your other example, yet.

Thanks
Doug

[Doug Birdwell]

Jacek,

I created a clean Debian build environment using docker (debian:latest (therefore NOT sid) + apt-get install build-essentials), installed the prerequisites for forgottenserver / tfs, built afl-1.94b w/ the network code and forgottenserver/tfs, and fuzzed tfs - and it ran without problems.

I also played with the delay parameters, and with "-t 7 -D 2" was able to reach 300 executions / second (using a 3.1GHz Intel i7 dual core processor in a MacBook Pro 13", running Debian as a VM under VMWare Fusion).  I was using much larger delay values in my Ubuntu test (-t 100 -D 60) because I thought tfs was slow -- it isn't especially slow compared to other network applications I have fuzzed.

I also built and executed all of the programs in my test suite, and they all ran as expected, so I am fairly confident that the network version of afl-fuzz will run on Debian as well as Ubuntu.  These are now the only two versions of Linux I have tested (debian:latest, and Ubuntu 14.04 and 15.04).

Perhaps debian:sid is not suitable for this work -- it is, after all, "unstable". ;-)

Let me know if you can figure out more about what is happening.

Thanks again for trying out the code!
Doug

[Jacek Wielemborek]

W dniu 14.10.2015 o 04:19, Doug Birdwell pisze:

> Jacek,
>
> I created a clean Debian build environment using docker (debian:latest
> (therefore NOT sid) + apt-get install build-essentials), installed the
> prerequisites for forgottenserver / tfs, built afl-1.94b w/ the network
> code and forgottenserver/tfs, and fuzzed tfs - and it ran without problems.
>
> I also played with the delay parameters, and with "-t 7 -D 2" was able to
> reach 300 executions / second (using a 3.1GHz Intel i7 dual core processor
> in a MacBook Pro 13", running Debian as a VM under VMWare Fusion). I was
> using much larger delay values in my Ubuntu test (-t 100 -D 60) because I
> thought tfs was slow -- it isn't especially slow compared to other network
> applications I have fuzzed.
>
> I also built and executed all of the programs in my test suite, and they
> all ran as expected, so I am fairly confident that the network version of
> afl-fuzz will run on Debian as well as Ubuntu. These are now the only two
> versions of Linux I have tested (debian:latest, and Ubuntu 14.04 and 15.04).

Strange, I'll check that again. Thanks for testing.

> Perhaps debian:sid is not suitable for this work -- it is, after all,
> "unstable". ;-)

I picked it for afl-sid because it has latest versions of software. It
should be trivial though to use debian:testing or maybe even
debian:stable after changing it in afl-sid's Dockerfile and rebuilding
the project.

[Doug Birdwell]

To make it easier for anyone to experiment with fuzzing across a (localhost) network connection (IP, not UNIX), I have created a GitHub repo with both afl-1.94b and (as the HEAD) afl-1.94b with my network patch applied.  This can be cloned using "git clone https://github.com/jdbirdwell/afl" and then built by "cd afl; make" (use "make install" to install the codes).  Note that I have only added the network code to afl-fuzz; additions to the other tools that interact with the target will probably need to wait until afl is refactored to remove some of the redundancies.  However, as time permits I will update this repo (and the container described below) to current versions of afl.

I have also created two Docker images based on debian:latest (jessie at present).  One is a development environment with build-essential, autoconf, automake, libtool, gnulib, pkg-config, curl, wget, git, net-tools, and vim installed; this image can be run using the command "docker run -ti birdwell/debian:devel /bin/bash" (interactively).  The other builds upon this image, adding the afl-1.94b code with network support.  It can be run using the command "docker run -ti birdwell/debian:afl /bin/bash".  These images are not precisely in the normal spirit of Docker -- they are rather large (around 500MB each).  The issue is the inclusion of the development tools, which appear necessary for the moment.  At some point in the future it may be desirable to have two types of images - one to develop (compile and statically link) a fuzzing target, and the other to execute afl-fuzz to perform fuzzing.  The present approach is not elegant, but it works.  The dockerfiles for these two images are available on GitHub at https://githubcom/jdbirdwell/afldockerfiles.

Enjoy, and please post or email feedback.

Jacek - when I have some more time I will look at your "aflize" code; those are good ideas!  I will also update my code to address most of the comments in your review, although I don't expect that to change the (external) functionality.

Michal - I know there is quite a lot of code in this patch (ca. 1K lines) and fully understand the effort necessary to review it, but I hope it can be incorporated at some point into your distribution of afl.  Let me know how I can help.

Sincerely,
Doug Birdwell

[Doug Birdwell]

I have updated both the GitHub repo and the Docker image to afl-1.95b + the networking code.

Enjoy!
Doug