Fuzzing’s Impact on Vulnerability Discovery


I just seen the new advisory for Opera, headlining a ‘memory corruption’ vulnerability that sounds like its triggered by specially crafted html construction, that is gathered from this almost incoherent ‘detailed’ description of the bug:

“Certain HTML constructs affecting an internal heap structure. As a result of a pointer calculation, memory may be corrupted in such a way that an attacker could execute arbitrary code.”

I often wonder when I see advisories like this if the vulnerabilities have been found by fuzzing.

Another bug found in Adobe Flash Player that I also discuss here, found by iSEC, looks also to be found by fuzzing, but more (nearly directly) implied in the advisory.

“iSEC applied targeted fuzzing to the ActionScript 2 virtual machine used by the Adobe Flash player, and identified several issues which could lead to denial of service, information disclosure or code execution when parsing a malicious SWF file. The majority of testing occurred during 120 hours of automated SWF-specific fault injection testing in which several hundred unique control paths were identified that trigger bugs and/or potential vulnerabilities in the Adobe Flash Player. Paths leading to duplicate issues where condensed down to a number of unique problems in the Adobe Flash Player. The primary cause for these vulnerabilities appears to be simple failures in verifying the bounds of compartmentalized structures.”

Now, both of these examples could have been found by other means than fuzzing, but I know every time I see scrupulous advisories like those it just makes me wonder. By the way, IMHO Fuzzing: Brute Force Vulnerability Discovery is a great book and a great read. Kudos to the swift, engineering authors as well.

You can browse a list of fuzzers hosting by PacketStorm to exercise your mind even more.

So what do you think? Have fuzzers, being at the most ‘trivial’ to write in ideal conditions (well documented protocol, continued aggressive latency, etc), taken a strong hold in many security researcher’s work?

  • Vincent Claeys

    I think fuzzing really became a hype over the last few years since it is a rather easy way to find vulnerabilities, and you were even able to get some results with public fuzzers in the past. Nowadays this is harder and you have to write your own fuzzer which does just that little extra or is specially created for a certain protocol/application (= dumb fuzzing vs smart fuzzing?). But yes, I think fuzzing has been used a lot to find vulnerabilities, and it still is a good way to find them considering the combination of “effort – skill – time”.
    So far, most of the vulnerabilities I discovered were found with fuzzing (own coded fuzzers though), and some of them were in popular software. However, I am now switching to Reverse Engineering because I needed a new challenge and I think this is one of the coolest (and most effective) ways of bug hunting.