[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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 [0] 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:
> ===========
>
> [0]
> http://www.halfdog.net/Security/2015/PtChownArbitraryPtsAccessViaUserNamespace/
> [1]
> http://www.halfdog.net/Security/2016/OverlayfsOverFusePrivilegeEscalation/
In [0], "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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
