ECS 289M Projects

Goal Research projects are a major requirement of this course. You will do original research on a problem of interest in software security to advance the state of the art knowledge. Be ambitious! Aim for publishable results in prestigious security conferences, such as:

• IEEE Symposium on Security and Privacy
• USENIX Security Symposium
• ACM Conference on Computer and Communications Security
• Network and Distributed System Security Symposium

Teams You will form a group of 2-3 people. Although I will not categorically rule out solo teams, I expect that working in groups will allow you to tackle more substantial research issues. You may use the class mailing list to find project partners, or I may help you find a partner.

Topics Your project topic should be relevant to software security in some way, but I will interpret this requirement broadly. I encourage you to be creative in identifying valuable problems. You are welcome to tie your project with your current research or with your project in another class.

Please come to talk to me about your project ideas. Here are some example topics to give you a feeling of potential projects. Although you are welcome to choose from these topics, you are in no way limited to them.

Project proposals, due Sunday, 10/17. Choose your project topic and discuss it with me. Form your project team. Set up a web page with the name of your project, team members, and your proposal. Your proposal should briefly describe the problem, the past work on it, your new or improved approaches, and your project schedule. Email me the URL of your project web page.

Midterm report, due 11/16, in class. Your report should define the problem, your approach, your progress, and your plan for the rest of the project. Turn in your report on paper in class.

Presentations or poster session, in the week of December 6. The students will nominate the best project, and I will present an award. So try your best!

Final report, due Saturday, 12/18. Write a conference-style paper describing the problem, your approach, your results, the merits and shortcomings of your approach compared to the past work on the problem. Discuss how to improve your approach or future work on the problem.

Apply program analysis tools Use program analysis tools to discover vulnerabilities. There are many opportunities for making original contributions:

• Discovering a new class of vulnerabilities.
• Checking a vulnerability that no tool has checked.
• Checking a vulnerability better than previous work, because the tool of your choice is more sound, complete, scalable, etc.
• Checking programs that no tool has checked.

Tools You may consider the following tools:

• Cqual: a C qualifier inference tool that has been used to check format string bugs, user/kernel pointer bugs, Y2K bugs, etc.
• MOPS: a software model checker that has been used to check privilege escalation, race conditions, standard file descriptor vulnerabilities, temporary file vulnerabilities, etc.

Writings on vulnerabilities Besides the vulnerabilities that we discussed in class, you may find more from these fine sources:

• Secure Programming for Linux and Unix HOWTO
• Writing Secure Code

Vulnerability examples Here are some examples of vulnerabilities that static analysis tools may help.

Improve program analysis tools You may extend current program analysis tools to make them more sound, complete, scalable, or capable of checking more vulnerabilities.

Evaluate program analysis tools Compare several program analysis tools. Evaluate their merits and shortcomings, both in design, implementation, and usability. Suggest how you would improve them.

Study the usability of program analysis tools Few, if any, studies have been conducted to evaluate the usability of program analysis tools. As a result, most such tools are difficult to use by ordinary programmers. You may select a few tools, identify their usability problems by empirical evaluation or experimental study involving other people, and suggest how you may address these problems. Better yet, propose guidelines for evaluating and improving the usability of program analysis tools.

Check executable programs Most tools check source programs, because it is easy to extract their control flows. However, we need tools that can check binary programs, when

• The source code is inaccessible, because it is proprietary, or is lost.
• The parser that generates executables may parse the source program differently than the parser in the analysis tool. For example, the C language standard does not specify the order of evaluation in certain expressions, so different parsers may implement the order differently.

Identify the challenges in applying techniques for checking source programs to executables. Make a first attempt to implement a simple tool for checking executables. Summarize the lessons learned and propose future work.

Mitigate attacks through diversity Biological systems protect themselves from diseases by diversity: their genes are sufficiently diverse that no disease can infect the entire population. Software systems, however, are highly homogenuous: a worm targeting a vulnerability in a program will infect the program running on all computers. By introducing diversity into software, we may mitigate attacks by limiting the number of programs where the attack may succeed. For example, if we randomize the order of local variables on the stack, one buffer overflow attack may not affect the majority of the programs.