Re: Does Fuzzing really work?

[Pusscat <pusscat () gmail com>]

I'm going to go WAAAY out on a limb here and say that when Dave said there
were no new bugs, what he really meant was, "Of course if finds goddamn bugs
you monkey, otherwise why would I mention it?"

And when he said stop looking, what he really meant was, "If you're stupid
enough to believe that, by all means, take me seriously and stop looking, so
that I can release them all slowly over the next year while I lounge on the
beach."


On 9/25/06 3:35 PM, "Aviram Jenik" <aviram () beyondsecurity com> wrote:

> There's a lot of talk lately on whether fuzzing can actually be used to find
> vulnerabilities - and more importantly, reliably rule out the existence of
> unknown vulnerabilities.
>
> Since most of this talk revolves around Dave's note "There are no new
> MSRPC bugs. You should give up looking for them" I thought this was the right
> forum to answer this question.
> The question was whether RPC fuzzing can really rule out vulnerabilities, and
> our experience shows it can (at least, as much as you can rule out anything
> in IT security).
>
> Let me throw some numbers at you(*). The FTP protocol has 310 "scenarios" of
> valid FTP sessions. If you try to overflow each time a different part of the
> command in every scenario you get a little over 12M attack combinations. If
> you use some of our nifty beSTORM 2.0 optimizations you get to 70,679 attack
> vectors. Even with the lamest FTP server allowing just 5 simultaneous
> connections and taking a full second to process each session it would take
> only 4 hours to fully test the protocol.
>
> FTP is too simple you say? With more complex protocols like SIP you have
> > 15,000 scenarios and something like 40,680,459 attack vectors after
> optimizations. Sounds scary at first, but a SIP server capable of handling
> 500 requests per second would take only 22 hours to test, which means you can
> leave it running when you go home for the weekend and come back for the
> results. If you don't feel like waiting 22 hours, put it on 5 machines and
> have an answer by 4 hours. If you don't feel like waiting 4 hours... well you
> get the point.
>
> HTTP is probably as complex as they come, but most servers can handle >100,000
> requests per second in a closed environment and a fast local network.
> Suddenly trying all HTTP combinations is not as hard as it seems.
>
> And so on, and so on.
>
> My point is to those people who mock fuzzers - you either tried the wrong
> kind, or you tried them a long time ago. I'm not saying that buffer overflows
> are suddenly obsolete (don't delete that ZERT bookmark just yet!). But
> nowadays there is no reason for an FTP server to come out with buffer
> overflows; there's just no excuse.
>
>
>
> (*) Don't believe the numbers? Check the URL below and see for yourself.

~ Puss


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