Re: Exploit writing thoughts

[Nate Lawson <nate () root org>]

Halvar Flake wrote:
> dave wrote:
> > One of the hard things about exploits (especially these days) is that
> > you have to absorb a LOT of failure in order to get the spectacular
> > results that are your bread and butter. Exploit devs have huge egos by
> > way of necessity and are tenacious like an Overtown pitbull, so one of
> > the harder parts of the job is to tell them to "give up, find another
> > one".
>
> There is also often a strange tradeoff involved: You can invest more
> time in finding bugs
> (not only mem corruption, but also all those wacky little things that I
> call "glue" bugs --
> they help making the rest stick together). You do this in the hope of
> being paid back this
> time investment in the exploitation step.
[...]
> The tenaciousness of most exploit devs is also reflected in "there is no
> failure, just
> a waiting loop until I get time to do another draw". You don't give up,
> you pick up
> something else while waiting for a good idea.

The hardest case is working on a particular target for pay. Unless you
already have a bug in your back pocket, it's very easy to go over your
estimate and waste lots of time trying to glue together the pieces.
Spend too much time trying to find "just one more piece" and you go out
of business.

That's why if your customer is the vendor, it's best to have an
understanding that you will find potentially exploitable bugs for them
to fix, not deliver an exploit itself. Unfortunately, only the most
educated customers understand the difference, and may be hampered
because they have to prove something to their management.

In this case, it's worth doing some poking around before providing an
estimate to see how fertile the particular software or hardware is. Time
spent up front may save you much more later on.

-- 
Nate

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave