COMMAND
/dev/pts
SYSTEMS AFFECTED
RedHat 6.0
PROBLEM
noc-wage once again come up with another trivial DoS flaw, (wow,
seems to be good at this Conseal Firewall, +++ath0, ppp
byte-stuffing). Many of you RedHat 6.0 users who installed
RedHat 6.0 rather than upgrading may have noticed the new way
RedHat displays remote TTY's. Instead of the old fashioned
/dev/ttyp<number>, it now uses /dev/pts/<number>. There is a flaw
in this new implementation that local users can exploit to cause
minor disruption to anyone using X-windows on the local machine.
This DoS is more of a nuisance than a "real problem" but it could
possibly be used to cause some minor havok.
The way it works is simple. When whoever is using X opens up an
"xterm" (eterm, rxvt, nxterm...) a connection is made to the X
server. If you do a "who" you will see:
(RedHat 6.0, without upgrading from previous RedHat release)
wage pts/0 Jun 6 01:39 (:0.0)
Or on older versions:
wage ttyp0 Jun 6 01:39 (:0.0)
Now this is normal, but the problem lies within the permissions
of that device. On older RedHat's if you did:
ls -l /dev/ttyp3
crw------- 1 wage tty 3, 0 Jun 6 12:41 /dev/ttyp0
Which is normal and what it should look like. For those of you
who may be new to unix those letters at the beginning of the line
indicate the permissions on the device. For our output above, the
line indicates it is a device (c), and that the OWNER has read
and write permissions (rw) Group has no permissions (---), and
everyone has no permissions (---). They basically go
<type indicator><owner><group><everyone>
An example line of a device will ALL permissions set follows:
crwxrwxrwx
/ | \
Owner Group Everyone
This means that everyone has read/write/execute permissions to
that device. So as you can see our ttyp0 can only be read or
written to by it's owner (and root). In the case of RedHat 6.0
with regular remote connections (like telnet) the standard
permissions are as follows:
crw--w---- 1 ov3r tty 136, 0 Jun 6 12:32 /dev/pts/0
Here it's almost the same except that group "tty" also has write
access. The problem lies in the way that the permissions are set
for local connections with the X server using xterm. if you do
an ls -l /dev/pts/<the xterm's tty> (we will use pts/0) You get:
crw--w--w- 1 ov3r ov3r 136, 0 Jun 6 12:32 /dev/pts/0
Notice how now "everyone" has write access to this terminal?
This leads to the hole that any local user can disrupt any
xterminal connected to the local machine. Simply typing
cat /dev/urandom > /dev/pts/<number>
will flood the xterm with garbage data making it impossible to
use. Or we can also bring back the old "flash" attack and flash
the user's xterm by dumping ASCII escape characters to his
terminal. This isn't a particularily "deadly" DoS attack, but
can be used as a nuisance OR perhaps even to trick the user into
doing something he may not want to do. (For example dumping
"Login:" then "Password:" to the terminal may trick the user into
adding his login/password to a file or to his .bash_history).
Same was confirmed on Red Hat 6.0 system (with the 2.2.5-22 kernel
upgrade from Red Hat) when using a "gnome-terminal", as opposed
to "xterm" or "nxterm". All 3 types of terminals use the
/dev/pts/(number) with this version of Red Hat 6.0, but it looks
like if you launch an "xterm" or "nxterm" the permissions for
those terminal windows are set like this:
crw--w---- 1 stoddard stoddard 136, 0 Jun 7 23:44 0
This would appear to give only my user login and group "stoddard"
(on tested system, that group only has one user) write access to
that terminal window. It appears that the problem is with the
"gnome-terminal" program, part of the "gnome-core" RPM from the
Red Hat 6.0 install (specifically, on my system, that would be
gnome-core-1.0.4-34.i386.rpm), that is susceptible to the attacks
mentioned in the previosly (able to do the "cat /dev/urandom >
/dev/pts/(number)" and see the random stream of characters on that
window).
This problem applayes also to Midnight Commander both under X
and text mode.
SOLUTION
You can disable it from the /etc/fstab by commenting the /dev/pts
and redhat will use the default /dev/tty. In /etc/fstab:
none /dev/pts devpts gid=5,mode=620 0 0
This is not sufficient when using rxvt and apparently several
other xterm-a-likes. By default rxvt overides the gid with the
user's gid and changes the permissions to 622, even if the
permissions specified in fstab are more restrictive than 622.
The solution with rxvt is to pass --enable-ttygid to the configure
script.
If compiled with USE_TTY_GROUP defined, xterm checks for the "tty"
group. If it exists, the permissions on the terminal device are
set to 0620. If it does not exist, or if USE_TTY_GROUP is not
defined, the permissions are set to 0622. You can fix this by
either recompiling with USE_TTY_GROUP defined, or by editing
main.c and changing the permissions there.
Under kde this problem applyes to rxwt, but not to kvt, xterm and
nxterm.
Since Eterm was mentioned, let's go ahead and say this. If Eterm
is has sufficient permissions (either by being installed setuid
root or by being executed by the owner of the tty), it will
change the ownership and permissions on the device to 0620. If
it cannot change the permissions on the device, any
vulnerabilities resulting therefrom are the responsibility of the
system administrator. No current version of Eterm sets the
permissions on any device file to 0622 under Linux so skip that.
New dev, rxvt, and screen packages are available that fix a
security issue with the packages that originally shipped with
Red Hat Linux 6.0. RPMs required:
Intel: ftp://updates.redhat.com/6.0/i386/
dev-2.7.7-2.i386.rpm
rxvt-2.6.0-2.i386.rpm
screen-3.7.6-9.i386.rpm
Alpha: ftp://updates.redhat.com/6.0/alpha/
dev-2.7.7-2.alpha.rpm
rxvt-2.6.0-2.alpha.rpm
screen-3.7.6-9.alpha.rpm
Sparc: ftp://updates.redhat.com/6.0/sparc/
dev-2.7.7-2.sparc.rpm
rxvt-2.6.0-2.sparc.rpm
screen-3.7.6-9.sparc.rpm
While the post-install script for the dev package will add the
correct permissions for the /dev/pts file system in the
/etc/fstab file, you will have to manually unmount and remount
the /dev/pts file system with the following commands, once the
correct permissions have been set in the /etc/fstab file:
umount /dev/pts
mount /dev/pts
If you get the error message "umount: /dev/pts: device is busy"
when trying to unmount the filesystem, you will have to close
all connections using the filesystem, such as screen, xterm
(and other such X terminal programs), and some remote
connections.