About the Course
Lectures:
Mondays and Wednesdays, 5:00–6:20 PM, in CENTR 201
Final exam:
Thursday, 10 December, 7:00–9:59 PM, room TBD
Instructor: Hovav Shacham, hovav@cs.ucsd.edu
Zoom office hours: Mondays, 11 AM–1:00 PM
Course Description
CSE 291Y is a hands-on introduction, at the graduate level, to computer security. Topics covered include systems security and memory safety; language runtime security; microarchitectural security and side channels; network security; and Web security. The cross-cutting theme of the course is how programmability in target systems helps attackers craft reliable exploits, with Web browsers serving as the running example of an attacker-programmable target system. Students learn by writing exploits for, and retrofitting mitigations into, realistic software systems.
The course covers many of the same topics as CSE 127, but more in depth and with additional, more demanding projects. While both CSE 227 and CSE 291Y assign research papers as readings, CSE 227 teaches students how to undertake original research in security, whereas CSE 291Y does not.
Logistics
We will have in-person lectures at our registrar-assigned time. Try to attend these lectures, if you can; that will allow you to participate in discussion. But please do not come to class if you might be sick!
I have created a basic Canvas site for the course, which we will use for course management tasks. But you should check this Website for course content.
In addition to Canvas, we will use Zoom for some office hours; Gradescope for assignment submission; and Piazza for asynchronous discussion. You may find links to each of these tools on Canvas.
For more on course logistics and policies, see the policies page.
Prerequisites
You should have taken an undergraduate course in operating systems, equivalent to UCSD’s CSE 120. This is the most important prerequisite for CSE 291Y.
We expect you to be comfortable with the Unix programming environment; with debugging using GDB; with scripting in Python and Perl; with systems programming in C; with reading and writing assembly language (and with learning new ISAs, if you haven’t encountered RISC-V assembly before); and with the hardware-software interface.
You will also benefit from prior exposure, at the undergraduate level, to compilers, programming languages, computer architecture, and computer networks. We will provide some background in class as we go; if you would like pointers to additional material, let the course staff know.
Major Course Goals
Our first goal in CSE 291Y is for students to learn to think like an attacker. We expect that students will be able to analyze scenarios and understand how one party’s actions can frustrate another’s goals. This applies to scenarios that have to do with computers and to scenarios that do not.
Our second goal in CSE 291Y is to bring students up to date with the computer security research literature. We expect that, by the end of the quarter, students will be able to read, understand, discuss, and adapt the ideas from a substantial fraction of the papers that appear at top academic and industrial security venues: Oakland, Usenix Security, CCC, Black Hat, and so on.
Our third goal in CSE 291Y is for students to learn the skills and mindset needed to reach what 0vercl0k calls “the state of no unknowns”, a complete understanding of the parts of a software system relevant to the exploitation of a vulnerability. Modern software systems are complex, but they are built artifacts, not magic; with careful inquiry their behavior is knowable.
Specific Learning Outcomes
System Security and Memory Safety
We expect students will understand how C programs are compiled to assembly, and to be able to cross-reference C source code, assembly listing, and debugger output to understand how programs behave, even when their memory safety guarantees have been violated. We expect students will learn one or more new assembly languages—for this quarter, 64-bit RISC-V. We expect students to be able to write shellcode.
We expect students will be able to exploit memory bugs in the absence of modern mitigations, from simple stack buffer overflows to format string vulnerabilities, malloc arena corruption, and other tricky bugs. We expect them to be able to spot bugs in programs (given C source or a binary), to examine the execution environment when the bug is triggered, and to craft reliable exploit payloads that execute appropriate shellcode.
We expect students will be familiar with modern mitigations: generic mitigations like ASLR and DEP; bug-specific mitigations like stack canaries; and variants of CFI. We expect students to know (at least in general terms) how each technique might be implemented; its benefits; its performance overheads; and its limitations.
We expect students will be able to structure exploits to bypass
mitigations; specifically, we expect them to craft ROP chains and to
exploit memory bugs in JavaScript interpreters using structured
exploit primitives like addrof and fakeobj.
Microarchitectural Security
We expect students will understand the distinction between ISA-visible and non-ISA-visible microarchitectural state. We expect they will understand the memory hierarchy (page tables, TLBs, and caches) enough to recreate common cache-timing attacks: evict-and-time, prime-and-probe.
We expect students will understand how out-of-order, superscalar, and speculative execution work together to allow processors to hide memory latencies and keep functional units busy; how speculative execution can leak information to non-ISA-visible state, and how that state can be recovered from, e.g., cache timing.
We expect students will understand the threat model for speculative execution information-leak attacks that don’t cross an isolation boundary, in particular against JavaScript runtimes, and to understand how common mitigations work and where they should be applied.