it-ebooks - MIT 6.858 Computer Systems Security Lecture Notes

Lecture notes from 6.858, taught by Prof. Nickolai Zeldovich and Prof. James Mickens in 2014. These lecture notes are slightly modified from the ones posted on the 6.858 course website.

• Lecture : : what is security, what's the point, no perfect security, policy, threat models, assumptions, mechanism, buffer overflows
• Lecture : : buffer overflows, stack canaries, bounds checking, electric fences, fat pointers, shadow data structure, Jones & Kelly, baggy bounds checking
• Lecture : : costs of bounds checking, non-executable memory, address-space layout randomization (ASLR), return-oriented programming (ROP), stack reading, blind ROP, gadgets
• Lecture : : privilege separation, Linux discretionary access control (DAC), UIDs, GIDs, setuid/setgid, file descriptors, processes, the Apache webserver, chroot jails, remote procedure calls (RPC)
• Lecture : Penetration testingguest lecture by Paul Youn, iSEC Partners
• Lecture : : confused deputy problem, ambient authority, capabilities, sandboxing, discretionary access control (DAC), mandatory access control (MAC), Capsicum
• Lecture : : sandboxing x86 native code, software fault isolation, reliable disassembly, x86 segmentation
• Lecture : : modern web browsers, same-origin policy, frames, DOM nodes, cookies, cross-site request forgery (CSRF) attacks, DNS rebinding attacks, browser plugins
• Lecture : : cross-site scripting (XSS) attacks, XSS defenses, SQL injection atacks, Django, session management, cookies, HTML5 local storage, HTTP protocol ambiguities, covert channels
• Lecture : Symbolic executionguest lecture by Prof. Armando Solar-Lezama, MIT CSAIL
• Lecture : Ur/Webguest lecture by Prof. Adam Chlipala, MIT, CSAIL
• Lecture : : threat model, sequence numbers and attacks, connection hijacking attacks, SYN flooding, bandwidth amplification attacks, routing
• Lecture : : Kerberos architecture and trust model, tickets, authenticators, ticket granting servers, password-changing, replication, network attacks, forward secrecy
• Lecture : : certificates, HTTPS, Online Certificate Status Protocol (OCSP), ForceHTTPS
• Lecture : Medical softwareguest lecture by Prof. Kevin Fu, U. Michigan
• Lecture : : side-channel attacks, RSA encryption, RSA implementation, modular exponentiation, Chinese remainder theorem (CRT), repeated squaring, Montgomery representation, Karatsuba multiplication, RSA blinding, other timing attacks
• Lecture : : what you have, what you know, what you are, passwords, challenge-response, usability, deployability, security, biometrics, multi-factor authentication (MFA), MasterCard's CAP reader
• Lecture : : private browsing mode, local and web attackers, VM-level privacy, OS-level privacy, OS-level privacy, what browsers implement, browser extensions
• Lecture : Torguest lecture by Nick Mathewson, Tor Project
  • 6.858 notes from 2012 on : onion routing, Tor design, Tor circuits, Tor streams, Tor hidden services, blocking Tor, dining cryptographers networks (DC-nets)
• Lecture : : Android applications, activities, services, content providers, broadcast receivers, intents, permissions, labels, reference monitor, broadcast intents
• Lecture : : TaintDroid, Android data leaks, information flow control, taint tracking, taint flags, implicit flows, x86 taint tracking, TightLip
• Lecture : MIT's IS&Tguest lecture by Mark Silis and David LaPorte, MIT IS&T
• Lecture : : economics of cyber-attacks, the spam value chain, advertising, click-support, realization, CAPTCHAs, botnets, payment protocols, ethics

• Lecture : : isolation, Iago attacks, enclaves, attestation, Haven

List of papers we read ():

• (or why capabilities might have been invented)
• (capabilities)
• (sandboxing x86 code)
• , the most critical web application security risks
• (symbolic execution)
• (functional programming for the web)
• : An authentication service for open network systems
• : the second-generation onion router
• : an information-flow tracking system for realtime privacy monitoring on smartphones
• : End-to-end analysis of the spam value chain

• Iago Attacks: Why the System Call API is a Bad Untrusted RPC Interface

Note: These lecture notes were slightly modified from the ones posted on the 6.858 course website from 2014.

• Achieving some goal in the presence of an adversary.
  • Many systems are connected to the internet, which has adversaries.
    • Thus, design of many systems might need to address security.
    • i.e., will the system work when there's an adversary?
• High-level plan for thinking about security:
  • Policy: the goal you want to achieve.
    • e.g. only Alice should read file F.
    • Common goals: confidentiality, integrity, availability.
  • Threat model: assumptions about what the attacker could do.
    • e.g. can guess passwords, cannot physically grab file server.
    • Better to err on the side of assuming attacker can do something.
  • Mechanism: knobs that your system provides to help uphold policy.
    • e.g. user accounts, passwords, file permissions, encryption.
  • Resulting goal: no way for adversary within threat model to violate policy.
    • Note that goal has nothing to say about mechanism.
• Why is security hard? It's a negative goal.
  • Contrast: easy to check whether a positive goal is upheld, e.g., Alice can actually read file F. Harder to check that there's no possible way Alice can read file F.
    • How would you even begin to enumerate all the possible ways Alice could go aboutreading the file? Too many layers at which Alice could exploit bugs to gainaccess to file F.
  • Need to guarantee policy, assuming the threat model.
  • Difficult to think of all possible ways that attacker might break in.
  • Realistic threat models are open-ended (almost negative models).
  • Weakest link matters.
  • Iterative process: design, update threat model as necessary, etc.

• In this class, we'll push the boundary of each system to see when it breaks.
  • Each system will likely have some breaking point leading to compromise.
  • Doesn't necessarily mean the system is not useful: depends on context.
  • Important to understand what a system can do, and what a system cannot.
• In reality, must manage security risk vs benefit.
  • More secure systems means less risk (or consequence) of some compromises.
  • Insecure system may require manual auditing to check for attacks, etc.
  • Higher cost of attack means more adversaries will be deterred.
• Better security often makes new functionality practical and safe.
  • Suppose you want to run some application on your system.
  • Large companies sometimes prohibit users from installing software thathasn't been approved on their desktops, partly due to security.
  • Javascript in the browser is isolated, making it ok (for the most part)to run new code/applications without manual inspection/approval.(or virtual machines, or Native Client, or better OS isolation mechanisms)