[10756] in bugtraq
Re: RedHat 6.0, /dev/pts permissions bug when using xterm
daemon@ATHENA.MIT.EDU (Zack)
Tue Jun 8 14:20:16 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <375D51CD.CCAD108B@nwlink.com>
Date: Tue, 8 Jun 1999 10:24:29 -0700
Reply-To: desync@nwlink.com
From: Zack <desync@NWLINK.COM>
X-To: sacha faust <sfaust@ISI-MTL.COM>
To: BUGTRAQ@NETSPACE.ORG
in /etc/fstab:
none /dev/pts devpts gid=5,mode=620 0 0
sacha faust wrote:
>
> you can desable it from the /etc/fstab by commenting the /dev/pts and
> redhat will use the default /dev/tty . I think Solaris use the /dev/pts and
> with proper
> permissions.
>
> -----Original Message-----
> From: noc-wage <wage@IDIRECT.CA>
> To: BUGTRAQ@NETSPACE.ORG <BUGTRAQ@NETSPACE.ORG>
> Date: 7 juin, 1999 13:19
> Subject: RedHat 6.0, /dev/pts permissions bug when using xterm
>
> >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).
> >
> >
> >--
> >Max Schau (noc-wage) <wage@idirect.ca>/<nocwage@globalserve.net>
> >KeyID 1024/0F699BD3
> >"The only secure computer is one that's unplugged, locked in a
> >safe, and buried 20 feet under the ground in a secret location...
> >and i'm not even too sure about that one"--Dennis Huges, FBI
--
---------------------{*}-----------------------
The sand castle is being washed out by the sea.
-----------------------------------------------
