CSE 409/509 Fall 2010. Computer Security

There are 3 project options available to 509 students this semester. Students in 409 must do Option 1. Project teams must schedule a demo session for 12/2 (or earlier) and must turn in a final report by 12/13. The report should describe the project and any revisions made in response to feedback during the demo.

Deadlines are:
DateTaskWeight of Grade
12/2Demo bugs20
12/13Final report80
You should email me to make a demo appointment on or before 12/2. Teams will have about 10 minutes/person for their demo (e.g. a 1-person team will have 10 minutes, 2-person teams will have 20 minutes, etc.).

Note: For students in 409 or 509, if you would like to do a different class project, feel free to come discuss your project ideas with me.

Project Option 1: (409 students only) Audit open source software

In this project, you will audit open-source software projects for security bugs. For each security bug, you must write a patch, submit the patch to the developers of the project, and get it approved and accepted into the project source code. The number of bugs you must find depends on the size of your team:

Team SizeNumber of bugs
110
218
325

For each bug you find and fix, you must submit the following information:

The best way to submit the above information is to

  1. Send a bug report with a description of the bug to the project mailing list.
  2. Continue any discussion of the bug on the mailing list.
  3. Get the developers to commit the code to their source code repository and acknowledge doing so on the mailing list or in their commit log message.
  4. Your final report will consist of the URLs of the mails in the project mailing list archives.

Note that you must find and fix bugs in open-source projects. Do not find bugs in live websites or other software in active use by other people! To do so would be illegal! To find bugs, you should:

  1. Download the source code of the project.
  2. Compile and install the software and get it running on your own system.
  3. Search for bugs in the program by reading or analyzing the source code or through testing of the software on your own system.
  4. Patch the bug in the source code you downloaded, then recompile, reinstall, restart, and retest the software to confirm that you fixed the bug.
  5. Send a bug report and patch to the developers explaining the fix.

You will likely need to use several tools to complete the project, including subversion, git, diff and patch.

You've probably learned to use svn (maybe git) in previous classes, but you may have never learned to use patch, so I'll explain it here. First, you should obtain the current development version of the project using svn, git, or whatever other version management software the project uses. Patches to old versions of a project that no one uses anymore are not so useful. Assuming you checked out the code for the project into directory project, then the most common way to generate patches is to do as follows:

  $ cp -a project project-new
  $ cd project-new
    ... find, fix, and test the bug in project-new ...
  $ cd ..
  $ diff -urN project project-new > project.patch
Then inspect project.patch to make sure it contains only what you expected. If it has more changes than necessary, then clean up your project-new so that the only different between it and project is your bug fix. Once you've created a good patch, you can mail it to the developers with an explanation of the bug.

Students must also present their findings in an end-of-project interview. Each member of your group should be prepared to present one of the bugs you found and fixed. Be prepared to give a brief overview of the program with the bug, a code walk-through of the bug, and an explanation of your patch. If you think it will help make it clearer that the bug is exploitable, then you may also demo the program "behaving weirdly" because of the bug, although this is not required. You don't have to write a full exploit, just cause the program to crash or generate some incorrect output.

You can use Freshmeat and SourceForge to find projects to audit.

The following code auditing tools may be helpful

Project Option 2: Capability-oriented secure web applications

In this project, you will apply the principles of capability-oriented programming to improve the security of web applications. There are two relevant background papers:

The CLAMP paper describes an important security goal of all web applications: an attacker that breaks into a web site should not be able to read or modify any data that he could not modify through the web site itself. For example, an attacker that breaks into a web server should not be able to read other users' private account information. CLAMP isolates clients by starting a new instance of the web service in a virtual machine for each client and directing all input from the client to his or her virtual machine. Each virtual machine's access to the web site's database is mediated by a "database restrictor" to prevent reading or modifying data that does not belong to that client. The obvious downside to this approach is that starting virtual machines is expensive.

Joe-e is a subset of the java language that is designed to make it easy for programmers to run each module of their code with the least privilege that it needs. In a Joe-e program, each class, object, method, etc, only has access to other objects that are explicitly granted to it. Programs written in Joe-e cannot use certain java features that violate the capability-oriented programming model.

For this project, you must modify an existing java web application to encapsulate each client within a joe-e subset of the program. In other words, you should structure the program so that, for each client, it instantiates an object of a class written in Joe-e, and all interaction with the client is handled by that Joe-e object. You will probably have to convert several classes to Joe-e in order to completely isolate the client. Note that you do not need to convert the entire application to java -- the main part of the program that accepts incoming connections can be written in java.

The web application you modify must be at least 20KLOC in size. After selecting your application, please send me a brief email telling me about the application so I can approve it.

Evaluation and grading: During your demo, you should briefly describe the web application and its original code design, e.g. was it multi-threaded, event-oriented, or a hybrid? You should also demonstrate that the original application failed to compile with Joe-e. You should then describe at a medium-to-high level how you modified the application for Joe-e and demonstrate that the modified version compiles with Joe-e. Be prepared to explain the major difficulties you encountered while converting the program to Joe-e. Your final report should cover these issues, including any additional progress you make after the demo.

Project Option 3: FaceBook-based access controls for file sharing

DirectConnect is a peer-to-peer filesharing protocol with many open-source implementations. Each DC user can set up his or her own hub, and specify permissions for who can access that hub. Typically, individuals grant access to their friends so that they can share files with only people they trust.

Configuring the privacy settings of a DC hub can be a tedious process, espcially since many users have already created a list of all their friends on FaceBook. Why can't they just import that list?

In this project, you will design and implement a scheme for using FaceBook friends information to configure access controls in a DC network client and/or hub.

There are several design decisions you must make before you begin coding:

You do not need to write your own DC software from scratch -- you can download an existing DC client or hub and modify it to add your FaceBook-related features?

Evaluation: You should describe and demonstrate your application and features in the demo meeting. You should also be prepared to explain your design choices with respect to the above issues. Your final report should cover your design decisions and explain the advantages and disadvantages of your design.

Project Option 4: Develop a new bug-finding tool

In this project, you will develop a new static analysis tool to detect security bugs of your choice. Your tool may analyze C, C++, Java, PHP, Python, Perl, Ruby, or some other language. You should first pick a class of bugs, and then find (or create) a toolkit for parsing and analyzing the appropriate language. Example bug classes are There are also several toolkits for parsing and manipulating source code:

Before starting on this project, you should write a 1-2 page plan of attack and submit it to me for approval. Your plan should identify the class of bugs you hope to detect (including a few examples), give some recent bug reports demonstrating that this is an important security bug, describe a high-level algorithm for detecting them, and list several open source projects you can use to test your algorithm.

After developing your bug-finding tool, you should test it on several open-source projects. You should plan a demo of your project with me sometime before the end of the semester, and you must turn in a 6-8 page final report describing your algorithm and experimental results at the end of the semester. You may work in teams of 2-3 students.

You can use Freshmeat and SourceForge to find projects to audit.