SUID Programming Part 1 - Due before class February 6th

Your task is to examine the other programs on mclovin and attempt to break their security. You may also attack your own program. Here is how I suggest you approach this task:

  • First, test each program and make sure they are configured correctly and that the given user name and password operate correctly. If not, let me know.
  • Second, look through the source code to see what you can affect by providing input to the program. Test and see if any of the data structrues that take input or otherwise work with user-provided input can be overflowed or otherwise corrupted. If so, see if you can make the program crash. This will help your grade. If you manage to complete a buffer overflow, despite the OS protections, you win.
  • Third, see if you can get the programs to read a file of your choosing instead of what the programmer expected. This can sometimes be done in programs that do not specify a full path to input files by creating an appropriate configuration file locally and then symlinking to the other needed files, then running the program from the current directory instead of the directory where it is located.
  • Fourth, see if any of the programs use non-standard crypto for password protection. If so, see if you can attack that, perhaps in combination with the file exploit above
  • Fifth, see if you can use the logging mechaism to your advantage. If the log is written with the SUID still effective and you are able to redirect it, it may be possible to overwrite the .cfg or even the .txt file with something that you create.

You should test your methods to see if they actually work. If, during your testing, you accidently break something, let me know so I can restore it.

Before class on the 6th you should submit a PDF report, by email, that contains the following items:

  • For each program, a description of how you attempted to break the security of the program, and if you were successful or not.
  • A brief description of how you would recommend the user change their program to avoid the methods you would use to break it, or other constructive comments.
  • These comments will be shared with the author of the program to help them improve their work. Be constructive, not destructive.