Re: RFC: Adding a SECURITY.md document to the Binutils

Michael Matz via Gdb
2023-04-17T15:31:56Z

Hello,

On Fri, 14 Apr 2023, Ian Lance Taylor via Binutils wrote:

> And, honestly, these are not standards that are unusually difficult to
> meet. Don't dump core, don't use up all of memory, don't have buffer
> overflows. Treat failures of this sort as security bugs to be fixed
> ASAP in minor releases. These are achievable goals.

These are all noble goals to reach for. But the fact is that all the crap
CVE entries from script-kiddies with their fuzzers are mainly fixed by
Alan with his seemingly endless patience. Downstream they are the cause
of endless worries (as customers blindly _demand_ that all CVEs be fixed
by checking tickmarks on an endless list of entries they've downloaded
last week from mitre; just by virtue of the entry having a CVE number and
hence "be a serious security problem"). All of these are bugs to be fixed
eventually. Literally _none_ of them are in any way a serious bug
demanding an immediate fix. Next release is completely fine for that.

The endless trouble is in either (a) disputing the CVE with mitre, or (b)
discussing each of the entries with the customer of why it's harmless and
so on or (c) to backport zillions of useless patches to multiple
codestreams and (d) to rebuild all stuff with the new patched binutils.
And _then_ multiply this by the overwhelming feeling of wasting lifetime
on completely irrelevant, unrealistic and stupid problems that noone in a
realistic world will hit. Fixing the (e.g. buffer overflow) bug is good.
Fixing it "right now because I'm important" is not.

Essentially fuzzers have destroyed any value of the CVE database (they are
wonderful as bug hunters, don't get me wrong on that; but CVEs are
meanwhile used as "I'm important, fix my bug right now!!!"). We as
downstream for instance, since a long time, essentially defer all
binutiles "CVEs" resulting from fuzzing to the next release of binutils
(even though updating to new releases in old codestreams brings its own
problems, they are just a lot easier to deal with than backporting 100
"CVE" fixes, where each of them poses the danger of introducing an actual
bug).

If it were me my SECURITY.md text would read "If you get a CVE from a
fuzzed input we ignore you. Report it as normal bug and stop hunting for
a CVE-entry ranking record.", but I can see why that might be a bit too
blunt :)

Sorry for the rant :)

Ciao,
Michael.