Network fuzzing functionality Issues - bind socket failure (addr in use), test cases time out (during dry_run)

[ghost]

Summary I am a student currently trying to create a base test case for the network fuzzer with a simple TCP server that merely creates, binds, listens, accepts, receives a string, and closes a socket. However, I'm stuck on two errors I'm receiving when attempting to fuzz the application. While running the application by itself or using strace it functions properly and exits appropriately.

Do you mind helping me with these errors? I feel I don't quite understand how the network fuzzer functionality works.

Error 1 Possible bad values for -t flag and -D flag?

When attempting to run the fuzzer:

afl-fuzz -i testcases/ -o findings/ -t 5000+ -D 1000 -N tcp://127.0.0.1:8080 -- ./netprog/tcpserver 8080

I receive the following error:

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

Following a netstat -an | grep 8080 I found this:

tcp    0    0 0.0.0.0:8080             0.0.0.0:*              LISTEN
tcp    0    0 127.0.0.1:32800       127.0.0.1:8080            TIME_WAIT

Error 2 Test case is simply a file containing the string "test string" How does the fuzzer send this data to the application?

Is the file parsed and the string data sent in an afl-formed TCP packet? OR Is the file itself sent?

When attempting to run the fuzzer:

afl-fuzz -i testcases/ -o findings/ -t 10000+ -D 5000 -N tcp://127.0.0.1:8080 -- ./netprog/tcpserver 8080

I receive the following error:

[-] PROGRAM ABORT : All test cases time out, giving up!
Location : perform_dry_run(), afl-fuzz.c:3240

Trying to determine if I need to tweak the application itself to be compatible with the fuzzer or if I don't quite understand how the network fuzzer works.

Thank you for your consideration.

[j-delaney]

You might get an answer here, but just so you know this is an unofficial mirror repo for AFL. You might have better luck posting this question on the afl-users Google Group. Everyone there is super friendly and helpful.

[jdbirdwell]

In the first case I suspect another process has a TCP listen socket on port 8080 and a wildcard IP address (listening on every network adapter on the machine, using IPv4). Check and see what processes are associated with those sockets.

In the second case yes, the entire contents of the file (up to a maximum number of bytes, if I remember correctly) is copied to the TCP stream (and is therefore in the payload of one or more packets - in this example, one). The failure probably occurs because the target is not exiting after receiving and processing the packet, causing a timeout. Use ncat (available in the nmap package if it's not already installed) to test your target code to be certain it receives the packet, exits, and gracefully closes the socket.

Yes, this is an old fork of the afl code because I've been tied up on a different project for several months and have not had the time to update it. I do, however, try to answer questions that are posted, and when the workload settles down I should be able to update this.

The Google group is great, but the official release doesn't support fuzzing across network connections (except by code modification or shims). The advantage of the official release's approach is it can be a lot faster. The disadvantage is ... one has to modify the code, which can introduce or mask flaws.

Doug Birdwell

On Thu, Jul 14, 2016, 6:29 PM J Delaney notifications@github.com wrote:

You might get an answer here, but just so you know this is an unofficial mirror repo for AFL. You might have better luck posting this question on the afl-users Google Group https://groups.google.com/forum/#!forum/afl-users. Everyone there is super friendly and helpful.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jdbirdwell/afl/issues/3#issuecomment-232811356, or mute the thread https://github.com/notifications/unsubscribe-auth/AOaIvUOTWGYrSgKkMMF4JbHHd2lO-IeUks5qVrhXgaJpZM4JMtO_ .

[jdbirdwell]

BTW, the delay parameter is in milliseconds. 1 and 5 seconds are ages to the processes. I understand the reason is to get it to work, but the shorter the delay, the more evaluations per unit time.

Doug Birdwell

On Thu, Jul 14, 2016, 7:00 PM Doug Birdwell birdwell@gmail.com wrote:

In the first case I suspect another process has a TCP listen socket on port 8080 and a wildcard IP address (listening on every network adapter on the machine, using IPv4). Check and see what processes are associated with those sockets.

In the second case yes, the entire contents of the file (up to a maximum number of bytes, if I remember correctly) is copied to the TCP stream (and is therefore in the payload of one or more packets - in this example, one). The failure probably occurs because the target is not exiting after receiving and processing the packet, causing a timeout. Use ncat (available in the nmap package if it's not already installed) to test your target code to be certain it receives the packet, exits, and gracefully closes the socket.

Yes, this is an old fork of the afl code because I've been tied up on a different project for several months and have not had the time to update it. I do, however, try to answer questions that are posted, and when the workload settles down I should be able to update this.

The Google group is great, but the official release doesn't support fuzzing across network connections (except by code modification or shims). The advantage of the official release's approach is it can be a lot faster. The disadvantage is ... one has to modify the code, which can introduce or mask flaws.

Doug Birdwell

On Thu, Jul 14, 2016, 6:29 PM J Delaney notifications@github.com wrote:

You might get an answer here, but just so you know this is an unofficial mirror repo for AFL. You might have better luck posting this question on the afl-users Google Group https://groups.google.com/forum/#!forum/afl-users. Everyone there is super friendly and helpful.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jdbirdwell/afl/issues/3#issuecomment-232811356, or mute the thread https://github.com/notifications/unsubscribe-auth/AOaIvUOTWGYrSgKkMMF4JbHHd2lO-IeUks5qVrhXgaJpZM4JMtO_ .

[ghost]

Thanks, I really appreciate the prompt reply.

I had the same suspicion about the timeout but didn't understand how the delay parameters were interpreted.

So my next question would be... Does the fuzzer want the application to exit and start back up again in between each fuzzing attempt being that the delay parameter is the duration of complete tear down and restart of the TCP server app? (as I imagine it would after crashing the app requires a new process, right?) OR Does the application continue to run - with a persistent listening socket - closes the client connection - then waits to accept a new connection thus the delay parameter for sending the subsequent fuzzed input?

Sorry for requesting additional clarification. I'm new to fuzz testing.

Thanks again for your help.

[jdbirdwell]

The first, but not quite. Afl has some nice tricks that avoid starting from scratch. But yes, the socket starts up each time. I typically got 300 or so executions per second.

On Thu, Jul 14, 2016, 8:09 PM tjcorwin notifications@github.com wrote:

Thanks, I really appreciate the prompt reply.

I had the same suspicion about the timeout but didn't understand how the delay parameters were interpreted.

So my next question would be... Does the fuzzer want the application to exit and start back up again in between each fuzzing attempt being that the delay parameter is the duration of complete tear down and restart of the TCP server app? (as I imagine it would after crashing the app requires a new process, right?) OR Does the application continue to run - with a persistent listening socket

• closes the client connection - then waits to accept a new connection thus the delay parameter for sending the subsequent fuzzed input?

Sorry for requesting additional clarification. I'm new to fuzz testing.

Thanks again for your help.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jdbirdwell/afl/issues/3#issuecomment-232827462, or mute the thread https://github.com/notifications/unsubscribe-auth/AOaIvXcy--rI0lbpYBtJSZ5TiqWPO0U-ks5qVs-_gaJpZM4JMtO_ .

[ghost]

Is there a current working instance of a simple server application that has been successfully fuzzed so I can reproduce and view what normal operating conditions show?

I ran strace on the fuzzer running the application and found the following:

After an initial successful base case run, the bind failure occurs...

setsockopt(9, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
bind(9, {sa_family=AF_INET, sin_port=htons(46334), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use)

I feel as if the setsockopt() call should read: setsockopt(9, SO_SOCKET, SO_REUSEADDR | SO_REUSEPORT, [1], 4) = 0 Am I wrong in this assumption?

Also, the server application is listening on port 8008, so the bind() call appears to be from the fuzzer on port 46334 which doesn't make sense to me. Only the server should be calling bind() for a TCP connection or is the fuzzer doing something else?

Running it through gdb now trying to figure out why it's calling bind().

Thank you for your consideration.

[stuartly]

I am trying the afl-network tool now, and I have a question about the hang problem of network application. Could you tell me your approach to handle the non-exiting problem of the protocol system when finishing processing a message ?

"Use ncat (available in the nmap package if it's not already installed) to test your target code to be certain it receives the packet, exits, and gracefully closes the socket." I do not see related code about ncat in afl-network, or we also need to modify the target code to solve the problem?

[jdbirdwell]

A target that hangs and does not release it clean up a socket is always going to be a problem and can not be fixed within afl. Ncat is a part of nmap, not afl-network. That is one way to test the target to be certain it exits gracefully. Yes, one often needs to modify the target.

On Sat, Jun 17, 2017, 12:43 PM stuartly notifications@github.com wrote:

I am trying the afl-network tool now, and I have a question about the hang problem of network application. Could you tell me your approach to handle the non-exiting problem of the protocol system when finishing processing a message ?

"Use ncat (available in the nmap package if it's not already installed) to test your target code

to be certain it receives the packet, exits, and gracefully closes the socket." I do not see related code about ncat in afl-network, or we also need to modify the target code to solve the problem?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jdbirdwell/afl/issues/3#issuecomment-309225939, or mute the thread https://github.com/notifications/unsubscribe-auth/AOaIvYXOYsFx3e2_aWaVffKFiEkB2CZNks5sFAIlgaJpZM4JMtO_ .

[stuartly]

Hi, I have tried afl-network to fuzz a server application successfully by modifying the target program, thus it could exit gracefully. But , I found that the stability is very low, (99%s -> 75%->25%). But when I fuzz the same target using preeny, the stability is always 100%. I have test the afl-network to ensure consistency of the processing of test case.

It will be grateful if you could give me some suggest to find out the reason of low stability and solve it, thanks.

[jdbirdwell]

Target failure rates may differ using afl-network and preeny since the methods used to transfer information between the target and afl are different. I can tell you that I have used afl-network against ntpd, sshd (openssh), and other network daemons, running millions of iterations over days of execution time without problems. How much time (delay) are you allowing for the target to respond? See if your failure rate goes down if you increase the delay. If it doesn't, check your patches to the target. My suspicion is the issue is in the target.

Thanks for using afl-network!

Doug Birdwell

On Mon, Jul 3, 2017 at 1:52 AM, stuartly notifications@github.com wrote:

Hi, I have tried afl-network to fuzz a server application successfully by modifying the target program, thus it could exit gracefully. But , I found that the stability is very low, (99%s -> 75%->25%). But when I fuzz the same target using preeny, the stability is always 100%. I have test the afl-network to ensure consistency of the processing of test case.

It will be grateful if you could give me some suggest to find out the reason of low stability and solve it, thanks.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jdbirdwell/afl/issues/3#issuecomment-312555182, or mute the thread https://github.com/notifications/unsubscribe-auth/AOaIvSyplsARe0tg764fFh05DX4p2gu6ks5sKIGggaJpZM4JMtO_ .