Hi, Max. Thank you for the warning. I observe the problem here, on two PCs on which I installed Red Hat 6.0 from scratch. However, it doesn't happen for me with xterm or nxterm, only with rxvt. I ran them all in X sessions that I started via xdm. I was also logged in via mingetty. [trevor@localhost trevor]$ ps uaxw|grep xterm|grep -v grep trevor 738 0.0 1.4 2844 1808 ? S 22:54 0:00 nxterm trevor 760 0.0 1.3 2812 1700 pts/0 S 23:02 0:00 xterm -rv -sb [trevor@localhost trevor]$ ps uaxw|grep rxvt|grep -v grep trevor 862 0.0 0.8 1932 1032 pts/0 S 23:36 0:00 rxvt [trevor@localhost trevor]$ who trevor tty1 Jun 7 21:22 trevor tty2 Jun 7 21:36 trevor tty3 Jun 7 21:49 trevor tty4 Jun 7 22:03 trevor tty5 Jun 7 22:06 trevor tty6 Jun 7 22:08 trevor :0 Jun 7 21:21 [trevor@localhost trevor]$ ls -l /dev/pts total 0 crw--w---- 1 trevor trevor 136, 0 Jun 7 23:36 0 crw--w---- 1 trevor trevor 136, 1 Jun 7 23:29 1 crw--w--w- 1 trevor trevor 136, 2 Jun 7 23:36 2 [trevor@localhost trevor]$ grep tty /etc/group tty::5: [trevor@localhost trevor]$ rpm -qf `which xterm` `which nxterm` XFree86-3.3.3.1-49 XFree86-3.3.3.1-49 [trevor@localhost trevor]$ rpm -qa|grep rxvt rxvt-2.6.PRE2-5 [trevor@localhost trevor]$ cat /proc/version Linux version 2.2.5-15 (rootat_private) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Apr 19 23:00:46 EDT 1999 [trevor@localhost trevor]$ ls -l `which rxvt` `which xterm` `which nxterm` -rwxr-xr-x 2 root root 159080 Apr 18 16:33 /usr/X11R6/bin/nxterm -rwxr-xr-x 1 root root 77920 Mar 26 12:53 /usr/X11R6/bin/rxvt -rwxr-xr-x 2 root root 159080 Apr 18 16:33 /usr/X11R6/bin/xterm [trevor@localhost trevor]$ rpm -qa|grep ^glibc glibc-devel-2.1.1-6 glibc-2.1.1-6 When I killed the rxvt, the mode 622 pty went away. When I ran rxvt twice, there were two such bad ptys. > 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. [...] > 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). __ Trevor Johnson
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:48:25 PDT