Automatic Exploitation Paper Peer Review

[dave <dave () immunityinc com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So I've been reading the "Brumley, Hao, Cha, Avgerinos" AEG paper. I thought it might
be good to apply some peer review to it. (The paper is available at the following
link and will be presented at some conference in 2011, it seems:
http://www.ece.cmu.edu/~aavgerin/papers/aeg-ndss-2011.pdf )

The paper automates some trivial exploitation problems and then the authors posit
that their tool changes the world (ALERT ALERT!).

Trivial problems are easy to automate. How many interesting new ways can we find to
defeat Caesar cyphers? Is it possible to invent new guns that can target only Dodos?
Some of the work in the paper is interesting - but it's "Blackhat Talk" interesting,
not "Revolutionize the space" interesting. And there's a lot of incorrect statements
in the paper that make it difficult to swallow the broad and reaching statements in
the introduction.

One of the "0day" they found using their code was in an older Expect (which is a
scripting language - aka, a shell!) - the other was in a 2003 version of iwconfig,
just to provide some context to the exploitation engineers reading this list who
don't want to read the paper itself.

They claim to be first at a lot of things, but they're essentially not.
Here's just two examples of automated exploitation that also work well against
trivial problems:
http://lists.immunitysec.com/pipermail/dailydave/2005-January/001431.html
http://vrt-sourcefire.blogspot.com/2009/01/new-byakugan-functionality.html

Here's the thing - if you make claims like "Our automatic exploit generation
techniques have several immediate security implications. First, practical
AEG fundamentally changes the perceived capabilities of attackers." then you need
something other than just optimism to back that up, or yes, you will get called out,
on public lists with extremely high Google rankings, as being full of it.

Below is the introduction, along with two hilarious snippets from the paper itself,
and some minor comments.

- -dave


AEG: Automatic Exploit Generation
Thanassis Avgerinos, Sang Kil Cha, Brent Lim Tze Hao and David Brumley
Carnegie Mellon University, Pittsburgh, PA
{thanassis, sangkilc, brentlim, dbrumley}@cmu.edu

Abstract
The automatic exploit generation challenge is given
a program, automatically find vulnerabilities and gener-
ate exploits for them. In this paper we present AEG, the
first end-to-end system for fully automatic exploit gener-
ation. We used AEG to analyze 14 open-source projects
and successfully generated 16 control flow hijacking ex-
ploits. Two of the generated exploits (expect-5.43 and
htget-0.93) are zero-day exploits against unknown vul-
nerabilities. Our contributions are: 1) we show how
exploit generation for control flow hijack attacks can be
modeled as a formal verification problem, 2) we pro-
pose preconditioned symbolic execution, a novel tech-
nique for targeting symbolic execution, 3) we present a
general approach for generating working exploits once
a bug is found, and 4) we build the first end-to-end sys-
tem that automatically finds vulnerabilities and gener-
ates exploits that produce a shell.

1 Introduction
Control flow exploits allow an attacker to execute ar-
bitrary code on a computer. Current state-of-the-art in
control flow exploit generation is for a human to think
very hard about whether a bug can be exploited. Until
now, automated exploit generation where bugs are auto-
matically found and exploits are generated has not been
shown practical against real programs.
In this paper, we develop novel techniques and
an end-to-end system for automatic exploit generation
(AEG) on real programs. In our setting, we are given
the potentially buggy program in source form. Our AEG
techniques find bugs, determine whether the bug is ex-
ploitable, and, if so, produce a working control flow hi-
jack exploit string. The exploit string can be directly
fed into the vulnerable application to get a shell. We
have analyzed 14 open-source projects and successfully
generated 16 control flow hijacking exploits, including
two zero-day exploits for previously unknown vulnera-
bilities.

Our automatic exploit generation techniques have
several immediate security implications. First, practical
AEG fundamentally changes the perceived capabilities
of attackers. For example, previously it has been be-
lieved that it is relatively difficult for untrained attackers
to find novel vulnerabilities and create zero-day exploits.
Our research shows this assumption is unfounded. Un-
derstanding the capabilities of attackers informs what
defenses are appropriate. Second, practical AEG has ap-
plications to defense. For example, automated signature
generation algorithms take as input a set of exploits, and
output an IDS signature (aka an input filter) that recog-
nizes subsequent exploits and exploit variants [3, 8, 9].
Automated exploit generation can be fed into signature
generation algorithms by defenders without requiring
real-life attacks.

... (Essentially none of their Introduction is based in fact. This is just pure media
trolling and should be removed from a scientific paper. I'm as guilty of media
trolling as anyone, of course. But I'm in sales.)

Advanced Exploits. In our experiments we focused
on stack buffer overflows and format string vulnerabili-
ties. In order to extend AEG to handle heap-based over-
flows we would need to extend the control flow reason-
ing to also consider heap management structures, which
is a straight-forward extension.

...(This kind of sentence demonstrates a profound lack of understanding of how heap
exploitation is done.)

                                        For example, if
there is a dereference from the stack before the vulner-
able function returns, simply overwriting the stack will
not always produce a valid exploit. Suppose an attacker
tries to exploit the program shown in Figure 8 using the
strcpy buffer overflow vulnerability. In this case, ptr
is located between the return address and the buf buffer.
Note that ptr is dereferenced after the stack overflow
attack. Since ptr is also on the stack, the contents of
ptr are garbled by the stack overflow, and might cause
the program to crash before the return instruction. Thus,
a sophisticated attack must consider the above case by
overwriting a valid memory pointer to the stack. AEG
properly handles this situation by examining the entire
stack space during DBA, and passing the information
(μ) to EXPLOIT-G EN.
... (That works assuming stack addresses are always the same...so not in the real
world. This is a harder problem than they seem to realize.)

Modern compilers would page-align the de-
clared buffers, resulting in both data structures getting
16 bytes. Since the destination buffer would be 16 bytes,
the 12-byte copy would not be problematic and the bug
not exploitable
... (Word align, I assume?)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAk0Cf0gACgkQtehAhL0gheoG5ACfbli7ZV7qC9Ha6gSFfuBed6xw
SQwAniIuBdOqnEGW/bPH/82DcbsKkV9V
=+/jd
-----END PGP SIGNATURE-----
_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave