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.
|Date||Task||Weight of Grade|
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.
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 Size||Number of bugs|
For each bug you find and fix, you must submit the following information:
The best way to submit the above information is to
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:
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.patchThen 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
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.
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.
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.