Date: Tue, 7 Apr 2015 18:58:40 -0700 From: Michal Zalewski <lcamtuf@...edump.cx> To: oss-security <oss-security@...ts.openwall.com> Subject: Re: Hanno Boeck found Heartbleed using afl + ASan! >> The answer I've always heard from commercial software vendors is that >> "they had no time to work on open source projects", but that's about >> as unconvincing as it gets. I bet they would love to be credited for >> this or any comparably serious find. > > Nit: Let me change "commercial" to "proprietary", since there is > lots of commercially-supported OSS. Those are weird comments you're being told. I think that cases such as Coverity are more of an exception than a rule. Yup, they get credit for a steady trickle of issues (mostly through their self-service offering to developers, rather than any in-house analysis); but if you consider the size of the commercial and research "market" for static analysis and symbolic execution tools, it's not a common practice. Coverity and the singular case of Heartbleed aside, the mark left by others isn't as easy to find. The only other example of sustained contributions that I remember was the Mayhem / ForAllSecure project out of CMU, although it focused almost exclusively on inconsequential targets and I'm not sure if it really improved the quality of OSS code in the long haul. > Codenomicon's approach took some effort (you need to describe the protocol > and the required postconditions), but their approach unquestionably worked. Sure. Protocol-specific fuzzers likely take credit for the a significant majority of serious bugs discovered today (especially in the browser land), so this does not come as a surprise; the unorthodox anomaly detection part credited for Heartbleed feels a bit more like a lucky coincidence, but ASAN or project-specific integral state consistency checks can definitely provide a more reliable and reproducible baseline. Now, one of AFL's main goals is to lessen the need for protocol-specific fuzzers, since they take an awful lot of time to build and are bound by the assumptions made by their authors, need to be maintained to reflect changes to the fuzzed codebase, etc. I think it generally works OK; Hanno's post provides an interesting anecdote and explains how to set up similar jobs, so to be clear, I'm not saying it provides no value. I'm just trying to be mindful of the fact that I wouldn't give a proprietary tool an easy pass in similar circumstances, so I don't want to give one to my own tool =) Cheers, /mz
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ