**CS 361S: Computer Security** *Spring 2024* Lectures: : Tuesdays and Thursdays, 9:30--11:00 AM, on Zoom Final presentations: : Thu, May 2, 1:00--3:00 PM, on Zoom Instructor: : [Hovav Shacham](/~hovav/), hovav@cs.utexas.edu   office hours: : Mondays, 9:00--11:00 AM, on Zoom Teaching assistant: : Willy Vasquez   office hours: : Thursdays, 1:00--3:00 PM, on Zoom Course Overview ======================================================================== Welcome to CS 361S, computer security! Assignments ======================================================================== Exercises ------------------------------------------------------------------------ * [Exercise 1: Getting started](ex1.html) - Due: Friday, January 26th, 11:59 PM * [Exercise 2: Stack canaries](ex2.html) - Due: Friday, February 9th, 11:59 PM * [Exercise 3: Return-oriented programming](ex3.html) - Due: Friday, February 16th, 11:59 PM * [Exercise 4: Interpreter memory layout](ex4.html) - Due: Monday, March 1st, 11:59 PM * [Exercise 5: Sandboxing with RLBox](ex5.html) - Due: Friday, March 29th, 11:59 PM * [Exercise 6: Wasm SFI](ex6.html) - Due: ~~Friday, April 12th~~ Monday, April 15th, 11:59 PM Programming Projects ------------------------------------------------------------------------ * [Project 1: Shellcoding](proj1.html) - Due: Friday, February 2nd, 11:59 PM * [Project 2: Control-flow integrity](proj2.html) - Due: Friday, February 23rd, 11:59 PM * [Project 3: Interpreter exploitation](proj3.html) - Parts A and B due: Friday, March 8th, 11:59 PM - Part C due: Friday, March 22nd, 11:59 PM * [Project 4: Software fault isolation](proj4.html) - Due: Friday, April 5th, 11:59 PM * [Project 5: ISA support for security](proj5.html) - Due: ~~Friday, April 19th~~ Friday, April 26th, 11:59 PM Final Project ------------------------------------------------------------------------ Due: Thursday, May 2nd, **3:00 pm** Online Instruction Logistics ======================================================================== We will have synchronous lectures at our registrar-assigned time. Try to attend these lectures live, if you can; that will allow you to participate in discussion. As a backup, the lectures will also be recorded, with the link available on canvas. I have created a basic Canvas site for the course. That site links to Zoom meeting codes for lectures and for course staff office hours. We'll use Gradescope for assignment submission and Canvas for other course management tasks, but you should check this home page for course content. Asynchronous discussion and updates will take place on Ed; our discussion board is linked from the class Canvas. We will use the Perusall platform to annotate the readings ahead of each class. Course Expectations ======================================================================== Prerequisites ------------------------------------------------------------------------ The formal prerequisite for CS 361S is CS 439 (or 352 or 372) or CS 439H (or 352H or 372H). This prerequisite will be strictly enforced. We expect you to be comfortable with debugging and Unix command-line tools and with C/C++ and assembly programming and the hardware-software interface. Major Course Goals ------------------------------------------------------------------------ Our most important goal in CS 361S 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 CS 361S 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. 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 semester, 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 use-after-free 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 and WebAssembly runtimes, and to understand how common mitigations work and where they should be applied. Course Policies ======================================================================== Attendance ------------------------------------------------------------------------ Attending lectures and keeping up with the readings is crucial for success in CS 361S. You must not register for another class whose lecture times overlap those of CS 361S, even in part. Office Hours ------------------------------------------------------------------------ Your instructor and TAs will each hold regular office hours, listed on the course home page. Office hours are the best way to get extended help with the course material. Please come to office hours! Readings and Textbooks ------------------------------------------------------------------------ There is no textbook for this class. Instead, we will read and discuss research papers. These papers are listed in the Calendar and Readings section, below. For additional background, you may find some of the following books useful: - M. Dowd, J. McDonald, and J. Schuh: [_The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities_](https://www.informit.com/store/art-of-software-security-assessment-identifying-and-9780321444424), Addison-Wesley, 2006. - J. Gustedt, [_Modern C_, 2nd ed.](https://gustedt.gitlabpages.inria.fr/modern-c/), Manning, 2019 - M. Haverbeke, [_Eloquent JavaScript_, 4th ed.](https://eloquentjavascript.net/), No Starch, 2024 - A. Møller and M.I. Schwartzbach: [Static Program Analysis](https://cs.au.dk/~amoeller/spa/spa.pdf), manuscript, 2023. - D. Patterson and A. Waterman: [_The RISC-V Reader: An Open Architecture Atlas_](http://riscvbook.com/), 2017. - F. Rastello and Florent Bouchez Tichadou, eds.: [_SSA-based Compiler Design_](https://link.springer.com/book/10.1007/978-3-030-80515-9), Springer, 2022 Paper Discussion and Presentation ------------------------------------------------------------------------ Instead of a textbook, we will read research papers---old and new, industrial and academic, chosen (to the extent possible) to give an accessible introduction to material discussed in class. We expect that you complete all assigned reading ahead of each class meeting and come prepared to discuss the reading. We will use the Perusall platform to annotate the readings ahead of each class. The deadline for completing the assigned readings on Perusall will be midnight before each class. Perusall scoring is opaque; we will try to tweak the weights to give full credit if you spend time reading the paper and make a comment or two. It is tempting to game the scoring to get full credit without engaging with the reading. Don't! We have carefully chosen the assigned readings as the best available to help you in the class, and Perusall is your chance to clarify points of confusion before class discussion. We may dock you points if you engage in unconstructive ways. For example, highlighting a term and quoting from a Wikipedia definition for it is often unhelpful---especially if you end up quoting the wrong one of several possible definitions. Programming Projects and Exercises ------------------------------------------------------------------------ To complete the projects you will need access to a computer capable of compiling and running Qemu. It may be possible to use the WSL environment in Windows or the native Unix command-line tools in macOS, but course staff may not be in a position to help you if you run into trouble. If you have a Windows or macOS machine, consider running Linux inside a full-fledged virtual machine or dual-booting Linux from a separate partition. Alternatively, you should be able to use the department's public Unix workstations, but the (virtual) hard disk for our course virtual machine may grow to multiple gigabytes, and you may run into quota issues. Final Project ------------------------------------------------------------------------ The final project will ask you to find and exploit a bug in a substantial software system, putting into use the skills you have learned through the semester. You will work on the final project *by yourself*. More details about the system we would like you to audit, and about our expectations for your exploit submission and writeup, will be posted in the later part of the semester. Exams ------------------------------------------------------------------------ Because the course this semester will be taught entirely online, we will not have written exams. On the one hand, testing in an uncontrolled environment increases the temptation to cheat, something I believe [faculty should avoid](https://communitystandards.stanford.edu/policies-guidance/honor-code/previous-honor-code). On the other hand, [remote proctoring tools violate student privacy and may undermine the security of student devices](https://arxiv.org/abs/2205.03009). Grading ------------------------------------------------------------------------ The programming projects will count for 60% of your class score. The projects will be weighted equally except for project 3, which will count double. The exercises, weighted equally, will count for 20% of your class score. Your reading (and comments) on the Perusall platform will count for 5% of your class score. The final project writeup and presentation will together count for the remaining 15% of your score. We expect to apply the following cutoffs in translating scores to letter grades: A/B cutoff at 85%; B/C cutoff at 76%; C/D cutoff at 67%; and D/F cutoff at 58%. We may adjust these cutoffs (downward) if we determine that some assignments were more difficult than intended. Plus and minus cutoffs will be determined based on score distribution. Participation---in lecture, at office hours, and on Ed---may affect your final grade at the margin. You may request a regrade of a programming project no later than two weeks after that project is handed back. You should do so in writing, by e-mail to the course staff, explaining exactly what errors in grading you identified. Assignment Preparation and Submission ------------------------------------------------------------------------ All exercises and programming projects must be submitted using Gradescope. Submissions by other means---on paper, by e-mail, etc.---will not be accepted. The final project proposal, status updates, and final report should be submitted as PDFs directly in Canvas. Late policy ------------------------------------------------------------------------ Unless otherwise stated, exercises and programming projects will be due by 11:59 PM on the due date. Each student will have a total of ten (10) twenty-four hour extensions ("late days") for the semester. Late days can be used, in twenty-four hour quantums, on any assignment due date. For programming projects done in pairs, late days will be charged to both students in the pair; both partners must have sufficient late days for a late submission. No additional extensions will be given for any reason. Once all late days have been used up, late assignments will not be accepted. We encourage you to hold on to your late days so you can use them in an emergency. Each late assignment submission must indicate how many late days it uses. Once used, late days are permanently deducted from your balance. Late days cannot be reassigned after the fact. Policy on Academic Accommodations ------------------------------------------------------------------------ If you are a student with a disability, or think you may have a disability, and need accommodations please contact Disability and Access (D&A). You may refer to D&A's website for contact and more information: http://diversity.utexas.edu/disability/. If you are already registered with D&A, please deliver your Accommodation Letter to me as early as possible in the semester so we can discuss your approved accommodations. Collaboration Policy ------------------------------------------------------------------------ You should complete the exercises _on your own_. You may work in pairs on the programming projects. It is expected that both students in a pair contribute to each part of an assignment. If you worked with a partner, you must make a joint submission. You may switch partners between projects, but not between parts of the same project. You must not discuss the programming projects or homework with anyone else in the class besides your partner except in general terms, nor with anyone who is not enrolled in CS 361S. This includes both people at UT and people not at UT. If you are unsure about what constitutes allowed collaboration, ask the course staff! Book and Internet Use Policy ------------------------------------------------------------------------ You must not seek out solutions to specific assigned problems on the Internet, from computer security courses offered at other universities, or from computer security courses offered in previous semesters at UT. If you consult any external resources while working on an assignment, you must note those resources in your assignment submission. If you are unsure about what constitutes allowed use of outside resources, ask the course staff! Are Artificial Intelligence Tools Allowed? ------------------------------------------------------------------------ [Absolutely](https://dl.acm.org/doi/abs/10.1145/3442188.3445922) [not](https://www.journaloffreespeechlaw.org/volokh4.pdf). Posting of Solutions ------------------------------------------------------------------------ You must not post online or otherwise distribute to others your solutions to the exercises, programming projects, or final project in this course. This prohibition applies both during and after the semester. This prohibition specifically covers posting any programming assignments to GitHub or similar sites except in a private repository. Students violating this policy will be subjected to the academic integrity disciplinary process. Academic Integrity ------------------------------------------------------------------------ Recall the Student Honor Code: "As a student of The University of Texas at Austin, I shall abide by the core values of the University and uphold academic integrity." Students who violate University rules on academic dishonesty are subject to disciplinary penalties, including the possibility of failure in the course and/or dismissal from the University. Since such dishonesty harms the individual, all students, and the integrity of the University, policies on academic dishonesty will be strictly enforced. For further information, please visit the [Student Conduct and Academic Integrity Website](https://deanofstudents.utexas.edu/conduct/). To detect instances of academic integrity violations in programming assignments we may use 3rd party software. Class Recordings ------------------------------------------------------------------------ Class recordings are reserved only for students in this class for educational purposes and are protected under FERPA. The recordings should not be shared outside the class in any form. Violation of this restriction by a student could lead to Student Misconduct proceedings. Senate Bill 17 ------------------------------------------------------------------------ [Texas Senate Bill 17](https://capitol.texas.gov/BillLookup/History.aspx?LegSess=88R&Bill=SB17), the recent law that purports to outlaw diversity, equity, and inclusion programs at public colleges and universities in Texas, does not in any way affect content, instruction or discussion in a course at public colleges and universities in Texas. Expectations and academic freedom for teaching and class discussion have not been altered post-SB 17, and students should not feel the need to censor their speech pertaining to topics including race and racism, structural inequality, LGBTQ+ issues, or diversity, equity, and inclusion. The following readings are specifically relevant to this course: - S. Browne: [_Dark Matters: On the Surveillance of Blackness_](https://www.dukeupress.edu/dark-matters), Duke University Press, 2015 - K. Levy: [_Data Driven: Truckers, Technology, and the New Workplace Surveillance_](https://press.princeton.edu/books/hardcover/9780691175300/data-driven), Princeton University Press, 2023 - A. Powell and N. Henry, [_Sexual Violence in a Digital Age_](https://link.springer.com/book/10.1057/978-1-137-58047-4), Springer-Verlag, 2017 Calendar and Readings ======================================================================== Tue 16 Jan 2024: Welcome; introduction to RISC-V Thu 18 Jan 2024: Memory bugs and exploitation - *Reading*: - E.H. Spafford: “[The Internet Worm Program: An Analysis](https://spaf.cerias.purdue.edu/tech-reps/823.pdf)” (1988) Tue 23 Jan 2024: Shellcoding - *Reading*: - rix: “[Writing ia32 alphanumeric shellcodes](http://phrack.org/archives/issues/57/15.txt)” (2001) Thu 25 Jan 2024: Legacy mitigations - *Reading*: - V. van der Veen, N. dutt-Sharma, L. Cavallaro, and H. Bos: “[Memory Errors: The Past, the Present, and the Future](https://www.isg.rhul.ac.uk/sullivan/pubs/tr/technicalreport-ir-cs-73.pdf)” (2012) Tue 30 Jan 2024: Code reuse (I) - *Reading*: Nergal, “[The advanced return-into-lib(c) exploits: PaX case study](http://phrack.org/issues/58/4.html)” (2001) Thu 1 Feb 2024: Code reuse (II) - *Reading*: - R. Roemer, E. Buchanan, H. Shacham and S. Savage: “[Return-Oriented Programming: Systems, Languages, and Applications](/~hovav/dist/rop.pdf)” (2012) Tue 6 Feb 2024: The control-flow graph Thu 8 Feb 2024: Control-flow integrity (I) - *Reading*: - M. Abadi, M. Budiu, Úlfar Erlingsson, and J. Ligatti: “[Control-Flow Integrity: Principles, Implementations, and Applications](https://www.cse.usf.edu/~ligatti/papers/cfi-tissec.pdf)” (2009) Tue 13 Feb 2024: Control-flow integrity (II) - *Reading*: - N. Carlini et al.: “[Control-Flow Bending: On the Effectiveness of Control-Flow Integrity](https://people.eecs.berkeley.edu/~daw/papers/cfi-sec15.pdf)” (2015) Thu 15 Feb 2024: Introduction to JavaScript Tue 20 Feb 2024: JavaScript interpreter internals Thu 22 Feb 2024: JavaScript interpreter exploitation (I) - *Reading*: - saelo: “[The Art of Exploitation: Attacking JavaScript Engines](http://phrack.org/issues/70/3.html)” (2016/2021) Tue 27 Feb 2024: JavaScript interpreter exploitation (II) Thu 29 Feb 2024: ERCOT flex day Tue 5 Mar 2024: Process isolation - *Reading*: - A. Barth et al.: “[The Security Architecture of the Chromium Browser](https://seclab.stanford.edu/websec/chromium/chromium-security-architecture.pdf)” (2008) Thu 7 Mar 2024: System call subsets and process sandboxing - *Reading*: - T. Garfinkel: “[Traps and Pitfalls: Practical Problems in System Call Interposition Based Security Tools](https://xenon.stanford.edu/~talg/papers/traps/traps-ndss03.pdf)” (2003) Tue 12 Mar 2024: Spring break, no class Thu 14 Mar 2024: Spring break, no class Tue 19 Mar 2024: Confused deputy - *Reading*: - S. Narayan et al.: “[Retrofitting Fine Grain Isolation in the Firefox Renderer](https://arxiv.org/abs/2003.00572)” (2020) Thu 21 Mar 2024: Software fault isolation (I) - *Reading*: - chapters 1, 2, and 3 from G. Tan: “[Principles and Implementation Techniques of Software-Based Fault Isolation](http://www.cse.psu.edu/~gxt29/papers/sfi-final.pdf)” (2017) Tue 26 Mar 2024: Software fault isolation (II) Thu 28 Mar 2024: SFI in practice: WebAssembly - *Reading*: - B.L. Titzer: “[A fast in-place interpreter for WebAssembly](https://arxiv.org/abs/2205.01183)” (2022) Tue 2 Apr 2024: (Future) ISA support for CFI - *Reading*: - “[RISC-V Shadow Stacks and Landing Pads](https://github.com/riscv/riscv-cfi/releases/download/v1.0-rc1/riscv-cfi.pdf)” (2023) Thu 4 Apr 2024: (Future) ISA support for SFI - *Reading*: - S. Narayan et al.: “[Going beyond the Limits of SFI: Flexible and Secure Hardware-Assisted In-Process Isolation with HFI](https://cseweb.ucsd.edu/~dstefan/pubs/narayan:2023:hfi.pdf) (2023) Tue 9 Apr 2024: Microarchitecture background - *Reading*: - B. Grayson et al.: “[Evolution of the Samsung Exynos CPU Microarchitecture](https://people.engr.tamu.edu/djimenez/pdfs/exynos_isca2020.pdf)” (2020) Thu 11 Apr 2024: Speculative execution (I) - *Reading*: - L. Fiolhais and L. Sousa: “[Transient-Execution Attacks: A Computer Architect Perspective](https://dl.acm.org/doi/pdf/10.1145/3603619)” (2023) Tue 16 Apr 2024: Speculative execution (II) Thu 18 Apr 2024: Ethics - *Reading*: - P. Rogaway: “[The Moral Character of Cryptographic Work](https://www.cs.ucdavis.edu/~rogaway/papers/moral-fn.pdf)” (2015) Tue 23 Apr 2024: Passover, no class Thu 25 Apr 2024: Recent developments; wrapping up - *Reading*: - P.A. Karger and R.R. Schell: “[Multics Security Evaluation: Vulnerability Analysis](https://www.acsac.org/2002/papers/classic-multics-orig.pdf)” (1974) Thu 2 May 2024: Final presentations