6.858 Spring 2017 Final assignment: Project

If you choose to do a project, you get to choose what to build, subject to our approval. The project may be done individually, or you can form a group of 2 to 3 6.858 students to collaborate on the project. We encourage students to work in groups, as this often enables more interesting projects. You'll turn in your code and a short write-up describing the design and implementation of your project, and make a short in-class presentation about your work. We will post your write-up and code on the web site after the end of the semester, unless you explicitly talk to us about why you want to keep yours confidential.

The primary requirement for project ideas is that they are interesting. They should also be at least tangentially related to security, and should be of similar size and difficulty as the final lab. Below, we give some half-baked ideas that we believe could turn into interesting projects. Each one requires some measure of scoping and refinement before they would be suitable as a final project

We encourage final projects that leverage multiple classes you might be taking, or that involve other research or projects you are already working on. For example, if you are also taking 6.824 or 6.857, it would be fine with us to have a single project that counts for both 6.858 and another class. Same for other upper-level course-6 classes or MEng and AUP projects.

Most of the final projects from last year are posted here.

Deliverables

There are four steps to doing a final project; they are as follows:

  1. Project proposal. Discuss your proposed idea with course staff before the proposal deadline of March 24th to flesh out the exact problem you will be addressing, how you will go about doing it, and what tools you might need in the process. Remember: project ideas must be approved by us to be eligble for class credit! By the proposal deadline, you must submit a one-to-two-page proposal to the submission web site describing: your group members list, the problem you want to address, how you plan to address it, and what are you proposing to specifically design and implement.
  2. Project presentation. Prepare a short in-class presentation about the work that you have done for your final project. We will provide a projector that you can use for slides, demos, etc. Depending on the number of groups and the kinds of projects that each group chooses, we may decide to limit the total number of presentations, and some groups might end up not presenting in class.
  3. Write-up and code. Write a document describing the design and implementation of your project, and turn it in along with your project's code by May 12th. The document should be about 2-3 pages of text that helps us understand what problem you solved, and what your code does. The code and writeups will be posted online after the end of the semester. Take a look at the list of writeups from past years (2013, 2014, 2015) to get a sense of what this writeup should look like.

A note about attack-oriented projects

If you are interested in a more attack-oriented final project, your goal for this project is to pick an interesting service provided by MIT's IS&T (or any other computing service at MIT, such as those provided by SIPB), and try to find vulnerabilities in it. We will judge your project based on what kinds of vulnerabilities you find. Beware that there's no guarantee of success with this (or any other attack-oriented) project, because you may accidentally choose a very secure service, and might end up finding no vulnerabilities, which can potentially result in a failing grade. However, if you have an interesting approach to finding vulnerabilities (e.g., you have designed a new tool for finding bugs), you may receive a good grade even without finding real vulnerabilities.

IMPORTANT: In any attack-oriented project, you must be very careful to avoid disrupting existing services, inconveniencing users of those services, compromising the security of that service, or taking advantage of any vulnerabilities you find. If you are ever in doubt, please get in touch with us. If you discover real vulnerabilities in a service, please get in touch both with the operators of that service and with us. Please don't exploit the vulnerability to gain any additional privileges on a service, and don't announce it widely before the service operators have a chance to understand it.

Your grade in this project depends on how interesting the vulnerabilities are that you have found, or how interesting the techniques are that you used to discover those vulnerabilities. For example, obtaining passwords through traditional brute-forcing techniques is not interesting. The general scale of work expected should be comparable to the amount of work involved in solving the final lab. Of course, much of your work will involve reading and understanding an existing system, and carefully constructing proof-of-concent exploits to demonstrate the vulnerabilities that you discovered, and the total amount of resulting code may be minimal; think back to how much time you spent on lab 1, and how many lines of code your final exploits were.

Here is a list of services that might be interesting targets for security evaluation as part of this project:

If you are interested in looking for bugs in MIT's newly developed APIs or OpenID Connect, several folks at IS&T have volunteered to help you get started: Chris Giles <csgiles@mit.edu>, Stephen Buckley <sbuckley@mit.edu>, and Thomas Hardjono <hardjono@mit.edu>.

Half-baked project ideas

We encourage you to come up with your own ideas for what you would like to work on, but if you're looking for inspiration, what follows is a list of ideas that could turn into good final projects: