10/14/2014

Critical Vulnerabilities

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.
https://security.fnal.gov/CriticalVuln/X-Servers.html

1/2

10/14/2014

Critical Vulnerabilities

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 remotesession-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 8.0.0.7 or later, for reasons described on
Hummingbird's support pages.
Run the xconfig utility (Start -> Programs -> Hummingbird Connectivity -> Exceed ->
Xconfig)
Go to the Security panel
In the Host Access Control List section, check the File button
Click on the Edit button to edit the xhost.txt file
Add the names of any nodes which will run X client programs which you want to display
windows on your Exceed X server
Exit the editor and click OK
For Exceed V8 and V9, edit %windir%\win.ini and add the lines
[Exceed]
AskUserToAddHost=0

Restart Exceed
(Thanks to Jim Smedinghoff for contributing the above.)
nightwatch@fnal.gov
https://security.fnal.gov/CriticalVuln/X-Servers.html

2/2