[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dailydave
Subject:    Re: [Dailydave] A change
From:       Dragos Ruiu <dr () kyx ! net>
Date:       2010-01-28 7:28:17
Message-ID: 30D1F67F-BA45-462B-9D81-CDCEBA5D0471 () kyx ! net
[Download RAW message or body]


/me points to Jason Shirk's and Dave Weinstein's (from MS's internal  
tools group)
presentation on !exploitable - an open source tool to automate  
identification of
exploitable crashes, which they gave at CanSecWest last year.

cheers,
--dr

On 27-Jan-10, at 7:24 AM, Lurene Grenier wrote:

>> I think that while finding 0-days might be 'not terribly difficult',
>> selecting and properly weaponising useful 0-days from the masses of
>> dreck your fuzzer spits out IS difficult - at least in my experience.
>> There was some discussion of the 'too many bugs' problem on this list
>> previously and I know several of the other fuzzing guys are currently
>> researching  the same area.
>
> I really feel that the "selecting good crashes" problem is not that
> hard to overcome if you have a proper bucketing system, and the
> ability to do just a bit of auto-triage at crash time.  For example,
> the fuzzer I use now both separates crashes by what it perceives to be
> the base issue at hand, and provides a brief notes file with some
> information about the crash and what is controlled.  This requires
> just a bit of sense in providing fuzzed input, and very little smarts
> on the part of the debugger. I really think the next step is
> automating that brain-jutsu; much of it is hard to keep in your head,
> but not hard to do in code.
>
> Using this output, it's pretty easy to spend a lazy morning with your
> coffee grepping the notes files for the sorts of things you usually
> find to be reliably exploitable.  From there you can call in your 30
> ninjas and have at.
>
> Creating reliable exploits is for sure the hardest part, but once
> you've done the initial work on a program, the next few exploits in it
> are of course more quickly and easily done.
>
> As for the thought experiment, I think that the benefit of the top
> four researchers is that they've trained themselves over a long period
> of time (and with passion) to have a very good set of
> pattern-recognition tools which they call instincts.  They know how to
> get crashes, and they know having seen one crash what's likely to find
> more.  They know how to think about a process to get proper execution,
> and they're rewarded by success emotionally which makes the lesson
> learned this time around stick for when they need it again.
>
> I honestly think that there is more pattern recognition
> "muscle-memory" type skill involved in RE, bug hunting, and exploit
> dev than pure mechanical process, which is why the numbers are so
> skewed.  It's like taking 4 native speakers of a language (who love to
> read!) and 100 students of general linguistics with a zillion dollars.
> Who will read a book in the language faster?
>
> -- 
> ~ Lurene


--
World Security Pros. Cutting Edge Training, Tools, and Techniques

Vancouver, Canada March 22-26  http://cansecwest.com
Amsterdam, Netherlands June 16/17 http://eusecwest.com
pgpkey http://dragos.com/ kyxpgp





_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
[prev in list] [next in list] [prev in thread] [next in thread]