Red Hat Bugzilla – Bug 3025
/dev/pts has global write permissions
Last modified: 2017-01-04 17:39:40 EST
The RedHat installer, at least when doing an upgrade (from
5.2), creates an /etc/fstab entry for /dev/pts with
mode=622. The appropriate options for RedHat (which uses a
tty group with gid 5) are either mode=620,gid=5 (mesg y by
default) or for extra paranoia mode=600,gid=5 (mesg n by
I logged a duplicate bug a while back.
Even with the /dec/pts permissions set properly, screen and rxvt
seemed to insist on chmod'ing the pty to world write. xterm, nxterm
and login behave.
Fixing this problem properly probably involves fixing screen and rxvt
as well as permissions /dev/pts is mounted with.
*** Bug 2611 has been marked as a duplicate of this bug. ***
/dev/pts is mounted "mode=0622". This is WRONG - it bypasses
the security on write. /dev/pts _should_ be mounted
"mode=0620,gid=5" (gid 5 is tty on the system)
The problem is worse though - xterm and nxterm work properly
with the above change, as do telnet logins. Unfortunately
screen and rxvt (maybe others) change the /dev/pts
permissions such that everyone has write acess and the
group is the user's group NOT tty.
Aside from this slip up I have been VERY impressed with
Re-reading my message I'm not sure I've been clear - drop me
a note if any clarification is needed. Sorry about the duff
package too but /etc/fstab isn't owned by any package
------- Additional Comments From email@example.com 05/07/99 14:04 -------
This has been assigned to a developer for further review.
------- Additional Comments From firstname.lastname@example.org 05/09/99 02:39 -------
I don;t really think this is a security problem - this is no change
from the previous ttyp* devices permissions. If somebody enables 'mesg
y' on their console they are open to a DOS. This will be probably be
handled more tightly in the future, but that will require engineering
in a lot of places to get it right.
For now, 'mesg n' takes care of all the problems. We will address this
issue in a next release, though. I am marking the bug as 'later' - we
will look back at it and fix it when we have a full understanding of
all the places we have to look at to take care of this problem
------- Additional Comments From email@example.com 05/09/99 07:12 -------
Sorry to be awkward but I must disagree with your comment "no changes
from the previous device permissions".
If I telnet to RH5.2 system I see
/dev/ttyp8 crw--w---- chris tty
On RH6.0 I see
/dev/pts/0 crw--w--w- chris chris
The difference is crucial; under RH6.0 a malicious user can send any
arbitrary character stream to a tty. Some terminals can be
reprogrammed so a given key can be made to map to a sequence of the
Under RH5.2 only the "write" program (and talkd) has sufficient
privilege to send text to tty's - and the "write" program filters out
malicious sequences AFAIK.
So RH6.0 represents a lowering in tty security :-) To fix this isn't
too bad; the line for the /dev/pts filesystem in fstab needs changing
as I originally suggest. Also, screen and rxvt need to be made to
desist from changing the pty permissions from 0620 to 0622.
As an aside note that console logins on RH6.0 get the tty1/tty?
permissions correct e.g.
/dev/tty1 crw--w---- chris tty
------- Additional Comments From firstname.lastname@example.org 06/11/99 11:42 -------
Hi, i've tested this agains't my redhat 6.0 box and the solution
pointed by chris works well against, xterm, telnet, nxterm,
gnome-terminal and kterm
rxvt needs a simple patch to honour the tty group, you could get the
(S)RPMS (unsigned) for ftp://ftp.lared.net.pe/pub/linux/carenas, or
you can build your own.. adding --enable-ttygid on the configure call
seems like screen is also affected, and kvt (from KDE) doesn't even
honour the new Unix98 pty
*** Bug 3326 has been marked as a duplicate of this bug. ***
This message was recently submitted to bugtraq:
Just in case anyone missed it! :-)
Once again I've come up with another trivial Denial of
I seem to be good at this Conseal Firewall, +++ath0, ppp
It's been a few months since my last DoS, so here you go:
Many of you RedHat 6.0 users who installed RedHat 6.0
upgrading may have noticed the new way RedHat displays
Instead of the old fashioned /dev/ttyp<number>, it now uses
/dev/pts/<number>. There is a flaw in this new
users can exploit to cause minor disruption to anyone using
the local machine.
This DoS is more of a nuisance than a "real problem" but it
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
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
On older RedHat's if you did:
ls -l /dev/ttyp3 you would see:
crw------- 1 wage tty 3, 0 Jun 6
Which is normal and what it should look like.
For those of you who may be new to unix those letters at
the line indicate the permissions on the device.
For our output above, the line indicates it is a device
(c), and that
OWNER has read and write permissions (rw)
Group has no permissions (---), and everyone has no
They basically go <type indicator><owner><group><everyone>
An example line of a device will ALL permissions set
/ | \
Owner Group Everyone
This means that everyone has read/write/execute permissions
So as you can see our ttyp0 can only be read or written to
by it's owner
In the case of RedHat 6.0 with regular remote connections
the standard permissions are as follows:
crw--w---- 1 ov3r tty 136, 0 Jun 6
Here it's almost the same except that group "tty" also has
The problem lies in the way that the permissions are set
connections with the X server using xterm.
if you do an ls -l /dev/pts/<the xterm's tty> (we will use
crw--w--w- 1 ov3r ov3r 136, 0 Jun 6
Notice how now "everyone" has write access to this terminal?
This leads to the hole that any local user can disrupt any
connected to the local machine. Simply
typing "cat /dev/urandom >
/dev/pts/<number>" will flood the xterm with garbage data
impossible to use. Or we can also bring back the
old "flash" attack and
flash the user's xterm by dumping ASCII escape characters
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
------- Additional Comments From email@example.com 06/09/99 11:32 -------
Confirmed on Gnome-Terminal, rxvt, and xterm. One peculiarity is that
if you "su" while in the terminal, and no other terminals are open on
your machine, permissions change to crw-------, and stay that way when
Fixed in errata releases:
Commit pushed to master at https://github.com/openshift/openshift-ansible
Merge pull request #3040 from sdodson/issue3025
Enable repos defined in openshift_additional_repos by default