Dailydave mailing list archives
Automatic Exploitation Paper Peer Review
From: dave <dave () immunityinc com>
Date: Fri, 10 Dec 2010 14:28:08 -0500
-----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
Current thread:
- Automatic Exploitation Paper Peer Review dave (Dec 10)
- Re: Automatic Exploitation Paper Peer Review Charles Miller (Dec 10)
- Re: Automatic Exploitation Paper Peer Review Arrigo Triulzi (Dec 11)
- Re: Automatic Exploitation Paper Peer Review Jeffrey Walton (Dec 11)
- Re: Automatic Exploitation Paper Peer Review Arrigo Triulzi (Dec 11)
- Re: Automatic Exploitation Paper Peer Review William Arbaugh (Dec 11)
- Re: Automatic Exploitation Paper Peer Review Marius (Dec 11)
- Re: Automatic Exploitation Paper Peer Review Arrigo Triulzi (Dec 11)
- Re: Automatic Exploitation Paper Peer Review Fergie (Dec 11)
- Re: Automatic Exploitation Paper Peer Review Chris Eagle (Dec 12)
- Re: Automatic Exploitation Paper Peer Review Julien Vanegue (Dec 12)
- Re: Automatic Exploitation Paper Peer Review Arrigo Triulzi (Dec 11)
- Re: Automatic Exploitation Paper Peer Review Charles Miller (Dec 10)