Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ