A4: Fuzzing and Fixing Programs

Authored by Professor Gang Tan of Penn State University. Slightly adjusted by Jie Zhou for this course.

In this project, you will use AFL to perform fuzzing on a vulnerable program and find inputs that crash the program. From the crashing inputs, you will then manually locate the errors in the program and fix those errors.

Part 0

Build and install American Fuzzy Lop (AFL) 2.52b under your user account on the Linux Lab machines. AFL is easy to build; download the source tarball and follow the quick start guide for building it. Its installation and running do not require root access. After installation, do a quick test following our course slides to make sure AFL installs and runs correctly.

If you have your own Linux machine, you can also install AFL++ and do this homework using AFL++, which runs faster than AFL.

Part 1: Fuzz testing on a vulnerable program (3 points)

Perform AFL fuzz testing on this vulnerable program. The program takes from stdin an input in one of the two forms:

  • “u N string”, where N is a number; when receiving an input of this form, the program outputs back the string, except with the letters in the first N characters of the string converted to the corresponding upper case letters. For example, for “u 5 abcdefg”, the output should be “ABCDEfg”.

  • “head N string”; when receiving an input of this form, the program outputs back the first N characters of the string. For example, for “head 5 abcdefg”, the output should be “abcde”.

Fuzz the vulnerable program by compiling the program using afl-gcc, setting up initial seeds, and performing a fuzzing campaign. Notes:

  • Setting up a good Makefile would help you automate the process. Also note that vulnerable.c takes input from stdin, while the examples in class take file names from command line and read from files. So you should read the AFL manual to find out the right syntax for fuzzing programs that take input from stdin.
  • For fuzzing, create a directory called testcase and put some test files in there. Your test files should cover the two forms of the input. E.g., one for “u 5 abcdefg” and one for “head 5 abcdefg”.
  • Each fuzzing campaign should be given sufficient time (e.g., 60 minutes).

Part 2: Isolating and fixing the bugs (10 points)

  • After a fuzzing campaign, AFL gives a set of inputs, if there are any, that make the program crash or hang (under the crashes and hangs sub-directories of the output directory). Inspect those directories to find those inputs and use them to run the vulnerable program and figure out where the bugs are; this may involve inserting extra debugging code (such as printf) into the program.
  • Once errors are isolated, manually fix the vulnerable program by changing its code. Some of the crashes/hangs may be caused by the same bug; so one fix may cover multiple crashes/hangs. Please record a mapping between crashes/hangs and fixes in your report.

Part 3: Repeating parts 1 and 2 for multiple rounds (2 points)

After one round of bug fixing, repeat Part 1 to find more crashing/hanging inputs on the fixed program. If AFL finds more crashing/hanging inputs, repeat Part 2. Repeat this process for multiple rounds until AFL can no longer find crashing/hanging inputs after a sufficiently long fuzzing campaign.

What you need to submit

Please submit a zipped or tarball file with the following files:

  • A report. It should describe how many rounds you did for part 1 and part 2. For each round, it should have the following information. For part 1: (1) how long was the fuzzing process; (2) how many inputs AFL found that could make the program crash or hang. For part 2: (1) describe your process of identifying bugs from AFL-generated inputs and what bugs you found in the program; (2) describe how you fixed the bugs and why your fixes worked.
  • For each round of part 1, provide a copy of “fuzzer_stats” file produced by AFL, and a copy of the crashes and hangs directories under the output directory created by AFL. Put these data under clearly labeled subdirectories in your zipped file such as “round1”, “round2”, etc.
  • The final copy of your fixed vulnerable.c.

Submit your work through Blackboard. It’s due on October 29th by midnight.