The ease of using X11 ab

The ease of using X11 ab

The ease of (ab)using X11

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

A friend 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, Gnome, KDE, 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 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!
...Brian Hatch - Onsight

Internet Security News Home