You are here: Home » Aktuelle Meldungen » RUS-CERT Security Advisories » RUS-CERT Advisory 2002-08:03 - Unwanted reconfiguration of X clients

RUS-CERT Advisory 2002-08:03 – Unwanted reconfiguration of X clients

X 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.

Systems affected

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 xterm and 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.

Attack requirements

Access to the X display (for example, over an X11 session forwarded by SSH) on which a vulnerable client such as xterm or xbiff is running.

Impact

The impact of the two vulnerabilities differs slightly.

  1. X clients can change X resources of any running application the the same display, using the Editres protocol.
  2. 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 xterm client although the allowSendEvents resource 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 xterm feature which is designed to enhance security is useless.
  • An attacker changes the checkCommand resource used by xbiff and thus execute arbitrary commands on the host running xbiff.

Description

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 xkeycaps.

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 xbiff.

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 allowSendEvents or checkCommand settings, as described above).

Technical Background

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).

Countermeasures

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 .Xdefaults or .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:

  1. 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 xterm terminal anyway.
  2. Implement proper access control for the RESOURCE_MANAGER property 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.)
  3. Implement a way to lock the contents of the RESOURCE_MANAGER property as soon as the requested values have been set by the user. For example, write access to the RESOURCE_MANAGER and RESOURCE_MANAGER_READ_ONLY properties could be denied if the RESOURCE_MANAGER_READ_ONLY property 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).

About RUS-CERT

RUS-CERT is the Computer Emergency Response Team located at the Computing Center (RUS) of the University of Stuttgart, Germany.

Revision History

This document was published on 2002-08-xx.