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 default).
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. *** Hi! /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 Cheers Chris ------- 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 effectively. ------- 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
*** 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, (wow, I seem to be good at this Conseal Firewall, +++ath0, ppp byte-stuffing) 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 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 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 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). ------- 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.
Fixed in errata releases: dev-2.7.7-2 rxvt-2.6.0-2 screen-3.6.7-9
Commit pushed to master at https://github.com/openshift/openshift-ansible https://github.com/openshift/openshift-ansible/commit/71ae12fc775d4606a66959eb45def687ba716a28 Merge pull request #3040 from sdodson/issue3025 Enable repos defined in openshift_additional_repos by default