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.
There are four steps to doing a final project; they are as follows:
Project proposal.
Discuss your proposed idea with course staff before the proposal
deadline of March 18th 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.
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.
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 6th. 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
(2011,
2012,
2013,
2014,
2015,
2017,
2018,
2019)
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:
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:
Build a hardware U2F token, perhaps using an Arduino.
Use WebAssembly and
WASI, the WebAssembly System Interface, to
run Linux applications inside a WebAssembly sandbox. One benefit from doing
this using WebAssembly, as opposed to namespaces, is that you might be able
to better virtualize the file and network APIs seen by the application, or
interpose on those operations at runtime. Perhaps you can make a log of all
of the files that the application accessed, and its network connections, or
ask the user if access should be allowed, etc.
Experiment with building applications using Intel SGX.
You might find it interesting to read Haven
as a starting point.
Write a tool to help privilege-separating Python applications, and
apply it to the Zoobar labs or other real applications. Perhaps
you can draw some inspiration from the RLbox
paper.
Get the concolic execution system from lab 3 to work on real-world
Python web applications, and try to find real bugs.
Port the concolic execution system from lab 3 to a different
language (e.g., Go).
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. 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, and you
can also leverage support for Python type hints.
Find bugs in real code, whether it be C, C++, Go, Rust, etc.
Fuzzing is probably a good starting point, using either
AFL directly
or a language-specific fuzzer (e.g., using
Go fuzzing supportFuzzFactory
and PerfFuzz.
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 or
S2E 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 and more recent
transient execution
side channels.
Build an interesting application on top of Webathena
(site,
code).
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.
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?
The Tor Project has some ideas for possible Tor-related projects
here.