6.858 Fall 2012 Lab 7: Final project

Piazza idea discussions due:	Monday, October 29, 2012
Proposals due:	Monday, November 5, 2012
Presentations due:	Wednesday, December 12, 2012 (in class)
Code and write-up due:	Friday, December 14, 2012 (5:00pm)

Introduction

In this lab, you will work on a final project of your own choice. Unlike in previous labs, you may work in groups of 3-4 for the final project. You will be required to turn in both your code and a short write-up describing the design and implementation of your project, and to make a short in-class presentation about your work.

The primary requirement is that your project be something interesting. Your project should also have something to do with security, but that's relatively easy, and it's much more important for your project to be interesting.

Below are some ideas for final projects that you might use as inspiration, including some of the projects from past years. We encourage you to come up with your own ideas for what you would like to work on; there's no need to restrict yourself to this list.

• Try to study what adversaries do when they break into a machine. Adversaries often scan random machines looking for vulnerabilities. For example, you could set up a system with known-vulnerable software (e.g., an old version of OpenSSH that has some bugs, an old version of some well-known web application that has bugs, etc), and see what an adversary does when they compromise your system.
• Build a static analysis tool to find bugs in real web applications. It would be great to have a static analysis tool for Python programs, even if it's not perfectly sound, much like the PHP static analysis tool we discussed in lecture. In addition to the standard XSS bugs, can you find bugs where application developers forget to perform permission checks, or inadvertently leak sensitive data? Such a tool might also be useful to find non-security bugs in Python programs. One existing tool that's quite limited is PyLint.
• Find bugs in real C code. Take a look at some recent research papers on finding real bugs in the Linux kernel and other C-based programs, involving integer errors or undefined behavior. We can give you access to our source code to these tools; you can apply them to existing software to see what bugs you can find, and also think about ways to extend the tools to make them more accurate, to make them find other kinds of bugs, etc.
• Extend program analysis tools used by Linux kernel developers, such as sparse and smatch, to catch different kinds of bugs in the kernel.
• Use the KLEE symbolic execution system to build an analysis tool that finds interesting bugs in C programs.
• Explore the extent to which covert channels / side channels matter, e.g. in shared VMs like EC2, vs. shared OS, vs. other environments. See this paper for some background information.
• Add Capsicum support to Linux.
• Port an interesting application to use Capsicum (on FreeBSD).
• Analyze the security of MIT's single-signon system, Touchstone / Shibboleth.
• Find an interesting application / use case for Webathena (site, code), or extend it to support non-DES enctypes (AES, etc).
• Implement Kerberos for Android. We can put you in touch with some folks at the Kerberos Consortium that are working on this. It would be interesting to implement a Kerberos ticket caching service, accessed via Android intents, so that an application can use Kerberos tickets for a specific service without being able to steal the user's entire TGS ticket.
• Implement progressive authentication: instead of requiring the user to log in to do anything, require different levels of credentials for specific tasks. For example, on Athena, perhaps running a web browser should not require any credentials, but accessing your personal files (or your browser accessing your google.com cookie that gives access to gmail) should require your Kerberos password, etc. The same would apply on an Android phone: checking the weather or the map should not require any credentials, but accessing the mail app should prompt for a PIN, swipe pattern, or password. A paper from Microsoft Research might give you some things to think about, although it may not be worthwhile to implement all of the environment monitoring done in that work.
• Examine the security of Android applications. Look at some previous studies for inspiration (one, two).
• Improve sandboxing for Android applications. Is there something that you could do to prevent a malicious application from exploiting kernel bugs? Consider recent improvements to seccomp, using Linux KVM, or using Native Client.
• Audit interactions between Android applications, perhaps by tracing all intents sent via the reference monitor. When something goes wrong, can your system tell the user why an application might be broken?
• Implement an environmental key generation system.
• Build a password manager for Android applications, perhaps by implementing a virtual keyboard that can automatically enter passwords into an application. The virtual keyboard can know exactly what application it's entering passwords into, which can guard against phishing-style attacks.
• Provide more fine-grained network access control in Android, to protect an internal corporate network from possibly-malicious applications on a phone.
• Allow users to control application permissions in Android. For example, a user may want to install some application that requires access to the current GPS location, but the user doesn't actually want to give the app this permission. Would it suffice to simply remove the permission from the manifest, or is it necessary to provide dummy services that give back fake data?
• Implement more efficient sandboxing support for Python, so that it's possible to import an untrusted Python module without giving it full access to your system or your application, and without having to run the entire application in a separate PyPy sandbox. Python already provides some basic memory safety guarantees (although you might need to implement some mechanism to restrict introspection).
• Speed up PyPy's sandbox mode.
• Implement a more fully-featured PyPy sandbox. Can you run all of zoobar in the sandbox, to avoid any need for uid-based privilege isolation?
• Implement a buffer overflow protection scheme, perhaps similar to Baggy bounds checking, building on top of Clang and LLVM.
• Use DynamoRIO's binary instrumentation to implement some cool security mechanism for unmodified binaries. For example, you could implement a binary-level taint tracking system, similar to Resin, that prevents secret files from being sent out over the network. You can look at a previous lab we used to have involving DynamoRIO from a few years ago here.
• Use Resin's taint tracking for Python to enforce some interesting properties in zoobar.
• Find an interesting use for trusted hardware, and figure out how to expose trusted hardware safely to applications. Linux should already have a basic device driver for a TPM.
• Write a tool to help privilege-separating Python applications.
• Evaluate how hard it is to privilege-separate a real application (pick any application and try to privilege-separate it yourself; there should be many examples of Django-based Python apps).
• Implement more flexible protection mechanisms for Linux (so that any user can create additional protection domains -- sub-users -- to run code with less privileges, without having to be root). You can build upon a class project from a previous year, UserFS.
• Based on Google's caja library, sandbox existing Javascript mashups/applets (what to do about existing uses of globals in the Javascript environment?)
• Write a browser plugin to prevent cross-site scripting attacks when both the server and the client are following some rules (e.g. explicitly annotating privileged JS code). Bonus points for allowing untrusted JS code using something like caja!
• Improve the security of HTTPS in web browsers in the face of possibly compromised CAs. For example, define a new URL syntax that includes the server's certificate public key in the URL itself, so that one site can unambiguously include a link to another site without relying on CAs. Or, include the CA name in the URL, so that another CA cannot subvert security. See SSL observatory, perspectives, and CertPatrol.
• Implement an encrypted file system with plausible deniability (i.e. where there can be multiple encrypted file system images within a single FS, and without the right password, you don't know if unused blocks are free or part of another encrypted FS you don't have the password for.) See paper on deniable file systems and TrueCrypt.
• Auditing support for web applications. For instance, suppose someone broke into your blog or forum, added a user account for themselves, changed permissions, and posted garbage messages. How can you track down all of the changes made by the attacker? Could be done with the help of a language runtime, such as Resin.
• Examine the security of Google's Chromebook laptops. We can loan out some CR-48 laptops to interested students.
• Integrate zoobar with single-signon protocols like OAuth or OpenID.
• Figure out how to integrate password-authenticated key exchange protocols into a web browser. Note that such protocols could be used to both authenticate the user to the server (thus avoiding phishing attacks), and to authenticate the server to the user (thus avoiding compromised CA attacks). For references, look up SRP and PAKE.
• The Tor Project has some ideas for possible Tor-related projects here.
• Analyze the Bitcoin transaction graph. How hard is it to anonymize Bitcoin exchanges? Here's one recent paper analyzing the Bitcoin data set, which might give you ideas for other things to try.

We encourage final projects that combine some ideas you have learned in 6.858 with other classes or projects you are already working on. For example, implementing some aspects of a capability design from Capsicum in the JOS kernel from 6.828 might make a good final project that you could use in both classes. Extending some system you are already working on to add better security mechanisms would also be a good candidate project.

Several final projects from last year's class ended up being subsequently published as research papers (e.g., UserFS, BStore, and LXFI). If this sounds interesting to you, try to pick an ambitious class project that you might want to continue working on afterwards!

There are four concrete steps to the final project, as follows:

We have posted final project submissions here.