Bug 600624 (CVE-2013-4392) – sys-apps/systemd: TOCTOU race condition when updating file permissions and SELinux security contexts

• Product: Gentoo Security
• Status: IN_PROGRESS ---

[Description Thomas Deutschmann (RETIRED) 2016-11-23 20:58:05 UTC]

A TOCTOU (time-of-check time-of-use) race condition was found in the way systemd, a system and service manager, used to update file permissions and SELinux security contexts. A local attacker could use this flaw to conduct symbolic link attacks possibly leading to their ability to modify permissions / security context of a path different than originally intended / requested.

Issue found by Florian Weimer, Red Hat Product Security Team

[Comment 1 Thomas Deutschmann (RETIRED) 2016-11-23 21:08:31 UTC]

This only affects setups using SELinux. 

Looks like a design issue which won't be resolved very soon. From https://bugzilla.redhat.com/show_bug.cgi?id=858760#c0:

> shared/label.c:label_fix() does not prevent symlink resolution on the
> path name.  The function should check if the path name contains slashes
> and refuse to proceed in this case.  I think such a drastic measure is
> warranted because by design, this function works on files in other users'
> directories, and is subject to path name races. (There is not fsetxattrat
> interface in the kernel, so fchdir followed by lsetxattr/lsetfilecon is
> the only safe alternative.  Obviously, this is not thread-safe.)

From https://bugzilla.redhat.com/show_bug.cgi?id=859060#c11:

> This is currently blocked by the need for new system calls (or making
> existing system calls work with O_PATH):
> 
> http://article.gmane.org/gmane.linux.file-systems/82821
> 
> We need to open files to check their hard link count and make sure that
> is not greater than 1, so that we do not improperly relabel a file that
> is visible elsewhere in the file system.  Without O_PATH, the open
> operation can have side effects, so we would introduce another type of
> security bug.
> 
> Addressing this would also fix the other issue (lsetfilecon is called
> with absolute paths, which does not prevent symbol link resolution on
> non-final path components), but this issue could be fixed separate if
> desired.


This was first reported in bug 486904.

If you compare the criticized code from https://github.com/systemd/systemd/blob/v208/src/shared/label.c#L93-L136 with https://github.com/systemd/systemd/blob/331d6a201b82a03c5343bb9c25280f0cd8b7d9fb/src/basic/label.c#L29-L41 aka https://github.com/systemd/systemd/blob/331d6a201b82a03c5343bb9c25280f0cd8b7d9fb/src/basic/selinux-util.c#L83-L119 (due to code move in https://github.com/systemd/systemd/commit/a095315b3c31f7a419baceac82c26c3c5ac0cd12) you will notice that a race is still possible and that the code doesn't check for slashes or symlinks.

[Comment 2 Aaron Bauman (RETIRED) 2019-03-29 01:54:07 UTC]

Marking this as unstable considering systemd is masked for SELinux profiles. Thus, it is not a stable profile or configuration.