Bugtraq mailing list archives
Re: X11 cookie hijacker
From: dawes () XFREE86 ORG (David Dawes)
Date: Tue, 3 Nov 1998 18:13:54 +1100
On Mon, Nov 02, 1998 at 11:04:43PM +0100, Pavel Kankovsky wrote:
drwxrwxrwx 2 root root 1024 Oct 30 19:57 /tmp/.X11-unixHang 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
Current thread:
- X11 cookie hijacker Pavel Kankovsky (Nov 02)
- SSHD Exploit Justin Foutts (Nov 01)
- ISS Security Advisory: BMC PATROL File Creation Vulnerability X-Force (Nov 02)
- Re: X11 cookie hijacker David Dawes (Nov 02)
- Re: X11 cookie hijacker Alan Cox (Nov 03)
- Re: X11 cookie hijacker Olaf Kirch (Nov 05)
- [rootshell] Security Bulletin #25 Aleph One (Nov 03)
- Re: X11 cookie hijacker Willy TARREAU (Nov 04)
- Re: X11 cookie hijacker Casper Dik (Nov 04)
- <Possible follow-ups>
- Re: X11 cookie hijacker der Mouse (Nov 04)
- Regarding the reported DOS against the internal interface of a WatchGuard Rapid Response (Nov 04)
- IE 4.x does not appear to save custom security settings John Schultz (Nov 04)
- Re: X11 cookie hijacker David Dawes (Nov 04)
- xlock mishandles malformed .signature/.plan Aaron Campbell (Nov 04)
(Thread continues...)