ARCHIVED: What sorts of security concerns are there with the X Window System?

This document addresses security issues on the Indiana University Bloomington Computer Science Department Sun workstations. The general principles involved are applicable to most Unix installations of the X Window System.

Security of the X Window System

X is a wonderful, network-transparent windowing environment. However, the introduction of network accessibility introduces some new risks to the system. Fortunately, most of these risks are not too difficult to deal with.

Note: This information applies if you are using X on a workstation, such as one of the Ships or Burrow machines. Xterminals are somewhat different, and not covered here.)

X works by a server-client system; an X server process, which manages your display, is started up on your workstation, and numerous X clients (e.g., xterm, xclock, xbiff) attach to your X server and access your display. Since your server controls screen access, anybody who can connect to your X server with a client can access your display. The main security issue is controlling who can connect to your X server.

The default security mechanism is host-based access, via a program called xhost. Its description in the Xsecurity manual (which you should also read) states the following:

Host Access

Any client on a host in the host access control list is allowed access to the X server. This system can work reasonably well in an environment where everyone trusts everyone, or when only a single person can log into a given machine, and is easy to use when the list of hosts used is small. This system does not work well when multiple people can log into a single machine and mutual trust does not exist.

By default, the workstation you are using is the only host from which connections are permitted. Many people add other machines to their xhost list for convenience, such as Steel, moose, etc. Some people add every machine in the Ships lab to their xhost list, or (worst of all) just use xhost +, which allows anybody from anywhere in the universe to access their X server.

Obviously, with the multiuser workstations we have here, anybody (with an account, legitimate or not) can log into your workstation and access your X server if you use xhost. Xhost stands for "X hanging open -- security terrible."

Why this is undesirable

Anyone who can access your X server could perpetuate harmless, annoying, or quite damaging activity. A casual mischief-maker might simply do a "meltdown" on your display. Others might accidentally open an Emacs window on your display because they have something incorrect in their configuration, such as putting setenv DISPLAY `hostname`:0 in the .login file. Somebody might do an xkill or even xterminate to destroy any (or all) of your windows. Somebody might use a utility called XWatchWin to view the contents of any (or all) of your windows and see everything you are doing. Somebody might even quietly attach to your server and monitor all keyboard events, allowing a log to be made of everything you type while in X, including passwords. You might not even notice unless you specifically hunt for intrusions, and even so, they're difficult to spot.

What you can do

There are a number of ways to secure an X server, described in man Xsecurity. The mechanism described here is called MIT-MAGIC-COOKIE-1. There are stronger means of securing your server, but they are not sensible to use in the environment here.

Note: xdm is a display manager which isn't used here, so you may ignore those sections.

MIT-MAGIC-COOKIE-1

When using MIT-MAGIC-COOKIE-1, the client sends a 128 bit "cookie" along with the connection setup information. If the cookie presented by the client matches one that the X server has, the connection is allowed access. The cookie is chosen so that it is hard to guess; xdm generates such cookies automatically when this form of access control is used. The user's copy of the cookie is usually stored in the .Xauthority file in the home directory, although the environment variable XAUTHORITY can be used to specify an alternate location. Xdm automatically passes a cookie to the server for each new login session, and stores the cookie in the user file at login.

The cookie is transmitted on the network without encryption, so there is nothing to prevent a network snooper from obtaining the data and using it to gain access to the X server. This system is useful in an environment where many users are running applications on the same machine and want to avoid interference from each other, with the caveat that this control is only as good as the access control to the physical network. In environments where network-level snooping is difficult, this system can work reasonably well.

Thus, you have a 128 bit secret code, or cookie, which is stored in a file normally called .Xauthority. (See man xauth for more about managing this file.) There are a few issues regarding its use, however, that remain.

Generating cookies

There is a program called newcookie in /usr/bin/X11/newcookie, which will generate cookies for the current host. UITS does not recommend it, because its cookies are not very random, do not have enough significant bits, are passed as arguments in command calls (snoopable via a lucky ps), and most notably, are generated by a simple random number generator which uses the current time as a seed. Thus, any potential cracker who can figure out when the cookie was generated (by checking your login time, or the modification time of the .Xauthority file) can narrow the seed value down to a few possibilities and try them. You are more secure using xhost than you are using /usr/bin/X11/newcookie as a cookie generator; I have a (very short) algorithm which breaks cookies generated in this fashion.

There is another algorithm I have which uses the time in microseconds rather than seconds as a key; it is in /u/mvanheyn/bin/newcookie. I recommend it over the system newcookie. The key algorithm is a routine I hacked up called "cookiegen", in my bin directory (source is in my src directory). It's not a fantastic cookie generator, and a potential cracker might be able to narrow the search space down to "only" several million possibilities. There exist better cookie algorithms, like the one I use.

Normally, cookies are generated each time you log on; this allows them to change over time (so that somebody who steals your cookie somehow cannot use it next time) and allows the system to deal well with first logins (i.e. when you use a new workstation the first time.) You may want something in your .login along the lines of

  if ($TERM == sun) then
    /u/mvanheyn/bin/newcookie
  endif

which should handle everything rather nicely. (Feel free to check my stuff for a model, though I probably don't use the same login shell you do.)

Passing your cookie around

Your cookie must be known by all the machines which will be accessing your display; if you run xbiff on a different machine (e.g., Steel), your cookie will need to be passed over there.

The simplest way to achieve this is with xrsh, which can handle cookie-passing for you. Include near the top of your .xinitrc file:

  XRSH_AUTH_TYPE=xauth;export XRSH_AUTH_TYPE

Note: You also may wish to put xhost - near the top of your .xinitrc to ensure that xhost protocol is off.

This will do two good things for you: it will get xrsh to do the right thing (copy your cookie to another system you try to use via xrsh) and stop xrsh from doing the wrong thing (by default, xrsh will assume xhost protocol, and start adding machines to your xhost list, making you insecure again. For security to work, your xhost list must be empty.)

(Note: xrsh still can do some moderately stupid things with regard to passing cookies around; the above will work, but check my .xinitrc file for a somewhat more efficient method. In particular, xrsh doesn't check for exclusion on your .Xauthority file, so if you have two xrsh processes starting up simultaneously, it can screw up. This is probably only a problem if you have multiple xrsh commands in your .xinitrc. Xrsh also uses the <gagC shell to do things, which generally makes life unpleasant.)

If you have occasion to need to pass your cookie around manually rather than having xrsh do it, the cookie for the display foo:0 (normally just $DISPLAY) can be copied to the machine bar by the command:

  xauth extract - foo:0 | rsh bar xauth merge -

Your clients will automatically consult the file .Xauthority as long as your HOME environment variable is set properly. You still, however, need to deal with:

Telling your X server to use your cookie

Create a file called .xserverrc in your HOME; this file will be executed to start your X server (so be sure to chmod +x .xserverrc). Here is mine (more or less), which I stole from sahayman:

  #!/bin/sh
  exec X -auth $HOME/.Xauthority 

Supposedly, the -auth option also tells the X server that it should not include any hosts, even the local one, in the xhost list. I don't trust this, so I have xhost - in my .xinitrc.

How secure you are now

Nobody can now access your X server process as long as nobody can find out your cookie. Obviously, the file .Xauthority should be unreadable, your cookie generation algorithm should be unpredictable, and your xhost list should be empty. If somebody has an illicit network connection then he could monitor it and capture your cookie in transit, but illicit network connections could see the cookie as NFS sends it from the machine where your HOME is to your local workstation, so going to the DES-based XDM-AUTHORIZATION-1 makes little sense. Also, if somebody has already broken general security on the system (either your account or root), this system won't make you secure, although screen manipulation should be the least of your problems under such circumstances.

There still exist other layers to the system which are vulnerable to security breaks, but they are not as risky as the X layer. The fbtab file has been changed to secure configuration, so people can't circumvent your security by sneaking in at the framebuffer level or sabotage your session with things like clear_colormap or kbd_mode -a. The network layer might become insecure, in which case you may as well go home and give up on security (unless you really want to go to Sun's secure RPC setup for all transactions.) The human layer is still the biggest security problem though; don't choose a guessable password, don't have . as the first directory in your PATH (preferably don't have it at all), don't walk away from your workstation leaving yourself logged on... (although there is a method which lowers the risks from that; ask me about it.)

If you can't get magic cookies to work after all that, send me email and I might be able to help. Happy hunting, and remember, just because you're paranoid doesn't mean they're not out to get you... :-)

by Marc VanHeyningen (mvanheyn@cs.indiana.edu)