When & Where

The second exam will be held in our regular classroom on Monday, November 2, 2026.

It will take up about half the lecture, starting approximately during the second half of the class period. Please arrive on time and do not plan on coming in just to take the exam. If you arrive after the exam has started, you will not be allowed to take it.

Exam rules

Be sure to arrive on time. If you arrive after the exam starts, you will not be allowed to take it.

This will be a closed book, closed notes exam. Calculators, phones, augmented reality glasses, laptops, and tablets are neither needed nor permitted. If you have these devices, you must turn them off, put them out of sight, and not access them for the duration of the exam.

No other electronic devices are permitted except for hearing aids, pacemakers, electronic nerve stimulators, other implanted medical devices, or electronic watches that function only as timekeeping devices or chronographs.

Bring a couple of pens or pencils with you. Plan to use a pen only if you are supremely confident in not changing your mind about your answers. . Check here for information about pencils, sharpeners, and the craft of pencil sharpening.

Past exams

You can use my past exams as a guide to what this exam may look like, but realize there are differences in topics and in the sequencing of the topics. Expect around 25 multiple-choice questions. You won’t have to recite lists, do a frequency analysis, or present algorithms, so you should focus your studying to being able to recognize concepts. I do not refer to old exams when I come up with a new one, so it is likely that many of the topics that I considered important in past exams will show up on future exams. Some material may have changed, however, so do not worry about questions that appear to relate to topics we have not covered.

Get past 419 exams here.

Study guide

You are responsible for the material from the first four lectures and recitations.

The study guide is a concatenation of the study guides from the past lectures. It attempts to cover most of the material you should know. It is not a substitute for the lectures, lecture material, and other reading matter. All the material may not be in the guide. My goal is to put most of the information you need to know a concise with fewer elaborations.

You can also prepare your own guide, which would be a much better way to prepare for the exam!

→ Get the study guide

Topics

Topics that you should know and may be on the exam include:

Hash Pointers, Merkle Trees, and Bitcoin

• Cryptographic foundations

  • Hash pointers vs. normal pointers

  • Blockchains as tamper-evident linked lists: protecting the head pointer detects tampering anywhere

  • Merkle trees and Merkle proofs: verifying membership with sibling hashes and a trusted root

• Core concepts

  • Distributed ledger: full nodes store complete copies and verify independently; no master copy

  • Double-spending problem and how Bitcoin solves it

  • Pseudonymity: no names, but every transaction is public

  • UTXOs (Unspent Transaction Outputs) vs. account balances

• Transactions

  • Transaction components: inputs, outputs, public key, signature, change output, fee

  • Public/private keys and digital signatures: what a signature proves and what it covers

  • Addresses as hashes of public keys and why (not derivation steps)

  • What a full node checks before accepting a transaction

• Mining and consensus

  • What mining is and why miners do it

  • Block header: previous block hash, Merkle root, target, nonce, and what each is for

  • Proof of Work: finding a header whose hash is at most the target; why the nonce alone is not enough

  • Target: a smaller target makes mining harder

  • Difficulty adjustment: maintains 10-minute blocks as hash rate changes

  • Coinbase transaction, block rewards, and halving

• Security

  • Chain selection: the valid chain with the most accumulated work (the longest chain when targets are equal)

  • Competing chains/forks: how they occur, how they resolve, and chain reorganization

  • Confirmations: why transactions need multiple blocks and why no count is a guarantee

  • 51% attack: what it can do and what it cannot do

Access control

• Protection and the operating system

  • What the operating system must guarantee: protect itself, protect processes from each other, stay in control

  • Hardware timer and preemptive multitasking

  • Memory isolation: each process confined to the memory the kernel assigned it

  • Kernel mode vs. user mode; privileged instructions

  • Entering the kernel: system calls, faults, hardware interrupts

  • Trusted computing base

  • Reference monitor and its three requirements

• Core concepts

  • Subjects, objects, principals, and rights

  • Identification, authentication, and authorization

  • Access control matrix; protection domains and domain transfer

  • Access Control Lists (ACLs) vs. capability lists: what each makes easy and hard

  • An open file descriptor as a capability

  • The confused deputy problem

  • Principle of Least Privilege

  • Privilege separation and attack surface

• Discretionary Access Control (DAC)

  • Owner-controlled access

  • UNIX permissions: owner, group, other; read, write, execute

  • How the check picks one set of bits

  • What read, write, and execute mean for a directory

  • umask and default permissions

  • The permission check happens at open

  • Root

  • Real user ID vs. effective user ID

  • setuid and setgid bits; why setuid programs are dangerous

  • Time-of-check to time-of-use race conditions

  • Full ACLs: named entries, deny entries, inheritance, and why they are hard to audit

  • Why DAC is not enough: programs run with the user’s authority, rights propagate, owners set the policy

• Mandatory Access Control (MAC)

  • Concept of MAC: rules set by the organization that owners cannot override

  • Multilevel security

  • Bell-LaPadula model (confidentiality)

    • No read up; no write down; ordinary permissions still apply within the labels

    • Why no write down exists (a program acting for a cleared user)

    • Limits: declassification needs trusted subjects, nothing about integrity, covert channels

    • Remember the rules; you don’t have to remember the terms “simple security property” or “star property”

  • Compartments and multilateral security

    • Need to know; labels as level plus compartments

    • Dominance, incomparable labels, and the lattice

  • Biba model (integrity)

    • No read down; no write up

    • Windows integrity levels as a restricted form of Biba (no write up only)

  • Type Enforcement (TE)

    • Domains and types; rules allow, everything else is denied

    • SELinux and why TE confines a compromised program, even one running as root

• Chinese Wall model

  • Conflict of interest prevention

  • Company datasets and conflict of interest classes

  • History-based access: the read rule

  • The write rule and sanitized data

  • Separation of duties (general principle)

• Role-Based Access Control (RBAC)

  • Users, roles, permissions, and sessions

  • Permissions assigned to roles; users assigned to roles

  • Roles vs. groups

  • Role explosion

  • Attribute-Based Access Control (ABAC): just the basic idea

• Key comparisons

  • What each model protects and where it falls short

  • When to use each model

  • How real systems layer the models (for example, Unix permissions, SELinux, and Android permissions)

Memory Vulnerabilities and Code Injection

• Foundations

  • Virtual address space and memory layout (text, data, BSS, heap, stack)

  • Stack frames and the saved return address

  • Vulnerability vs. exploit

  • Control-flow hijacking and code injection

• Memory corruption and unsafe access (spatial and temporal errors)

  • Buffer overflow (stack and heap)

  • Out-of-bounds reads and information disclosure (a leaked pointer defeats ASLR)

  • Integer overflow and signed-to-unsigned mismatch

  • Off-by-one errors

  • Use-after-free

  • Double-free

  • Type confusion

• Exploitation techniques

  • Shellcode and NOP sleds

  • Return-to-libc attacks

  • Return-oriented programming (ROP) and gadgets

• Finding and preventing bugs

  • Auditing, static analysis, and compiler warnings

  • Fuzzing

  • Correct use of counted string functions (size from the destination’s capacity; gets() is unsafe)

  • Memory-safe languages (Rust, Go) and their limits

• Runtime and hardware defenses

  • Non-executable memory (NX, DEP, W^X)

  • Address space layout randomization (ASLR) and entropy

  • Stack canaries

  • Hardened allocators (metadata protection, delayed reuse of freed blocks)

  • Control-flow integrity (CFI)

  • Intel CET (shadow stack)

  • ARM pointer authentication

• Key principles

  • Defense in depth

  • How code reuse (return-to-libc, ROP) bypasses non-executable memory

  • How ASLR raises the cost of code reuse, and how a leaked pointer undoes it

  • Why data-only attacks bypass most defenses

  • Matching each vulnerability to the defenses that address it

  • Hardware assumptions can fail (Rowhammer)

Command Injection and Input Validation Attacks

• Command injection

• SQL injection

  • Parameterized queries (prepared statements) and stored procedures

  • Escaping as a last resort

  • The principle of least privilege for the database account

• Shell command injection

  • Avoiding shells: argument vectors (execve()) vs. system() and popen()

  • Quoting as a secondary defense

• Interpreters hidden in libraries

  • eval() and how it differs from shell injection

  • Logging libraries and data formats that run code

• Input validation and sanitization

  • Validation, sanitization, and structural separation

  • Allowlists vs. denylists

  • Canonicalization: decode before validating

  • Sanitizing for the context of use

• Path traversal and path equivalence

• Time-of-check to time-of-use (TOCTOU)

• Search paths, library injection, and function interposition

• Package and dependency attacks

  • Typosquatting and dependency confusion

  • Installation scripts

Containment and Isolation

• Why containment

  • Limits of access control for confining programs

  • The principle of least privilege and its limits when the program enforces it

  • Sandboxes and the trusted computing base

  • Criteria for evaluating a containment mechanism

• chroot and jails

  • Restricting names vs. restricting operations

  • chroot and its limitations

  • FreeBSD Jails

• System call filtering

  • The system call interface as an enforcement point

  • User-level system call monitors and their weaknesses

  • seccomp-BPF and why it cannot check file names

• AppArmor and how it complements seccomp-BPF

• Language runtime sandboxes (know they exist in platforms such as the JVM and JavaScript engines)

• Application sandboxes

  • The app as the principal (Android, iOS)

  • Install-time vs. runtime permissions

  • Limits of permission models

• OS-level isolation primitives

  • Namespaces (what processes can see)

  • Control groups (resource limits)

  • Capabilities (dividing root privileges)

  • User namespaces

• Containers

  • How containers combine namespaces, cgroups, capabilities, seccomp, and AppArmor

  • Benefits and overhead

• Virtual machines

  • Hypervisor (virtual machine monitor); guest vs. host

  • Hardware virtualization support, memory isolation, and device emulation

  • Type 1 (bare-metal) vs. Type 2 (hosted) hypervisors

  • Overheads

  • Risks: VM escape, hypervisor compromise, shared hardware

• Virtualization-based security: what it protects and its limits

• Comparing containers and virtual machines

  • Shared kernel vs. separate kernels

  • Interface size, isolation strength, and overhead

  • Layering, and trust in the layer beneath

Last update: Fri Oct 30 09:29:05 2026