Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun,  6 Mar 2016 21:03:38 -0500 (EST)
Subject: Re: Access to /dev/pts devices via pt_chown and user namespaces

Hash: SHA256



> ... 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.


>> 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":


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

>>>> 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/ 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
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)

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


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.