Date: Tue, 23 Feb 2016 19:17:54 +0300 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: Access to /dev/pts devices via pt_chown and user namespaces On Tue, Feb 23, 2016 at 12:03:54PM +0000, halfdog wrote: > Sending content from  also to oss-security as requested last time: Thank you. This public disclosure is very late, though. I didn't realize you were still holding some of your findings on this. > With Ubuntu Wily and earlier, /usr/lib/pt_chown was used to change > ownership of slave pts devices in /dev/pts to the same uid holding the > master file descriptor for the slave. I think pt_chown is only needed for legacy BSD pty's, and no longer needed for Unix 98 pty's that Linux systems use these days. Perhaps it should be dropped from upstream glibc by now. e.g. on Owl we haven't been installing it SUID ever (as it was already legacy 15 years ago), and we haven't been packaging it at all since 2005. > In my opinion, this security bug should be fixed two-fold: At first, > kernel should prevent the TIOCGPTN ioctl when invoked called by a > process within one namespace but acting on a filedescriptor from a > devpts instance mounted in a different namespace. Additionally > pt_chown should check via readlink and stat, that the passed file > descriptor really was from the /dev/ptmx or /dev/pts/ptmx device > present in the same namespace as the /dev/pts/[num] device is > residing. This of course is only relevant if pt_chown is going to > survive on recent namespace aware systems. I think the primary fixes should be different: disable unprivileged user namespaces by default, and drop pt_chown. > Timeline: > ========= > > 20151220: Discovery > 20151227: Report at Ubuntu Launchpad1529486 > 20160104: Report to distros list > 20160122: Patch to disable unprivileged userns due to this and > other issues LKML > 20160222: CRD and publication Ouch. As you're aware, everything you report to distros must be made public in at most 2 weeks. Unfortunately, I didn't keep track of this, and I don't recall if your report to distros included the detail you're disclosing just today. I thought you had already disclosed whatever was on distros here: http://www.openwall.com/lists/oss-security/2016/01/19/17 Now I see you were asking for advice on further handling of these issues in there, and got no replies. :-( I think going forward, you shouldn't make any use of the distros list, and should post to oss-security right away. > References: > =========== > >  > http://www.halfdog.net/Security/2015/PtChownArbitraryPtsAccessViaUserNamespace/ >  > http://www.halfdog.net/Security/2016/OverlayfsOverFusePrivilegeEscalation/ In , "LKML" points to: https://lkml.org/lkml/2016/1/22/7 Unfortunately, that archive of LKML is currently broken (doesn't display the actual message to me), so I don't know what exactly this was. I did, however, watch the discussion CC'ed to kernel-hardening, where Kees Cook proposed "sysctl: allow CLONE_NEWUSER to be disabled": http://www.openwall.com/lists/kernel-hardening/2016/01/22/19 http://www.openwall.com/lists/kernel-hardening/2016/01/22/20 http://www.openwall.com/lists/kernel-hardening/2016/01/22/21 Unfortunately, this was NAK'ed by the maintainer, Eric W. Biederman: http://www.openwall.com/lists/kernel-hardening/2016/01/23/4 http://www.openwall.com/lists/kernel-hardening/2016/01/25/11 http://www.openwall.com/lists/kernel-hardening/2016/01/26/7 Eric suggested "a per user limit on the number of user namespaces users may create". There was some further discussion after that point, but no clear outcome. Last message posted on January 28. If there's no clear decision upstream, distros must do what they must - disable unprivileged userns ASAP, in whatever way they can. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ