[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201208223558.GF3381169@millbarge>
Date: Tue, 8 Dec 2020 22:35:58 +0000
From: Seth Arnold <seth.arnold@...onical.com>
To: Robert Watson <robertcwatson1@...il.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Bugs found by Cryptofuzz - some missing CVEs or
too low impact for CVE?
On Tue, Dec 08, 2020 at 05:18:04PM -0500, Robert Watson wrote:
> Question from a retired programmer but security novice... Since fuzzing is
> used to find bugs in other programs, doesn't it need to be held to a bit
> higher standard in order to maintain credibility?
The output from fuzzers is a large body of inputs (or programs, in the
case of syzkaller) that directly demonstrate the problem in the program
being fuzzed.
The generated inputs can be used separately from the fuzzing framework.
Many are only useful when combined with sanitizers, or debug builds,
or similar efforts to turn errors into something visible (corrupting
the stack may not be visible directly, for example). It's unfortunate
that this step is required, and I have seen maintainers not interested
in taking fixes that are "only visible with ubsan", for example, but
this attitude is thankfully rare.
Developers can keep these example inputs for their test suites, CI /
CD systems, etc, and make sure that their programs don't fail on these
inputs in the future, too.
This does put a lot of trust into the sanitizers but compilers tend to
have pretty good test suites. Afterall, they, too, are fuzzed, and
automated tooling like csmith, creduce, delta, cvise, and probably more,
can help find minimal test cases.
The most difficult part of working with fuzzers, in my opinion, is that
it can take a long time to figure out the cause of a crash or sanitizer
alert. Often finding the causes, or to propose a fix, takes longer than
finding issues.
Thanks
Download attachment "signature.asc" of type "application/pgp-signature" (489 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.
