DOC PREVIEW
Berkeley COMPSCI 161 - CS 161 Project

This preview shows page 1 out of 2 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 2 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 2 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Project 1CS161 Computer Security, Fall 2008Assigned 10/01/08Due 10/15/08If you know the enemy and know yourself, you need not fear the result of a hundred battles. Ifyou know yourself but not the enemy, for every victory gained you will also suffer a defeat. If youknow neither the enemy nor yourself, you will succumb in every battle. - Sun TzuIn this project, you will play the attacker’s role. We will give you a program that is vulnerable,and you will create the exploit for it!1 Problem StatementYour goal is to create an exploit for a buffer overflow vulnerability. To get started, read over AlephOne’s “Smashing the Stack for Fun and Profit”.1(You don’t have to read the section “Shell Code”,since we provide you with shellcode, though you may find it interesting.)The vulnerable program is /home/ff/cs161/proj1-fa08/targets/target on the instructionalmachines. Copy the directory /home/ff/cs161/proj1-fa08/exploits to your working space; itcontains skeleton code and a Makefile for your exploit program. The source code for the vulnerableprogram, /home/ff/cs161/proj1-fa08/targets/target.c, is also provided for your reference.Your task is to edit exploit.c so that it exploits the buffer overflow vulnerability in target torun a shell. We provide exploit code in shellcode.h; you just have to cause it to be executed intarget. If you are successful, you should see a ‘$’ shell prompt:bash-3.1$ ./exploit$The only file you should edit is exploit.c. Build it with gmake. The path to target is hard-codedin exploit.c; please do not change it.Because buffer overflow exploits are highly machine-dependent, you are restricted to working onsphere.cs, rhombus.cs, or pentagon.cs. Your exploit must work on one of those machines (theyare Solaris x86 boxes).To start with, we recommend that you use gdb to explore the stack and memory layout oftarget. It will be different when called via execve(), so here is the best way to get set up (afterrunning gdb ./exploit):(gdb) runStarting program: ./exploit1http://reactor-core.org/stack-smashing.htmlProgram received signal SIGTRAP, Trace/breakpoint trap.0xce7cb7b6 in ?? ()(gdb) symbol-file /home/ff/cs161/proj1-fa08/targets/targetLoad new symbol table from "/home/ff/cs161/proj1-fa08/targets/target"? (y or n) yReading symbols from /home/ff/cs161/proj1-fa08/targets/target...done.warning: rw_common (): unable to read at addr 0xce7a2060warning: sol_thread_new_objfile: td_ta_new: Debugger service failed(gdb) break mainBreakpoint 1 at 0x8050834: file target.c, line 21.(gdb) continueContinuing.Breakpoint 1, main (argc=2, argv=0x8047f14) at target.c:2121 if (argc != 2)(gdb)Running it this way makes it difficult to restart, however, so you may want to just run gdb targetto explore initially and then switch to the execve() version when it’s time to find the actual ad-dresses for your exploit.You will want to become familiar with the following gdb commands (use the ’help’ command):break, where, disassemble, next, nexti, x, and info. Be sure to explore the display options forthe x command.You should not follow Aleph One’s directions too closely. You may or may not want to executethe shellcode on the stack, and you can use gdb to figure out the exact address to jump to, so youdon’t have to use anything like get_sp() or NOP padding.You must submit your code electronically. Go to the directory where exploit.c resides andtype submit proj1. You should only submit exploit.c; you should not change the other files.2 Grading1. (1 point) You must ensure that your code runs on one of the three servers listed above. Pleasetell us which server you ran your code on (sphere, rhombus, or pentagon), as comment(/* Server : rhombus.cs/sphere.cs ... */) in the beginning of your submission fileexploit.c. The grader will check out your submitted exploit.c and compile it. The graderwill type gmake and then ./exploit to run your exploit. Please also list names of your projectgroup members as a comment in the beginning of the file exploit.c.2. (7 points) When the exploit is executed by the grader, it must exploit the target, giving thegrader a remote shell. Do not change the hard coded path for target in your solution.3. (1 point) List the name of the function containing the vulnerable buffer. Draw the stacklayout showing the absolute locations of the variables you had to be concerned about to makeyour exploit work.4. (1 point) You should include in your homework writeup a brief description of how you arrivedat your solution, including how you determined which address to jump to. The writeup forthis question should be at most 4


View Full Document

Berkeley COMPSCI 161 - CS 161 Project

Documents in this Course
Rootkits

Rootkits

11 pages

Load more
Download CS 161 Project
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view CS 161 Project and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view CS 161 Project 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?