Assignment 9. Buffer overruns

Useful pointers

Laboratory: Exploiting a buffer overrun

As usual, keep a log in the file lab.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.

For this laboratory, you will find and exploit a simple buffer overrun in a web server.

Consider the following patch to sthttpd. This patch applies to sthttpd 2.27.0.

--- sthttpd-2.27.0/src/thttpd.c	2014-10-02 15:02:36.000000000 -0700
+++ sthttpd-2.27.0-delta/src/thttpd.c	2015-03-02 08:03:12.295880387 -0800
@@ -1604,7 +1604,7 @@ handle_read( connecttab* c, struct timev
     /* Read some more bytes. */
     sz = read(
 	hc->conn_fd, &(hc->read_buf[hc->read_idx]),
-	hc->read_size - hc->read_idx );
+	hc->read_size );
     if ( sz == 0 )
 	{
 	httpd_send_err( hc, 400, httpd_err400title, "", httpd_err400form, "" );
  1. Build sthttpd with this patch applied, and run the modified thttpd daemon on port 8080 on your host. You may find the thttpd man page useful.
  2. Verify that your web server works in the normal case.
  3. Make your web server crash by sending it a suitably-formatted request.
  4. Run your web server under GDB, and get a traceback immediately after the crash.
  5. Briefly describe how you'd go about building a remote exploit for the bug in the modified thttpd. Your exploit should allow you to conduct a highly-effective denial-of-service attack on the web server, or perhaps even run arbitrary code on the web server.
  6. Does GCC's -fstack-protector option help? Use GCC's -S option to generate the assembly language code for thttpd.c twice, once with -fstack-protector, and once with -fno-stack-protector. Call the resulting files thttpd-stackprot.s and thttpd-nostackprot.s. Use diff to compare the two assembly-language files. Which code looks less efficient, and why? Write a simple shell command that invokes diff and determines which functions are called (in the sense of the machine-language call instruction) by one version and not the other, and use the command to see what functions these are. Will these extra functions prevent your exploit?
  7. Does AddressSanitizer help more? Build the patched thttpd with -fsanitize=address -fstack-protector, run it under GDB, send it a suitably-formatted request, and see what the traceback looks like. Note that -fsanitize=address requires the use of the linker option -Xlinker --rpath=... as illustrated below. Do your experiment on the SEASnet GNU/Linux servers: Use the port number specified by your T.A. (which is probably not port 8080), and compile in 32-bit mode using the CS version of GCC, with something like the following shell command: 
    make CC="gcc -m32" \
  CFLAGS="-fsanitize=address -fstack-protector" \
  LDFLAGS="-Xlinker --rpath=/usr/local/cs/gcc-$(gcc -dumpversion)/lib"
  8. Use GCC's -S option to generate the assembly language code for thttpd.c, with the -fsanitize=address -fstack-protector option. Call the resulting file thttpd-sanitize.s. Use diff to compare it to thttpd-stackprot.s. Which code looks less efficient, and why?
  9. Will Valgrind help? Try running the step-4 web server under Valgrind; what does it do?

Homework: Reproducing under EC2; vulnerability review

This homework has two parts: checking for a slightly different type of vulnerability under EC2, and reviewing some recent vulnerabilities.

First, consider the following sthttpd patch, which you should apply instead of the lab's patch.

--- sthttpd-2.27.0/src/libhttpd.c	2014-10-03 11:43:00.000000000 -0700
+++ sthttpd-2.27.0-delta/src/libhttpd.c	2015-03-02 08:28:43.155685750 -0800
@@ -710,8 +710,13 @@ httpd_realloc_str( char** strP, size_t*
 	}
     else if ( size > *maxsizeP )
 	{
+	size_t const maxsize_expansion = 2;
+	size_t const size_expansion_times_4 = 5;
+	_Static_assert( 1 < maxsize_expansion, "maxsize grows" );
+	_Static_assert( 4 < size_expansion_times_4, "size grows" );
 	str_alloc_size -= *maxsizeP;
-	*maxsizeP = MAX( *maxsizeP * 2, size * 5 / 4 );
+	*maxsizeP = MAX( *maxsizeP * maxsize_expansion,
+			 size * size_expansion_times_4 / 4 );
 	*strP = RENEW( *strP, char, *maxsizeP + 1 );
 	str_alloc_size += *maxsizeP;
 	}

Get access to a fresh 32-bit Amazon EC2 instance (you can get a free one from Amazon AWS – if you have trouble getting one please contact a TA). Build your patch web server on this instance, except change the constants maxsize_expansion and size_expansion_times_4 to values large enough to cause problems. (If your instance is so old that the compiler does not support _Static_asserts, comment them out; but your constants should still respect the constraints that the static assertions embody.) Make your modified web server crash under EC2, in different ways with different values for the constants. Take notes on all the steps you needed to do. If you can't make your server crash using these steps, give details about why not.

Second, look at some recent known vulnerabilities under the following assumption. Suppose you have built and deployed a networked application from standard software components and are now worried that the application might be vulnerable to outside attackers via the Internet. Assume that each of the following entries in the CERT Vulnerability Notes Database describes a component of your system. Give the urgency of each vulnerability as low, medium, or high. (By "highly urgent" we mean "so urgent that your team should fix this right away in your deployed system".) Justify your urgency assignments by evaluating the plausibility of attack scenarios.

Submit

Submit the following files.

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

expand lab.txt hw.txt |
  awk '/\r/ || 200 < length'

should output nothing.

© 2005, 2007, 2008, 2010–2015 Paul Eggert. See copying rules.
$Id: assign9.html,v 1.24 2015/03/02 18:07:26 eggert Exp $