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.
“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.
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?