Re: RE: [security-vendor] Re: [oss-security] Fuzzing findings (and maybe CVE requests) - Image/GraphicsMagick, elfutils, GIMP, gdk-pixbuf, file, ndisasm, less

[Seth Arnold <seth.arnold () canonical com>]

On Wed, Nov 19, 2014 at 12:21:29AM +0100, Hanno Böck wrote:
> 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.

You'd be surprised how infrequently file formats come up.. :)

> > 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).

Oh, AFL itself looks pretty blindingly easy to use: CC=... CXX=...  and go
with it. It's our packaging and building infrastracture that I think would
make it more complicated: they're designed to make repeatable builds
easy, not necessarily to allow arbitrary changes to the compiler. And,
AFL only works for C/C++.

> A bit sad is that afl+asan is somewhat tricky business, because that'd
> be the ultimate combo.

That does sound nice, not every Bad Thing is necessarily visible to the
fuzzer, but asan is more likely to recognize Bad Things.

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

Oh my yes; having a contact readily visible, having someone respond
quickly, both are very strong indicators of quality.

Thanks

Attachment: signature.asc
Description: Digital signature