Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 751424 (CVE-2018-21269) - sys-apps/openrc : checkpath root privilege escalation following non-terminal symlinks (CVE-2018-21269)
Summary: sys-apps/openrc : checkpath root privilege escalation following non-terminal ...
Status: CONFIRMED
Alias: CVE-2018-21269
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: https://github.com/OpenRC/openrc/issu...
Whiteboard: A4 [upstream]
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-27 08:43 UTC by filip ambroz
Modified: 2020-10-30 18:06 UTC (History)
2 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 filip ambroz 2020-10-27 08:43:55 UTC
checkpath in OpenRC through 0.42.1 might allow local users to take ownership of arbitrary files because a non-terminal path component can be a symlink

Reproducible: Always
Comment 1 filip ambroz 2020-10-27 08:46:49 UTC
Links:
https://nvd.nist.gov/vuln/detail/CVE-2018-21269
Comment 2 Michael Orlitzky gentoo-dev 2020-10-27 19:17:39 UTC
More information: http://michael.orlitzky.com/cves/cve-2018-21269.xhtml
Comment 3 William Hubbs gentoo-dev 2020-10-30 17:08:37 UTC
I have received a couple of suggestions for this, neither is quite what
I would want.

- make checkpath only check things without changing them (this would break
  compatibility).

- use linux specific fixes (this would cause different behavior for
	non-linux users).
Comment 4 Michael Orlitzky gentoo-dev 2020-10-30 18:02:43 UTC
There was a long thread about in January 2018:

  https://archives.gentoo.org/gentoo-dev/message/e6169799a2c57b43e71de8783bd58b3d

In summary: checkpath promises something it can't safely do, so checkpath should be deprecated and replaced by something that promises less.

I called it "newpath" in that thread, and there are two main things that need to happen:

  * The new helper should be able to drop privileges before it acts. This is
    basically just a portable "su", since "su" itself is not portable.

  * The new helper should verify, from the root up, that it never traverses a 
    directory that is writable by anyone other than root or itself. You can
    steal part of the systemd tmpfiles implementation for this.

I also think the new helper should refuse to modify the ownership or permissions on an existing file or directory. (Attempting to do so is fine, if the operation would turn out to be a no-op.)

Once those things are done, the basic pattern is...

  1. Create a "top-level" user-writable path within a root-only path.
     For example, "newpath --directory /run/foo"

  2. Drop privileges and create/modify whatever you need beneath that
     "top-level" path as the restricted user. For example,
     "newpath --as=foo --file /run/foo/bar"
Comment 5 Michael Orlitzky gentoo-dev 2020-10-30 18:06:27 UTC
(In reply to Michael Orlitzky from comment #4)
> 
> Once those things are done, the basic pattern is...
> 
>   1. Create a "top-level" user-writable path within a root-only path.
>      For example, "newpath --directory /run/foo"

Whoops, for the example to make sense that should be:

  newpath --owner=foo --directory /run/foo

that way the "foo" user can write to it in step 2.