CS 261 Homework 2


This problem set is due Thursday, 14 October. Turn in your answers, on paper, at the beginning of class that Thursday. Please include both your name and your WebReview username at the top of the first page of your solutions.

Work on your own for this homework. 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

You've been assigned two implementations of htmlfilter (see HW 1 Question 3) that were submitted to me in HW1. Your goal will be assess how well those implementations meet the security goals set out in HW1 (you may want to refer to the HW1 assignment if you've forgotten the problem specification). You do not need to review how well they meet the functionality requirements.

To begin, find your assigned implementations. Implementations are identified by a two-digit code (e.g., 17.tar); next to your WebReview userid you will find your two assigned implementations. Download those two implementations from this directory. Do a security audit of both.

  1. What is the two-digit ID number of your first assigned implementation? What are its main security weaknesses or most plausible security failure mode?
  2. What is the two-digit ID number of your second assigned implementation? What are its main security weaknesses or most plausible security failure mode?
  3. If you were forced to choose between these two implementations, which one would you judge to be more likely to meet its security goals (i.e., less likely to have its security penetrated)? Why?

Promise: Your answers on this homework will not affect the grades of anyone else. You can feel free to critique an implementation honestly and frankly without fearing that your comments will have any negative effect on that person's grade. Grades for HW1 have already been assigned. I will not show your evaluation to the authors of your assigned implementations.

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, 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.), or you could look here. Or, you can pick one yourself.

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 did last time I offered this course.
    Print out and attach to your homework your audit summary. If you found any potential security holes, notify the code maintainer as well.