CS261 Projects

General information

Your term project should address a research issue in computer security and consist of the design of some computer security system or technique, or the analysis and possible improvement of some existing system or technique. The main goal of the project is to do original research on a problem of interest in computer security.

You should work in a small group; I expect that teams of approximately 2--3 will be appropriate for most projects. Of course, expectations will be adjusted according to the number of people in your group. I will not categorically rule out solo teams, but I expect that working in groups will allow you to tackle more substantial research issues. If you have trouble finding a project partner, I can help you get matched up with someone else by maintaining a list of people seeking teammates.

Projects will be evaluated on the quality of their research in computer security. At the end of the semester, you will write a conference-style paper on your work. See below for more details.

I expect that most projects will fall (more or less) into one of two categories:

1. Design. Design projects will usually attempt to solve some interesting problem by proposing a design; implementing a prototype; and using the implementation as a basis for evaluating the proposed system architecture.
2. Analysis. Analysis projects might, for example, study some previously-proposed implementation technique, existing system, or class of systems; evaluate its security properties; find flaws, or strengths, in it; and provide new insight into how to build secure systems.

If you're at a loss for a project topic, I've prepared a list of possible project topics that you can peruse as examples of how to a pick a suitable project. See below. But don't feel limited to these suggestions! They are intended only as examples.

You're welcome to come discuss possible project ideas with me, if you like. I'm happy to make myself available to discuss projects.

A final suggestion: Aim high! The top projects could lead to publication. In past years, the best two or three projects have consistently led to publications.

The process

You will write a concise (approximately 1 page) project proposal that should clearly state the problem you will be solving, the key challenges for new research, your plan of attack (including milestones and dates), and list relevant papers that you are aware of. If there are any special resources you might need from me, mention this as well.

The project proposal is due Friday October 24.

Here's how to submit your proposal. You should put together a web page for your project; currently all it needs to contain is the project members, their email addresses, title of your project, and proposal. Then just email the URL for your project web page to daw@cs.berkeley.edu by Oct 24th.

In mid-November I might ask you to write a concise status report so I can make sure the projects are on-track. I am always available to meet with any groups who would like to discuss their project, request additional resources, or ask for advice.

You will also be required to present your project at a poster session, on Thursday, December 11, 10:30am-noon in the Woz lounge.

Finally, a project report will be due on Thursday, December 18th at 9am.

The final report

You are expected to write a technical paper, in the style of a conference submission, on the research you have done. State the problem you're solving, motivate why it is an important or interesting problem, present your research thoroughly and clearly, compare to any related work that may exist, summarize your research contributions, and draw whatever conclusions may be appropriate. There is no page limit (either minimum or maximum), and reports will be evaluated on technical content (not on length), but I expect most project reports will probably be between 7--15 pages long.

If you are not familiar with writing conference-style papers in computer science (or even if you are), the following resources may help:

• Armando Fox's hints on writing good systems papers
• Detailed advice on technical writing
• Advice on research and writing

You may submit your project report electronically or on paper. I prefer electronic submission, although you may choose either. In either case, the deadline is the same.

If you submit electronically:

1. Please use a format which is easily readable on Unix platforms: HTML, Postscript, or PDF is fine.
2. Place a link to the file on your project web page (see here for the list of project web pages), and send me email with the URL. I will send you confirmation of receipt.

Example ideas for project topics

Note: Many of these examples are quite generic; be sure to narrow down the topic substantially and propose something concrete and focused. If you are interested in any of the project topics below, feel free to talk to me about it; I may be able to make some more concrete suggestions.

Analysis and attacks

Security analysis of HTML sanitization libraries

There are many open-source libraries available that aim to sanitize HTML (e.g., for RSS feeds). Following up on HW1 and HW2, do a thorough security analysis of a suite of sanitization libraries. What lessons did you find?

Security auditing

Evaluate the security of some widely-used or under-scrutinized open-source package. Report on your experiences and lessons. How would you re-structure/re-implement the system to make it more robust? What tools would have made your auditing task easier? How effective are existing tools?

Security review of published schemes

Pick any recently published paper that proposes a new security mechanism or scheme. Ask the authors for the code. Perform a careful security review of the paper's scheme; does it meet the claims made for it? To find recent papers, you could peruse recent proceedings of Usenix Security, IEEE Security & Privacy, ACM CCS, ISOC Network and Distributed System Security, or other security-related conferences.

Web security

Web frameworks

There are many frameworks and libraries out there for building web services (especially for Java). Pick a handful and analyze them in detail. Do they protect against common types of web vulnerabilities? Compare them: which would be the best choice, for a project where security is important?

Ajax security

Develop a way to detect vulnerabilities associated with Ajax and client-side Javascript. For instance, many web services split the code between the server and the client: some of the code runs on the server side (e.g., as Java or PHP), and some of it runs on the web browser (e.g., as Javascript provided as part of the web page). Develop methods to detect vulnerabilities in these kinds of web services. For instance, one common vulnerability involves executing input validation code or other trusted logic on the client instead of on the server; the problem is that the client may be under the attacker's control and so the attacker may be able to bypass that code.

Taint-tracking for vulnerability detection

Does taint-tracking improve the effectiveness of web vulnerability scanners? Most web vulnerability scanners today are black-box testing tools: they crawl a web site, try to send malicious requests, and guess based upon the responses whether the web site might have any vulnerabilities. If we could instrument the web site's code with taint-tracking, this might find more vulnerabilities (i.e., reduce the rate of vulnerabilities that are overlooked). Is this true? You could try to evaluate the question to see.

Defenses against phishing

There has been a great deal of research on defenses against phishing. Can you improve upon any of them?

Key management for SSL

Today, one of the barriers to deploying SSL on small sites is the cost of buying a SSL certificate; and there are questions about whether these certificates add much value anyway (as the CAs don't always do a lot of verification). An alternate model might be to use a SSH-like key management paradigm (sometimes called Key Continuity Management) -- but it's not clear how one could make that work well in practice, on the web. You could take a look at possible schemes for this.

Software security

Inferring security annotations for C/C++ programs

Microsoft has proposed SAL, a set of annotations for C and C++ code intended to help avoid buffer overrun and similar vulnerabilities: the programmer annotates their code with information about buffer lengths and the like, and a static analysis tool checks those annotations to detect possible bugs. See also Deputy, an open-source system from Berkeley with similar goals. Writing these annotations can get a bit tedious. Can you design a dynamic analysis tool that observes code as it runs and infers SAL/Deputy annotations from how the code is used? For instance, if you run the program on 1000 inputs, and in every case, function f() is only called with null-terminated strings, you might infer a SAL/Deputy annotating asserting that the argument to f() is always null-terminated. (See also Daikon, though Daikon is a general-purpose tool; you can probably do a lot better by focusing specifically on the kinds of properties that SAL/Deputy are designed for.) Tools like Valgrind, CIL, ltrace, etc. could be a good building block for this project.

Avoiding integer overflow vulnerabilities in Java

Modern type-safe languages like Java improve on C/C++ by eliminating many classes of vulnerabilities that have plagued C/C++ programs, but it does not eliminate integer overflow and integer casting vulnerabilities. One way to write Java code that is free of integer overflow bugs is to use java.lang.BigInteger (infinite-precision integers) instead of int. However, this introduces a notational burden and makes code less readable: e.g., instead of writing x*(y+z) - 2, the programmer must write x.times(y.plus(z)).minus(new BigInteger(2)). Can you come up with an extension to Java that eliminates this notational burden? For instance, you might build a tool that performs source-to-source translation to transform the former short version into the latter long version before compilation, allowing programmers to use the ordinary binary operators with BigIntegers.

Detecting algorithmic denial-of-service vulnerabilities

An algorithmic denial-of-service vulnerability is a flaw that allows an attacker to provide a carefully chosen input that will trigger worst-case performance behavior in the application under attack and deny service to legitimate users. For instance, at one point the Apache web server had a flaw where URL parsing took time quadratic in the number of "/" characters in the URL; by sending a URL consisting of thousands of slashes, one could cause Apache to consume a huge amount of CPU time. Develop a method to automatically detect these kinds of bugs in application source code. For instance, you might consider using Trend-prof (see also this paper) to detect performance anomalies, and try to infer attacks.

Privilege separation

Pick an interesting security-critical application that is currently implemented monolithically. Investigate how to apply privilege separation techniques to reduce the size of the TCB. Can you implement your new design and evaluate its effectiveness? If you were designing the application from scratch, how would you design it to maximize its security? Any network client or server could be a good candidate for investigation.

Software verification tools for security

Researchers have recently made dramatic improvements in tools for software verification. See, e.g., ESC/Java2 and JML (verification tools for Java) and Spec# (a verification tool for C#). These tools allow programmers to verify properties, such as that the program will never throw a NullPointerException, ArrayIndexBoundsOutofBoundsException, or other runtime exception, and that the program will never use uninitialized memory. Since unexpected exceptions can cause surprising behavior (which is dangerous in a security-critical program), these could be useful for secure programming. You might study how useful and expensive these are for security. For instance, pick one or two security-critical applications written in Java or C# and attempt to verify that they satisfy some useful property (e.g., free of runtime exceptions). How many annotations did you have to add? How much time or effort did it take? Did the effort reveal any vulnerabilities? Or, you might try to see if you can express any of the security requirements for those applications into the JML/Spec# modelling language and see whether it is possible to verify that those requirements are met by the code. Are the JML/Spec# annotation languages rich enough to specify important security policies? If not, what kinds of extensions would be useful for security? Are the existing tools powerful enough to verify that code meets those requirements?

Tools for vulnerability detection

Study ways to build tools to help automate the process of reviewing security-critical applications. Can you use runtime testing, static analysis, model checking, formal verification, or other techniques to detect any interesting classes of common security holes? You may want to consult CWE's list of top classes of vulnerabilities for the past five years.

Virtual machines for security

Virtual machines (e.g., VMWare, Xen, etc.) seem to provide a powerful mechanism for executing dangerous actions in an isolated environment. How secure are existing commercial virtual machines? How hard would it be for a malicious guest application to defeat the VM and harm the host OS? (For instance, an interesting project would be to look at a few commercial or open source VMs and try to see if you can break isolation.) How would you design a high-assurance VM to be sure that isolation could not be compromised and to make it as easy as possible to verify that these security goals have been met?