-
Notifications
You must be signed in to change notification settings - Fork 2
victtavares/CS642-Comp-Security_HW1
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
CS 642: Computer Security Project One ---==[ The Environment ]==--- You will test your exploit programs within a VMware virtual machine (VM) we provide, which is configured with Debian stable ("Lenny"). You can use the ssh daemons running in the image to transfer files into the VM, or access the Web directly from the VM using something like wget. ---==[ The Targets ]==--- The targets/ directory in the assignment tarball contains the source code for the targets, along with a Makefile specifying how they are to be built. Your exploits should assume that the compiled target programs are installed setuid-root in /tmp -- /tmp/target1, /tmp/target2, etc. Note that there are five targets that you are responsible for. To build the targets, change to the pp1/targets directory and type "make" on the command line; the Makefile will take care of building the targets. To install the target binaries in /tmp, run "make install". To make the target binaries setuid-root, first run "make install"; then, *as root*, run "make setuid". You can get a root shell in the current directory using the "su" command; once you've run "make setuid" you can exit this shell, which will return you to your user shell. Alternatively, you can keep a separate terminal or virtual console open with a root login, and run "make setuid" (in the ~user/pp1/targets directory!) in that terminal or console. Keep in mind that it'll be easier to debug the exploits if the targets aren't setuid. (See below for more on debugging.) If an exploit succeeds in getting a user shell on a non-setuid target in /tmp, it should succeed in getting a root shell on that target when it is setuid. (But be sure to test that way, too, before submitting your solutions!) ---==[ The Exploits ]==--- The sploits/ directory in the assignment tarball contains skeleton source for the exploits which you are to write, along with a Makefile for building them. Also included is shellcode.h, which gives Aleph One's shellcode. ---==[ The Assignment ]==--- You are to write exploits, one per target. Each exploit, when run in the virtual machine with its target installed setuid-root in /tmp, should yield a root shell (/bin/sh). Your task is to attack the five targets named target1 through target5. ---==[ Hints ]==--- Read the readings in Phrack suggested below. Read Aleph One's paper carefully, in particular. Read Scut's paper on format string vulnerabilities, linked from the course syllabus. To understand what's going on, it is helpful to run code through gdb. See the GDB tips section below. Make sure that your exploits work within the provided virtual machine. Start early! Theoretical knowledge of exploits does not readily translate into the ability to write working exploits. Target1 is relatively simple and the other problems are quite a bit more complicated. ---==[ GDB tips ]==--- Notice the ``disassemble'' and ``stepi'' commands. You may find the ``x''command useful to examine memory (and the different ways you can print the contents such as ``"/a'' ``/i'' after ``x''). The ``info register''command is helpful in printing out the contents of registers such as ebp and esp. A useful way to run gdb is to use the -e and -s command line flags; for example, the command ``gdb -e sploit3 -s /tmp/target3'' in the VM tells gdb to execute sploit3 and use the symbol file in target3. These flags let you trace the execution of the target3 after the sploit's memory image has been replaced with the target's through the execve system call. When running gdb using these command line flags, you should follow the following procedure for setting breakpoints and debugging memory: 1. tell gdb to notify you on exec(), by issuing the command ``catch exec'' 2. run the program. gdb will execute the sploit until the execve syscall, then return control to you 3. set any breakpoints you want in the target 4. resume execution by telling gdb ``continue'' (or just ``c''). If you try to set breakpoints before the exec boundary, you will get a segfault. If you wish, you can instrument the target code with arbitrary assembly using the __asm__ () pseudofunction, to help with debugging. Be sure, however, that your final exploits work against the unmodified targets, since these we will use these in grading. ---==[ Warnings ]==--- Aleph One gives code that calculates addresses on the target's stack based on addresses on the exploit's stack. Addresses on the exploit's stack can change based on how the exploit is executed (working directory, arguments, environment, etc.); in my testing, I do not guarantee to execute your exploits exactly the same way bash does. You must therefore hard-code target stack locations in your exploits. You should *not* use a function such as get_sp() in the exploits you hand in. (In other words, in grading the exploits may be run with a different environment and different working directory than one would get by logging in as user, changing directory to ~/pp1/sploits, and running ./sploit1, etc.; your exploits should work even so.) Your exploit programs should not take any command-line arguments. ---==[ Deliverables ]==--- You will have three deliverables. (1) You will need to submit the source code for your exploits (sploit1 through sploit5), along with any files (Makefile, shellcode.h) necessary for building them. (2) In addition, along with each exploit, you should include a text file (sploit1.txt, sploit2.txt, and so on). In this text file, explain how your exploit works: what the bug is in the corresponding target, how you exploit it, and where the various constants in your exploit come from. (3) Finally, you must include file called ID which contains, on a single line, the following: your UW ID; and your name, in the format last name, comma, first name. An example: $ cat ./ID 9064562678 Doe, John $ If you work with a partner, the ID file should contain two lines, one for each of you. You can submit your work via handin: handin -c cs642-1 -a pp1 -d <DIRECTORY>. ---==[ Grading ]==--- You will receive two points (out of 10) for each exploit that yields a root shell in our testing. There will not normally be partial credit, but we may make an exception depending on your explanatory writeup. We may also ask you to explain to us how and why each exploit works. If you work with a partner, be sure that each of you understands every exploit you turn in! ---==[ Suggested reading in Phrack, www.phrack.org ]==--- Aleph One, ``Smashing the Stack for Fun and Profit,'' Phrack 49 #14. klog, ``The Frame Pointer Overwrite,'' Phrack 55 #08. Bulba and Kil3r, ``Bypassing StackGuard and StackShield, Phrack 56 #0x05. Silvio Cesare, ``Shared Library Call Redirection via ELF PLT Infection,'' Phrack 56 #0x07. Michel Kaempf, ``Vudo - An Object Superstitiously Believed to Embody Magical Powers,'' Phrack 57 #0x08. Anonymous, ``Once Upon a free()...,'' Phrack 57 #0x09. Nergal, ``The Advanced Return-into-lib(c) Exploits: PaX Case Study,'' Phrack 58 #0x04. Gera and Riq, ``Advances in Format String Exploiting,'' Phrack 59 #0x04. Anonymous, ``Bypassing PaX ASLR Protection,'' Phrack 59 #0x09. blexim, ``Basic Integer Overflows,'' Phrack 60 #0x10. ---==[ Other Books ]==--- W. Richard Stevens, /Advanced Programming in the Unix Environment./ Addison-Wesley, 1993. AEleen Frisch, /Essential System Administration,/ second edition. O'Reilly, 1995. /IA-32 Software Developer's Manual, Vol. 1: Basic Architecture./ Intel, 2001. /IA-32 Software Developer's Manual, Vol. 2: Instruction Set Reference./ Intel, 2001. /IA-32 Software Developer's Manual, Vol. 3: System Programming Guide./ Intel, 2001. (The latest versions of these manuals are online at http://developer.intel.com/products/processor/manuals/ .) Dean Elsner, Jay Fenlason, et al., /Using AS./ FSF, 1994. Richard Stallman et al., /Using the GNU Compiler Collection/ FSF, 2002. Richard Stallman, Roland Pesch, Stan Shebs, et al. /Debugging with GDB./ FSF, 2001. (These are online at http://www.gnu.org/manual/manual.html .)
About
CS642/Fall 2014 - University of Wisconsin, Madison
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published