Re: Access to /dev/pts devices via pt_chown and user namespaces

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> http://www.halfdog.net/Security/2015/PtChownArbitraryPtsAccessViaUserNamespace/

> http://www.openwall.com/lists/oss-security/2016/02/23/3

> ... condition can be easily created by creating an user namespace,
> mounting devpts with the newinstance option, create master and slave
> pts pairs until the number overlaps with a target pts outside the
> namespace on the host, where there is interest to gain ownership and
> then invoke pt_chown.
>
> ... intercept all keystrokes and display faked output from
> commands never really executed.


> > http://www.openwall.com/lists/oss-security/2016/02/23/7

> > glibc documentation clearly states that "the use of pt_chown introduces
> > additional security risks to the system and you should enable it only
> > if you understand and accept those risks":
> > https://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html#index-grantpt-1


> > > http://www.openwall.com/lists/oss-security/2016/02/24/5

> > > So for pt_chown, this could hopefully be
> > > just an Ubuntu issue. Should we assign an CVE for that?

> > > > http://www.openwall.com/lists/oss-security/2016/02/24/10
> > > > And Debian 8

We think this is currently the best option. Use CVE-2016-2856. This
CVE is about the specific pt_chown finding in the
PtChownArbitraryPtsAccessViaUserNamespace document. Also, we do not
want this to be considered an upstream glibc vulnerability.

(In addition, this CVE is not about whether the pt_chown program
should exist at all, or about whether all users should be able to
create user namespaces. Each of those is an important security topic,
but the importance is a consequence of multiple issues that could be
associated with multiple CVEs.)

The initial CVE-2016-2856 description might look roughly like:

   pt_chown in the glibc package before 2.19-18+deb8u4 on Debian
   jessie lacks a namespace check associated with file-descriptor
   passing, which allows local users to capture keystrokes and spoof
   data, and possibly gain privileges, via pts read and write
   operations, related to debian/sysdeps/linux.mk. NOTE: this is not
   considered a vulnerability in the upstream GNU C Library because
   the upstream documentation has a clear security recommendation
   against the --enable-pt_chown option.

See the
http://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?h=jessie&id=09f7764882a81e13e7b5d87d715412283a6ce403
and
http://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?h=jessie&id=11475c083282c1582c4dd72eecfcb2b7d308c958
commits. Here, Debian jessie is just an example; a similar statement
might be made about Ubuntu Wily Werewolf, etc. The
09f7764882a81e13e7b5d87d715412283a6ce403 commit can be associated with
(at least) two CVE IDs that motivated the change: CVE-2013-2207 (which
is directly mentioned there) and the new CVE-2016-2856.


> > > On the other hand, the TIOCGPTN ioctl still is problematic with
> > > USERNS, also for other tools. I just started with pt_chown for
> > > demonstration because it is SUID, perhaps there are other programs
> > > using this ioctl.
> > >
> > > Should information about this risk/attack method just be added to the
> > > kernel docs/man-page of TIOCGPTN or is it a separate vulnerability
> > > with need for addressing (another CVE?).

We don't feel that enough information has been sent to reach a
conclusion about whether the "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" recommendation should have a CVE ID. We could, for example,
assign separate CVE IDs to other affected applications (if any)
instead.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
  http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJW3ODUAAoJEL54rhJi8gl5zaUP/RRwv6Npic0DYvGFwqCQZq9v
hH5QeGvA6ZYCETdAfsN73wmZ9GlhiXMWwTprDf4Zq3r5yfTzfFzrN7f5hu1hTOPa
/Eonam4l+OML+IymPl85e0wqifeVyJAQj1mk1KYB9tk5jBYcxxARpI3RRt7iC0Jp
+HLo7ayQcEmIE+6XxcVW0C4A5ahBFq75mceqPdJmluNmcBQxx5RHGvJPVeAAAEQA
ccFyqR1lCHlU29WifN99KUjrBzIzR/WzJFvmyL+g8fD7/nA4iT08S8wQf9HbPncv
puFdPn0q23bRwHtH0uOjpdG6V4rWFgSreZW8r+U6xeDYO1yk+uVL1I99s+/0iquH
ghlU4JtbKt8v4nBobh8JGrwdncdpvvS5ojZ9KPVgeBPhe1LAUQRKqiiaAsjRtlDl
tCdIsTnMYV530D9ykw6c82am7Y2ZAW9Tiov6Ug9fHsItAaWMiNzl+AXSMZ6qRPSK
vw0zLIOn4xh9dMKr9VbXN1WX/i/aR6Nbn2ZE7rSF8UlPlff83UeFYhVJ+20iAMXq
sDINreZzpcXRITlsX7h7BDumyrYbNcwNgQMqp9YYV35nA8i4FJubGGHzUAlhrdIh
UF7k+w7nmFN/kgsE0I6Lyi1Ow04F1KvsJfM4+aV/032liDxle7XPl6sZwsOlH7p0
uUXK4WJDDt3SBJQIap5W
=YYhd
-----END PGP SIGNATURE-----