CSci 4271 Lab 4

Today's lab will again focus on building a memory-safety attack, but now in the context of a larger program where you need to search to find a good vulnerability to attack. We've given you an extended version of the Badly Coded Print Server code that you previously saw in class. Your end goal is to attack the program, taking over its control flow. But first you need to find a vulnerability that allows that attack (this is auditing, which you started on earlier), then understand what control you have over the program's memory, and plan the attack accordingly.

Your attack should overwrite a return address to return control to a function that is otherwise not accessible during the program run, named attack_function. Go through the program first to understand the control flows, then identify the vulnerable functions that you can potentially attack. Often it is a good plan to first check that you can control the program to the point where the vulnerable function segfaults. Then after that adjust the input that causes a crash so that causes a jump to the attacker's target instead. Transferring control to the attack_function serves as a proxy for transferring control to shellcode that would be used in a more complete attack: if you can make the control flow go to some "shellcode" that's already in the program, the same technique would also allow transfers anywhere else the attacker wanted.

To get some experience with both phases, we recommend that you spend about the first 15 minutes of the lab period auditing the program and deciding which vulnerability it would be easiest to attack, and then the rest of the time constructing an attack. On a separate page that we'll suggest you look at after 15 minutes have elapsed, will give you our suggestion about which vulnerability to attack.

The bclpr.c program that you will run today has been slightly modified from the one we previously looked at in class, so that you can try attacks out by running it and not just read the code. This version doesn't need to be installed using root access, and we've confirmed that the bugs are still vulnerable when compiled to x86-64 (the original version from several years ago was x86-32).

You can copy the program source code to your working directory using a similar command as in previous labs:

cp /web/classes/Spring-2022/csci4271/labs/04/bclpr.c .

Because this is a simulation of a program that would be installed in a system-wide location if you controlled the full computer, we need to do a bit more to simulate "installing" it so that it will run correctly. As a location that you will have access to but will be unique even on a shared computer, we recommend that you compile and install the program to a location similar to /tmp/bclpr-goldy007, but where goldy007 is replaced with your UMN ID. /tmp is a directory for temporary files that everyone has access to, while using your UMN ID makes it unique. You'll need to make this change both on line 24 of the source that defines the INSTALL_PREFIX macro and in the commands below that create directories the program will use:

gcc -no-pie -z execstack -g -Wall -Wno-format-security -fno-stack-protector bclpr.c -o bclpr
mkdir -p /tmp/bclpr-goldy007/spool/lp0
mkdir -p /tmp/bclpr-goldy007/printouts/lp0

This is a simplified simulation of print server program which will ask for the pathname of the file that you want to print. For instance if you have a text file named hello.txt you can use the command ./bclpr hello.txt to simulate printing the file. The contents of the directory /tmp/bclpr-goldy007/printouts/lp0 (but again with your username) holds the output of the simulated printer.

You can tell that your attack has been successful if you see the following message printed:

...You have successfully completed the attack...

This code contains several buffer-overflow vulnerabilities, as well as at least one non-buffer-overflow vulnerability that could also be applied to hijack control flow. But since we have limited time in lab, we recommend you start by the vulnerability that looks like it would be easiest to exploit.

Once you've gotten to this point in the lab instructions, we recommend that you audit the code looking for vulnerabilities until 15 minutes into the lab. After that time, compare your attack plans to the ones mentioned in the next page and then carry out your attack.