[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <546E0AFE.1040801@redhat.com>
Date: Thu, 20 Nov 2014 08:38:38 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Fuzzing project brainstorming
The most important part of all: who's going to interpret the fuzzing
results and then co-ordinate with upstreams to make source code fixes?
Fuzzing is the easy part, fixing the code... not so much. It's not that
the devs don't feel this is important, but that they have a million
other things to do, plus personal lives/etc.
If this was easy we wouldn't have any tmp vulns, witness the push back
on something as simple as "please just use mkstemp!" from various devs.
On 20/11/14 05:34 AM, Hanno Böck wrote:
> Hi,
>
> Following the discussions here I feel this whole fuzzing thing could
> need a project to coordinate efforts and I will probably start
> something within the following days.
>
> I wanted to lay out my rough plans / brainstorming and welcome any
> feedback and especially if people have worries about such a project.
>
> * The core of the project will be a list of free software projects that
> in one way or another parse fileformats (I'll leave fuzzing network
> and other input out for now). It should have rough categories (ok =
> fuzzed and no unfixed issues in latest release, wip: fuzzed and issues
> are being worked on or already fixed in source repo, stale: fuzzed and
> issues don't seem to be worked on, unavalable = project with no
> developers to contact, wontfix = developers don't feel memory access
> issues and crashes need to be fixed / declare their product
> unsuitable for untrusted input, unknown = no known fuzzing efforts)
> I feel that it's important to make the limitation of this info
> transparent (e.g. about to change rapidly, always further /different
> fuzzing strategies that might turn up more issues, fuzzing is not a
> good indicator for overall security etc.).
> * A sharing place for stuff that might be useful for fuzzing, I think
> especially about patches that disable sanity checks (CRCs etc.) that
> make fuzzing harder. And maybe file collections with small example
> files for various file formats.
> * Some introduction tutorials that should give people with no fuzzing
> experience a starter. Preferrably so easy that everyone with some
> basic linux/unix knowledge can follow them. Explain zzuf, asan, afl.
> * All kinds of pointers/links to further information.
>
> Data and things like file archive should preferrably be public domain
> / cc0 to make data sharing as easy as possible.
>
> I welcome your feedback. I also welcome all reports (preferrably with
> links to public sources where this is documented - bugtrackers, mailing
> list archives etc.) of fuzzing. The good ("I fuzzed this for so long
> and it seems just nothing turned up") and the bad ("I found 10.000
> unique crashers and reported them all upstream, nobody cares").
>
> cu,
>
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
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.
