Computer Security: Building Secure Systems

Goal: Understand how to build secure systems, why systems" cover: image: "" alt: “LLM & Foundation Models News” hidden: true

Based on MIT 6.858 Computer Systems Security lecture on security fundamentals, attack vectors, and defense strategies.

Course Overview

Goal: Understand how to build secure systems, why systems are insecure, and how to make them better.

Approach: Case studies of research papers, examining what works, what doesn’t, and when ideas apply.

Labs: Each uses different languages (C/assembly, Python, JavaScript) - reflects real-world complexity.

The Security Framework

Three Core Components

Security Goals (CIA Triad)

• Confidentiality: Data accessible only to authorized parties
• Integrity: Data modifiable only by authorized parties
• Availability: System remains operational under attack

Why Security Is Hard

The Negative Goal Problem

“Security is a negative goal - we must ensure policy is followed regardless of what the attacker can do.”

Contrast with positive goals:

• Positive: “TAs can access grades file” - easy to test
• Negative: “No one else can access grades file” - must consider all possible attacks

The Weakest Link Problem

Every component must be correct. One mistake compromises the entire system.

“In computer security, almost every detail has a chance of really mattering.”

Where Security Fails

1. Policy Failures

Account Recovery Questions

Problem: Recovery questions change the policy from “know password” to “know password OR know recovery answers.”

Example - Sarah Palin’s Yahoo Account:

• Recovery questions: “Where did you go to school?”, “What’s your birthday?”
• Answers: Available on Wikipedia
• Result: Account compromised via public information

Lesson: Adding recovery mechanisms strictly weakens security.

Multi-System Interactions (Matt Honan Hack)

The Attack Chain:

Each system in isolation seemed reasonable, but together created vulnerability.

Lesson: Security policies must account for what other systems might reveal.

2. Threat Model Failures

Human Factors

Bad Assumptions:

• Users will pick strong passwords
• Users won’t click random links
• Users won’t enter passwords on fake sites

Reality: People pick bad passwords, click phishing links, and don’t pay attention.

“Don’t have threat models that make strong assumptions about what humans will do.”

Outdated Assumptions (Kerberos)

Timeline:

• Mid-1980s: MIT’s Kerberos uses 56-bit DES keys (reasonable for the time)
• System becomes popular, widely deployed
• Assumption never revisited
• 2013: Students crack 56-bit keys in ~1 day using modern hardware

Lesson: Threat models must keep up with technological progress.

Trusted Certificate Authorities (SSL/TLS)

The Problem:

• HTTPS relies on Certificate Authorities (CAs) to verify identities
• ~300 CAs worldwide (governments, companies, organizations)
• Any CA can issue certificate for any domain
• Assumption: All 300 CAs remain perfectly secure

Reality: Weakest CA becomes the attack vector.

“Bad idea to build a system around the assumption that you’ll keep 300 certificate authorities perfectly secure.”

Physical Access (DARPA Red Team)

The Attack:

1. Secure OS developed with rigorous security
2. Source code stored on unprotected development machine
3. Attackers compromised dev machine, inserted backdoor
4. Researchers built compromised OS
5. “Secure” OS had backdoor

Lesson: Consider the entire development and deployment pipeline.

3. Mechanism Failures

iCloud Password Guessing (2014)

The Bug:

• Most iCloud interfaces: Rate-limited login attempts
• “Find My iPhone” interface: No rate limiting
• Same accounts accessible through both

Attack: Brute-force passwords through unprotected interface.

Lesson: Mechanisms must be consistent across all interfaces.

Citibank Account Access

The Bug:

• URL after login: citibank.com/account?id=1234
• Changing the ID number displayed different account
• No check that ID matched logged-in user

Possible causes:

• Forgot to check authorization (mechanism bug)
• Assumed users can’t edit URLs (bad threat model)

Android Bitcoin Wallet (PRNG Bug)

The Problem:

• Bitcoin security relies on unpredictable private keys
• Android’s SecureRandom class generates keys
• Bug: PRNG sometimes not seeded (all zeros)
• Same seed = same “random” numbers = same private keys

Result: Attackers could regenerate victims’ private keys and steal bitcoins.

Lesson: Cryptographic mechanisms are fragile - small bugs have catastrophic results.

SSL Certificate Encoding (Moxie Marlinspike)

The Mismatch:

• SSL certificates: Length-prefixed strings ([10][amazon.com])
• C programs: Null-terminated strings (amazon.com[\0])

The Attack:

1. Attacker owns foo.com
2. Gets certificate for amazon.com\0.foo.com
3. Certificate authority approves (valid subdomain)
4. Browser loads into C string, stops at \0
5. Browser sees amazon.com - trusts certificate

Lesson: Encoding mismatches between systems create exploitable ambiguities.

Buffer Overflows: A Deep Dive

The Setting

Threat Model: Attacker can send any packet but has no other access.

The Vulnerability

void read_request() {
    char buffer[128];
    int i;
    gets(buffer);           // DANGEROUS - no length check
    i = atoi(buffer);
    return i;
}

Problem: gets() reads until newline, regardless of buffer size.

Stack Layout (x86, stack grows down)

The Attack

1. Attacker sends >128 characters
2. gets() writes past buffer end
3. Overwrites i, saved EBP, return address
4. Function returns to attacker-controlled address
5. Program jumps to location chosen by attacker

Exploitation Techniques

1. Jump to Existing Code

• Overwrite return address with address of existing function
• Example: Jump to printf in main() to print values
• Works even with non-executable stack

2. Shellcode Injection

• Include executable code in the input buffer
• Overwrite return address to point into buffer
• CPU executes attacker’s code
• Traditional payload: Execute /bin/sh for shell access

Why Stack Direction Doesn’t Help

Stack grows down: Overflow overwrites return address of current function

Stack grows up: Overflow overwrites return address of called function (e.g., gets())

“The buffer is surrounded by return addresses on all sides.”

Defense Mechanisms

Non-Executable Stack (NX bit)

How it works:

• Modern CPUs associate permissions with memory regions
• Stack marked as non-executable
• CPU refuses to execute code on stack

Bypass: Return-to-libc attacks

• Jump to existing code in program/libraries
• Don’t need to inject new code
• Still achieve attacker’s goals

Minimizing Trusted Computing Base

“The best design: Security doesn’t depend on all software being correct.”

Principle:

• Security enforced by small number of components
• Rest of system can have bugs without compromising security
• Reduces attack surface dramatically

Key Principles

1. Details Matter

“A single byte can make a huge difference.”

• Encoding mismatches
• Off-by-one errors
• Uninitialized variables
• Missing checks

2. Push Edge Cases

Testing approach:

• Largest/smallest inputs
• Strange input combinations
• Corner cases
• What happens if…?

3. Be Conservative

Threat models:

• Assume adversary is capable
• Don’t trust other systems’ security
• Plan for human error
• Revisit assumptions over time

4. Defense in Depth

• Multiple layers of protection
• Don’t rely on single mechanism
• Assume each layer can fail

Summary Checklist

Policy Design

• Does adding convenience features weaken security?
• What information could other systems reveal?
• Are there implicit policy changes from new features?

Threat Modeling

• What can the adversary actually do?
• Are assumptions still valid today?
• What happens if humans make mistakes?
• What other systems interact with yours?

Mechanism Implementation

• Is the mechanism enforced everywhere?
• Are all interfaces consistent?
• What happens with unexpected inputs?
• Are there encoding mismatches?
• Is the trusted computing base minimized?

Key Quotes

“Security is all about achieving some goal when there’s an adversary present.”

“The big reason security is hard is because it’s a negative goal.”

“In computer security, almost every detail has a chance of really mattering.”

“You really have to be very clear about what is the specification of your system.”

“Whenever there’s disagreement [in encoding], there’s a chance the bad guy can take advantage.”

“The general answer to mechanism problems is probably to have fewer mechanisms.”

Based on MIT 6.858 Computer Systems Security lecture. The course covers buffer overflows, web security, network security, and secure system design through case studies of real-world systems and attacks.

Disclaimer: This blog post was automatically generated using AI technology based on news summaries. The information provided is for general informational purposes only and should not be considered as professional advice or an official statement. Facts and events mentioned have not been independently verified. Readers should conduct their own research before making any decisions based on this content. We do not guarantee the accuracy, completeness, or reliability of the information presented.