michael orlitzky

CVE-2017-18078: systemd-tmpfiles root privilege escalation sans fs.protected_hardlinks

Product
systemd (systemd-tmpfiles)
Versions affected
236 and earlier
Published on
2018-01-29
Author
Michael Orlitzky
Fixed in
commit 5579f85 , version 237
Bug report
https://github.com/systemd/systemd/issues/7736
MITRE
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18078
OSS-security
http://www.openwall.com/lists/oss-security/2018/01/29/3
Acknowledgments
Lennart Poettering who—instead of calling me an idiot for not realizing that systemd enables fs.protected_hardlinks by default—went out of his way to harden the non-default configuration.

Summary

Before version 237, the systemd-tmpfiles program will change the permissions and ownership of hard links. If the administrator disables the fs.protected_hardlinks sysctl, then an attacker can create hard links to sensitive files and subvert systemd-tmpfiles, particularly with Z type entries.

Systemd as PID 1 with the default fs.protected_hardlinks=1 is safe.

Details

When running as PID 1, systemd enables the fs.protected_hardlinks sysctl by default; that prevents an attacker from creating hard links to files that he can't write to. If, however, the administrator should decide to disable that sysctl, then hard links may be created to any file (on the same filesystem).

Before version 237, the systemd-tmpfiles program will voluntarily change the permissions and ownership of a hard link, and that is exploitable in a few scenarios. The most problematic and easiest to exploit is the Z type tmpfiles.d entry, which changes ownership and permissions recursively. For an example, consider the following tmpfiles.d entries,

1
2
d /var/lib/systemd-exploit-recursive 0755 mjo mjo
Z /var/lib/systemd-exploit-recursive 0755 mjo mjo

Whenever systemd-tmpfiles is run, those entries make mjo the owner of everything under and including the directory /var/lib/systemd-exploit-recursive. After the first run, mjo can create a hard link inside that directory pointing to /etc/passwd. The next run (after a reboot, for example) changes the ownership of /etc/passwd.

A proof-of-concept can be run from the systemd source tree:

root # sysctl -w fs.protected_hardlinks=0

root # sysctl -w kernel.grsecurity.linking_restrictions=0

root # ./build/systemd-tmpfiles --create

mjo $ ln /etc/passwd /var/lib/systemd-exploit-recursive/x

root # ./build/systemd-tmpfiles --create

mjo $ /bin/ls -l /etc/passwd

-rwxr-xr-x 2 mjo mjo 1504 Dec 20 14:27 /etc/passwd

More elaborate exploits are possible, and not only the Z type is vulnerable.

Resolution

The recursive change of ownership/permissions does not seem to be safely doable without fs.protected_hardlinks enabled.

In version 237 and later, systemd-tmpfiles calls fstatat() immediately after obtaining a file descriptor from open():

1
2
3
4
5
6
fd = open(path, O_NOFOLLOW|O_CLOEXEC|O_PATH);
if (fd < 0) {
  ...
}

if (fstatat(fd, "", &st, AT_EMPTY_PATH) < 0)

The st->st_nlink field is then checked to determine whether or not fd describes a hard link. If it does, the ownership/permissions are not changed, and an error is displayed:

1
2
3
4
if (hardlink_vulnerable(&st)) {
  log_error("Refusing to set permissions on hardlinked file %s while the fs.protected_hardlinks sysctl is turned off.", path);
  return -EPERM;
}

There is still a tiny window between open() and fstatat() where the attacker can fool this countermeasure by removing an existing hard link to, say, /etc/passwd. In that case, st->st_nlink will be 1, but fd still references /etc/passwd. The attack succeeds, but is much harder to do, and the window is as narrow as possible. More to the point, it seems unavoidable when implementing the tmpfiles.d specification.

mitigation

Leave the fs.protected_hardlinks sysctl enabled.