[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141119002129.4f88e733@pc>
Date: Wed, 19 Nov 2014 00:21:29 +0100
From: Hanno Böck <hanno@...eck.de>
To: oss-security@...ts.openwall.com
Subject: Re: RE: [security-vendor] Re: Fuzzing
findings (and maybe CVE requests) - Image/GraphicsMagick, elfutils, GIMP,
gdk-pixbuf, file, ndisasm, less
Am Tue, 18 Nov 2014 13:32:09 -0800
schrieb Seth Arnold <seth.arnold@...onical.com>:
> Adding a fuzzer or two to the process might be worthwhile; the
> downside is that most fuzzers seem to require a certain amount of
> preperation work before they start giving good results, and depending
> upon the program, a fuzzer may not reliably represent the attack
> surfaces available. (Consider trying to fuzz e.g. openssh or nginx.)
> I don't think it'd be easy to automate.
It'd already be a good start to do this for format-parsing tools. So
stuff that runs on files. Everything else is more complicated, fuzzing
file formats is the easiest.
> Getting AFL to work with every package suggested for Ubuntu main is
> probably too much work.
You may overestimate the complexity of afl. Once you get used to it it
basically takes minutes to start a fuzzing job.
And Michal is very open to suggestions to improve it (and it is
improving on a daily basis right now).
A bit sad is that afl+asan is somewhat tricky business, because that'd
be the ultimate combo.
> The results of a fuzzing project would not greatly influence our
> decision to support a package. I don't believe surviving a fuzzer is
> the best proxy for code quality, though it would be nice to have more
> information when making a decision to support a package.
I agree that it's not the best proxy for code quality. But for me what
is a good proxy for *project* quality is how they handle the bugs that
result from fuzzing.
While libbfd was in a terrible state, Nick did a marvellous job in
fixing everythin we reported in a timely manner.
Whilst for others you simply don't get a reply (or there is noone to
report to).
That's the difference between a healthy and an unhealthy project.
--
Hanno Böck
http://hboeck.de/
mail/jabber: hanno@...eck.de
GPG: BBB51E42
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
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.
