RUS-CERT Advisory 2002-08:03 – Unwanted reconfiguration of X clientsX clients on the same display can reconfigure each other over the Editres protocol and the Resource Manager. This can circumvent configurable security measures and lead to arbitrary command execution.
Who should read this document
Users of the X Window System should read this advisory. Vendors are encouraged apply the countermeasure mentioned below in default installations.
RUS-CERT has verified that the following products are affected by this defect:
- XFree86 4.1.0 (as shipped with Debian GNU/Linux woody)
- Solaris 9
X client applications affected by the Editres vulnerability include
xbiff (a mailbox monitoring tool often shipped along with the X Window System).
Probably all applications which use the X Athena Widgets (the
Xaw library) are affected in some way. This can extend to all X Toolkit Intrinsics (the
Xt library) if the vendor has compiled the library with suitable options (see below).
A second weakness affects all X clients which expect trustworthy data from the Resource Manager.
Access to the X display (for example, over an X11 session forwarded by SSH) on which a vulnerable client such as
xbiff is running.
The impact of the two vulnerabilities differs slightly.
- X clients can change X resources of any running application the the same display, using the Editres protocol.
- X clients can set X resource database entries which are applied when applications are started.
Attackers can use this possibilities in various ways:
- The attacker sends key and button events to the
xtermclient although the
allowSendEventsresource has never been enabled by the user (it is disabled by default).
- The attacker relabels menu items, including the Secure Keyboard option in
xterm, and can emulate the color inversion that signals the user that the Secure Keyboard option is active. As a result, this
xtermfeature which is designed to enhance security is useless.
- An attacker changes the
checkCommandresource used by
xbiffand thus execute arbitrary commands on the host running
It is sometimes expected that X clients using the same display are independent. For example, the manual page of
xterm contains the following statement:
allowSendEvents (class AllowSendEvents)
- Specifies whether or not synthetic key and button events (generated using the X protocol SendEvent request) should be interpreted or discarded. The default is “false” meaning they are discarded. Note that allowing such events creates a very large security hole.
We believe that the “very large security hole” is an exaggeration, but nevertheless, it is not possible to turn off this option permanently.
First, X clients such as
editres can alter the
allowSendEvents resource: Start
editres, invoke Commands|Get Tree to get the widget tree, click with button 2 on “
vt100”, invoke Commands|Show Resource Box, select “
allowSendEvents”, enter “
true”, and press Apply. Now you can send synthetic events, for example key presses using
In a similar way, it is possible to relabel menu entries (sometimes, you have to display a menu at least once before its entries show up in
editres), or change colors of widgets. This can be abused to give the user the impression that he has activated the Secure Keyboard option, although he has not. As a result, attackers can sniff passwords even though the user assumes that this is not possible. (A
GrabKeyboard request is required before the password can entered securely because the keyboard is a display-wide resource and any application can monitor key presses by default.)
In the case of
xbiff, it is possible to change the
checkCommand resource, which contains a shell command which is periodically run by
The second weakness involves the display-specific resource database. This database can be changed using
xrdb, and no access control restrictions are applied, as long as the
xrdb client is allowed to access the display. Another X client which uses the
Xt library uses the modified global database to initialize its local copy and can inherit dangerous values this (e.g. the
checkCommand settings, as described above).
Non-technical readers are advised to skip to the Countermeasures section.
The first vulnerability involves the Editres protocol which is implemented in the
Xmu library, “a collection of miscellaneous (some might say random) utility functions that have been useful in building various applications and widgets” (quote from the manual). The Editres protocol is used to propagate changes of the Resource Management database to individual X clients.
In order to react to Editres protocol events, the application has to register a protocol handler. The following invocation of
XtAddEventHandler achieves this:
XtAddEventHandler(shell, (EventMask) 0, True, _XEditResCheckMessages, NULL);
This registration happens automatically if an application uses the Athena Widgets, or if the application uses the Intrinsics Toolkit and the vendor has compiled the relevant file in the
Xt with the
-DEDITRES option. (In the latter case, there has to be an undefined reference to
_XEditResCheckMessages in the library
libXt.a which can be discovered using the
nm, at least on UNIX-like systems.)
The Editres protocol offers a wealth of possibilities: X clients store arbitrary information in the Resource Management database. In the cases above, we have security-relevant settings and the menu structure (
xterm) or arbitrary code in the form of a shell script (
xbiff) in the database.
The second weakness results from the fact that the Resource Manager in a client application uses the
RESOURCE_MANAGER property of the root window of the display to obtain user settings. Write access to this property is not restricted in any way (as soon as a client has authenticated itself and obtain an X connection).
It is possible to deactivate the
Editres protocol by setting the following resource:
! Disable the Editres protocol. It is a security risk. *editresBlock: all
User can add this entry to the
.Xresources file in their home directory. System administrators can usually set the system-wide default in a special file (on recent versions of Debian GNU/Linux,
/etc/X11/Xresources/xfree86-common can be used).
However, this only resolves the first vulnerability, and the second vulnerability permits an attacker to negate this countermeasure. There are several ways in which the second vulnerability can be addressed:
- Declare that users should not offer access to their X display to untrusted hosts. It is very difficult to interpret the screen contents correctly if untrusted applications are running, and most users do not properly use the Secure Keyboard option when entering passwords in an
- Implement proper access control for the
RESOURCE_MANAGERproperty of the root window. This requires that vendors implement substantial changes, possibly changing established practices and/or protocols. (A proposal for security extensions for X11R6.4 exists, but RUS-CERT is not aware of an implementation.)
- Implement a way to lock the contents of the
RESOURCE_MANAGERproperty as soon as the requested values have been set by the user. For example, write access to the
RESOURCE_MANAGER_READ_ONLYproperties could be denied if the
RESOURCE_MANAGER_READ_ONLYproperty exists. The second property could be set using an “
xrdb -lock” command.
According to the security contact at X.Org (the umbrella organization currently backing the X Window System development), option 1 had already been chosen even before this issue was brought to their attention (and the manual page for
xterm has not been updated accordingly).
RUS-CERT is the Computer Emergency Response Team located at the Computing Center (RUS) of the University of Stuttgart, Germany.
This document was published on 2002-08-xx.