This course makes use of Athena, MIT’s UNIX-based computing environment. OCW does not provide access to this environment.
Lectures: 2 sessions / week, 1.5 hours / session
6.033 Computer System Engineering
6.858 Computer Security studies the design and implementation of secure computer systems. Lectures cover threat models, attacks that compromise security, and techniques for achieving security, based on recent research papers. Topics include operating system (OS) security, capabilities, information flow control, language security, network protocols, hardware security, and security in web applications. Assignments include labs that involve implementing and compromising a secure web server and web application, and a group final project.
6.858 is primarily intended for seniors and Masters of Engineering students who want to learn about how to build secure computer systems in detail. Ph.D. students are also welcome. Students can use 6.858 to fulfill the engineering concentration requirements for Computer Systems.
Each lecture will cover a paper in systems security. Read the paper before lecture, and submit by 10PM the night before:
We’ll discuss the paper in class. Please interrupt, ask questions, and point out mistakes.
There will be two quizzes during our regular lecture time slot. No “final exam” during finals week; second quiz near end-of-term.
There are 6 labs and a final project in this course. Labs will look like real-world systems, in some respects: There are many interacting parts written in different languages. We’ll look at / write x86 asm, C, Python, Javascript, etc…
There will be a final project at the end of the course (groups of 3–4 people), and presentations during the last week of class. Think of projects you’d like to work on as you’re reading papers. Either attack or defense-oriented projects are possible. It is ok to combine this project with other class projects or your own research.
| ACTIVITIES | PERCENTAGES |
|---|---|
| 2 Quizzes | 20% |
| Lab Exercises | 35% |
| Final Project and Presentation | 25% |
| Homework and Class Participation | 20% |
Lab exercises will be graded on the correctness based on both the lab assignment and whether they fulfill the specifications imposed by the grading / checking scripts. Grading will be done with a staff-version of the Makefile and grading scripts, so you should pass all the tests without any modifications to those files.
You are required to turn in each lab; if you have not turned in all of the labs, you will receive an F. Labs that are turned in but score 0 points will receive a D. You have a total of 72 late hours to use throughout the semester. After you have used up your late hours, each additional day late will incur a full letter grade penalty. Saturday and Sunday both count as days. (Late days are tracked automatically, so you don’t need to email before using one.)
You may not collaborate on quizzes. You are welcome to discuss the labs with other students, but you should complete all assignments on your own, and you should carefully acknowledge all contributions of ideas by others, whether from classmates or from sources you have read. Final projects will be in groups, where you should collaborate.
You will learn how to attack systems so that you know how to defend them. Just because something is technically possible, doesn’t mean it’s legal.
| LABS | SUPPORTING FILES |
|---|---|
| Lab 1: Buffer Overflows (PDF) | vm-6858.zip (ZIP) (This ZIP contains the files .vmdx, .vmx, .vmx-e) lab1.zip (ZIP) (This ZIP contains the files .vmdx, .vmx, .vmx-e) |
| Lab 2: Privilege Separation (PDF) | lab2.zip (ZIP) (This ZIP contains the files .txt, .sh, .ico, .py, etc.) |
| Lab 3: Symbolic Execution (PDF) | lab3.zip (ZIP) (This ZIP contains the files .txt, .sh, .ico, .py, etc.) |
| Lab 4: Attacking the Server (PDF) | <no supporting files> |
| Lab 5: Browser Security (PDF) | lab5.zip (ZIP) (This ZIP contains the files .txt, .sh, .ico, .py, etc.) |
| Lab 6: JavaScript Sandboxing (PDF) | lab6.zip (ZIP) (This ZIP contains the files .txt, .sh, .ico, .py, etc.) |
This course makes use of Athena, MIT’s UNIX-based computing environment. OCW does not provide access to this environment.
Idea discussions due: One day after Lecture 13
Proposals due: Two days after Quiz 1
Presentations due: Lecture 24 (in class)
Code and write-up due: Two days after Lecture 24 (5:00pm)
In this lab, you will work on a final project of your own choice. Unlike in previous labs, you will 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. 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 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.
We encourage students to choose any project idea that you might think is interesting. If you are not sure, we provides you with two kinds of ideas. First, we present two reasonably well-defined starting points for projects. Second, we give a list of half-baked ideas that we think could turn into an interesting project, but we haven’t given them too much thought.
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.828 Operating System Engineering or 6.S897 (elections and voting technology), 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 online. Several final projects from previous years ended up being subsequently published as research papers (e.g., UserFS (PDF), BStore (PDF), and LXFI (PDF)). 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 short summary of your idea (one to two paragraphs). Discuss ideas with others. Use these discussions to help find other students interested in similar ideas for forming a group. Course staff will provide feedback on project ideas; if you’d like more detailed feedback, come chat with us in person.
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:
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. 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 a document describing the design and implementation of your project, and turn it in along with your project’s code by the final deadline. 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 (2012 and 2013) to get a sense of what this writeup should look like.
We provide two starting points if you want a well-defined project. One involves building a defensive system, namely an encrypted file system that allows users to share data through an untrusted server. The other involves finding vulnerabilities in existing systems, namely in various MIT services that IS&T runs.
Your goal for this project idea is to develop a file system that allows users to store data on an untrusted file server. The file server should not be able to obtain the user’s plaintext data (i.e., your file system should encrypt the data), and the file server should not be able to corrupt the data either (i.e., your file system should authenticate the data it gets back from the file server).
Your file system should support many users, and allow users to share files with one another. For each file, it should be possible to control the set of users who can read, and who can write, to that file.
At a minimum, your file system should meet the following requirements:
The final result of this project should be a functional file system implementation that meets the above requirements. You can implement your prototype in any language you want, such as Python or C++ or Go. You can decide how the file system client and server should be run. One reasonable design would be to have the file system client provide a minimal shell environment that allows users to perform the operations described in the above requirements.
As a challenge, you may want to think about providing freshness guarantees: that is, that a client should always see the latest version of a file, or at least that a client should never see an older version of a file after it sees a newer one. The SUNDR file system (PDF) may provide some inspiration for this, although it is a rather complicated system. You can choose to implement some limited freshness guarantees, unlike SUNDR’s ideal fork consistency.
As another challenge, you may want to think about integrating your file system with the OS of your choosing. You may find FUSE helpful for this.
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 building a file system (see project above). 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.
If you are interested in working on something other than the two projects proposed above, here are some half-baked ideas. Use them to come up with more well-defined projects; we expect the final work to be comparable in terms of total effort to the two well-defined projects listed above. Of course, 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.
This section contains external resources related to the material taught in this class.
| LEC # | READINGS | READING QUESTION |
|---|---|---|
| 1 | No readings | No question |
| 2 | Akritidis, Periklis, Manuel Costa, et al. “Baggy Bounds Checking: An Efficient and Backwards-Compatible Defense against Out-of-Bounds Errors.” USENIX Security Symposium (2009): pp. 51–66. | Lecture 2 Question (PDF) |
| 3 | Bittau, Andrea, Adam Belay, et al. “Hacking Blind.” Proceedings of the IEEE Symposium on Security & Privacy (2014). | Lecture 3 Question (PDF) |
| 4 | Krohn, Maxwell. “Building Secure High-Performance Web Services with OKWS (PDF).” USENIX Technical Conference (2004): pp. 185–198. | Lecture 4 Question (PDF) |
| 5 | No readings | No question |
| 6 | Hardy, Norm. “The Confused Deputy.” ACM SIGOPS Operating Systems Review 22, no. 4 (1988): pp. 36–38. Watson, Robert N. M., Jonathan Anderson, et al. “Capsicum: practical capabilities for UNIX.” (PDF) Proceedings of the 19th USENIX Security Symposium (2010). | Lecture 6 Question (PDF) |
| 7 | Yee, Bennett, David Sehr, et al. “Native Client: A Sandbox for Portable, Untrusted x86 Native Code.” IEEE Symposium on Security and Privacy (2009): pp. 79–93. | Lecture 7 Question (PDF) |
| 8 | “OWASP Top 10 - 2013: The Ten Most Critical Web Application Security Risks.” Zalewski, Michal. Chapters 9–13 in The Tangled Web: A Guide to Securing Modern Web Applications. No Starch Press, 2011. ISBN: 9781593273880. | Lecture 8 Question (PDF) |
| 9 | Lecture 9 Question (PDF) | |
| 10 | Cadar, Cristian, Daniel Dunbar, et al. “KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs.” Operating Systems Design and Implementation (2008): pp. 209–224. | Lecture 10 Question (PDF) |
| 11 | Chlipala, Adam. “Ur / Web: A Simple Model for Programming the Web.” ACM SIGPLAN-SIGACT Symposium (2015): pp. 153–165. | Lecture 11 Question (PDF) |
| 12 | Bellovin, Steven M. “A Look Back at ‘Security Problems in the TCP/IP Protocol Suite’.” Computer Security Applications Conference (2004): pp. 229–249. | Lecture 12 Question (PDF) |
| 13 | Steiner, Jennifer G., Clifford Neuman, et al. “Kerberos: An Authentication Service for Open Network Systems.” USENIX Conference (1988). | Lecture 13 Question (PDF) |
| 14 | Jackson, Collin, and Adam Barth. “ForceHTTPS: Protecting High-Security Web Sites from Network Attacks.” Proceedings of the 17th international conference on World Wide Web (2008): pp. 525–534. | Lecture 14 Question (PDF) |
| 15 | Fu, Kevin. “Trustworthy Medical Device Software,” 2011. | Lecture 15 Question (PDF) |
| 16 | Brumley, David, and Dan Boneh. “Remote Timing Attacks are Practical.” Proceedings of the 12th USENIX Security Symposium 12, (2003): pp. 1. | Lecture 16 Question (PDF) |
| 17 | Bonneau, Joseph, Cormac Herley, et al. “The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes.” IEEE Symposium on Security and Privacy (2012): pp. 553–567. There is an optional extended version published by the University of Cambridge: Computer Laboratory. | Lecture 17 Question (PDF) |
| 18 | Aggarwal, Gaurav, Elie Burzstein, et al. “An Analysis of Private Browsing Modes in Modern Browsers.” USENIX Conference on Security (2010). | Lecture 18 Question (PDF) |
| 19 | Dingledine, Roger, Nick Mathewson, et al. “Tor: The Second-Generation Onion Router.” Proceedings of the 13th USENIX Security Symposium 13 (2004): pp. 21. Blog posts: | Lecture 19 Question (PDF) |
| 20 | “Enck, William, Machigar Ongtang, et al. “Understanding Android Security.” IEEE Security and Privacy 7, no. 1 (2009): pp. 50–57. Errata: Bug in the paper: In Figure 1, in the FriendViewer application, the top right blue oval (shown as Activity “FriendTracker”) should actually be a rounded-rectangle Activity “FriendMap” (see Figure 2). | Lecture 20 Question (PDF) |
| 21 | Enck, William, Peter Gilbert, et al. “TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones.” Communications of the ACM 57, no. 3 (2010): pp. 99–106. | Lecture 21 Questions (PDF) |
| 22 | No readings | No question |
| 23 | Levchenko, Kirill, Andreas Pitsillidis, et al. “Click Trajectories: End-to-End Analysis of the Spam Value Chain.” IEEE Symposium on Security and Privacy (2011): pp. 431–446. | Lecture 23 Question (PDF) |
| 24 | No readings | No question |
| LEC # | TOPICS AND NOTES |
|---|---|
| 1 | Introduction, Threat Models (PDF) |
| 2 | Control Hijacking Attacks (PDF) |
| 3 | Buffer Overflow Exploits and Defenses (PDF) |
| 4 | Privilege Separation (PDF) |
| 5 | Guest Lecture: Paul Youn from iSEC Partners (no notes) |
| 6 | Capabilities (PDF) |
| 7 | Sandboxing Native Code (PDF) |
| 8 | Web Security Model (PDF) |
| 9 | Securing Web Applications (PDF) |
| 10 | Symbolic Execution (no notes) |
| 11 | Ur / Web (no notes) |
| 12 | Network Security (PDF) |
| 13 | Network Protocols (PDF) |
| 14 | SSL and HTTPS (PDF) |
| 15 | Medical Software (no notes) |
| 16 | Side-Channel Attacks (PDF) |
| 17 | User Authentication (PDF) |
| 18 | Private Browsing (PDF) |
| 19 | Anonymous Communication (no notes) |
| 20 | Mobile Phone Security (PDF) |
| 21 | Data Tracking (PDF) |
| 22 | Guest Lecture: Mark Silis and David LaPorte from MIT IS&T (no notes) |
| 23 | Security Economics (PDF) |
| 24 | Project Presentations (no notes) |
