[fuzzing] Talks that make you go hmmm

[nnp]

On 8/9/07, Debasis Mohanty <d3basis.m0hanty at gmail.com> wrote:
> At the first place, comparing fuzzers with static analysis tools is like
> comparing apples with oranges. I believe it is an unfair comparison where
> static analysis is meant for identifying security holes at code level

I would have thought the only alternatives to code level security
holes are design based and trust based so assuming that break down
then fuzzers are also working at identifying code level bugs. No?

> whereas fuzzers for programs during runtime.
>
> I hope now someone is *not* going to argue both static analysis and runtime
> analysis are same...
>

I don't think anyone would be silly enough to make that statement and
I don't think that was the point of this talk. The point of it was
comparing them in terms of number of exploitable bugs found which is a
valid comparison in my opinion as thats all that matters really.

I think its a bit naive of him to claim fuzzing only discovers super
easy bugs though. Poorly written fuzzers will only return low hanging
fruit or nothing at all but then again poorly written static analysis
tools have similar problems coupled with the fact that they can return
issues in code that aren't even reachable by user supplied input.

On the topic of 'low hanging fruit' etc. Does anyone here really care
about how complex the bug is that they find? I mean if my fuzzer finds
a strcpy() overflow that I can create an exploit for in 10 mins and
get root then I sure as hell don't care that I missed out on some
convoluted design issue that would have taken me days to reverse
engineer and the same again to exploit.


-- 
http://www.smashthestack.org
http://www.mastersofthewang.com