Information Assurance
back to projects page
|
For this part of the secure programming project, you are going to
try and break other student's projects.
First, you need to put your project up anonymously. If you look
in your account on ia-class, you will find a file named
user_number. This is the new secret identity we will use
for this project. I have disabled the wtmp file, so you should
not be able to use finger or last to find out
who owns which accounts.
In this new account, you should place:
- Your executable code. This should be suid to your user
number, and should be world readable and executable.
- You source code, with any identifying information such as
name or netid removed. This should be world readable
- A configuration file that includes at least 5 working
passwords, if you have chosen to store them there. If not, there
should be 5 working passwords for the project wherever you put
them. This should be world readable.
- A log file. It does not need to have any entries when
started. It should be world readable.
- The secret file people are trying to get access to. This
should not be world readable.
Once you have these in place, e-mail the instructor to test
your set up. This should be done by Tuesday, April 10th.
After the 10th,you will find a number of user
directories on the ia-class machine. They are named
user#, where # is some random number. They should be
accessible to you; if they are not, let the instructor know.
In each directory will be an anonymized project submission set up for
you to test. Your goal is to find the contents of as many of the
protected text files as possible, subject to this list of rules:
- You may only use the features of the project submissions
themselves in order to retrieve the contents of the text
file. No exploiting the operating system.
- You may not attack your own submission.
- You may not tell others which submission is yours or how
to get into it.
- One you find the contents of the file, you may not divulge
what they are or how you got them to anyone else in the
class. You may not work together to subvert the submissions.
- The projects should be anonymized, but if you do find
something that identifies the author, you will let the
instructor know which directory and what the identifying marks
are immediately. This does not apply if you recognize your own
source code.
Grading will be based on a few things, in roughly this order of importance:
- The degree of sophistication of the attacks you
use. Writing a buffer overflow is hard. Guessing a password is
easy. You may attack a particular program in different ways,
and receive credit for each success. Here is a rough ordering of some
attacks you might perform, from hardest to easiest:
- Buffer overflow.
- Tricking the program into reading a fake password file.
- Extracting passwords out of core dumps or memory.
- Password cracking
- Automated guessing
- Manual guessing
- The number of programs you succeed in breaking.
- How well your program withstands attack.
What to turn in:
For each program you manage to defeat, you will turn in by email
before class on April 17, 2007, a description to include:
- Which user program it was
- How you broke it, in sufficient detail that I can reproduce
the attack. If you have sizeable amounts of code, you can
leave it in your home directory and reference it in your
submission. Do not make the code world readable.
- What is required to fix the problem you identified, in
sufficient detail that the program's author could make
the changes.
- What the contents of the secret file were as proof of your exploit.
|