CS 261 Homework 2

Instructions

Briefly sketch answers to each of the following problems. Two or three short sentences should be enough for nearly all of the questions. Feel free to use incomplete sentences if you like.

This problem set is due Thursday, 3 October. Turn in your answers, in paper, at the beginning of class that Thursday.

You may discuss the questions on this homework with others, but the writeup you turn in must be your own. You may use any source you like (including other papers or textbooks), but if you use any source not discussed in class, you must cite it.

Question 1

1. It is popular these days to use cookies as a means of authentication for access to web pages. When you initially log in to the webserver, it generates a random cookie (a secret, unguessable string of bits) and sends it to your browser, which will re-send it back to the webserver whenever you re-visit that web page again to prove that you are an authorized viewer.
   What are the weaknesses of this scheme?
2. Another mechanism in the standard uses challenge-response authentication. You and the webserver share a secret passphrase; when you want to view the web page, the webserver sends you a random challenge (which is different every time), and you compute a cryptographic checksum of the passphrase and challenge and send the result back to the webserver. This allows the webserver to check whether you know the passphrase by verifying whether your response is correct.
   Assume the crypto algorithm is perfect (there are no mathematical shortcut attacks against it). What attacks are there on this scheme?

Question 2

For this question, you will practice doing a security audit of some interesting program. Pick any open-source application where security is relevant. The only requirement is that it must consist of at least 2000 lines of code. If you're at a loss for a program to audit, you can check out the Sardonix web site's list of suggestions. Or, you can pick one yourself. Good choices might include network daemons, standard Unix utilities, setuid programs, or clients that process data that came from the network (mailers, browsers, MP3 players, etc.).

Then, do the following.

1. What application did you pick? Which version? Give the URL where I can download the source. How many lines of code is it? (One simple way to count the number of lines is using "find . -name '*.[ch]' -print | xargs wc -l" from within the source directory.)
2. Briefly describe the threat model and security goals for your program.
3. Spend 1-2 hours to understand the organization, structure, and goals of your program. (You'll probably have to browse source code for this, because it is often not documented.) Draw a diagram depicting the program architecture at a high level. Probably your diagram will show a few key components and how they interact. Include your diagram with the solution you turn in to this homework.
4. Based on the diagram you drew, what portions of the program are most likely to have the highest risk of security holes?
5. Spend 1-2 hours reading code from the high-risk portions you named above, looking to see whether the program meets its security goals. This should include an intensive review of the source code, looking for common implementation errors. You don't have to audit all the high-risk pieces you named above; instead, stop after 1-2 hours, and describe which pieces you did audit.
6. Next, download RATS and run it on the source code. It will warn you about potential trouble spots that could use manual inspection, prioritized according to the risk of security hole. Each such warning will name a describe a type of implementation error that could be present there, and it is up to you to inspect that segment of code and decide whether it is ok or not (you are much smarter than RATS). Spend 1-2 hours examining the warnings it gives you by hand to see whether they correspond to security holes or not. You don't have to inspect all the RATS warnings; look at them in priority order, and stop after 1-2 hours. Print out the output from RATS, and circle the warnings that you did inspect.
   Hint: If you use vim, redirect the output from RATS into a file "rats.out", run "vim -q rats.out", and type ":cn" repeatedly to cycle through the lines identified by RATS. I mapped function key F3 to the next-warning functionality by adding

   map #3 :cn^V^M

   to my ~/.vimrc file (here "^X" represents a control-X character, which can be entered in vi by typing control-V control-X). Type ":h quickfix" within a vi window for more on the next-warning functionality.
   If you use emacs, I believe you can run "emacs rats.out" and type "C-x `" (control-X backtick) repeatedly to get a similar effect.
7. Write a lucid summary of the results of your audit. Did you find any security holes or fishy-looking code? Could the code have been structured better for security? Describe your findings.
   To get the idea of what an audit summary might look like, you can refer to an example audit I entered on the Sardonix web site (sadly, my formatting sucks; you could use HTML tags a bit better than I did).
   Submit your audit summary to the Sardonix audit portal (you'll need to register as an auditor first; use your real name to make my life easier), filling out all fields. (The Sardonix web site is a forum for those who have done security audits to report on their findings.)
   Also, print out and attach to your homework your audit summary. If you found any potential security holes, email the code maintainer as well.