New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CVE-2017-18925: root privilege escalation by symlink attack #4
Comments
|
Hi, this issue was assigned with CVE-2017-18925. |
|
More information: http://michael.orlitzky.com/cves/cve-2017-18925.xhtml |
|
I've added https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=06d012cc3dacb4a2c7ac2e28553c96965f9ddea9 very lightly tested, of course some work needed before it'll be possible to integrate that and add to virtual, but it's de-facto standard implementation, so it should work fine. it's not vulnerable to symlink attack. |
|
and just to clarify, systemd officially supports building standalone |
|
Hello! Is there a plan to resolve this? |
The bigger picture here is that it just isn't safe for root to change ownership/permissions of files that live in a user-controlled directory. The symlink and recursive-chown issues can be fixed, but at the very best we are left with a race condition for regular hardlinks. Pragmatically, your best bet is to:
|
|
This is still broken. :/ |
We know.
Most or all of these race conditions/TOCTOU problems can't really be fixed in shell scripts. systemd-tmpfiles is written in C. Nobody is interested in maintaining opentmpfiles anymore and it's not really thought that there's a need for it now: #19 (comment) (and f33d0ea). |
|
This seems to have lost all git history and have no activity since. EDIT: nor does it seem to have been rewritten, or made any progress towards such, in C or a language which allows avoiding the TOCTOU issues discussed in detail above (which shell cannot). Diff: |
The default behavior of chown when called without the
-Rflag is to follow symlinks. At least thedtype, and possibly theftype, can exploit that fact to take ownership of arbitrary files on the system. For example,The first time that opentmpfiles-setup is run, things are fine; but then suppose I replace "foo" with a symlink:
and restart the service...
The call to chown has followed my symlink, and given me ownership of
/etc/passwd:The tmpfiles specification is silent on whether or not symlinks should be followed in this case, however, the same vulnerability was addressed in OpenRC's
checkpathhelper in Gentoo bug #540006.The text was updated successfully, but these errors were encountered: