[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150529220430.GA3210@kroah.com>
Date: Fri, 29 May 2015 15:04:30 -0700
From: Greg KH <greg@...ah.com>
To: Henri Salo <henri@...v.fi>
Cc: oss-security@...ts.openwall.com, cve-assign@...re.org
Subject: Re: CVE request: vulnerability in the kernel tty
subsystem.
On Sat, May 30, 2015 at 12:36:19AM +0300, Henri Salo wrote:
> Please correct me if I am wrong somewhere in this email. I just want to
> understand why you said this.
>
> On Tue, May 26, 2015 at 07:52:47AM -0700, Greg KH wrote:
> > For a 2 year old bugfix?
>
> Age does not matter for CVE assigment as far as I can tell.
Sweet, who is going to go and start asking for CVEs for all bugs that we
have fixed in the past 10 years in the Linux kernel? Should I just to
flood the list of CVEs and see if people's tools can really handle the
extra number problem when parsing them? :)
What good would it be to do such a thing?
> > I know you all like to try to track bugs for old and obsolete products,
> > but really, there's no end of CVEs you could request if you wish to do
> > this. Heck, I could start asking for multiple CVEs for every single
> > stable kernel release I do, which would just be pointless.
> > Please just mark this as a "oh look, a bug was fixed years ago and we
> > need to backport it because we have old kernels out in the wild and our
> > customers don't like to upgrade" type issue.
> > Don't force CVEs to play by the odd enterprise rules that you all wish
> > perpetuate.
>
> CVE is defined as "common identifiers for publicly known information-security
> vulnerabilities in publicly released software packages".
>
> How is it pointless to request CVE identifier for security issue in kernel or
> other software if that software is released and used by some distro or other
> entity? How do you calculate how many users are using some kernel if it is
> released in public website? Please note that this might be easier for kernel
> than some other software like web-application project in GitHub.
The issue is, where do you draw the line? I know systems still using
2.x kernels, in supported configurations. Those were released a very
long time ago, do we assign CVEs for bugs fixed from the past 10 years
till 5 years ago just to make it easy for the company that is
maintaining that kernel to justify to their customers the reason they
should be updating their kernels?
And that's it, it's not a "we need to track this", for such old bugs
(and by "old" I would classify anything older than a year for the kernel
as old, as that's hundreds of thousands of patches ago)? It's the job
of companies that insist on using such old software, to maintain and
keep them up to date, it's not the job of the "community" here to have
to deal with assigning issues to things that are really old and already
fixed.
> One reason I could think of for not requesting CVEs for issues is that it
> creates workload to MITRE or other CNA (and in some cases users of CVE when they
> are tracking issues). If that is the case could you or MITRE tell me where
> should that line be drawn?
It's not up to me to tell other people what to work on or spend
resources on. If MITRE wishes to track things in really old releases,
that's their business. But from a community point of view, that seems
foolish and wasteful as the only thing you are catering to here are
people who somehow only wish to update if they see a "CVE" number
assigned to that update.
And that's the issue here I think. Otherwise, why ask for CVEs for old
releases that no one in the community is supporting anymore? What good
is it for except for the customers of the companies that wish to do that
support for them?
> Or if this is not the case do you mean that "vulnerability in the kernel tty
> subsystem" is not critical enough for CVE? If that is the case how is that
> calculated?
As the maintainer of the tty subsystem, I'm not going to judge what is
and what is not "critical enough" for a CVE, as I personally think the
whole thing is a joke for old bugs like this.
Maybe for newly found things, it makes sense to be able to track across
releases what has and what has not been applied. But when it comes to
older things like this, I seriously fail to see the point.
> Or even "vulnerability in the kernel tty subsystem" is not a security issue?
Define "vulnerability"? :)
We fix things that cause kernel crashes every single day. Do you see us
asking for CVEs for everyone of those? No, because that would be
foolish.
Although, it would point out the foolishness of the whole system if I
were to start doing that. Call it "performance art", that might be fun
to do for a few months if for no other reason than to enjoy the show :)
tl;dr
I feel that CVEs for old kernels / releases that are not being
maintained by the upstream project, and have been fixed for a
long time in those upstream maintained releases, are pointless.
thanks,
greg k-h
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.
