6.858 Fall 2011 Lab 7: Final project
|Wiki submission due:
||Friday, November 4, 2011|
||Monday, November 14, 2011|
||Monday, December 12, 2011 (in class)|
|Code and write-up due:
||Friday, December 16, 2011 (11:59pm)|
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 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.
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; don't restrict yourself to this list.
- Examine the security of Android applications. Look at some previous
studies for inspiration
- Improve sandboxing for Android applications. Is there something that
you could do to prevent a malicious application from exploiting kernel
recent improvements to seccomp or using
- 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
- 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?
- 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 last year
- 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.
- Extend Native
Client to support a richer set of external I/O operations,
such as safe network I/O, local files, etc.
- Build tools to find common vulnerabilities in programs of your choice
(e.g., C code, PHP, Python, etc). There are several existing frameworks
on which you could start building, such as
and LLVM for C code, or
PQL (the tool from the Java
static analysis paper) for Java.
- 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,
- Based on Google's caja
- 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
- 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
- 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.
- 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.
- Examine the security of Google's Chromebook
laptops. We can loan out some
to interested students.
- Integrate zoobar with single-signon protocols like Microsoft Passport,
OpenID, OAuth, etc.
- 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.
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 KeyKOS
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
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:
Decide on the project you would like to work on, and post a one-to-two-sentence
summary of your idea to the
project ideas wiki page.
Use the same list of project ideas to help you find other students interested
in similar projects, for forming a group.
Discuss your proposed idea with course staff over the next week,
before the proposal deadline, 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. By the proposal deadline, you must
submit a one-to-two-page proposal 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.
Submit your proposal via email to the course staff
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
to demonstrate your project.
Write a document describing the design and implementation of your project,
and turn it in along with your project's code by the final deadline.