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.