Summary: X11 is the protocol that underlies your graphical desktop environment, and you need to be aware of its security model.

A friend of mine decided to finally get a computer recently. He's one of those people who is very bright, he just didn't have the need for one before.[1] Being a very intelligent and worldly guy, he naturally wanted a Linux box.

After a few months of hardware problems[2] we installed Knoppix to the hard drive. Knoppix is a bootable CD distribution based on Debian and has the best hardware auto configuration out there. Plus, it's based on Debian, a huge plus in my book.

After getting everything set up for him, configuring Mozilla, twiddling his desktop, etc, he took it home. Naturally, being a new user, some mistakes were made, and the technical support desk (read: me) was called in.

So here's the first problem: they turn their computer off at night, making it much harder for me to troubleshoot it at 3am. I wanted a quick way to leave them a note to tell them I'm planning on working on it that evening. Since email was the thing that was broken, I didn't want to send email, and I didn't want to wake up their kid by calling.

Seemed the easiest thing to do would be to just plop a message up on their screen. Here's where we get into the X11 security model.[3] X11 is the engine of whatever graphical user environment you have. For example metacity, kwm, fvwm, IceWM, fluxbox, sawfish, are all window managers that live on top of X11, and help decide what the boarders of windows look like, how they're iconified, and the like. Your applications, like Mozilla, terminals, the Gimp, are all X11 applications - they create windows and get input from user keys and mouse movements by interacting with the underlying X11 library routines.

The X11 server has an amazingly simplistic and abusable security model. In modern installations, there are only two things you need to know to be able to connect to the X11 server:

DISPLAY

The Display number is typically something like :0 or :1, which mean "the first X11 display on the local machine" and "the second X11 display on the local machine" respectively. The display is stored in the environment variable DISPLAY, and any X11 application uses this variable to determine how to contact the X11 server and show it's windows when it starts up.

If your X11 server is listening on the network, then people can contact it from outside your computer. The first display :0 lives on port 6000, the second on 6001, etc:

    $ netstat -natp |grep :600
    tcp   0 0   0.0.0.0:6000     0.0.0.0:*    LISTEN   1029/X11

Here we see that X11 (process 1029) is listening on port 6000. A remote machine can attempt to connect and use this server.

Not all X11 servers listen on the network by default any more -- this is a very good thing. The server also will listen on a unix socket, which is equivalent to a TCP port except it's available via a file on the local machine. Processes can connect to it only if they are on this machine, which makes this avenue unavailable from outside machines. If my DISPLAY variable is set to :0, then the underlying X11 calls in my applications will find the appropriate socket on their own. For example on this Knoppix box, it keeps the socket in the /tmp directory:

    $ ls -l /tmp/.X11-unix/
    srwxrwxrwx 1 root     root      0 Jan 21 11:51 /tmp/.X11-unix/X0

X11 Magic Cookie

Once a client (be it local or remote) is able to connect to an X11 server, any modern X11 server will require that the client application prove it's authorized to connect. When the server is started, it has a list of xauth(1) cookies (random strings) that are authorized -- if the client can provide one of them, then the connection is allowed, else it's dropped.

These cookies are stored in your home directory, and can be viewed using the xauth(1) program:

    $ cd $HOME
    $ ls -l .Xauthority
    -rw------- 1 fernando twins 152 Jan 21 11:52 /home/fernando/.Xauthority
  
    $ xauth list
    dingo/unix:10 MIT-MAGIC-COOKIE-1 566e1128ce92a0126587cf30f4e19815
    dingo/unix:0 MIT-MAGIC-COOKIE-1 d506c80eb23511a2c28ce9242810c132
    dingo:0 MIT-MAGIC-COOKIE-1 d506c80eb23511a2c28ce9242810c132

So remember, the goal is to put something on his screen, even though I'm sitting across the city connected via SSH. After logging in and becoming root (I'll need that later), let's set my DISPLAY variable. Using ls in /tmp/.X11-unix, or netstat I can easily determine that he's running on screen #0, which is not a surprise at all.

    # DISPLAY=:0
    # export DISPLAY

Now I need to get access to his magic cookies. Since I'm root, I can read all files on the filesystem, so I just need to let the underlying X11 calls know where "my" .Xauthority file lives:

    # xauth list
    xauth:  creating new authority file /root/.Xauthority
  
    # XAUTHORITY=/home/fernando/.Xauthority
    # export XAUTHORITY
  
    # xauth list
    dingo/unix:10 MIT-MAGIC-COOKIE-1 566e1128ce92a0126587cf30f4e19815
    dingo/unix:0 MIT-MAGIC-COOKIE-1 d506c80eb23511a2c28ce9242810c132
    dingo:0 MIT-MAGIC-COOKIE-1 d506c80eb23511a2c28ce9242810c132

Bingo! Now xauth, and by extension all X11 applications, will use that .Xauthority file.

I should now have access to his X11 server. Indeed, if I run xclock from the command line, it just sits there, rather than complaining about being unable to connect to the screen and exiting, so I assume it's working. So, I whip up a quick shell script to let me show a file to him on an xterm so I can leave him notes on the screen. I'm sure there's a good program for this sort of thing already, so if anyone knows what it is let me know.

Here's my terribly boring shell script.

    # cat shownote
    #!/bin/sh
  
    if [ "$#" -gt "2" ] ; then
            echo "Usage: $0 filename" >&2
            exit 1
    fi
    
    if [ -z "$2" ] ; then
            nohup xterm -e $0 $1 blah >/dev/null 2>&1 &
            exit;
    fi
    
    if [ -z "$1" ] ; then
            echo "Usage: $0 filename" >&2
            exit 1
    fi
    
    cat $1
    sleep +1d
  
    
    # shownote /tmp/dont_turn_machine_off.txt & 

It takes a filename, and then opens an xterm that shows that file in it via cat. Simplistic but easy.

The key here is that I should not be allowed to show things on his X11 server -- if I can, I can do other nastier things. Next time, we'll see some of the more interesting things that are possible. If you have favourites in your arsenal, let me know and I'll try to include them!

NOTES:

[1] To some of us, having a computer is a need, just like breathing. Sometimes breathing is run at a higher nice(1)ness level, for that matter.

[2] Damned be to Microtel!

[3] You didn't think I was going to just ramble on the whole time, did you?

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He looks back on his college days of playing xtank at 3am and wonders "Did anyone steal my passwords when we all ran 'xhost +' " ? Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2004

This is the May 13, 2004 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.