[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
