CS 361S - Network Security and PrivacySpring 2014Project #2Part 1 due: 11am CDT, March 25, 2014Part 2 due: 11am CDT, April 3, 2014Submission instructionsFollow the submission instructions in the Deliverables section.If you are submitting late, please indicate how many late days you are using.Collaboration policyThis assignment can be done individually or in two-person teams. Any cheating (e.g., sub-mitting another person’s work as your own, or permitting your work to be copied) willautomatically result in a failing grade. The Computer Science department code of conductcan be found at http://www.cs.utexas.edu/undergraduate-program/code-conduct.Late submission policyThe first part of this project is due at the beginning of class on March 25. The secondpart is due at the beginning of class on April 3. All late submissions will be subject to thefollowing policy.You start the semester with a credit of 3 late days. For the purpose of counting latedays, a “day” is 24 hours starting at 11am on the assignment’s due date. Partial days arerounded up to the next full day. You are free to divide your late days among the take-homeassignments (3 homeworks and 2 projects) any way you want: submit three assignments1 day late, submit one assignment 3 days late, etc. After your 3 days are used up, nolate submissions will be accepted and you will automatically receive 0 points for each lateassignment.1Buffer Overflow Project (75 points + 25 bonus points)ObjectiveThe objective of this project is to give you hands-on experience with implementing bufferoverflow exploits. You are given source code for five exploitable programs (target1.c, . . . ,target5.c). These programs are all installed as setuid root in the the VMware virtual ma-chine. Your goal is to write five exploit programs (sploit1, . . . , sploit5). The sploit[i]program will execute target[i], giving it a certain input that should result in a root shellon the VMware virtual machine. See below (Your Assignment) for more details.FilesYou will need:• The VMware Player: http://www.vmware.com/products/player/• The virtual machine image: http://www.cs.utexas.edu/~shmat/courses/cs361s/cs361s-proj2vm.tar.bz2• The project files: http://www.cs.utexas.edu/~shmat/courses/cs361s/cs361s-proj2.tar.bz2VMware environmentYou will test your exploit programs in a VMware virtual machine. To do this, you will needto download the virtual machine image as well as the VMware Player from VMware’s website(see above). VMware Player can run on Linux, Windows, and Mac OS X (VMware Fusion).The virtual machine we provide is configured with Debian Etch. Should you need anyother packages to do your work (e.g., emacs), you can install it with the command apt-get(e.g., apt-get install emacs). You may need to edit the /etc/apt/sources.list file andreplace http://mirrors.kernel.org/debian with http://archive.debian.org/debianeverywhere.The virtual machine is configured to use NAT for networking. From the virtual machine,you can type ifconfig as root to see the IP address of the virtual machine. It should belisted under the field inet addr: under eth0.The virtual machine also has an SSH server. You can SSH into the virtual machine fromyour machine, using the IP address produced by ifconfig (see above) as the destination.You can also use this to transfer files onto the virtual machine using scp. Alternatively, youcan fetch files directly from the web on the VM using wget.TargetsThe project files (cs361s-proj2.tar.bz2) contain the source code for the targets, alongwith a Makefile specifying how they are to be built.2Your exploits should assume that the compiled target programs are installed setuid-rootin /tmp – /tmp/target1, /tmp/target2, etc.ExploitsThe project files (cs361s-proj2.tar.bz2) also contain skeleton source code for the ex-ploits which you are to write, along with a Makefile for building them. Also included isshellcode.h, which gives Aleph One’s shellcode. Exploit programs are very short, so thereis no need to write a lot of code.Your assignmentYou are to write one exploit per target. Each exploit, when run in the virtual machine withits target installed setuid-root in /tmp, should yield a root shell (/bin/sh). You can usewhoami to tell if you are root or not.GradingThere are five targets. Each successful exploit will give you a certain amount of points.Part 1 (due March 27)Target 1: 10 pointsTarget 2: 15 pointsPart 2 (due April 5)Target 3: 25 pointsTarget 4: 25 pointsTarget 5 is the bonus target. It is worth 25 extra points on top of the regular points forthis assignment.Hintsgdb is your best friend in this assignment. It will help you inspect the contents of memoryas your target is executing and generally understand what’s going on. In particular, noticethe disassemble and stepi commands. You may find the x command useful to examinememory (and the different ways you can print the contents such as /a /i after x). Theinfo register command is helpful in printing out the contents of registers such as ebp andesp. Another very useful command is info frame. It prints a detailed description of theselected frame.3When you run gdb, you will find the -e and -s command-line flags useful. For example,the command gdb -e sploit1 -s /tmp/target1 in the VM tells gdb to execute sploit1and use the symbol file in target1. These flags let you trace the execution of target1 afterthe sploit has forked off the execve process. When running gdb using these command-lineflags, be sure to first issue catch exec, then run the program before you set any breakpoints;the command run naturally breaks the execution at the first execve call before the target isactually exec-ed, so you can set your breakpoints when gdb catches the execve. Note thatif you try to set break points before entering the command run, you’ll get a segmentationfault.If you wish, you can instrument your code with arbitrary assembly using the __asm__()pseudofunction.IMPORTANT: Your code must run within the provided virtual machine environment.WarningsAleph One gives code that calculates addresses on the target’s stack based on addresses onthe exploit’s stack. Addresses on the exploit’s stack can change based on how the exploitis executed (working directory, arguments, environment, etc.). In our testing, we do notguarantee to execute your exploits as bash does.You must therefore hard-code target stack locations in your exploits. You should notuse a function such as get_sp() in the exploits you hand