CMSC 414: Computer and Network Security (Univ. of Maryland) 1
Homework #2: Fuzzing Due February 17, 11:00 PM
Getting Set Up
This homework assignment uses Docker. Download the NEW FOR HW2! preconfigured Docker
image we have given you, available here: https://umd.box.com/s/kx6ii92l72ssvg7nh2q4dqx5v882qsnc
Once you download the docker image, you will need to load it as:
$ docker image load -i /path/to/ubuntu-hw2.tar
where /path/to/ is replaced by the location of ubuntu-hw2.tar. This command loads the docker image from the tarball, which you can view using the command docker images. You only need to load the image once.
Once you load the docker image, you can start a container using:
$ docker run –rm -it -v $(pwd):/opt ubuntu:hw2
The-itoptiontellsdockertostartaninteractiveshell,andthe-v /path/on/host:/path/on/container option mounts a directory on the host to a directory on the container. In the example command above,
we used the $(pwd) bash command to get the path of the current working directory and mounted all
files in it to the directory /opt on the container.
This is the image we will use for testing your submissions. If it doesn’t work on that image, you will get no points. It makes no difference if your submission works on another Ubuntu version (or another OS).
Starter files
Starter files are available at:
https://umd.box.com/s/z049kl75sqvc1lc2pdgvtx4uds2p6war
Task 1: AFL Warmup
In this task you will run the afl fuzzer on a simple program fun.c. afl is already installed in the docker image. Once you start the docker container, compile fun.c using afl-gcc as follows:
$ CC=afl-gcc make
Next we need to set up the input and output directories for afl to use. The input directory stores sample inputs called the input corpus to the program we want to fuzz, and the output directory stores the output of running afl including inputs that crash the program and other useful information. We provide an initial input corpus (which in this case is just one file) called testin. In order to make the input and output directories and copy testin to the input directory run:
CMSC 414: Computer and Network Security (Univ. of Maryland) 2
$ mkdir task1-in task1-out
$ cp testin task1-in/
Now that we have the directories set up, we are ready to use afl. Note that fun.c reads input from a file, so we need to use the special symbol @@ to indicate that to the afl-fuzz command. In order to run the afl fuzzer do:
$ afl-fuzz -i task1-in -o task1-out /opt/task1/fun @@ (Assuming you mounted your code files in /opt on the docker container)
After you run the command, the fuzzer should take about 2-3 minutes to find a crash. Once the fuzzer finds a crash, you can stop afl using Ctrl+C.
afl will place inputs that crash the program under task1-out/crashes. Run the program using
the bad input file (the filename should start with something similar to id:000000,sig:06,src:000000.., although some of the values might be different for you) as follows:
$ ./fun task1-out/crashes/
Typically, tab-completion should work once you type task1-out/crashes/id followed by the
Tab key in the command above.
Running the command should result in the program aborting with the message Aborted. Take a screenshot of the command and the message and name it task1_screenshot.
Create a file called task1.txt and write one paragraph about the bug you found and why it causes a crash.
Submit task1_screenshot.
Task 2: Writing a harness
Sometimes we cannot directly fuzz a program or library. We need a harness to enable automated fuzzing of our test program. A harness is a program that takes input from STDIN, calls the functions in our test program, and exits.
In this task, you will write a simple harness for a program we provide called important.c, and use the harness with afl to find inputs that crash the test program. To get you started we have provided a template for the harness in task2/harness.c along with a Makefile that compiles it.
The code that you will be writing a harness for is provided in task2/important.c has a function passwd with an intentional bug as shown below:
int passwd(char *data, size_t len) {
if(strlen(data) < 6) {return 0; } unsigned ok;
CMSC 414: Computer and Network Security (Univ. of Maryland) 3
if(!ok)
ok = len;
if(data[0] == if(data[1] ==
)
)
if(data[2] == if(data[3] ==
)
'o'
'b'
'i'
'w'
)
if(data[4] == if(data[5] ==
}
return 0; }
After you write your harness, compile it, create the input and output directories, and place an initial input file in the input directory, run afl-fuzz the same way as Task 1 but this time without the @@ symbol since the harness takes input from STDIN.
$ CC=afl-gcc make
$ afl-fuzz -i task2-in -o task2-out /opt/task2/harness
Take a screenshot of AFL running that shows AFL having found the crash. Call the file task2_screenshot.
Submit the following four files:
• Your edited harness.c
• The initial input file you created, which you should name task2_in
• The screenshot of AFL running, task2_screenshot.
• The bad-input file generated by AFL to document the crash. Rename it to task2_out.
Task 3: Fuzzing a binary
You are given two binary files of an extremely bug ridden program. One is compiled with AFL (called yoda-afl) and the other compiled using standard gcc with -m32 -g flags enabled (called yoda-gcc). Your job is to produce an input corpus that will allow AFL to find vulnerabilities in this program quickly.
Your input corpus should be set up so that it covers all the branches of code. You can use gdb and the 32bit binary provided (yoda-gcc) to figure out what to put in your input corpus. Your input corpus will likely need to be more than one individual file.
When you have a good (start to your) input corpus, AFL will start finding vulnerabilities (use yoda-afl to run with afl-fuzz). AFL may or may not find all the vulnerabilities of the program. You will be graded on your input corpus, which should cover all the branches of code, as well as the crashes you find. (For full credit for the crashes, you will need to find at least two different bugs; if you find more
‘a’
){
raise(SIGSEGV); //Bug
)
‘n’
CMSC 414: Computer and Network Security (Univ. of Maryland) 4
than two you may receive extra credit.)
Take a screenshot of AFL running though the code, showing it having found at least two crashes. Name
the screenshot task3_screenshot.
Create a file called task3.txt and write one paragraph about the how you designed your input cor-
pus and why it works.
Create a tarball of your input corpus and afl output directories as follows:
$ tar -cvzf task3_in_out.tgz in/* out/crashes/id*
(Assuming your input and output directories are called in and out respectively. If you named them
something else, substitute those names in the command above)
Submit the following:
• task3_screenshot.
• task3.txt
What to submit
You will submit this homework via ELMS.
Submit the following files:
Required:
1. Task1:
• task1/task1_screenshot.
• task1/task1.txt
2. Task 2:
• task2/harness.c
• task2/task2_in
• task2/task2_screenshot.
3. Task 3:
• task3/task3_screenshot.
• task3/task3.txt
Before you prepare your submission tarball, change directories to the directory that contains the folders task1, task2, and task3. Prepare your submission tarball with the following command:
CMSC 414: Computer and Network Security (Univ. of Maryland) 5
$ tar -czvf
task1/task1_screenshot.
task2/harness.c task2/task2_in task2/task2_screenshot.
task2/task2_bad_input \
task3/task3_screenshot.
This is one command. The \ character tells the shell that the command continues on the next line. Submit
Note: Only the latest submission counts. Grading Rubric:
Task
Points
1 2 3
20 35 45