[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181214164518.GA25363@openwall.com>
Date: Fri, 14 Dec 2018 17:45:18 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Greg KH <greg@...ah.com>, Yves-Alexis Perez <corsac@...ian.org>,
Brad Spengler <spender@...ecurity.net>,
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)
On Fri, Dec 14, 2018 at 03:14:54PM +0100, Jann Horn wrote:
> I think one additional aspect here is the kernel config.
Definitely. But relatively few people build their own per-machine
kernels. For many Linux distros, it's a choice of which base kernel to
use and maintain, and then they enable plenty of features that are in
any demand at all.
> From what
> I've seen, distros tend to turn on all the config options because they
> probably have some user, somewhere, who wants to use that feature; and
> if you use that strategy for your kernel config, then yes, new
> releases probably add new features and attack surface.
>
> But since you're able to use a 3.10 kernel, evidently you don't need
> those features. So I think it makes sense to, instead of comparing a
> 3.10 distro kernel and a 4.19 distro kernel, look at an old and a new
> kernel with the same feature set enabled.
For someone doing their own kernel builds and bothering to spend time
deciding on every option, yes. This was slightly time-consuming in the
2.0.x days. Much more so later. Probably unaffordable for most now.
> Looking at the public Linux kernel bugs I filed in our bugtracker
> (which, of course, are a very small number of bugs and probably not
> very representative):
Thank you for this impressive list!
It starts Apr 25 2016, which is before I'd have considered RHEL7 kernels
mature enough for purposes of this discussion. Although it gets close.
I started to comment on some of these, but I don't want us to be
splitting hairs over old bugs that I don't have a perfect understanding
of, so I deleted my comments and will instead summarize:
In my first message in this thread I was focusing on issues
that are: high or critical overall severity (not all of yours are),
affect x86-64 kernel builds (although I didn't say so), and are fully
exposed in a typical distro. A weird fs type isn't sufficiently exposed
even if compiled in, or if it is then I think that's a distro issue to
be fixed. I assume it normally takes at least plugging in a USB thumb
drive or having privileges to be able to mount a rogue filesystem.
> So by my count, that's roughly:
>
> A) 5 bugs that were already in 3.10 (reiserfs, coredump leak, W+X
> bypass, ARM64 perf_event_open(), perf_event_open()/execve() race)
That's 3 low or medium severity, one non-x86-64, and one high+ severity
but slightly before my time range (let's say, latest one year).
> B) 3 additional bugs that were already in 3.10, and where the bug was
> worse in old kernels than in the affected one (UAF via late TLB flush;
> infoleak from the stack), or where modern kernels would mitigate the
> issue (stack overflow)
That's 1 high+ severity (UAF via late TLB flush). The other two feel
lower severity either because of lower impact (infoleak from the stack)
or obscure prerequisites (stack overflow via ecryptfs).
> C) 8 bugs that are gated behind config flags that you won't have set
> if you haven't enabled new features after 3.10 (BPF and userfaultfd)
> D) 9 bugs that are newer than 3.10 and that might be compiled in even
> if you haven't enabled new features since 3.10 (user namespaces, VMA
> UAF, kernel read into dmesg, TLB race, percpu refcounts, ext4, compat
> adjtimex, RNG issues, mincore heap leak)
(Un)fortunately, RHEL7 has backports of some of these features - IIRC,
eBPF since RHEL 7.6, userfaultfd for a long time, user namespaces for a
long time but disabled by default.
If a feature is backported after it's had those bugs already found and
fixed upstream, then those bugs don't count against that distro kernel.
I could be wrong about some of the detail. I mention it to illustrate
how non-trivial it is to consider even a small set of bugs like this wrt
different kernel versions and builds.
This also means that my analysis of Kees' data was relatively easy only
due to lack of detail (no vulnerability detail with that data, and no
"3.10 RHEL7" kernel in the illustration).
When each new high+ severity issue is found, what matters is whether it
affects the kernel (in the chosen branch or distro) patched against the
previous such issue or not. We have no illustration on that.
> I think it might be helpful to ensure that kernels used in
> environments where you care about security are not configured with the
> maximum amount of features possible, but instead adjusted to actual
> requirements via kernel config and sysctls. Examples:
>
> Regarding the specific bug that started this thread: userfaultfd is
> enabled by distro kernels, but the only current usecase I'm aware of
> is reduction of downtime for QEMU live migration. You probably don't
> need it.
> You might not need compat support.
> You probably don't need support for every single filesystem Linux knows about.
> eBPF is useful for some networking and performance tracing stuff, but
> you probably don't actually need it to be available for non-root, even
> if you do have a use for it.
>
> This should let you avoid many bugs that are introduced as part of new
> features; but of course, it doesn't do much against bugs introduced by
> performance optimizations and such.
>
> It sucks that distros shipping binary kernels kinda have to do the
> opposite of this in order to fulfill their users' needs, at least for
> config options where "build as a module" isn't an option. :( If
> distros want to use a single kernel image for everything, perhaps
> having more sysctls to lock down new features, in addition to the
> kernel config, would help...
Sure. You and others should feel encouraged to identify such features
that are currently compile-time only but could be made possible to
enable/disable via sysctls and such, and contribute patches under KSPP
or otherwise. Then maybe we'll see distros enable fewer questionable
features by default or/and more systems will have those features
disabled by sysadmins.
> > P.S. I guess Jann's message did not reach subscribers who are on Gmail
> > and such because of google.com's DMARC policy. So I made sure to quote
> > all of it above.
>
> Bleeh... I guess maybe I should use a @googlemail.com account for that...
google.com has "p=reject", googlemail.com has "p=quarantine\;
sp=quarantine", gmail.com has "p=none\; sp=quarantine\". I know that
mail from @gmail.com has been getting through via the list to recipients
on Gmail fine. I don't yet know if @googlemail.com will work just as
well or not. I hope it will.
Alexander
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.
