Re: Automatic Exploitation Paper Peer Review

[Miles Fidelman <mfidelman () meetinghouse net>]

Chris Eagle wrote:
> On 12/11/2010 1:22 PM, Fergie wrote:
>    
> > Something I used to tell my troops when I was in the Army ...  Don't sit
> > back in your area and bitch about something.  Anyone can bitch.  If you
> > bring a problem to light, bring a potential solution as well...
> >
> > I don't mean that as harsh as it sounds when I read it back.  I just mean to
> > say that all of you smart folks who identify these problems can surely posit
> > a solution to them....
> >      
> So, there's this little problem I have where given a program to analyze,
> all I want to know is whether it ever exits.  Now having brought the
> problem to light, I am afraid I have no solution, perhaps you can help?
>
> Sometimes the "solution" is to point out that there is no solution, or
> that any potential solution is orders of magnitude more difficult than
> one might expect.
>
>    
Though, as a colleague pointed out to me yesterday, there are a lot of 
times where a general solution may be hard (or incomputable), while 
there are solvable special cases that are quite useful.

Along those lines, I thought the Automatic Exploitation Paper/tool 
wasn't quite as weak or useless as people seem to be claiming here.  
After all, it did find exploitable holes in a number of commonly used 
packages - not a particularly good or comforting sign.  At the very 
least, it strikes me as a useful tool for running against new code as a 
basic diagnostic, during debugging.

One thing, about the paper, that gave me a lot of pause was that it kind 
of calls into question a commonly held presumption about open source 
code - that having the code available makes it easier for people to spot 
exploits, and close them quickly.  The paper suggests that having the 
source code available ALSO makes it easier to find exploitable holes 
through automated tools - which at leads one to think about whether 
there's a tradeoff to be considered involving difficulties of finding 
exploitable holes when source code is vs. is not available.  At the very 
least, it suggests that there are a whole slew of automatic tests that 
could/should be run as part of the release process for open source code; 
and perhaps built into regression testing.  (Along the later line: is it 
just me, or have others noted that fewer and fewer pieces of code 
include regression tests as part of "make test"?).

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In<fnord>  practice, there is.   .... Yogi Berra


_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave