It was found that When executing a program via "chroot --userspec=someuser:somegroup / /path/to/test" the nonpriv session can escape to the parent session by using the TIOCSTI ioctl to push characters into the terminal's input buffer. CVE assignment: http://seclists.org/oss-sec/2016/q1/452
Created util-linux tracking bugs for this issue: Affects: fedora-all [bug 1312864]
Is that really against coreutils? Based on http://marc.info/?l=util-linux-ng&m=145694736107128&w=2 (and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922 ) it seems to be issue with runuser/su - therefore util-linux was IMHO correct.
(In reply to Ondrej Vasik from comment #4) > Is that really against coreutils? Based on > http://marc.info/?l=util-linux-ng&m=145694736107128&w=2 (and > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922 ) it seems to be > issue with runuser/su - therefore util-linux was IMHO correct. This BZ is for chroot jailbreak. the similar util-linux attack has its own BZ & CVE : CVE-2016-2779
Marking Not-a-bug for RHEL5 based on the following : RHEL5's chroot command does not have a drop-privilege feature (i.e. : --userspec). chroot will run command as a root, and it is expected from root to be able to break out of the jail (see https://securityblog.redhat.com/2013/03/27/is-chroot-a-security-feature/ or https://en.wikipedia.org/wiki/Chroot#Limitations for additional information)
I am not aware of any fix for chroot without unintended side-effect. The situation is fairly well described in util-linux-2.28 release notes: This security issue is NOT FIXED yet. It is possible to disable the ioctl TIOCSTI by setsid() only. Unfortunately, setsid() has well-defined use cases in su(1) and runuser(1) and any changes would introduce regressions. It seems we need a better way -- ideally another ioctl (or whatever is supported by the kernel) to disable TIOCSTI without setsid(). https://www.kernel.org/pub/linux/utils/util-linux/v2.28/v2.28-ReleaseNotes I am afraid the above statement applies to chroot, too.
Yes it does, and to polkit as well (CVE-2016-2568). This idea of the new ioctl was originally suggested in the thread http://www.spinics.net/lists/util-linux-ng/msg12451.html. There has been afaik no kernel side discussion, though.
coreutils upstream has applied a similar patch (using libseccomp) on runcon: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v8.27-97-g8cb06d4
(In reply to Kamil Dudka from comment #13) > coreutils upstream has applied a similar patch (using libseccomp) on runcon: > > http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v8.27-97-g8cb06d4 coreutils upstream has reverted the above patch: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v8.27-101-gf5d7c0842
Statement: This issue affects the versions of coreutils as shipped with Red Hat Enterprise Linux 6 and 7. Red Hat Product Security has rated this issue as having Moderate security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
Notes: - There has been kernel side discussion, with a patch proposal, to prevent unprivileged users to issue TIOCSTI ioctl. However, so far, the patchset has not been merged: https://patchwork.kernel.org/patch/9753697/ - since v2.31, util-linux has added a --pty option (currently non-default), to prevent these attacks in runuser and su, via a setsid() call.