what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

systemd Local Privilege Escalation

systemd Local Privilege Escalation
Posted Jan 31, 2018
Authored by Michael Orlitzky

systemd (systemd-tmpfiles) versions prior to 236 suffer from an fs.protected_hardlinks=0 local privilege escalation vulnerability.

tags | exploit, local
advisories | CVE-2017-18078
SHA-256 | ab5c7f27e35d1f4741577e57058839ae024c0d913dfc8c629d2aad07f55c2130

systemd Local Privilege Escalation

Change Mirror Download
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


Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    0 Files
  • 20
    Mar 20th
    0 Files
  • 21
    Mar 21st
    0 Files
  • 22
    Mar 22nd
    0 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    0 Files
  • 26
    Mar 26th
    0 Files
  • 27
    Mar 27th
    0 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close