• Information Security Office
• Secure Computing
• Notes on X Window Security

Secure Computing: Notes on X Window Security

The X Window System underlies the graphical interface for all Unix and Linux platforms, and X Window server software that allows users of Microsoft Windows PCs or Macintoshes to interact over a network with graphical Linux and Unix client applications can also be vulnerable.

Overview

The most common X Window exploit attacks a vulnerability that has been well-known for at least ten years. (It's described on a SLAC web page dating from 1995.) It allows the attackers to capture keystrokes remotely - that means every single tap at the keyboard, including user account names and passwords - from compromised machines. The attackers use other compromised machines to gather this information, thus covering their tracks.

What's the Nature of the Vulnerability?

There are three important means by which you can secure your X server:

• Host access list: You specify IP addresses, user names, etc., for machines or other entities that are permitted to connect to your server. This method is no longer considered to be very secure, though it's far better than nothing.
• MIT magic cookies: Each X Window session, between each X Window server display and X client application, uses a session key to authenticate the client to the server. Unless an interloper is sniffing packets off your network - his hand in the cookie jar, so to speak - this method is pretty secure.
• SSH tunneling: This method uses magic cookies for authentication, and all communication between the client and server is encrypted as well. Obviously this is the most secure X Window configuration, supported by most all current operating systems and X Window server software.

Until the mid-1990s X Window server security, to the extent it existed, was based only on static lists of allowed IP addresses or user names for remote clients. The most common means of configuring such a list made use of a program called xhost. If the list of allowed users was improperly configured (that is, absent any other security measures, if the list was empty, which can be accomplished by configuring the list using the command xhost +), the X server was available to anyone.

A better method of configuring access to X servers uses the xauth program, which relies on so-called magic cookies (sometimes called MIT magic cookies, pseudo-random keys generated for each X Window session and stored in a file named .Xauthority typically in the user's home directory), and which provides for fairly reliable authentication between local or remote X clients and servers. Stanford's School of Earth Sciences has a very good web page on X Window Authentication, which explains the basic security concepts involved, and the proper use of xhost, xauth and SSH tunneling on various platforms.

Today it's considered a best practice not to depend on static lists of allowed users or hosts - even properly configured - to provide X server security, or even on magic cookies alone, but rather to tunnel X Window sessions via SSH (also called X11 forwarding), which by default uses the X authority method of authentication. SSH has the added advantage of encrypting the tunneled X sessions. More specific instructions are below.

Unfortunately certain X Window server applications, especially for Microsoft Windows and the "Classic" Mac OS systems, at least in the past have not used magic cookies by default. Given the wide availability of SSH applications that support X11 forwarding for all current operating systems, however, there's no reason ever to use the X Window System insecurely for remote sessions.

How Can I Tell If My X Server Is Secure?

In all that follows, we make the assumption that any remote X Window client software that you allow to connect to your X server is running on a computer that is itself secure and has not been compromised. For example, if you initiate an X Window session with a client application running on one of Stanford's cardinal hosts, you trust that that cardinal host is being securely maintained.

X Window terminology may appear confusing at first: The X server (or, in a slimmed-down form, X terminal emulator) is software you run on your local computer - or a remote computer - that allows you to interact with one or more X client applications on either your local or still another remote computer. In order for your server to communicate with remote clients, you must open port TCP 6000 inbound in any personal hardware or software firewall you may be using. Running an X server, like any other server, can expose you to possible attacks over the network if you configure or use it insecurely.

Here's a quick way to determine if your X server software is accessible to anyone on the network: that is, unprotected even by a host access list. Let's say the X server you want to test is running on a computer named fred on the Stanford network. First be sure that the X server software actually is running on fred. Then log in to another networked computer running X software - either your own, or, for example, any of the Sweet Hall Unix or Linux workstations, such as elaine-best or cardinal. If you're connecting to another remote computer to make this test, be sure to use SSH or Samson (that is, kerberized telnet) for a secure connection. From that login, run this command:

xdpyinfo -display fred.stanford.edu:0

If you get a response describing the X server display characteristics of fred, then fred is wide open, a sitting duck. Such a response would begin something like this:

name of display: fred.stanford.edu:0.0
version number: 11.0
vendor string: The XFree86 Project, Inc
vendor release number: 40399016
XFree86 version: 4.3.99.16
maximum request size: 16777212 bytes
motion buffer size: 0
bitmap unit, bit order, padding: 32, MSBFirst, 32
image byte order: MSBFirst
number of supported pixmap formats: 7 ...

Otherwise you'll get a response like unable to open display "fred.stanford.edu:0": Such an outcome merely proves, of course, that it isn't possible to access fred's X server from the machine you're currently logged in to. If you receive an unable to open display message, then try once again accessing fred from a different machine. After a few failed attempts, you can pretty safely assume that any would-be attacker's attempts also would fail.

In the case of Mac OS X, Unix or Linux X servers, there's a definitive method for determining that the X Window server host access list, easily manipulated by the xhost command, is properly configured: At the X terminal command line on the X server itself (let's use fred once again) enter xhost. You should receive a response something like this:

fred:~ admin$ xhost
access control enabled, only authorized clients can connect
INET6:localhost
INET6:fe80:1::1
INET:localhost
INET6:fe80:5::20d:93ff:fe85:fa04
INET:fred.stanford.edu
LOCAL:

Notice that only localhost and the fully-qualified DNS name of the local machine (fred.stanford.edu) are listed as having access rights. (INET6 refers to the IPv6 protocol. Depending on the X software you're using, you might or might not see information about IPv6 addresses.) Access to the server for any remote X client applications will thus be controlled by the X authority file using magic cookies.

What you do not want to see when you run the xhost program is access control disabled, clients can connect from any host.

To remove all non-local entries from your host-based access list, run the command xhost - (that is, xhost followed by a space and then a minus sign (or hyphen)). You should then see:

fred:~ admin$ xhost -
access control enabled, only authorized clients can connect

Since the host access list will generally take precedence over the .Xauthority access list, it's a good idea to run the xhost - command to ensure that the host access list is securely configured.

For X servers running on Windows PCs (or Macintosh "Classic" operating systems) a command line interface may not be available, and you may therefore have to refer to your X Window software documentation in order to determine how best to secure your server. Links to more information concerning a few such servers are below.

How Do I Connect Securely to Remote Clients Using My X Server?

Use X11 forwarding over SSH! What does that mean in practical terms? See the references with respect to several common platforms below.

To confirm a secure X-over-SSH connection: Once you have established a remote X session using SSH's X11 forwarding capability, at your X terminal's command prompt enter echo $DISPLAY. You should get a response something like this:

cardinal4:~> echo $DISPLAY
localhost:10.0

This response indicates that the X display session is indeed being forwarded securely through the local computer (localhost) that is running your X Window server. If you are connected to an X server running on a remote machine, then you will see that remote machine's name instead of localhost.

Microsoft Windows

Stanford's site-licensed SSH client for Microsoft Windows, SecureCRT, supports X11 forwarding, as does PuTTY, a popular (and free) SSH client. So long as you have X Window server or terminal emulator software installed and running on your Windows PC, and then set up an SSH connection to the remote host (say, one of Stanford's cardinal machines), you can run remote X Window client software on your PC using a secure authentication method - and the entire session will also be encrypted!

Purdue University has a very helpful set of instructions for using Hummingbird Exceed securely for remote X Window sessions by way of X11 forwarding with SecureCRT.

Stanford's CSLI has provided instructions for configuring the X-Win32 X Window server. The Cygwin/X User's Guide provides instructions for X11 forwarding using OpenSSH.

Mac OS X

You can use MacOS X's X terminal application to set up an SSH tunnel to a remote host, and then run X Window client applications. But you will need to install the X11 software for MacOS X first. Once X11 is installed, at the Mac OS terminal command line enter startx: This command will launch the X11 display environment.

At the X terminal command line you would then enter, in order to connect, say, to one of the elaine Solaris hosts:

ssh -X elaine-best.stanford.edu

Unix and Linux

Once again, please see the information on X Window Authentication provided by the School of Earth Sciences.

For excellent background information on computer windowing systems in general, see this page also on the School of Earth Sciences' web site.