[Solved] Smashing lab

This assignment investigates an old-fashioned way of breaking into systems executing x86 machine code, along with a couple of machine-level defenses against this attack. Its chosen not to give you a toolkit to break in to other sites the method is well-known and ought to be commonly defended against nowadays but instead, to give a general idea of how an attacker can break into a system by exploiting behavior that is undefined at the C level but defined at the machine level, and what we can do about it at the machine level.

Useful pointers

• Elias Levy a.k.a. Aleph One, Smashing the stack for fun and profit, Phrack 7, 49 (1996-11-08), file 14
• Jake Edge, Strong stack protection for GCC, LWN.net (2014-02-05).
• Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitry Vyukov, AddressSanitizer: a fast memory error detector (2012)

Keep a log

Keep a log in the file smashinglab.txt of what you do in the lab so that you can reproduce the results later. This should not merely be a transcript of what you typed: it should be more like a true lab notebook, in which you briefly note down what you did and what happened. The log should help us verify that youve done the steps listed below, so that we can in principle reproduce them. For example, if one of the steps says get a backtrace, make sure the backtrace goes into the log.

Thats a nice little program you got there. Shame if anything were to happen to it

Consider the following patch to sthttpd. This patch applies to sthttpd 2.27.0, and deliberately introduces a bug into it. The idea is to suppose the the original programmer wrote this version by mistake.

--- sthttpd-2.27.0/src/thttpd.c	2014-10-02 15:02:36.000000000 -0700+++ sthttpd-2.27.0-delta/src/thttpd.c	2015-04-30 19:15:24.820042000 -0700@@ -999,7 +999,7 @@ static void read_config( char* filename )     {     FILE* fp;-    char line[10000];+    char line[100];     char* cp;     char* cp2;     char* name;@@ -1012,7 +1012,7 @@ read_config( char* filename ) 	exit( 1 ); 	}-    while ( fgets( line, sizeof(line), fp ) != (char*) 0 )+    while ( fgets( line, 1000, fp ) != (char*) 0 ) 	{ 	/* Trim comments. */ 	if ( ( cp = strchr( line, '#' ) ) != (char*) 0 )

Steps to illustrate and defend against the bug

1. Make sure that /usr/local/cs/bin is at the start of your PATH; the command which gcc should output /usr/local/cs/bin/gcc.
2. Build 32-bit sthttpd with this patch applied. Configure it with the shell command:

   ./configure    CFLAGS='-m32'    LDFLAGS="-Xlinker --rpath=/usr/local/cs/gcc-$(gcc -dumpversion)/lib"

   Compile it three times, with the following sets of compiler options:

   (SP) for strong stack protection:

   -m32 -g3 -O2 -fno-inline -fstack-protector-strong

   (AS) for address sanitization:

   -m32 -g3 -O2 -fno-inline -fsanitize=address

   (NO) for neither:

   -m32 -g3 -O2 -fno-inline

   Call the resulting executables src/thttpd-sp, src/thttpd-as, and src/thttpd-no. You can do this with, for example, the command make clean followed by make CFLAGS=-m32 -g3 -O2 -fno-inline -fstack-protector-strong and then by mv src/thttpd src/thttpd-sp and similarly for the other two variants.

3. Run each of the modified sthttpd daemons on port (12330 + 3 * (X % 293) + Y) on one of the SEASnet GNU/Linux servers, where X is your 9-digit student ID and Y is either 1, 2, or 3 depending on which variant of the daemon youre running (1=SP, 2=AS, 3=NO). For example, if your student ID is 123-456-789, (12330 + 3 * (123456789 % 293) + 1) equals 12532, so you can run the command src/thttpd-sp -p 12532 -D; the -p option specifies the port number and the -D is for debugging. You may find the thttpd man page useful.
4. Verify that your web servers work in the normal case. You can use the curl command to do this, e.g., the shell command curl http://localhost:12532/foo.txt where foo.txt is a text file in the working directory of your HTTPD server. The shell command man curl will give you more information about curl.
5. Make variant SP crash by invoking it in a suitable way. Run it under GDB, and get a backtrace immediately after the crash. Identify which machine instruction caused the crash, and why.
6. Make variant AS crash by invoking it in a similar way. Similarly, get a backtrace for it, and identify the machine instruction that crashed it and wy.
7. Likewise for variant NO.
8. Generate the assembly language code for thttpd.c three times, one for each variant, by using gcc -S rather than gcc -c -g3 when compiling the file. (Use the same -O and -f flags as before.) Call the resulting files src/thttpd-sp.s and src/thttpd-as.s and src/thttpd-no.s. Compare the three assembly-language files implementations of the handle_read function. Describe the techniques used by -fstack-protector-strong and -fsanitize=address to prevent buffer-overrun exploits in handle_read.
9. Build an exploit for the bug in variant NO that relies on the attacker tricking the victim into invoking thttpd with a particular value for the -C option. (Admittedly this is not much of an exploit, but we dont want you to have to put more easily exploitable HTTP servers on our network.) Your exploit should cause the victim web server to remove the file target.txt in the working directory of the web server. Or, if such an exploit is impossible, explain why not, and investigate simple ways to alter the compiler flags (or, in the worst case, to insert plausible bugs into the source code) to make the exploit possible.

Submit

Submit the files smashinglab.txt, thttpd-sp.s, thttpd-as.s, and thttpd-no.s as described above, along with any other files needed to explain your exploit.

All text files should be ASCII files, with no carriage returns, and with no more than 200 columns per line. For example, the shell command

expand smashinglab.txt thttpd-sp.s thttpd-as.s thttpd-no.s |  awk '/r/ || 200 < length'

should output nothing.