[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 6 Mar 2016 21:03:38 -0500 (EST)
From: cve-assign@...re.org
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: Re: Access to /dev/pts devices via pt_chown and user namespaces
-----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-----
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.
