[8382] in bugtraq
Re: X11 cookie hijacker
daemon@ATHENA.MIT.EDU (David Dawes)
Tue Nov 3 20:45:51 1998
Date: Tue, 3 Nov 1998 18:13:54 +1100
Reply-To: David Dawes <dawes@XFREE86.ORG>
From: David Dawes <dawes@XFREE86.ORG>
X-To: peak@kerberos.troja.mff.cuni.cz
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19981102213202.4734.0@kerberos.troja.mff.cuni.cz>; from Pavel
Kankovsky on Mon, Nov 02, 1998 at 11:04:43PM +0100
On Mon, Nov 02, 1998 at 11:04:43PM +0100, Pavel Kankovsky wrote:
>> > > > drwxrwxrwx 2 root root 1024 Oct 30 19:57 /tmp/.X11-unix
>> > > Hang on, aren't those dangerous permissions?
>> > Pretty dangerous. Shall I look for my old cookie hijacker?
>> Please post the bloody thing to bugtraq. XFree appear myopic on this issue
XFree86 is still waiting for someone to come up with a real solution to the
problem.
>Evil grin. It has already been told a million times: you are asking for
>a problem if your /tmp/.X11-unix (and/or /tmp/.X11-pipe on Solaris) has
>the permission bits allowing other users to play games with its contents.
>
>Unfortunately, such setting is the default one
>excerpt from xc/lib/xtrans/Xtranslcl.c (XFree86 3.3.2 + all patches):
>
> #define X_UNIX_DIR "/tmp/.X11-unix"
>
> if (!mkdir(X_UNIX_DIR, 0777))
> chmod(X_UNIX_DIR, 0777);
>
>The program appended to this message demonstrates how dangerous it is.
>Any lamer could delete the socket cause denial of service but using this
>program, you can hijack X11 connections and steal magic cookies. (In fact
>anything in the protocol not protected against man-in-the-middle attack
>is vulnerable.) Having access to the X display of your victim, you can
>do whatever you like: from displaying "Boo!" all over the screen to
>complete takeover of the session and the victim's accounts, both local
>and remote.
>
>Potential solutions:
>
>- set the sticky bit on /tmp/.X11-unix, make sure the bit stays there
>- make it world-unwritable, make sure it stays this way (this works if
> all your Xservers run with some extra privileges)
Both of these require all X servers (and servers for the other services
you mention later) run with sufficient privileges). The first opens up
a DoS for servers that don't have sufficient privileges. XFree86, for
example, ships with three "servers" that are not normally run with
sufficient privileges (lbxproxy, Xnest, Xvfb).
>- special Solaris option: put /tmp/.X11-{unix,pipe} into /etc/logindevperm
> (assumption: the user sitting at the console is the only who uses X)
>- abolish Unix-domain X11 sockets and use TCP only (giving up MIT-SHM etc)
I assume from this list that you don't have a real solution? We've all
seen the "potential" solutions before. The problem doesn't still exist
because nobody cares about it. It still exists because nobody has, to
my knowledge, found a real solution to it.
>PS1: /tmp/.X11-unix is not alone. It has brothers: /tmp/.font-unix,
>/tmp/.XIM-unix, /tmp/.ICE-unix and God knows what else, and they ALL
>have this problem. It is
>
>PS2: What about TOG's R6.4?
No change there.
David
