SUID Programming Part 4 - Due before class April 8

For this part of the secure programming project, you are going to try and find out what is in each student's secret text file.

You will find a number of user directories on the ia-class machine. They are named user#####, where # is a hexidecimal digit. 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 determine the contents of as many of the protected text files as possible, subject to this list of rules:

  • No attacking or exploiting the operating system or system passwords.
  • You may not tell others which submission is yours or how to get into it.
  • Once 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.
  • If you mess something up, tell the instructor immediately; do this particularly if you overwrite some file, including the hidden text file
  • 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.
  • At no time may you make any changes to anything in your anonymous directory. I have hashes of everything, and any detected changes will result in me being angry, which is bad for your grade.

Grading will be based on a few things, in roughly this order of importance:

  • How few people get your secret information. How few people get your secret information.. (Yes, this is twice as important)
  • 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 secret files your recover.
  • You will get partial credit for partial attacks. For example, getting a program to crash in a manner that indicates it might have a buffer overflow is worthwhile.

What to turn in: For each program you manage to defeat, you will turn in by email before class on April 8th, 2013, 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.