Bug 3025 - /dev/pts has global write permissions
Summary: /dev/pts has global write permissions
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matt Wilson
QA Contact:
: 2611 3326 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 1999-05-25 03:56 UTC by H. Peter Anvin
Modified: 2017-01-04 22:39 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-06-17 14:52:04 UTC

Attachments (Terms of Use)

Description H. Peter Anvin 1999-05-25 03:56:49 UTC
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

Comment 1 Chris Evans 1999-06-03 20:47:59 UTC
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.

Comment 2 Bill Nottingham 1999-06-15 22:09:59 UTC
*** 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
RH6.0 security.

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 dkl  05/07/99 14:04 -------
This has been assigned to a developer for further review.

------- Additional Comments From gafton  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 chris.ox.ac.uk  05/09/99 07:12 -------
Hi Cristian,

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
attackers choice...

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 carenas.pe  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
on %Build,

seems like screen is also affected, and kvt (from KDE) doesn't even
honour the new Unix98 pty

Comment 3 Bill Nottingham 1999-06-16 17:08:59 UTC
*** 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
Service flaw,
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
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
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
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
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
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
permissions (---)
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
to that
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
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
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

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
his .bash_history).

------- Additional Comments From dale  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
you exit.

Comment 4 Bill Nottingham 1999-06-17 14:52:59 UTC
Fixed in errata releases:

Comment 5 openshift-github-bot 2017-01-04 22:39:40 UTC
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

Note You need to log in before you can comment on or make changes to this bug.