From $URL This is a heads up for a trivial systemd local root exploit, that was silently fixed in the upstream git as: commit 06eeacb6fe029804f296b065b3ce91e796e1cd0e Author: .... Date: Fri Jan 29 23:36:08 2016 +0200 basic: fix touch() creating files with 07777 mode mode_t is unsigned, so MODE_INVALID < 0 can never be true. This fixes a possible DoS where any user could fill /run by writing to a world-writable /run/systemd/show-status. The analysis says that is a "possible DoS", but its a local root exploit indeed. Mode 07777 also contains the suid bit, so files created by touch() are world writable suids, root owned. Such as /var/lib/systemd/timers/stamp-fstrim.timer thats found on a non-nosuid mount. This is trivially exploited by something like: http://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/CreateSetgidBinary.c with minimal changes, so I wont provide a PoC here. The bug was possibly introduced via: commit ee735086f8670be1591fa9593e80dd60163a7a2f Author: ... Date: Wed Nov 11 22:54:56 2015 +0100 util-lib: use MODE_INVALID as invalid value for mode_t everywhere So we believe that this mostly affects v228 of systemd, but its recommended that distributors cross-check their systemd versions for vulnerable touch_*() functions. We requested a CVE for this issue from MITRE by ourselfs: CVE-2016-10156 We would like to see that systemd upstream retrieves CVE's themself for their own bugs, even if its believed that its just a local DoS. This would make distributors life much easier when we read the git logs to spot potential issues. The systemd git log is really huge, with lots of commits each week ("new services as a service").
@ Maintainer(s): Can we stabilize =sys-apps/systemd-232 (due to bug 595476)? Or will you rev bump and backport the fix?
The affected code is present since https://github.com/systemd/systemd/commit/f4f15635ec05293ffcc83a5b39f624bbabbd8fd0 so our current stable version *could* be unaffected. But given that this was a large rewrite, this needs further investigation.
Our stable version should be affected, see https://github.com/systemd/systemd/commit/c38dfac9ed6c1c3beb3dd88ebf82a13d1e561ff8
No, systemd-231 and systemd-232 are both unsuitable for stabilization. There are already a few security bugs filed against systemd. I am waiting for upstream to cut a release that doesn't have major functional regressions.
From what I can tell, v226 never calls touch_file with MODE_INVALID. Instead, it uses 0 as a sentinel value, which results in files being created with mode 0644. In other words, our stable version is unaffected by this issue.
I agree, > # grep -Fr 'touch_file' /tmp/sys-apps/systemd-226-r2/work > tmp/sys-apps/systemd-226-r2/work/systemd-226/src/timesync/timesyncd.c: touch_file("/var/lib/systemd/clock", true, min, uid, gid, 0644); > tmp/sys-apps/systemd-226-r2/work/systemd-226/src/basic/util.h:int touch_file(const char *path, bool parents, usec_t stamp, uid_t uid, gid_t gid, mode_t mode); > tmp/sys-apps/systemd-226-r2/work/systemd-226/src/basic/util.c:int touch_file(const char *path, bool parents, usec_t stamp, uid_t uid, gid_t gid, mode_t mode) { > tmp/sys-apps/systemd-226-r2/work/systemd-226/src/basic/util.c: return touch_file(path, false, USEC_INFINITY, UID_INVALID, GID_INVALID, 0); > tmp/sys-apps/systemd-226-r2/work/systemd-226/src/libsystemd/sd-device/device-private.c: r = touch_file(path, true, USEC_INFINITY, UID_INVALID, GID_INVALID, 0444); > tmp/sys-apps/systemd-226-r2/work/systemd-226/src/core/timer.c: touch_file(t->stamp_path, true, t->last_trigger.realtime, UID_INVALID, GID_INVALID, 0); > tmp/sys-apps/systemd-226-r2/work/systemd-226/src/core/timer.c: touch_file(t->stamp_path, true, USEC_INFINITY, UID_INVALID, GID_INVALID, 0); > tmp/sys-apps/systemd-226-r2/work/systemd-226/src/test/test-conf-files.c: assert_se(touch_file(path, true, USEC_INFINITY, UID_INVALID, GID_INVALID, 0) == 0); > OpenSUSE thinks this was introduced by https://github.com/systemd/systemd/commit/ee735086f8670be1591fa9593e80dd60163a7a2f So Gentoo is not affected, no vulnerable version in repository. Closing as invalid.
