[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181214132723.GA27168@grsecurity.net>
Date: Fri, 14 Dec 2018 08:27:24 -0500
From: Brad Spengler <spender@...ecurity.net>
To: oss-security@...ts.openwall.com
Cc: Jann Horn <jannh@...gle.com>
Subject: Re: Linux kernel: userfaultfd bypasses tmpfs file
permissions (CVE-2018-18397; since 4.11; fixed in 4.14.87 and 4.19.7)
I really wish such statistics would stop being cited as evidence of anything,
since the ingrained bias of CVE allocation (which is generally not done by
upstream itself, and is instead mostly done by the distros for issues that
affect their older kernels) inherently changes the range of conclusions that
can be reached. These statistics and the "5 year lifetime" of Linux kernel
bugs are simply myths. The original "5 year lifetime" analysis was wrong
from the start and already pointed out back then
(https://lwn.net/Articles/410674/), but people continue to cite it.
Garbage in, garbage out -- can we please stop feeding this pseudo-science?
-Brad
On Fri, Dec 14, 2018 at 02:07:55PM +0100, Solar Designer wrote:
> On Thu, Dec 13, 2018 at 09:02:12PM +0100, Yves-Alexis Perez wrote:
> > On Wed, 2018-12-12 at 15:24 +0100, Solar Designer wrote:
> > > A question to ask may be: out of Linux kernel vulnerabilities being
> > > patched, are there more high and critical overall severity (e.g., as
> > > risk impact times risk probability) vulnerabilities found in "too
> > > recent" kernels than there are high and critical severity untracked
> > > vulnerabilities (also or instead) affecting "sufficiently old" kernels?
> >
> > Data collected by Kees and regularly updated might help here. See
> > https://events.linuxfoundation.org/wp-content/uploads/2017/12/Overview-and-Recent-Developments-Kernel-Self-Protection-Project_Kees-Cook.pdf#%5B%7B%22num%22%3A22%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C0%2C446.4%2C0%5D
> > for the last edition (sorry for the weird anchor, in case it breaks it's on
> > slide 5)
>
> Thanks! Slide 4 says average lifetime among 3 critical issues is 5.3
> years, and among 79 high severity issues is 5.6 years. (And then
> there's over a thousand of medium and low severity issues. Ouch.)
>
> However, to answer my question above we need median and not average.
> For example, (1, 2, 3, 16) has an average of 5.5 years, but in that
> example by choosing a kernel version that is 2.5 years old, which is way
> below the average, we'd nevertheless avoid half of the issues.
>
> Slide 5 is in fact more relevant: it's an illustration showing
> "critical & high CVE lifetimes" against kernel versions. Per this
> illustration, we can see that my example of 3.10 (as RHEL7's base
> kernel) is hit by many low-numbered issues, but is hit by only two in
> the 67 to 82 range, which is 1/8 or 12.5% of issues found that recently.
> This is consistent with what I said about it having needed to mature
> "for a few years and a few hundred revisions" after RHEL7 was first
> released. I think it became mature enough just recently. It didn't
> feel mature enough to me when I ran Trinity for a few days (with many
> restarts) on a RHEL7-derived system two years ago. I hope those crashes
> have since been rediscovered with superior fuzzers allowing for easy
> reproduction, and patched. We've seen major improvement in fuzzing.
>
> Somehow Nicholas' reply below isn't part of the same thread (no proper
> In-Reply-To header), so let me bring it to the thread:
>
> https://www.openwall.com/lists/oss-security/2018/12/13/14
>
> On Thu, Dec 13, 2018 at 06:07:32PM -0500, Nicholas Luedtke wrote:
> > We have also been compiling and presenting the CVEs on a per stream
> > basis at https://www.linuxkernelcves.com because the question of which
> > upstream stable branch to choose has been asked on a enterprise level
> > many times. Of course, once you choose once you still have to track the
> > changes (or lack there of).
>
> This is also very interesting and relevant. As the website (and GitHub
> README.md) acknowledges:
>
> "This is currently autogenerated and will go through testing before any
> promises of accuracy are made. The eventual goal would be to have a
> community curated list of CVEs along with when the code was introduced
> and when it was fixed."
>
> Alexander
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
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.
