Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Nov 2014 19:56:37 -0800
From: Michal Zalewski <lcamtuf@...edump.cx>
To: oss-security <oss-security@...ts.openwall.com>
Subject: Re: Fuzzing findings (and maybe CVE requests) -
 Image/GraphicsMagick, elfutils, GIMP, gdk-pixbuf, file, ndisasm, less

> What about using fuzzing to find those tools withOUT vulnerabilities and
> "certifying them" in some way as safe for all inputs?

Certainly a good starting point. The main problem is that there are
hundreds of thousands developer cranking out OSS code every day, and
perhaps several dozen skilled security researchers who would want to
play that game.

One could delegate the fuzzing to developers, but if they do not
particularly care about getting it right, and just want a "seal of
approval" on their website, it would probably become meaningless. It's
fairly hard to select, configure, and run fuzzers, especially on more
verbose or strict data formats (say, XML).

Now, fuzzing coverage measurements - of the traditional gcov sort -
are actually probably a decent proxy for how much effort the team is
putting into getting it right. It still needs some interpretation -
how much of that code is security-relevant to begin with, and how much
coverage does that get?

Ultimately, though, you need compelling incentives. Perhaps spare for
OpenBSD or Openwall, I doubt that security factors into the decisions
to add or promote a particular package. Users won't visit a website to
make sure the program has been fuzzed before running it, too.

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