From: Michael Matz <matz@suse.de>
To: Binutils <binutils@sourceware.org>
Cc: Ian Lance Taylor <iant@google.com>,
Siddhesh Poyarekar <siddhesh@gotplt.org>,
Paul Koning <paulkoning@comcast.net>,
Richard Earnshaw <Richard.Earnshaw@foss.arm.com>,
Nick Clifton <nickc@redhat.com>,
"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: RFC: Adding a SECURITY.md document to the Binutils
Date: Mon, 17 Apr 2023 15:31:13 +0000 (UTC) [thread overview]
Message-ID: <alpine.LSU.2.20.2304171505370.3155@wotan.suse.de> (raw)
In-Reply-To: <CAKOQZ8x4KOfVhdGrf+mgkRJ9QkDn36jUJcWWXU=NG1E3g6BDyg@mail.gmail.com>
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.
next prev parent reply other threads:[~2023-04-17 15:31 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 8:42 Nick Clifton
2023-04-07 10:36 ` Eli Zaretskii
2023-04-11 13:29 ` Nick Clifton
2023-04-11 14:23 ` Simon Marchi
2023-04-11 15:00 ` Eli Zaretskii
2023-04-11 16:22 ` Nick Clifton
2023-04-11 16:32 ` Matt Rice
2023-04-11 18:18 ` J.W. Jagersma
2023-04-12 8:43 ` Nick Clifton
2023-04-08 6:30 ` Jan Beulich
2023-04-10 18:30 ` John Baldwin
2023-04-20 15:56 ` Nick Clifton
2023-04-11 19:45 ` Ian Lance Taylor
2023-04-12 16:02 ` Richard Earnshaw
2023-04-12 16:26 ` Siddhesh Poyarekar
2023-04-12 16:52 ` Richard Earnshaw
2023-04-12 16:58 ` Paul Koning
2023-04-12 17:10 ` Siddhesh Poyarekar
2023-04-13 3:51 ` Alan Modra
2023-04-13 4:25 ` Siddhesh Poyarekar
2023-04-13 5:16 ` Alan Modra
2023-04-13 12:00 ` Siddhesh Poyarekar
2023-04-13 10:25 ` Richard Earnshaw
2023-04-13 11:53 ` Siddhesh Poyarekar
2023-04-13 12:37 ` Richard Earnshaw
2023-04-13 12:54 ` Siddhesh Poyarekar
2023-04-13 13:11 ` Richard Earnshaw
2023-04-13 13:35 ` Siddhesh Poyarekar
2023-04-13 13:40 ` Richard Earnshaw
2023-04-13 13:56 ` Siddhesh Poyarekar
2023-04-13 14:50 ` Richard Earnshaw
2023-04-13 15:02 ` Siddhesh Poyarekar
2023-04-13 15:05 ` Richard Earnshaw
2023-04-13 16:42 ` Siddhesh Poyarekar
2023-04-14 9:52 ` Richard Earnshaw
2023-04-14 12:43 ` Siddhesh Poyarekar
2023-04-14 12:49 ` Richard Earnshaw
2023-04-14 13:13 ` Siddhesh Poyarekar
2023-04-13 15:08 ` Paul Koning
2023-04-13 16:02 ` Siddhesh Poyarekar
2023-04-13 16:49 ` Paul Koning
2023-04-13 17:00 ` Siddhesh Poyarekar
2023-04-13 17:05 ` Paul Koning
2023-04-13 17:29 ` Siddhesh Poyarekar
2023-04-13 17:37 ` Paul Koning
2023-04-13 18:16 ` Siddhesh Poyarekar
2023-04-14 17:37 ` Ian Lance Taylor
2023-04-14 18:27 ` Siddhesh Poyarekar
2023-04-14 20:46 ` Ian Lance Taylor
2023-04-14 21:24 ` Siddhesh Poyarekar
2023-04-17 15:31 ` Michael Matz [this message]
2023-04-17 19:55 ` Ian Lance Taylor
2023-04-14 19:45 ` DJ Delorie
2023-04-14 20:49 ` Ian Lance Taylor
2023-04-15 6:41 ` Xi Ruoyao
2023-04-13 16:06 ` Richard Earnshaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LSU.2.20.2304171505370.3155@wotan.suse.de \
--to=matz@suse.de \
--cc=Richard.Earnshaw@foss.arm.com \
--cc=binutils@sourceware.org \
--cc=gdb@sourceware.org \
--cc=iant@google.com \
--cc=nickc@redhat.com \
--cc=paulkoning@comcast.net \
--cc=siddhesh@gotplt.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).