Re: Bugs found by Cryptofuzz - some missing CVEs or too low impact for CVE?

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

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

Attachment: signature.asc
Description: