Note:
This should be a plain-text file. However, the apostrophes in my
summary get botched when trying to display this as a .txt file.
So, I changed it to a .html file and used <pre>
and </pre> tags. Please submit your summaries by e-mail
as plain text in the message body or as an attachment.
Thanks,
Mark
Paper: Automatic Exploit Generation, T. Avgerinos, et. al.
Date: September 14, 2015
My name: Mark Greenstreet
1. What problem does the paper address?
Large software projects (e.g. linux distros) have thousands of known
bugs. We need a way to identify those bugs that are most vulnerable
for creating security exploits.
2. What is the key insight/idea in the paper's solution to this problem?
The paper uses symbolic execution to find exploit-examples. They
introduce several techniques such as "preconditioned symbolic execution"
and "buggy path first" to try to focus the search on traces that are
most likely to have exploits.
3. What did the authors do to demonstrate their claims? (e.g. implement a tool,
present a proof, run simulations, etc.)
They have implemented an open source tool, Mayhem. They described its
operation showing how it found an exploit in the acpi_listen utility.
They stated that they've found exploitable bugs in several applications
for streaming media and for networking.
4. Is the support for the claims convincing? Why or why not?
The authors have used Mayhem to find zero-day exploits in code that is
in widespread use. That's pretty compelling. OTOH, I would have liked
to have seen a comparison that gave a more compelling justification for
their design choices. For example, they use "buggy path first" -- can
they compare this with randomized path selection in KLEE [0] or
"generational search" in [20]?
5. What are your questions or other comments about the paper?
I like the paper as intro to exploit generation, and the role of formal
analysis techniques for generating exploits. The paper is definitely
aimed at a general, computer science audience, and left many slightly
deeper "But what about...?" questions unanswered. On the other hand,
the references are *very* good. I enjoyed skimming 4 or 5 of the
references when I was curious about "return-oriented programming" [33],
reading about modeling the x86 shl instruction in SAGE [4], etc.