Summary: | sys-apps/opentmpfiles: Root privilege escalation | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Dimitris Nakos (sokan) <sokan> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | mjo, openrc, williamh |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://github.com/OpenRC/opentmpfiles/issues/3 | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=617580 https://bugs.gentoo.org/show_bug.cgi?id=751415 |
||
Whiteboard: | B1 [upstream cve] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 647778 |
Description
Dimitris Nakos (sokan)
2018-02-15 16:38:31 UTC
@Maintainers please confirm if we are affected by this CVE. Thank you We are, but it is mitigated with gentoo-sources where fs.protected_hardlinks is enabled by default. fs.protected_hardlinks is enabled by default in gentoo-sources per bug #540006. But if you install vanilla-sources, you silently become vulnerable to a bunch of easy root exploits? (In reply to Michael Orlitzky from comment #4) > But if you install vanilla-sources, you silently become vulnerable to a > bunch of easy root exploits? Security does not support vanilla-sources. 1. It is an unstable package 2. The Gentoo kernel project does not support it either (Aside from making it available) While those are valid reasons I would agree that maybe something more should be done to warn users. I will have to look at the upstream kernel to verify if fs.protected_hardlinks=1. Currently mitigated by the sysctl being set by default in bug 704914. But it is true it is not yet resolved upstream. Right, so we talked about this in #gentoo-dev. The gist is that while this is a real issue in opentmpfiles, there isn't really anything we can do (the best is the mitigation which resolves this for any systems in a supported configuration - the default), and that even with the systemd approach, the race still exists (just shorter). It's fixable, but only on recent linux systems. And it's possible to mitigate with a race condition everywhere from within opentmpfiles. But the big picture is pretty clear: the systemd tmpfiles "specification" is faulty, since it can't be implemented securely unless you're on a brand-new linux system. The goal of opentmpfiles is therefore impossible to achieve. Solution: give up, mask it, and get rid of it. (Or, mask it everywhere except with recent linux kernels... but why? I can use systemd's tmpfiles there if I want to. Opentmpfiles is only useful in situations where it introduces root exploits.) Also note that the sysctl tweaks DO NOT fix this other kindergarten root exploit: https://github.com/OpenRC/opentmpfiles/issues/4 The situation is the same: it's fixable only on recent linux systems, where opentmpfiles serves no purpose in the first place. See CVE-2018-6954 for the systemd solution. |