Your term project should address a research issue in
computer security and consist of the design
of some computer security system or technique,
or the analysis and possible improvement of some
existing system or technique. The main goal of the
project is to do original research on a problem of
interest in computer security.
You should work in a small group;
I expect that teams of approximately 2--3
will be appropriate for most projects.
Of course, expectations will
be adjusted according to the number of people in
I will not categorically rule out solo teams,
but I expect that working in groups will allow you
to tackle more substantial research issues.
If you have trouble finding a project
partner, I can help you get matched up with someone
else by maintaining a list of people seeking teammates.
Projects will be evaluated on the quality of their research
in computer security. At the end of the semester,
you will write a conference-style paper on your work.
See below for more details.
I expect that most projects will fall (more or less)
into one of two categories:
The research should be relevant to computer security,
but this will be interpreted broadly.
You are encouraged to find topics of interest to you;
feel free to be creative in selecting a project topic.
You're welcome to pick a topic that is connected to your
current research: for instance, if your primary research interest
is in digital libraries, you would be welcome to do a class project
on some aspect of security, cryptography, or privacy in digital libraries.
- Design. Design projects will usually attempt to solve
some interesting problem by proposing a design; implementing a prototype;
and using the implementation as a basis for evaluating the proposed
- Analysis. Analysis projects might, for example, study
some previously-proposed implementation technique,
existing system, or class of systems;
evaluate its security properties; find flaws, or strengths, in it;
and provide new insight into how to
build secure systems.
If you're at a loss for a project topic,
I've prepared a list of possible project topics that you
can peruse as examples of how to a pick a suitable project.
But don't feel limited to these suggestions!
They are intended only as examples.
You're welcome to come discuss possible project ideas with me,
if you like. I'm happy to make myself available to discuss projects.
A final suggestion: Aim high!
The top projects could lead to publication.
In past years, the best two or three projects
have consistently led to publications.
You will write a concise (approximately 1 page)
project proposal that should clearly state the problem
you will be solving, the key challenges for new research,
your plan of attack (including milestones and dates).
If there are any special resources you might need
from me, mention this as well.
You might mention any relevant papers that you are aware of.
The project proposal is due Monday October 15.
Here's how to submit your proposal.
You should put together a web page for your project;
currently all it needs to contain is the project members,
their email addresses, title of your project, and proposal.
Then just email the URL for your project web page to
by Oct 15th.
In mid-November I might ask you to write a concise status report
so I can make sure the projects are on-track.
I am always available to meet with any groups who would
like to discuss their project, request additional resources, or
ask for advice.
You will also be required to present your project
at a poster session, to be held on
Dec 5th, 4-6pm, in Woz lounge.
Finally, a project report will be due on Monday, Dec 17th, at 9am.
No exceptions or extensions will be granted, so get it in on time!
See below for instructions.
The final report
You are expected to write a technical paper, in the style
of a conference submission, on the research you have done.
State the problem you're solving, motivate why it is an
important or interesting problem, present your research
thoroughly and clearly, compare to any related work that
may exist, summarize your research contributions,
and draw whatever conclusions may be appropriate.
There is no page limit (either minimum or maximum),
and reports will be evaluated on
technical content (not on length), but I expect
most project reports will probably be between
7--15 pages long.
If you are not familiar with writing conference-style papers
in computer science (or even if you are), the following resources may help:
You may submit your project report electronically or on paper.
I prefer electronic submission, although you may choose either.
In either case, the deadline is the same.
If you submit electronically:
If you submit on paper, place it in my mailbox in Soda Hall
(in the mailroom, or outside my office -- 629 Soda).
- It must be in a format which is easily readable on Unix platforms:
that means HTML, Postscript, or PDF is fine (but not Microsoft Word).
- Place a link to the file on your project web page
here for the list of project web pages),
and send me email with the URL. I will send you confirmation of receipt.
Example ideas for project topics
Note: Many of these examples are quite generic;
be sure to narrow down the topic substantially and propose
something concrete and focused.
If you are interested in any of the project topics below,
feel free to talk to me about it; I may be able to make some
more concrete suggestions.
Analysis and attacks
- Security analysis of privilege-separated applications
- Pick a privilege-separated application (e.g., OpenSSH, vsftpd,
qmail, Postfix, Openwall popa3d, Openwall telnetd, OpenBSD ntpd,
OpenBSD syslogd). Do a security analysis of the implementation and
the effectiveness of the privilege separation. If someone compromises
the unprivileged portion, how much harm can they do? Any suggestions
for what would improve the security of the application, or make it
easier to perform security reviews of the code?
- Security auditing
- Audit a widely-used and under-scrutinized open-source package
that is security-critical. Report on your experiences and lessons.
How would you re-structure/re-implement the system to make it more
robust? What tools would have made your auditing task easier?
How effective are existing tools?
- Security review of published schemes
- Pick any recently published paper that proposes a new security
mechanism or scheme. Ask the authors for the code. Perform a careful
security review of the paper's scheme; does it meet the claims
made for it? To find recent papers, you could peruse recent proceedings
of Usenix Security, IEEE Security & Privacy, ACM CCS, ISOC Network
and Distributed System Security, or other security-related conferences.
- Fuzz testing
- Fuzz testing
has recently drawn interest because it is very cheap, and more
effective than you might expect (given its low cost) at finding
some kinds of security bugs. There a number of fuzzing-related
projects you might consider.
(1) Apply fuzz testing tools to several different OSs.
Can you draw any conclusions about how they compare with regards
to their robustness? For instance, OpenBSD is a BSD-based
distribution that is known for its focus on security; you might
compare how OpenBSD compares to FreeBSD/NetBSD as measured by
fuzz testing. (See also
from U Wisconsin.)
(2) Devise and perform an experiment to characterize the tradeoffs
between fuzz testing and static source code analysis. You might select
several applications, apply both fuzz testing and a source
code analysis tool to those applications, and compare the two techniques
in terms of how many vulnerabilities they found, how many false
positives they generated, and the time or effort it took to apply
these techniques. (For static analysis tools, you might consider
Fortify SCA, Coverity, or FindBugs, depending upon what kinds of
applications you decide to analyze.)
(3) White-box fuzz testing: In standard fuzz testing, one runs
the programs on random inputs and declares a testcase to have failed
if it causes the program to crash or freeze. Thus classical
fuzz-testing is a purely blackbox testing technique. Can you devise
a more discriminating oracle for classifying testcases as passing
or failing, perhaps by examining the program's state as it executes?
For instance, does compiling the program with a bounds-checking compiler
(like CRED), running it under a runtime analysis tool (like
Valgrind memcheck), and/or with a debugging library (e.g., debugging
malloc, ElectricFence) help fuzz testing to find more security holes?
(4) Conventionally, fuzz testing is normally done using end-to-end
blackbox tests. However, one could imagine performing unit testing
using fuzzing methods. Is there any way to make this effective?
The obvious problem is
that such tests might generate many false alarms, if the randomly
generated tests violate the module's preconditions or otherwise
cannot arise during normal program execution. Can
this problem be surmounted?
(5) Fuzz testing of web browsers: There have been some recent advances
in developing fuzzers to test web browsers. However, so far the tools
have focused primarily on fuzzing a few core formats (e.g., HTML,
You might consider picking a format (e.g., CSS, Flash, ActionScript,
SVG, PDF, XSLT, Quicktime, Shockwave, various audio/video formats)
that is widely supported
but hasn't been explored as well.
References: mangleme (only fuzzes
- CSRF vulnerability scanning
- Cross-request forgery (CSRF) vulnerabilities have been called
a sleeping giant of web security -- partially because current web
vulnerability scanners do not detect these vulnerabilities, and because
it is suspected that these kinds of vulnerabilities are rampant.
Develop a way to automatically scan web sites for
cross-request forgery (CSRF) vulnerabilities.
Implement it (perhaps as a plugin to a popular vulnerability scanner
like Nessus or Nikto or somesuch). Try it out: how well does it work?
- Ajax security
- Develop a way to detect vulnerabilities associated with
split the code between the server and the client: some of the code
runs on the server side (e.g., as Java or PHP), and some of it runs
web page). Develop methods to detect vulnerabilities in these
kinds of web services. For instance, one common vulnerability
involves executing input validation code or other trusted logic on
the client instead of on the server; the problem is that the client
may be under the attacker's control and so the attacker may be
able to bypass that code.
Or, propose a tool or framework for building secure Ajax
- HTML filtering
- Work out the details of how to build a robust, functional
HTML filter (along the lines of the homework, but exploiting what you
have learned). How much of the web can one still support without
endangering security overly much?
- Efficient taint-tracking for Java
- Most prior work on runtime taint-tracking has focused on
languages like C (or, in one case, PHP). Study techniques for
runtime taint-tracking of Java. You may want to focus on only
tracking taint for Strings, as that is enough for some applications
of taint-tracking. Minimizing the performance overhead is important
for many applications. How efficient can you make your solution?
Can you handle issues such as reflection, dynamic class-loading,
and multi-threading? You might want to consider building on existing
tools for bytecode instrumentation/transformation or
aspect-oriented programming. Also you might consider performing
some kind of static analysis (either of the JVML bytecode or the
Java source code) to determine which objects need to be instrumented
and which ones can never be tainted and thus do not need to be
instrumented, if this reduces the runtime overhead.
What is the performance cost of
byte-level taint tracking (where you track the taint status of
each byte of the String independently) vs object-level taint tracking?
One intriguing application of taint-tracking for Java includes
automatic detection of SQL injection vulnerabilities, cross-site
scripting vulnerabilities, and other security holes in web services
(see the Livshits and Lam paper you read for some examples).
You could try implementing this and seeing how effective it is.
- Inferring security annotations for C/C++ programs
- Microsoft has proposed
a set of annotations for C and C++
code intended to help avoid buffer overrun and similar vulnerabilities:
the programmer annotates their code with information about buffer
lengths and the like, and a static analysis tool checks those
annotations to detect possible bugs. See also
open-source system from Berkeley with similar goals.
Writing these annotations can get a bit tedious.
Can you design a dynamic analysis tool that observes code as it
runs and infers SAL/Deputy annotations from how the code is used?
For instance, if you run the program on 1000 inputs, and in every
case, function f() is only called with null-terminated strings, you
might infer a SAL/Deputy annotating asserting that the argument to
f() is always null-terminated.
(See also Daikon,
though Daikon is a general-purpose tool; you can probably do a lot
better by focusing specifically on the kinds of properties that
SAL/Deputy are designed for.)
Tools like Valgrind, CIL, ltrace, etc. could be a good building
block for this project.
- Avoiding integer overflow vulnerabilities in Java
- Modern type-safe languages like Java improve on C/C++ by
eliminating many classes of vulnerabilities that have plagued C/C++
programs, but it does not eliminate integer overflow and integer
One way to write Java code that is free of integer overflow bugs
is to use java.lang.BigInteger (infinite-precision integers) instead
of int. However, this introduces a notational burden and
makes code less readable: e.g., instead of writing x*(y+z) - 2, the
programmer must write x.times(y.plus(z)).minus(new BigInteger(2)).
Can you come up with an extension to Java that eliminates this
notational burden? For instance, you might build a tool that performs
source-to-source translation to transform the former short version
into the latter long version before compilation, allowing programmers
to use the ordinary binary operators with BigIntegers.
- Detecting algorithmic denial-of-service vulnerabilities
algorithmic denial-of-service vulnerability
is a flaw that
allows an attacker to provide a carefully chosen input that will trigger
worst-case performance behavior in the application under attack and
deny service to legitimate users. For instance, at one point the
Apache web server had a flaw where URL parsing took time quadratic
in the number of "/" characters in the URL; by sending a URL consisting
of thousands of slashes, one could cause Apache to consume a huge
amount of CPU time. Develop a method to automatically detect these
kinds of bugs in application source code. For instance, you might
consider using Trend-prof
(see also this paper)
to detect performance anomalies, and try to infer attacks.
- Privilege separation
- Pick an interesting security-critical application that is currently
implemented monolithically. Investigate how to apply privilege
separation techniques to reduce the size of the TCB. Can you
implement your new design and evaluate its effectiveness? If you
were designing the application from scratch, how would you design it
to maximize its security? Any network client or server could be
a good candidate for investigation.
- Improving Plash
- Improve the security of Plash by eliminating the possibility
for the sandboxed process to issue syscalls directly and bypass the
Plash monitor. For instance, right now, Plash imposes no limits
on the ability of the sandboxed program to use the network. Propose
and implement some solution to fix this. (seccomp? ptrace? SFI?
something else?) Here's a list of
of Plash, if you want to have some ideas on how it could be
- Software verification tools for security
- Researchers have recently made dramatic improvements in tools
for software verification. See, e.g.,
(verification tools for Java)
(a verification tool for C#).
These tools allow programmers to verify properties, such as that
the program will never throw a NullPointerException,
ArrayIndexBoundsOutofBoundsException, or other runtime exception,
and that the program will never use uninitialized memory.
Since unexpected exceptions can cause surprising behavior (which is
dangerous in a security-critical program), these could be useful for
You might study how useful and expensive these are for security.
For instance, pick one or two security-critical applications written
in Java or C# and attempt to verify that they satisfy some useful
property (e.g., free of runtime exceptions). How many annotations
did you have to add? How much time or effort did it take? Did the
effort reveal any vulnerabilities? Or, you might try to see if you
can express any of the security requirements for those applications
into the JML/Spec# modelling language and see whether it is possible
to verify that those requirements are met by the code. Are the
JML/Spec# annotation languages rich enough to specify important security
policies? If not, what kinds of extensions would be useful for security?
Are the existing tools powerful enough to verify that code meets those
- Tools for vulnerability detection
- Study ways to build tools to help automate the process of
reviewing security-critical applications. Can you use runtime
testing, static analysis, model checking, formal verification,
or other techniques to detect any interesting classes of common
security holes? You may want to consult CWE's list of
classes of vulnerabilities for the past five years.
- Virtual machines for security
- Virtual machines (e.g., VMWare, Xen, etc.) seem to
provide a powerful mechanism for executing dangerous actions in an
isolated environment. How secure are existing commercial virtual
machines? How hard would
it be for a malicious guest application to defeat the VM and harm the
host OS? (For instance, an interesting project would be to look
at a few commercial or open source VMs and try to see if you can
How would you design a high-assurance VM to be sure that
isolation could not be compromised and to make it as easy as possible
to verify that these security goals have been met?
- Defenses against phishing
- There has been a great deal of research on defenses against
phishing. Can you improve upon any of them?
- Verifiable distributed computation
- The Internet is a vast resource of idle machines; we
might like to harness these spare CPU cycles by offloading our
lengthy computations to other computers.
But in any such distributed setting, how do we know that the
result that comes back is the correct one we wanted?
Can we do anything?
- Formal modelling of security systems
- Build a formal model of some aspect of a security system,
and rigorously evaluate its properties.
For instance, you might look at the state machine associated
with a TCP/IP stack, and model how the various network events can affect
the state. You could build a formal model of actual behavior
by working from the OS source code or by exhaustively testing the
Then you might build a formal model of intended behavior -- e.g.,
by working from the RFC -- and you would check whether the
specification matches the verification.
Or, you might build a second model from a second operating system,
compare where their behavior differs, and study whether this has
any consequences for how to write portable security code.
Such models might also be useful for intrusion detection as well.