CSI 2107 Tues/Thurs 2:00-3:15pm
Office Hours By appointment
Dates | Class notes | Syllabus | Readings
- Take-home final exam, May 13-15
- Project presentations
- May 6: Chang Liu and Xaio Wang; Andrew Ruef
- May 8: Nate Parsons; Kris Micinski
- May 13: James Parker
- Project final writeup, May 21
- 28 Jan, Overview
of the course
- 30 Jan, War in
Memory; here is the scribe report (Andrew Ruef).
- 4 Feb, Low-level
attacks and ROP;
here is the scribe report (Nate Parsons)
- 6 Feb, Randomization-based defenses: ASLR and
diversification; here is the scribe report (Kris Micinski)
- 11 Feb, Control-flow integrity: Scribe report (James Parker)
- 18 Feb, Code injection attacks: Scribe report (Aseem Rastogi)
- 20 Feb, Information flow security: Scribe report (Xiao Wang)
- 25 Feb, Noninterference and leakage (forgot to scribe!)
- 27 Feb, Dynamic info-flow tracking: Scribe report (Chang Liu)
- 4 Mar, Information flow control and exceptions: Scribe notes (Nate Parsons)
- 6 Mar, Declassification: Scribe notes (Andrew Ruef)
- 27 Mar, Keyboards and PC side channels: Scribe notes (Kris Micinski)
- 1 Apr, Timing and traffic channels: Scribe notes (James Parker)
- 3 Apr, Models of noninterference: Scribe Notes (XIao Wang)
- 8 Apr, Quantifying information flow (QIF): Scribe Notes (Chang Liu)
- 10 Apr, Computing QIF, and beliefs in QIF: Scrive notes (James Parker)
- 17 Apr, Analyses to find vulnerabilities: Scribe notes (Andrew Ruef)
- 22 Apr, Authenticated data structures (generically): Scribe notes (Xiao Wang)
- 24 Apr, Abstract interpretation and obfuscation: Scribe
notes (Max Potasznik)
OS-level and hardware protection cannot solve the security problem
need ways to establish the trustworthiness of software, to augment or
even replace these mechanisms. For example, OS-level mechanisms
fail to protect against SQL injections, cross-site scripting, stack
smashing, and other attacks.
In this class we consider vulnerabilities in software, and means to
address them. Our focus will be on software-oriented techniques,
rather than OS-level and hardware techniques (though these will not be
ignored). In particular, we will consider novel programming languages,
programming language analyses (both on the source code, and as
instrumentation on the running program), and programming tools that
can be used to identify and address security issues.
Most of the class will consist of reading and discussing
papers in the research literature. The discussion site
has the reading list and blog software. It's not completely filled
out; here is a preliminary reading list (a prefix
of which is on the discussion site) .
Prerequisite: There is no official pre-requisite for this
class (beyond an undergraduate CS degree); we will attempt to make it
largely self-contained. We will be reading some technical papers from
the programming languages research literature, so having taken CMSC 631
(or taking it concurrently) will be helpful. That said, we will review
programming languages concepts crucial for understanding particular
papers prior to reading them. Contact the instructor if in doubt.
Grading: Graded work is as follows:
- Class Participation (40%), in two parts: (1) written reviews of the papers
we read; (2) attendance and participation in class; (3) scribed
reports of class discussion.
- Project (30%). Students will propose projects approximately one month
into the semester, to be completed by the end of the semester. Projects,
done individually or in groups, will attempt a non-trivial study or
implementation of a programming language, analysis, or tool. In the best
case, these projects will be a prelude to published papers. More details
on the project will be made available during the semester. Groups
present their projects at the end; grading criteria for
presentations is given below.
- Final Exam (30%). There will be a comprehensive final exam, which will
count for comp credit.
Paper reviews (comments) and class participation: Students
will be required to submit an insightful comment or question about
each paper by 9am the day of class. Insightful comments are not
redundant with prior comments, so consider starting early, or if late,
comment on comments. Good questions can point out things not made
clear in the paper. Paper comments are generally given scores of 0,
for missing or showing no evidence of having read the paper, 1, for
minimal effort or a not-insightful summary, and 2, for actively
insightful. There is a sweet spot of comment length that approximates
a paragraph: one or two sentences is too short to develop an idea,
three or four paragraphs is too long to describe a coherent idea well.
Here is some useful advice about how to read papers. Once you get
in the groove, you should expect to spend 1-3 hours per paper (you do
not need to understand every detail, especially for the longer papers).
Scribes: Each person will act as a scribe at several
points during the semester, taking notes on the class discussion
to be published on the course web site. The basic format for the notes
should be the following:
In general, the summary should mention people by name, if possible, to
give credit to those who made insightful comments.
- Summary: This is a one-to-two paragraph summary of the
key points about the papers that are introduced at the start of
- Questions: Collects technical questions and answers people have
about the paper that warranted clarification
- Criticisms: What parts of the paper did people criticize, and
which of these garnered consensus? Critcisms could be about
algorithms, benchmarks, claims in general, etc.
- Ideas: What ideas for further research came up during the
Presentations: Students making presentations will be graded
on the following criteria:
Remember that you will likely be able to explain more detail than you
can hope to cover in a single lecture. This is one reason that it's
hard work to prepare a good presentation: not only do you need to
understand the paper, but you need to filter out the irrelevant
details and amplify the key arguments. You'll probably have omit
entire sections of the paper from your talk -- don't worry about
it. Simply mimicking the structure of the paper ("regurgitating it")
tends to produce a disconnected sequence of boring facts. A good talk
should tell a story; every idea should be motivated, and all facts
should fit together in a coherent picture. Telling such a story in a
short time often requires creating your own explanations, motivation,
and examples. I would recommend reading some advice
by Simon Peyton Jones on giving good presentations.
- understanding: does the presenter understand the
- thoughtfulness: does the presenter have insights and
opinions beyond what was in the paper?
- background/perspective: did the presenter read
- clarity: can the audience understand the
presentation? is the "big picture" clear? are there useful examples?
- materials: do the slides or use of blackboard
illustrate and support the talk? are there diagrams to help convey the
technicalities? (when your talk gets into deep territory, a diagram is
worth 10K words)
- delivery: has the the presenter practiced?
- non-regurgitation: did the presenter do something
beyond simply typing sections of the paper as bullet points? did the
presenter motivate the ideas in their own words or just state ideas
from the paper verbatim?
- answering questions: can the presenter handle
questions from the audience?
Academic Dishonesty: The university policy on academic dishonesty
is strictly followed. All graded materials (whether exams, summaries,
presentations, or projects) must be strictly individual efforts. In the case
of a group project or assignment, only collaborations within the group are