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.