The vulnerable system is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or through terminal emulation (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
Low
PR
The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: systemd (systemd-tmpfiles) < 236 fs.protected_hardlinks=0 Local Privilege Escalation
Product: systemd (systemd-tmpfiles)
Versions-affected: 236 and earlier
Author: Michael Orlitzky
Fixed-in: commit 5579f85 , version 237
Bug-report: https://github.com/systemd/systemd/issues/7736
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,
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 /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, using
either two separate terminals or sudo:
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():
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:
if (hardlink_vulnerable(&st)) {
log_error("Refusing to set permissions on hardlink...", 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.
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum