Red Hat Bugzilla – Bug 1312863
CVE-2016-2781 coreutils: Non-privileged session can escape to the parent session in chroot
Last modified: 2017-08-30 10:18:44 EDT
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.
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().
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:
(In reply to Kamil Dudka from comment #13)
> coreutils upstream has applied a similar patch (using libseccomp) on runcon:
coreutils upstream has reverted the above patch: