Released Tuesday, February 9, 2016
Part 1 due Wednesday, February 17, 2016, 10:00 PM
Parts 2 and 3 due Wednesday, February 24, 2016, 10:00 PM
This lab is the first of a sequence that will give you practical experience with common attacks and counter measures. To make the issues concrete, you will explore the attacks and counter measures in the context of the zoobar web application.
These labs adapt assignments from MIT's 6.858, which extend assignments developed in Stanford's CS155. Much of the description below is borrowed from 6.858.
This lab will introduce you to buffer overflow vulnerabilities, in the context of a web server called zookws. The zookws web server is running a simple python web application, zoobar, where users can transfer "zoobars" (credits) between one another. You will find buffer overflows in the zookws web server code, write exploits for the buffer overflows to inject code into the server, and figure out how to bypass stack canaries and non-executable stack protection (for extra credit). Later labs look at other security aspects of the zoobar and zookws infrastructure.
Each lab requires you to use a new programming language or some other piece of infrastructure. For example, in this lab you must acquaint yourself with certain aspects of the C language, x86 assembly language, and gdb. The infrastructure in these labs is "overhead" that stems from the goal of having you understand attacks and defenses in realistic situations. Furthermore, you often need to understand this new infrastructure in detail. This is because security weaknesses often show up in corner cases, so you need to understand those corner cases to craft exploits and design defenses.
These two factors (new infrastructure and details) can make the labs time consuming. We have two pieces of advice here. First, work on the labs daily (or at least regularly) for a limited time, instead of trying to do all exercises in a single shot before the deadline. Second, try hard to understand the necessary details, instead of muddling your way through the exercises; it will make the exercises go much faster. If you get stuck on a detail, post a question on Piazza.
Some notes:
Several labs, including this lab, ask you to design exploits. These exploits are realistic enough that you might be able to use them for a real attack, but you should not do so. The point of the designing exploits is to teach you how to defend against them, not how to use them. Attacking computer systems is illegal (see NYU network rules) and can get you into serious trouble. Don't do it.
This assignment may be completed pair programming-style. Pair programming means that both of you should be at the screen, together. Take turns with the keyboard, passing it back and forth. (This is really the only way to learn this stuff. It won't work to split up the exercises.) Only one member of each pair should submit. The class's collaboration policies remain in effect, with "you" now referring to your team. (This means, among other things, that you cannot work in groups larger than a pair.)
This lab will require some python programming. The tutorial here provides a brief walkthrough of Python's features if you're unfamiliar with the language.
This lab will be performed on the virtual devbox you set up in lab 0. Explicit instructions on how to start the devbox can be found here. As before, we suggest you use ssh to connect to the virtual machine once it has been started.
The instructions below assume that your lab materials will be stored in ~/labs. You can place them elsewhere (none of our scripts explicitly on this absolute path); if you take that option, you will need to modify the sample commands.
To get the lab materials, do the following from the terminal of your virtual machine:
$ mkdir ~/labs $ cd ~/labs # For the following, replace <user> with the github username # you submitted in lab 0. $ git clone https://github.com/nyu-cs480-16sp/<user>-labs.git . Cloning into '.'... Username for 'https://github.com': <user> Password for 'https://<user>@github.com': remote: Counting objects: 133, done. remote: Total 133 (delta 0), reused 0 (delta 0), pack-reused 133 Receiving objects: 100% (133/133), 79.33 KiB | 0 bytes/s, done. Resolving deltas: 100% (48/48), done. Checking connectivity... done. $ git checkout lab2 $ _
Before you proceed with this lab assignment, make sure you can compile the zookws web server:
$ cd lab2 $ make cc zookld.c -c -o zookld.o -m32 -g -std=c99 -Wall -Werror -D_GNU_SOURCE -fno-stack-protector cc http.c -c -o http.o -m32 -g -std=c99 -Wall -Werror -D_GNU_SOURCE -fno-stack-protector cc -m32 zookld.o http.o -lcrypto -o zookld cc zookfs.c -c -o zookfs.o -m32 -g -std=c99 -Wall -Werror -D_GNU_SOURCE -fno-stack-protector cc -m32 zookfs.o http.o -lcrypto -o zookfs cc zookd.c -c -o zookd.o -m32 -g -std=c99 -Wall -Werror -D_GNU_SOURCE -fno-stack-protector cc -m32 zookd.o http.o -lcrypto -o zookd cp zookfs zookfs-exstack execstack -s zookfs-exstack cp zookd zookd-exstack execstack -s zookd-exstack cp zookfs zookfs-nxstack cp zookd zookd-nxstack cc zookfs.c -c -o zookfs-withssp.o -m32 -g -std=c99 -Wall -Werror -D_GNU_SOURCE cc http.c -c -o http-withssp.o -m32 -g -std=c99 -Wall -Werror -D_GNU_SOURCE cc -m32 zookfs-withssp.o http-withssp.o -lcrypto -o zookfs-withssp cc zookd.c -c -o zookd-withssp.o -m32 -g -std=c99 -Wall -Werror -D_GNU_SOURCE cc -m32 zookd-withssp.o http-withssp.o -lcrypto -o zookd-withssp cc -m32 -c -o shellcode.o shellcode.S objcopy -S -O binary -j .text shellcode.o shellcode.bin cc run-shellcode.c -c -o run-shellcode.o -m32 -g -std=c99 -Wall -Werror -D_GNU_SOURCE -fno-stack-protector cc -m32 run-shellcode.o -lcrypto -o run-shellcode rm shellcode.o $ _
The zookws web server consists of the following components.
After zookld launches configured services, zookd listens on a port (8080 by default) for incoming HTTP requests and reads the first line of each request for dispatching. In this lab, zookd is configured to dispatch every request to the zookfs service, which reads the rest of the request and generates a response from the requested file. Most HTTP-related code is in http.c.
You can run the web server using one of three configurations:
The *-exstack binaries have an executable stack, which makes it easier to inject executable code, given a stack buffer overflow vulnerability. The *-nxstack binaries have a non-executable stack, which is more challenging to exploit (exploiting these binaries will be extra credit). Last, the *-withssp binaries use stack canaries (and have a non-executable stack); this adds yet another challenge, and exploiting this setup will be further extra credit.
To run the web server in a predictable fashion – so that its stack and memory layout is the same every time – you will use the clean-env.sh script. This is the same way we will run the web server during grading, so please make sure all of your exploits work for this configuration.
We have provided reference binaries of zookws in bin.tar.gz. We will use them for grading, so make sure your exploits work on them. (This might be of concern if/when you modify code during later parts of the lab.)
Make sure you can run the zookws web server and gain access to the zoobar web application from a browser running on your machine, as follows. First, start the web server, and second, use /sbin/ifconfig/ to get the IP address of the virtual machine:
$ ./clean-env.sh ./zookld zook-exstack.conf
$ /sbin/ifconfig eth0
eth0 Link encap:Ethernet HWaddr 08:00:27:19:99:1a
inet addr:192.168.56.101 Bcast:192.168.56.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe19:991a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:757 errors:0 dropped:0 overruns:0 frame:0
TX packets:592 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:65439 (65.4 KB) TX bytes:77035 (77.0 KB)
Third, open your browser and point it to a URL that you construct from the IP address. In this example, it would be http://192.168.56.101:8080/. If something doesn't seem to be working, try to figure out what went wrong or contact the course staff before proceeding further.
In the first part of this lab assignment, you will find buffer overflows in the provided web server.
Exercise 0. If you have not already, read in detail Aleph One's article, Smashing the Stack for Fun and Profit, to learn (a) how to identify buffer overflows (this is the important part for this week) and (b) how to exploit them (which you need for the next week's part). A thorough understanding of this article will be critical in this lab.
Now, you will start developing exploits to take advantage of the buffer overflows you have found above. We have provided template Python code for an exploit in ~/labs/lab2/exploit-template.py, which issues an HTTP request. The exploit template takes two arguments, the server name and port number, so you might run it as follows to issue a request to zookws running on localhost. (The caption runs the server and the exploit in one terminal. However, we suggest using two terminals side-by-side, and in that case, you do not need the '&' in the first command.)
# Start the server $ ./clean-env.sh ./zookld zook-exstack.conf & [1] 2676 # Issue the request via the 'exploit-template' script $ ./exploit-template.py localhost 8080 HTTP request: GET / HTTP/1.0 ... $
The word localhost is a hostname that means this host. It is effectively the "address" of the machine on which it is used.
You are free to use this template, or write your own exploit code from scratch. Note, however, that if you choose to write your own exploit, the exploit must run correctly inside the provided virtual machine.
You will find gdb useful in building your exploits. As zookws forks off many processes, it can be difficult to debug the correct one. The easiest way to do this is to run the web server ahead of time with clean-env.sh and then attach gdb to an already-running process with the -p flag. To help find the right process for debugging, zookld prints out the process IDs of the child processes that it spawns. You can also find the PID of a process by using pgrep; for example, to attach to zookd-exstack, start the server and, in another shell, run
# While the server is running ... $ gdb -p $(pgrep zookd-exstack) ... 0x4001d422 in __kernel_vsyscall () (gdb) break <your-breakpoint> Breakpoint 1 at 0x1234567: file zookd.c, line 999. (gdb) continue Continuing.
Keep in mind that a process being debugged by gdb will not get killed even if you terminate the parent zookld process using ^C. If you are having trouble restarting the web server, check for leftover processes from the previous run, or be sure to exit gdb before restarting zookld.
When a process being debugged by gdb forks, by default gdb continues to debug the parent process and does not attach to the child. Since zookfs forks a child process to service each request, you may find it helpful to have gdb attach to the child on fork, using the command set follow-fork-mode child. We have included a .gdbinit file that automatically sets this option for you whenever you run gdb from the ~/labs/lab2 directory. You may wish to add other commands to the file or move/copy the file.
For this and subsequent exercises, you may need to encode your attack payload in different ways, depending on which vulnerability you are exploiting. In some cases, you may need to make sure that your attack payload is URL-encoded; that is, use + instead of space and %2b instead of +. Here is a URL encoding reference. You can also use quoting functions in the python urllib module to URL encode strings. In some cases, you may need to include binary values into your payload. The Python struct module can help you do that. For example, struct.pack("<I", x) will produce a 4-byte (32-bit) binary encoding of the integer x.
Write exploits that trigger them. Trigger here does not mean injecting code (yet). Your only job in this exercise is to overwrite memory (with junk), consistent with the requirements immediately above. Verify that your exploit actually corrupts memory by either checking the last few lines of dmesg | tail, using gdb, or observing that the web server crashes.
Provide the code for the exploits in files called exploit-2a.py and exploit-2b.py, and indicate in answers.txt which buffer overflow each exploit triggers.
Note that some of the vulnerabilities in Exercise 1 may be more or less easy to exploit. If you find yourself having difficulty exploiting a given vulnerability, choose a different one from Exercise 1; in the extreme case, back up, and modify (or enhance) your answer to Exercise 1.
Along the way, use gdb to set a breakpoint where you expect your exploit to be triggered. As you work, use gdb to step through the server's execution and explore the state of the process both before and after your exploit is triggered. You can use the backtrace command (bt) to print the stack frames line-by-line. By doing this, you confirm you're exploiting the vulnerability you think you are.
For exploit 2a, provide (in answers.txt) the results of two backtrace commands, each issued after the vulnerable line. One backtrace should be gathered when an innocuous request has been sent; the other backtrace should be gathered after exploit 2a has been sent. There should be a clear difference between the two traces: for the regular request, the stack should be "as you expect it", whereas for the malicious request, the stack should show that the return address has been tampered with.
For exploit 2b, use other gdb commands as appropriate (info reg, x, print, etc.) to demonstrate that an exploit has had the effect that you have predicted. You should again provide in answers.txt two "traces" (which could be memory or register dumps) after the vulnerable line: one when an innocuous request has been sent, and one when exploit 2b has been sent.
You can check whether your exploits crash the server as follows:
$ cd ~/labs/lab2 $ make check-crash
Here is a checklist for before you submit:
$ git add <new file 1> <new file 2> ...
$ git commit -am "My submission for lab 2 part 1" ... $ git push origin master # Prompts for username and password Counting objects: ... .... $ _
In this part, you will use your buffer overflow exploits to inject code into the web server. In particular, one of your exploits will be used to link a sensitive file, ~/labs/secret/grades.txt, to a public location, ~/labs/lab2/zoobar, and the other will unlink the new file to remove evidence. (This models an attacker who uses an exploit to exfiltrate a sensitive file, and then another exploit to remove the evidence.) The link function can be used to create a link between an existing file and a new file path/name. Similarly, unlink removes the link to a file, effectively deleting it (assuming no other links to the file exist). See man 2 link and man 2 unlink for more information on these system calls.
You will use the *-exstack binaries, as their stack is executable, which makes it easier to inject code. The zookws web server should be started as follows:
$ cd ~/labs/lab2 $ ./clean-env.sh ./zookld zook-exstack.conf
You will develop each exploit in two steps: write shell code that performs the desired operation (link or unlink), then embed the compiled code into an HTTP request that triggers the buffer overflow on the server.
When writing shell code, it is often easier to use assembly language rather than other higher-level languages, such as C. This is because the exploit usually needs fine control over the stack layout, register values and code size; meanwhile, the C compiler generates additional function preludes and performs various optimizations, and these things make the compiled binary code unpredictable.
We have provided Aleph One's shell code for you to use in ~/labs/lab2/shellcode.S along with Makefile rules that produce ~/labs/lab2/shellcode.bin, a compiled version of the shell code. Aleph One's exploit is intended to exploit setuid-root binaries, and thus it runs a shell. You will need to modify this shell code to instead link/unlink.
To help you develop your shell code for this exercise, we have also provided a program called run-shellcode that will run your binary shell code, as if you correctly jumped to its starting point. For example, running it on Aleph One's shell code will cause the program to execve("/bin/sh"), thereby giving you another shell prompt:
$ ./run-shellcode shellcode.bin
When developing an exploit, you will have to think about what values are on the stack, so that you can modify them accordingly. For your reference, here is what the stack frame of some function foo looks like; here, foo has a local variable char buf[256]:
STACK +------------------+ MEMORY
| ... |
| | stack frame of | /|\
| | foo's caller | |
| | ... | |
| +------------------+ |
| | return address | (4 bytes) |
| | to foo's caller | |
| +------------------+ |
| %ebp ------> | saved %ebp | (4 bytes) |
| +------------------+ |
| | ... | |
| +------------------+ |
| | buf[255] | |
| | ... | |
\|/ buf ------> | buf[0] | |
+------------------+
Note that the stack grows down in this figure, and memory addresses are increasing up.
When you're constructing an exploit, you will often need to know the addresses of specific stack locations, or specific functions, in a particular program. The easiest way to do this is to use gdb. For example, suppose you want to know the stack address of the pn[] array in the http_serve function in zookfs-exstack, and the address of its saved %ebp register on the stack. You can obtain them using gdb as follows: