Critical Vulnerability

Open X Servers

An open X server is one which accepts X client connections without restriction or authentication of the client. Internet attackers are scanning networks for open X servers. In particular, scanning is done from a compromised system inside a site's perimeter, so blocking the X server ports at the boundary is only a small help in preventing attacks on X.

An X client can obtain an image of any open windows or the entire display, copies of all keypress and/or mouse events sent to any windows, and can send synthetic events to windows. If an intruder has this access, he essentially can control all applications and sessions you have running. That leads to compromises of at least your account, and sometimes the entire system, on every machine you are logged into.

Secure X Servers

You improve your security quite a bit by only allowing client connections from the systems you need to use at any given moment. You can give your X server process a list of hosts from which client connenctions should be permitted. This is the next level of security above "none" and is barely acceptable. In this mode, your server is open to any user on any of the machines you have enabled.

Better security involves use of an authorization key, which is a string of bytes generated by the X server and stored in a private file on each machine where you want to run X clients. In the Unix world, a command-line program xauth manages this byte string. The string is sometimes referred to as a "magic cookie" or an "xauth key" X client programs obtain the string from the file when they open a connection to the X server. Because of the file protections, the key is only available to processes running under your account (or as root). This reduces the risk exposure for your display.

Even use of xauth keys leaves you vulnerable to sniffers on the network, because the X protocol transfers the authorization key in the clear. The final increment of security comes from combining use of the authorization key with an encrypted network connection. The ssh program can create a side channel to carry your X connection from a remote client when you use ssh to log into that remote system. (Ssh creates the appearance of a separate X display on the remote system itself, with a separate authorization key, and presents itself to the real X server as a local client.)

Securing your X server

Unix & Linux

Type xhost - to restrict access to certain client hosts. When the list of allowed clients is empty, access is then based on xauth keys. See the documentation for the xauth command for more information.

WRQ Reflection

Under the Settings menu, select Security. The Security mode MUST NOT be set to "Unrestricted access". "User-based access" is preferred. Then you must ensure that your remote-session-starting commands either send your cookie (authorization key) to the remote host, or use ssh to forward the X traffic over an encrypted tunnel. The middle choice, "Host-based access," allows all users on any of your designated hosts to access your X display.

When you choose user-based access, you have to send the authorization key to the remote system when you start a remote client. Including the following command in a session-startup dialog will do that:

/usr/bin/X11/xauth add %IP#% %C%;
With the semicolon in place as shown, you can simply put this before the xterm or whatever other command starts your remote X client. There's also a sample
session definition file you can edit and save. (Be sure to change some-host and yourname to fit the remote host's name and your login name. (You may also have to change the paths to the xauth and xterm programs on the remote system.)

There's a futher choice of what to do when clients not covered by the host- or user-based access control request a connection. If you set this to "prompt" you will get a dialog box every time the scanner checks your system. If you choose "prompt" you must deny the request to connect from the scanner when the dialog box appears or you will be found vulnerable and blocked again. You can only allow connections from nodes you recognize and trust. A setting of "refuse" is recommended.

Hummingbird Exceed

For Exceed V8, you may want to bring it up to Version or later, for reasons described on Hummingbird's support pages.

(Thanks to Jim Smedinghoff for contributing the above.)