systemd-tmpfiles in systemd through version 237 mishandles symlinks present in non-terminal path components, allowing local users to obtain ownership of arbitrary files under certain configurations. Depending on the configuration and access to files in /etc/tmpfiles.d, a local user can potentially create a symlink allowing them obtain full access to arbitrary files when the systemd-tmpfiles command is run. This occurs even if the fs.protected_symlinks sysctl is turned on. Upstream Issue: https://github.com/systemd/systemd/issues/7986
Created systemd tracking bugs for this issue: Affects: fedora-all [bug 1545018]
Patches: https://github.com/systemd/systemd/pull/8358 https://github.com/systemd/systemd/pull/8822
Attack Complexity (AC) set to High (H) because the attacker cannot perform the attack as will, but particular configuration files have to be already configured and be owned/accessible by the attacker. Moreover, the attacker needs to find the right timing to perform the attack, so that the symlink replacement is performed when the tmpfiles configuration files are parsed. Availability (A) set to High (H) because the attacker may be able to obtain ownership of files not originally owned by him and delete them or gain complete access to the system through changes to those files.
Mitigation: There is no known mitigation available.
Statement: This flaw affects in particular those systems where custom tmpfiles files are configured (e.g. in /etc/tmpfiles.d). Indeed systemd-tmpfiles installed by system packages set privileges of a directory either to root or to a service specific user and not to interactive users. Even in case they provide one of the vulnerable tmpfiles configuration file (e.g. recursive "Z" type entries), an attacker would still need to perform the attack as the service specific user, which means they would first need to compromise that service. Moreover, systemd-tmpfiles service is automatically executed only when the system boots, when it is very unlikely an attacker has already a chance to perform any action at all. Otherwise, an attacker would have to wait for an administrator to manually run the `systemd-tmpfiles --create` command.
Reference: https://www.openwall.com/lists/oss-security/2018/12/22/1