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++ vulnerablities 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 vulenrable 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, both dynamic and static. We'll learn about the idea of non-interference as it applies to software.
7. Symbolic execution, a verification technique used heavily in computer security. We'll learn about how it works, and applications of it such as proof carrying code.
8. Secure by construction: weakest preconditions. You've probably heard we should build software that is secure and correct by construction. What does this mean? We'll discuss how this is done using Hoare-style proof systems and weakest preconditions. You'll see just how hard it is.
9. Separation mechanisms. A standard security practice is to isolate privileges and use the least privilege necessary for an operation. We'll discuss how these ideas can be implemented.
10. Static analysis and vulnerability discovery. Lately several companies have started selling tools that find vulnerabilities in source code. We'll learn about how these work, and in the process, read research papers that are the key technology behind companies such as Coverity.

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 such as buffer overflows in C programs and SQL injection vulnerabilities against websites.
2. Create exploits against traditional vulnerabilities.
3. Describing current defenses

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 addition to lecture and homeworks, 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. 5% Class Participation
2. 30% Homework
3. 30% Midterm
4. 35% 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.

The course staff will treat all students ethically and fairly. If you have an issue with a grade, please first meet with the TA who graded it, and if it cannot be resolved that way, please feel free to email Prof. Brumley and along with the TA, we will meet to resolve any problems.

Students also promise to behave ethically. Due to the sensitivity and nature of computer security, and some of the offensive techniques we discuss, we take any unethical and/or illegal behavior very seriously. Any potential lapse in ethical behavior will be immediately reported to the appropriate university disciplinary unit. Really. Even if you just have to pass the class, even if you didn't know it was cheating or plagiarism or illegal, and even if it will never happen again.

In particular:

• Don't break laws or cause a nuisance. This course discussed security-related topics. As such, you will be exposed to ideas and techniques that could be used to break the law. This knowledge does not mean it is OK to break the law or cause a nuisance. Examples of prohibited activities include scanning networks, launching exploits, "testing" the security of a system without explicit permission from all necessary parties, and so on.
• Collaboration. Students are encouraged to talk to each other, to the course staff, or to anyone else about any of the assignments. Assistance should be limited to discussion of the problem and sketching general approaches to a solution. Each student must turn in his or her own solution.

Below we have the CMU and ECE policy, as well as references for more information. If you have any questions, talk to Prof. Brumley.

ECE Academic Integrity Policy

The Department of Electrical and Computer Engineering adheres to the academic integrity policies set forth by Carnegie Mellon University and by the College of Engineering. ECE students should review fully and carefully Carnegie Mellon University's policies regarding Cheating and Plagiarism; Undergraduate Academic Discipline; and Graduate Academic Discipline. ECE graduate student should further review the Penalties for Graduate Student Academic Integrity Violations in CIT outlined in the CIT Policy on Graduate Student Academic Integrity Violations. In addition to the above university and college-level policies, it is ECE's policy that an ECE graduate student may not drop a course in which a disciplinary action is assessed or pending without the course instructor's explicit approval. Further, an ECE course instructor may set his/her own course-specific academic integrity policies that do not conflict with university and college-level policies; course-specific policies should be made available to the students in writing in the first week of class.

This policy applies, in all respects, to this course.

Carnegie Mellon University's Policy on Cheating and Plagiarism states the following: