This assignment helps you develop a detailed understanding of the calling stack organization on an x86 processor. It involves applying a series of buffer overflow attacks on an executable file.
Note: In this lab, you will gain first-hand experience with one of the methods commonly used to exploit security weaknesses in operating systems and network servers. Our purpose is to help you learn about the runtime operation of programs and to understand the nature of this form of security weakness so that you can avoid it when you write system code. We vigorously condemn the use of these or any other form of attack to gain unauthorized access to any system resources. There are criminal statutes governing such activities.
In the directory
/u/cs252/bin/
you will see the files for three programs:
makecookie bufbomb sendstring In the following, we will assume that you have defined the lab directory to be on your execution path. You can do this by executing the following command:
unix> setenv PATH /u/cs252/bin/:$PATH[an error occurred while processing this directive]
You should create a team name for the one or two people in your group of the following form:
A cookie is a string of eight hexadecimal digits that is (with high
probability) unique to your team. You can generate your cookie with
the makecookie program giving your team name as the
argument. For example:
unix> makecookie bob+jane 0x78327b66In three of your four buffer attacks, your objective will be to make your cookie show up in places where it ordinarily would not.
bufbomb Program
The bufbomb program reads a string from standard input with a
function getbuf having the following C code:
int getbuf()
{
char buf[12];
Gets(buf);
return 1;
}
The function Gets is similar to the standard library function
gets. It reads a string from standard input (terminated by
‘\n’ or end-of-file) and stores it (along with a null
terminator) at the specified destination. In this code, the
destination is an array buf having sufficient space for 12
characters.
Neither Gets nor gets has any way to
determine whether there is enough space at the destination to store the
entire string. Instead, they simply copy the entire string, possibly
overrunning the bounds of the storage allocated at the destination.
If the string typed by the user to getbuf is no more than 11
characters long, it is clear that getbuf will return 1, as shown
by the following execution example:
unix> bufbomb Type string: howdy doody Dud: getbuf returned 0x1If we type a longer string, typically an error occurs:
unix> bufbomb Type string: This string is too long Ouch!: You caused a segmentation fault!As the error message indicates, overrunning the buffer typically causes the program state to be corrupted, leading to a memory access error. Your task is to be more clever with the strings you feed
bufbomb so that it does more interesting things. These are
called exploit strings.
Bufbomb takes several different command line arguments:
Bufbomb determines the cookie you will be using based
on your team name, just as does the program makecookie.
bufbomb so that some of
the key stack addresses you will need to use depend on your
team’s cookie.
sendstring can help you generate these raw
strings.
It takes as input a hex-formatted string. In this format, each
byte value is represented by two hex digits. For example, the string
“012345” could be entered in hex format as “30 31 32
33 34 35” since the ASCII code for decimal digit 0 is 0x30 and so
forth. Non-hex digit characters are ignored, including the blanks in
the example shown.
If you place a hex-formatted exploit string in the file
exploit.txt, you can apply the raw string to bufbomb
in at least two different ways:
sendstring.
unix> cat exploit.txt | sendstring | bufbomb -t bob
bufbomb:
unix> sendstring < exploit.txt > exploit-raw.txt unix> bufbomb -t bovik < exploit-raw.txt
bufbomb
from within gdb:
unix> gdb /u/cs252/bin/bufbomb (gdb) run -t bob < exploit-raw.txtOne important point: your exploit string must not contain byte value 0x0A at any intermediate position, since this is the ASCII code for newline (‘\n’). When
Gets encounters this
byte, it will assume you intended to terminate the string.
Sendstring will warn you if it encounters this byte value.
When you correctly solve one of the levels, bufbomb will
automatically send an email notification to our grading server. The
server will test your exploit string to make sure it really works, and
it will update the lab web page indicating that your team (listed by
cookie) has completed this level.
Unlike the bomb lab, there is no penalty for making mistakes in this
lab. Feel free to fire away at bufbomb with any string you
like.
As noted above, you may work in a group of up to 2 people. For the firecracker and dynamite assignments, you will want to work on cycle3.csug.rochester.edu in order to circumvent Linux's stack randomization. For the purposes of this assignment, we have temporarily disabled Linux's stack randomization so that you will see deterministic stack addresses for your procedure frames.
Any clarifications and revisions to the assignment will be posted to the class blackboard.
Hand in occurs automatically whenever you correctly solve a level.
The program sends email to our grading server containing your team
name (be sure to set the “–t” command line flag
properly), and your exploit string to the grading server. You will be
informed of this by bufbomb. Upon receiving the email, the
server will validate your string and update the lab web page. You
should check this page a few minutes after your submission to make sure
your string has been validated. [If you really solved the level, your
string should be valid.]
Note that each level is graded individually. You do not need to do them in the specified order, but you will get credit only for the levels for which the server receives a valid message.
Have fun!
Before noon, Tuesday, Feb. 19, submit answers on blackboard to the following questions.
makecookie with your team name as a
parameter. What is the output?
sendstring program?
Using gcc as an assembler and objdump as a
disassembler makes it convenient to generate the byte codes for instruction
sequences. For example, suppose we write a file example.s containing the
following assembly code:
# Example of hand-generated assembly code
pushl $0x89abcdef # Push value onto stack
addl $17,%eax # Add 17 to %eax
.align 4 # Following will be aligned on multiple of 4
.long 0xfedcba98 # A 4-byte constant
.long 0x00000000 # Padding
The code can contain a mixture of instructions and data. Anything to the right
of a '#' character is a comment. We have added an extra word of all
0s to work around a shortcoming in objdump to be
described shortly.
We can now assemble and disassemble this file:
unix> gcc -c example.s
unix> objdump -d example.o > example.d
The generated file example.d contains the following lines
0: 68 ef cd ab 89 push $0x89abcdef
5: 83 c0 11 add $0x11,%eax
8: 98 cwtl Objdump tries to interpret
9: ba dc fe 00 00 mov $0xfedc,%edx these as instructions
Each line shows a single instruction. The number on the left indicates the
starting address (starting with 0), while the hex digits after the ':'
character indicate the byte codes for the instruction. Thus, we can see that
the instruction pushl $0x89ABCDEF has hex-formatted byte code
68 ef cd ab 89.
Starting at address 8, the disassembler gets confused. It tries
to interpret the bytes in the file example.o as instructions, but these
bytes actually correspond to data. Note, however, that if we read off the 4
bytes starting at address 8 we get: 98 ba dc fe. This
is a byte-reversed version of the data word 0xFEDCBA98. This byte
reversal represents the proper way to supply the bytes as a string, since a
little endian machine lists the least significant byte first. Note also that it
only generated two of the four bytes at the end with value 00. Had
we not added this padding, objdump gets even more confused and
does not emit all of the bytes we want.
Finally, we can read off the byte sequence for our code (omitting the final
0s) as:
68 ef cd ab 89 83 c0 11 98 ba dc fe
There is no explicit turn-in. The bomb will notify us automatically after you have successfully defused it. You can keep track of how you (and the other groups) are doing by looking at http://www.csug.rochester.edu/users/grads/bomb/bombstats.html.
This web page is updated continuously to show the progress of each group.
For the “trivia” assignment: noon, Tuesday, February 19.
For the main assignment: 11:59pm, Tuesday, February 26.