Lecture 1: Introduction, Threat Models

What this lecture covers

This opening lecture of MIT's Computer Systems Security course asks what it actually means to build a secure system, and why doing so is hard. Rather than a textbook definition, it gives you a framework: security is about achieving a goal in the presence of an adversary, and every system can be broken down into a policy (what you want to be true), a threat model (assumptions about the attacker), and a mechanism (the software or hardware that enforces the policy under those assumptions).

The lecture also sets up the course logistics briefly, then spends most of its time walking through real incidents where policy, threat model, or mechanism failed, before ending with a live debugger walkthrough of a buffer overflow. After watching, you should be able to classify a security failure as a policy, threat-model, or mechanism problem, and understand at a basic level how a stack-based buffer overflow lets an attacker hijack a program's return address.

Key ideas

• Policy: the goal a system is supposed to enforce, such as confidentiality (who can read data), integrity (who can modify it), or availability (the system keeps working under attack).
• Threat model: the explicit assumptions made about what an attacker can and cannot do; a threat model that is too permissive makes security impossible, and one that is too narrow gets bypassed.
• Mechanism: the actual implementation that enforces the policy given the threat model; most real-world breaches trace back to a bug here.
• Negative goals: security requires a policy to hold against everything an attacker might try, which is much harder to verify than a positive goal like "authorized users can do X."
• Weakest link: combining several individually reasonable systems (recovery questions, backup email resets, credit-card-based account recovery) can create a chain an attacker can walk through, even when no single system is obviously broken.
• Trusted computing base: security is easier to get right when only a small number of components are responsible for enforcing policy, rather than every piece of software.
• Buffer overflow: writing past the end of a fixed-size stack buffer (for example with gets) can overwrite adjacent stack data, including the saved return address, letting an attacker redirect execution when the function returns.

Walkthrough

Course structure and threat model overview (0:00)

The lecture opens with course logistics: lectures center on assigned papers rather than a textbook, and lab assignments each use a different language (C and assembly for lab one, Python later, JavaScript for the browser labs). It then introduces the three-part framework of policy, threat model, and mechanism, using a grades-file access example to show how each part answers a different question: what should be protected, what can the attacker do, and what enforces it.

Why security is hard, and why it can also enable new systems (9:04)

The lecture explains that security policies are negative goals: a system must resist everything an attacker might try, not just satisfy one intended use case. It argues that every system has a breaking point, and the goal isn't a perfectly unbreakable system but understanding where a given design stops working. It also notes the positive side: strong sandboxing mechanisms, such as the technique that let native code run safely inside a browser, can make previously risky features possible.

Policy failures: recovery questions and cross-service chains (15:06)

Two examples illustrate policy mistakes. Security recovery questions weaken a password-only policy into "password or answers to public facts," which is how Sarah Palin's Yahoo email was compromised using information from her Wikipedia page. The Mat Honan case shows a more subtle chain: Amazon let anyone add a credit card to an account without signing in, then let that same partial card number reset the account password; Apple's iCloud/me.com service used the last four digits of a card to reset its own password; and Gmail sent recovery links to that backup address. No single service was obviously broken, but the combination let an attacker take over the victim's Gmail account.

Threat-model failures: passwords, aging assumptions, and trust in certificate authorities (22:13)

This section covers several ways threat models go stale or are too optimistic. Assuming users will pick strong passwords or avoid phishing links is unreliable. MIT's Kerberos system used 56-bit DES keys that were reasonable in the mid-1980s but were later broken in about a day by students with modern hardware. Government-capable adversaries may have access to hardware backdoors, changing what "physical security" even means. SSL/TLS trusts any of hundreds of certificate authorities worldwide to correctly verify domain ownership, so compromising the weakest CA is enough to impersonate any site. A DARPA red-team exercise on "secure" operating systems found attackers instead broke into an unsecured development server and planted a backdoor in the source code before it was even built.

Mechanism failures: rate limiting, access control, and randomness bugs (30:20)

Mechanism bugs are framed as the most common and hardest to eliminate, since they involve the most code. Apple's iCloud "Find My iPhone" interface forgot to rate-limit login attempts (unlike other iCloud interfaces), enabling fast password guessing. A Citibank site let users change an account ID number in the URL to view other customers' credit card data because the server didn't verify the ID belonged to the logged-in user. An Android Bitcoin app bug left a pseudo-random number generator seeded with all zeros in some cases, letting attackers regenerate identical private keys and steal funds. A related discussion covers why reusing a signature nonce can also leak a private key.

Encoding mismatches: SSL certificate names and C strings (41:30)

This part shows how disagreement between two ways of encoding the same data can be exploited. SSL certificates encode hostnames with an explicit length prefix, while C represents strings by scanning for a null terminator. An attacker who owns a domain can request a certificate for a name like amazon.com\0.attacker.com; the certificate authority sees a valid subdomain, but a C-based browser stops reading at the embedded null byte and displays only amazon.com. This class of encoding bug, discovered by researcher Moxie Marlinspike, recurs whenever different parts of a system disagree on how to interpret the same bytes.

Live buffer overflow demonstration (45:36)

The lecture walks through a small C program that reads input with gets into a fixed 128-byte stack buffer with no bounds checking. Using GDB, it shows the stack layout (buffer, then the integer variable, then the saved base pointer, then the return address) and demonstrates that feeding the program a long run of the letter A overflows the buffer, overwrites the return address with the bytes for A, and crashes the program when it tries to return to an invalid address. It then shows manually overwriting the return address to jump into the middle of main and execute a printf call that wasn't originally reached, illustrating that an attacker can redirect control flow, not just crash the program. The discussion covers why this works the same way even on machines where the stack grows upward, why return addresses can be pointed into the injected buffer itself to run attacker-supplied "shell code," and why modern non-executable stack protections force attackers toward more advanced techniques such as return-to-libc.

Before you watch

• No prior lectures exist yet; this is the first lecture of the course.
• Basic familiarity with C, the stack, and how function calls use return addresses will help with the debugger walkthrough.
• Course context: lab one, based on buffer overflow exploitation, follows directly from the demonstration in this lecture.

Check your understanding

1. What are the three components the lecture uses to analyze any security system, and how does a failure in each one differ?
2. Why did no single service in the Mat Honan Gmail compromise look obviously broken, yet the attacker still succeeded?
3. Why did MIT's Kerberos key size, chosen as reasonable in the 1980s, become a security weakness decades later?
4. In the buffer overflow demo, which stack values were overwritten by the long run of A characters, and why did that cause a crash?
5. Why does making the stack non-executable not fully prevent buffer overflow exploitation?