CSE 127: Computer Security Spring 2011Project #1Part 1 Due: Thursday, April 7th, 2011, 11:59 pmPart 2 Due: Thursday, April 14th, 2011, 11:59 pmGoalThe goal of this assignment is to gain hands-on experience with the effect of buffer overflowand other memory-safety bugs.All work in this project must be done on the VMware virtual machine provided on thecourse website; see below for information about this environment.You are given, in the targets/ directory, the source code for five exploitable programs,target1.c, . . . target5.c. These programs are to compiled and installed, setuid root, inthe /tmp directory of your VM. Your goal is to write five exploit programs sploit1, . . . ,sploit5, each of which will execute the corresponding target with input that exploits thattarget’s bug, giving a root shell on the VM.We have provided skeletons for these exploits programs in the sploits/ directory, assploit1.c, . . . , sploit5.c. Our own solutions, incidentally, are very short: just 200 or 300lines for all five exploits together. So while understanding and exploiting the bugs will notbe easy, you will not need to write a lot of code.CollaborationYou may work on this project with one other person. You will turn in a single set of solutionstogether, but it is expected that both of you understand and can explain how to exploit eachtarget. You must not discuss the project with anyone in the class besides your partner,nor with anyone outside of class. You may use online resources for general reference, butnot to search for solutions to specific questions posed in this project. (For more about thecollaboration policy and academic integrity, see the class syllabus.)The EnvironmentYou (and we, for grading!) will test your exploit programs within a VMware virtual machine.To use this VM on your personal Windows or Linux machine, you will need to downloadthe virtual machine image provided on the course website — boxes-2.1.tar.bz2 — as wellas the free VMware Player from VMware’s website.We have also arranged for VMware Player and VMware Workstation to be installed onthe ieng6 machines in the B230 cluster in the basement of EBU 3B.1The virtual machine is configured to use NAT (Network Address Translation) for net-working. From the virtual machine, you can type ifconfig as root to see the IP address ofthe virtual machine. It should be listed under the field inet addr: under eth0.The virtual machine also has an ssh server. You can ssh into the VM from your machine,using the IP address produced by ifconfig (as above) as the destination. You can also usethis to transfer files onto the virtual machine using scp or an sftp client. Alternatively, youcan fetch files directly from the Web on the VM using wget.The networking setup in B230 slightly restricts outgoing network connections from theVM, but this should not pose any problems.The TargetsThe targets/ directory in the assignment tarball contains the source code for the targets,along with a Makefile specifying how they are to be built. To compile the targets and installthem in /tmp, use the commands make and make install .Your exploits should assume that the compiled target programs are installed setuid-rootin /tmp — /tmp/target1, /tmp/target2, etc.For final testing, you can become root (using su) and use the command make setuid toset the targets setuid-root. If your exploits work, this will allow you to obtain a root shellwhen they are run. But it will make debugging impossible. You can always rm /tmp/target? ,log out as root, and run make install again to allow debugging.The ExploitsThe sploits/ directory in the assignment tarball contains skeleton source 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.Along with each esploit skeleton file, there is also an empty text file that you shouldfill with an explanation of the bug in the corresponding target and how your exploit takesadvantage of it. You will submit this explanation along with your exploit.The AssignmentYou are to write exploits, one per target. Each exploit, when run in the virtual machinewith its target installed setuid-root in /tmp, should yield a root shell (/bin/sh).Hints1. Read Aleph One’s “Smashing the Stack for Fun and Profit.” Carefully. Also readthe “suggested reading” listed in the project README. You will want to have a goodunderstanding of what happens to the stack, program counter, and relevant registersbefore and after a function call. Read scut’s “Exploiting Format String Vulnerabilities,”2linked from the course syllabus. It will be helpful to have a solid understanding of thebasic buffer overflow exploits before reading the more advanced exploit papers.2. The gdb debugger is your best friend in this assignment, as you’ll want to under-stand what’s going on in the target program’s memory space. Specifically, note the“disassemble” and “stepi” commands. You may find the “x” command useful toexamine memory (and the different ways you can print the contents such as /a or /iafter x). The “info register” command is helpful in printing out the contents ofregisters such as ebp and esp.A useful command to run gdb is to use the -e and -s command line flags; for example,the command “gdb -e ./sploit3 -s /tmp/target3” tells gdb to execute sploit3and use the symbol file in target3, which allows you to trace execution in the tar-get in exactly the way it is executed by the exploit. By contrast, executing just“gdb /tmp/target3” will trace the target in the way it is executed by the shell, so thememory layout will be different. (Avoiding a segfault while using this requires carefultiming in setting breakpoints. See the assignment README for the details.)3. Make sure that your exploits work within the provided virtual machine.4. Start early. Theoretical knowledge of exploits does not readily translate into the abilityto write working exploits. The first target is relatively simple to exploit, but thedifficulty ramps up from there . . .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 the same way bash does.You must therefore hard-code target stack locations in your exploits. You