The formal prerequisites for CSE 127 are CSE 21 or Math 15B, CSE 30, CSE 101, and one of CSE 120, CSE 123, and CSE 124. These prerequisites are strictly enforced.
Because security is a cross-cutting concern, CSE 127 will touch on many topics across the CS curriculum, including material covered in CSE 110 (software engineering), CSE 120 (operating systems), CSE 123 (computer networks), CSE 124 (networked services), CSE 130 (programming languages), CSE 131 (compiler construction), CSE 134B and 135 (Web applications), and CSE 141 (computer architecture). If you have not taken these courses, you can still enroll in CSE 127, but we will expect you to pick up the necessary background on your own.
We expect you to be comfortable with debugging and Unix command-line tools (CSE 15L), and with C and assembly programming and the hardware-software interface (CSE 30).
Our most important goal in CSE 127 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 important goal in CSE 127 is to bring students up to date with the computer security research literature. We expect that, by the end of the term, students will be able to read, understand, discuss, and apply a substantial fraction of the papers that appear at top academic and industrial security venues: Oakland, Usenix Security, CCC, Black Hat, and so on.
We expect students to understand how C programs are compiled to assembly, and to be able to cross-reference C source code, assembly listing, and GDB output to understand how programs behave, even when their memory safety guarantees have been violated. We expect students to learn one or more new assembly languages—usually 32-bit x86 and one other architecture. We expect students to be able to write shellcode.
We expect students to 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 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 to 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 to be able to structure exploits to bypass mitigations; specifically, we expect them to craft ROP chains and to mount JIT spraying attacks against browsers.
We expect students to distinguish in-path, on-path, and off-path network adversaries. We expect them to be familiar with the fields of IP and TCP headers relevant to in-path adversaries who wish to modify the contents of a specific TCP connection: IP addresses, port numbers, sequence numbers, flags, and checksums. Students should be able to learn details beyond those we cover in lecture by consulting RFCs or examining packet captures.
We expect students to know that source IP spoofing is possible and to understand the power that this gives off-path network adversaries to interfere with communications, with specific reference to the Kaminsky DNS attack and to at least one off-path sequence number reconstruction attack.
We restrict our attention to just two application protocols: DNS and HTTP. For DNS, we expect that students understand the concepts of glue and bailiwick; for HTTP, that they can write a parser to modify requests and responses.
We expect students understand, to be able to exploit, and to know how to fix common Web programming flaws: cross-site scripting, cross-site request forgery, and clickjacking.
We expect students to understand and be able to discuss the use of the TLS handshake and application protocols, the security guarantees that TLS can provide, and its limitations. We expect them to understand the composition of TLS and HTTP into HTTPS, how browsers perform certificate validation, the PKI, and the CA ecosystem (including efforts for reining CAs in such as Certificate Transparency).
We expect students to understand the benefits and limitations of common opt-in HTTP security features, including Content Security Policy, X-Frame-Options, Subresource Integrity, and Strict Transport Security.