|Teaching Assistant:||Jiyong Jang (Office hours: Mon 1:30-2:30pm @ CIC 2128B | 2312)|
|Thanassis Avgerinos (Office hours: Thu 4-5pm @ CIC 2308)|
|Matt Maurer (Office hours: Tue 11am-noon @ CIC 2128C)|
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:
- 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.
- 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.
- 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.
- Model checking: What is this, and how is it used in security?
- Web security: hacking both the client and server.
- Information flow. We'll learn about taint analysis, covert information flow (like timing attacks against crypto), and the idea of non-interference.
- 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:
- Describing and finding common vulnerabilities in programs.
- Create exploits against traditional vulnerabilities.
- Describing current defenses.
- 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:
- Describing how the method works
- Describing the sorts of attacks the method catches
- 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.
- 18-730 (or instructor permission)
- Skills in operating systems and programming languages (C and Java)
- Familiarity with UNIX command line utilities (e.g. gcc, ssh, man)
- 10% Class Participation
- 30% Homework
- 30% Midterm
- 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.
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.
- 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.
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:
Students at Carnegie Mellon are engaged in preparation for professional activity of the highest standards. Each profession constrains its members with both ethical responsibilities and disciplinary limits. To assure the validity of the learning experience a university establishes clear standards for student work.
In any presentation, creative, artistic, or research, it is the ethical responsibility of each student to identify the conceptual sources of the work submitted. Failure to do so is dishonest and is the basis for a charge of cheating or plagiarism, which is subject to disciplinary action.
Cheating includes but is not necessarily limited to:
- Plagiarism, explained below.
- Submission of work that is not the student's own for papers, assignments or exams.
- Submission or use of falsified data.
- Theft of or unauthorized access to an exam.
- Use of an alternate, stand-in or proxy during an examination.
- Use of unauthorized material including textbooks, notes or computer programs in the preparation of an assignment or during an examination.
- Supplying or communicating in any way unauthorized information to another student for the preparation of an assignment or during an examination.
- Collaboration in the preparation of an assignment. Unless specifically permitted or required by the instructor, collaboration will usually be viewed by the university as cheating. Each student, therefore, is responsible for understanding the policies of the department offering any course as they refer to the amount of help and collaboration permitted in preparation of assignments. 9.Submission of the same work for credit in two courses without obtaining the permission of the instructors beforehand.
Plagiarism includes, but is not limited to, failure to indicate the source with quotation marks or footnotes where appropriate if any of the following are reproduced in the work submitted by a student:
- A phrase, written or musical.
- A graphic element.
- A proof.
- Specific language.
- An idea derived from the work, published or unpublished, of another person.