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. Topics covered include the software design process; choices of programming languages, operating systems, databases and distributed object platforms for building secure systems; common software vulnerabilities, such as buffer overflows and race conditions; auditing software; proving properties of software; software and data watermarking; code obfuscation; tamper resistant software; and the benefits of open and closed source development.

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. Students we be asked to demonstrate such knowledge by successfully creating exploits.
2. Describing current applicable defenses
3. Describe weaknesses

We will then move towards state-of-the-art in research, and cover topics such as model checking, symbolic execution, taint analysis, proof-carrying code, and other topics. For each topic covered, students should be able to answer "Why is this secure?". In particular:

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

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)

Monday & Wednesday 10:30AM to 12:20PM
Wean Hall 4623

Approximately:

1. 5% Scribe and Class Participation
2. 30% Homework
3. 30% Midterm
4. 35% Project

Exceptional work will be rewarded as appropriate.

• Each student will have a total of 72 hours of automatic extensions for homework assignments. Hours are spent in 24 hour increments.
• The project deadlines are firm and cannot be extended or changed.

The course staff will treat all students ethically and fairly. The course staff assumes all students are also ethical and fair.

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, and even if it will never happen again. Prof. Brumley is very, very tough and intolerant of cheating, plagiarism, or unethical behavior.

The university policy on cheating and plagiarism is available here. Note that the policy gives several examples of what constitutes cheating/plagiarism. If you have any questions, you should contact the instructor.

Please ask the course staff if you have any questions regarding whether a particular behavior is OK or not. 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.