[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1eCqK7-00047g-Kl@rmmprod07.runbox>
Date: Thu, 09 Nov 2017 12:09:03 -0500 (EST)
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: "oss-security" <oss-security@...ts.openwall.com>
Subject: Re: CVE-2017-15102: Linux kernel: usb: NULL-deref
due to a race condition in [legousbtower] driver
> > On Tue, 2017-11-07 at 21:22 +0100, Greg KH wrote:
> > > I hate to ask, but why are you getting CVEs for bugs fixed over a
> > > year ago, and are already in all stable kernel releases a year ago? Why
> > > does it matter?...
> On Tue, Nov 07, 2017 at 08:30:05PM +0000, Maier, Kurt H wrote:
> > Kernel maintainers' policy is clear, and nobody is asking for that to
> > change, but please don't sandbag the process of keeping track of
> > vulnerabilities. The fraction of "products" (regardless of vendor)
> > that run linux and never get updates approaches unity. Being able to
> > precisely catalog which linux releases suffer from which
> > vulnerabilities is useful to many.
On Wed, 8 Nov 2017 10:15:17 +0100, Greg KH <greg@...ah.com> wrote:
> Well, I'm working on fixing the "devices do not get updates" issue
> through other means, so don't just give up on that one just yet :)
I applaud your work! I think getting CVE assignments may help, as I explain below.
> As for the "keep track of vulnerabilities", is that what is really
> happening here? Why pick a random bug fix from over a year ago for a
> CVE vs. the 100 other bugfixes in the past few weeks/months?
>
> I'm really curious as to what triggered this specific CVE request that
> somehow misses the hundreds/thousands of other fixes that land in newer
> kernel releases?
Manufacturers & recipients often won't update unless there's a *reason* to update.
Documenting a number of *specific* CVEs in older kernel versions
provides clear documented reasons that an update needs to occur,
instead of a vague "you should upgrade" claim.
Perhaps most importantly, once a vulnerability has a CVE id,
some laws and regulations can come into play. Manufacturers
will (correctly) argue that no one can track all the mailing lists, but if a
vulnerability has a CVE id, it's generally agreed that the
vulnerability is a publicly known vulnerability.
In the US, there has been recent proposed legislation that requires
that "Internet of Things" devices sold to the federal government cannot have
"known security vulnerabilities" ("Internet of Things Cybersecurity Improvement
Act of 2017" proposed by Senators Mark Warner (R-Va.) and Cory Gardner (D-Colo.)).
I suspect many other countries have or will pass similiar laws,
or will interpret their existing laws this way.
It's easy to argue that known security vulnerabilities are known flaws
that should be remediated by the manufacturer (at no cost to the consumer).
I agree that many vulnerabilities don't have CVE ids.
You don't need to identify *all* vulnerabilities in old kernels... just enough to make
it easier to update the kernel than try to back-patch everything.
If manufacturers have to fix the CVEs to sell products, or to avoid massive returns,
that creates an *economic* reason for manufacturers to
begin responsibly maintain their products.
There's no guarantee that this sequence of events will happen, but it's worth trying.
--- David A. Wheeler
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.
