Experiencing Fuzzing

In this project, you will use AFL to perform fuzzing on your program written for homework 3 and fix your program if AFL finds errors in it. You must do this project on the Westgate Linux lab machines. These machines are named cse-p204instXX.cse.psu.edu, where XX is a number between 01 and about 40.

Project tasks

Part 1 (6 points): Fuzz testing on your homework 3 client code

After downloading the project tarball, replace transfer.c with your own version in homework 3. Please also modify the transfer_file function in transfer.c to comment out the line "wait_message( sock, &hdr, block, EXIT )" toward the end of the function so that the client does not wait for messages from the server.

You will also need to modify the Makefile to change its AFLDIR variable to point to the directory where your AFL is installed. Invoke "make" to build the executables; the Makefile in the tarball invokes afl-gcc for compilation (instead of gcc). As mentioned earlier, in this project we will use only the executable for the client, not the server.

For fuzzing, first create a directory called testcase and put some test files there. Then invoke "make aflfuzz" to start fuzzing; it will find test files under testcase and put the result under the directory called output. You should have a look at the Makefile to see how "make aflfuzz" works; it sets up some environment variables and fuzz the client program with specified input and output directories.

You should run a fuzzing campaign that lasts between 2 and 3 hours. If it is going slower, you should look at your crashes; there may be a bug you need to fix that is preventing it from executing paths.

There is always a possibility that AFL cannot find any bugs in your program. After all, the fuzzing process is probabilistic and your program may be bug free! If you cannot find any bugs through AFL, you should manually inject some memory-corruption bugs into your program and repeat the process; for example, make a malloc allocate one less space than needed, free a buffer before a use, inject a format-string error, etc.

Part 2 (4 points): Fixing the bugs

What AFL gives is a set of inputs that make the program crash or hang (under the crashes and hangs sub-directories of the output directory). So you will need to manually run such an input on your program and figure out the bug before doing the fix; this may involve inserting extra debugging code (such as printfs) into the program. Once the bug is identified (e.g., not allocating a big-enough buffer or missing some input validation), fix your code accordingly.

If you manually injected bugs in part 1, then in your report just describe how you would identify those injected bugs from the AFL-generated inputs.

What do you need to submit?

• For part 1, provide a copy of "fuzzer_stats" file produced by AFL.
• For part 1, provide a copy of the crashes and hangs directories under the output directory created by AFL.
• A report. It should describe both of your part 1 and part 2 experience. For part 1: (1) how long was the fuzzing process; (2) how many inputs AFL found that could make the program crash or hang; (3) did you have to remove assertions in your program or adjusting your code to make the fuzzing process smooth? (4) if you manually injected some bugs, describe where and how you did that and the result of AFL fuzzing after injection. For part 2: (1) describe your process of identifying bugs from AFL-generated inputs; (2) describe how you fixed the code and why the fix would address the corresponding bug.

Author: Gang Tan, Penn State University, 2019. All rights reserved.