Date: Wed, 12 Dec 2018 15:24:15 +0100 From: Solar Designer <solar@...nwall.com> 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) On Wed, Dec 12, 2018 at 01:27:13AM +0100, Jann Horn wrote: > NOTE: I have requested a CVE identifier, and I'm sending this message, > to make tracking of the fix easier; however, to avoid missing security > fixes without CVE identifiers, you should *NOT* be cherry-picking a > specific patch in response to a notification about a kernel security > bug. (I resisted the urge to comment on this piece in previous postings.) What should distros/users do, then? Use latest mainline or upstream stable kernels? That would expose them to the many recent bugs like this one, but which haven't yet been found (or not yet made public, which is worse). As far as I can tell, by far most Linux kernel vulnerabilities (that are eventually found and made public) are in relatively recent (as of that time) kernel versions. So a user or a distro would avoid most vulnerabilities (that are eventually found and made public) by staying sufficiently behind current versions, and relying on backports, even if at risk of missing untracked vulnerabilities. Currently this can be achieved e.g. by using RHEL7'ish kernels forked by Red Hat off 3.10, but probably not anything newer than that yet. (And when RHEL7 was just released, its kernels were not quite ready for such use. It takes even RHEL kernels a few years and a few hundred revisions to mature and become a lower security risk. Fortunately, there's a previous RHEL at a few years and a few hundred revisions old yet still maintained during that time.) 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? My gut feeling is there are many more such vulnerabilities in "too recent" kernels than there are those untracked vulnerabilities in "sufficiently old" kernels. (BTW, a vulnerability being untracked likely correlates with it being a lower risk probability at least for non-targeted attacks.) Hence optimal strategy for a distro and their users is to stay with "sufficiently old" base versions and backport whatever is known to be worthy of a backport. There are no maintained upstream stable branches started long enough ago for them to be as mature as e.g. RHEL7 kernels are now. Besides, upstream stable branches also suffer from lack of backports of fixes for untracked vulnerabilities. The recommendation to use latest mainline or upstream stable kernels is safe to give (and in a way even the most responsible one to give), but not necessarily the best to follow. I do not have a suggestion on what to do about that as it relates to recommendations/disclaimers on postings such as Jann's. Ideally, we wouldn't have so many new security vulnerabilities being introduced to new Linux kernels all the time, but that seems unrealistic given the pace of Linux kernel development and growth. > In Linux kernel versions since 4.11, userfaultfd can be used to write > arbitrary data into holes in sparse tmpfs files to which an attacker > has read-only access. > > This is CVE-2018-18397. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29ec90660d68bbdd69507c1c8b4e33aa299278b1 > https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.87 > https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.7 > https://bugs.chromium.org/p/project-zero/issues/detail?id=1700 Interesting. How did you find this? Alexander 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.
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.