Software Security

Poor software design and engineering are the root causes of most security vulnerabilities in deployed systems today. Moreover, with code mobility now commonplace--particularly in the context of web technologies and digital rights management--system designers are increasingly faced with protecting hosts from foreign software and protecting software from foreign hosts running it. This class takes a close look at software as a mechanism for attack, as a tool for protecting resources, and as a resource to be defended.

This course is a graduate-level class covering research and advanced topics in software security. We will learn about:

1. Insecure languages and attacks. We first investigate programming in "unsafe" programming languages such as C. We cover typical C/C++ vulnerabilities such as buffer overflows, format strings, heap vulnerabilities, and so on. The homework problems should be really fun: you will create working exploits that give you a shell.
2. Fixing C: Backward compatible defenses. We will cover defenses such as ASLR and DEP that protect otherwise vulnerable programs from exploitation. We will also talk about their limitations and modern attacks, such as return-oriented programming.
3. Fixing C: Memory and Control Flow Safety. Why can't we just fix C to be safe? We'll explore two different solutions (control flow integrity and CCured) and their limitations.
4. Model checking: What is this, and how is it used in security?
5. Web security: hacking both the client and server.
6. Information flow. We'll learn about taint analysis, covert information flow (like timing attacks against crypto), and the idea of non-interference.
7. Software Model Checking. This loosely encompasses static analysis, temporal model checking, and proving programs correct.

This course first covers state-of-the-practice, and progressively moves toward start-of-the-art in research. We cover both secure software design and attacks. At the end of the course, students should be able to demonstrate mastery of state-of-the-practice by:

1. Describing and finding common vulnerabilities in programs.
2. Create exploits against traditional vulnerabilities.
3. Describing current defenses.
4. Describe some of the research in the area.

Students will also be able to describe what it means to be secure by design, the different kinds of "safety" we find in security, and the latest research directions. More simply, if someone asks you "What does it mean to be secure?" you should be able to answer by:

1. Describing how the method works
2. Describing the sorts of attacks the method catches
3. Describing weakness and possible attacks not caught or outside the scope of the method

In the homeworks, students will hone reverse engineering skills to analyze core dumps, discover key functions, identify important data and variable areas, evaluate stack and heap structures, and determine relevant breakpoints necessary to complete the assigned objective, which could include some or all of: recovery of cryptographic keys and/or materials, bypass authentication, enable arbitrary code execution, etc. This objective requires the student to reverse a target binary (potentially malware) susceptible to a security vulnerability, perform static analysis of the binary, use a debugger to attach to a running process to enable dynamic analysis, identify and set reasonable breakpoints, and develop a proof-of-concept exploit leveraging the vulnerability and above knowledge.

In addition to lecture and homework, students will pick the most interesting area to them, and develop a course project which extends current research and state-of-the-art. The course project is intended to synthesize knowledge acquired to make something new. Don't worry: we will help you get to where you can work on novel security research.

1. 18-730 (or instructor permission)
2. Skills in operating systems and programming languages (C and Java)
3. Familiarity with UNIX command line utilities (e.g. gcc, ssh, man)

Approximately:

1. 10% Class Participation
2. 30% Homework
3. 30% Midterm
4. 30% Project

Exceptional work will be rewarded as appropriate.

• We have a simple and fair late policy. All assignments should be turned in by all students on time.
• The project deadlines are firm and cannot be extended or changed.
• All deliverables (assignments, project reports) are due before the start of class.

We follow the university dropping and auditing policy. We do not make exceptions except under extremely exceptional circumstances. Examples of exceptional circumstances include lobotomies and involuntary institutionalization. These exceptional circumstances should be such that it affects all your classes, not just this class. Examples do not include (a) poor performance so far, (b) routine illnesses, (c) getting married (to a Kardashian or otherwise), (d) busy with other things.