Vulnerability Note VU#12212

Weaknesses in MIT magic cookie and XDM X Windows authorization

Overview

MIT magic cookie and XDM authorization contain vulnerabilities that could allow remote attackers to connect to X displays.

I. Description

Two widely used X Window System authorization schemes have weaknesses in their sample implementations.

MIT-MAGIC-COOKIE-1

On some systems built without the HasXdmAuth configuration option, the authorization key used by MIT-MAGIC-COOKIE-1 is guessable. The problem is that the system rand() function, used to generate cookies when DES is not available, is weak on some systems. If you use MIT-MAGIC-COOKIE-1 to authenticate X connections, and your xdm does NOT also support XDM-AUTHORIZATION-1 authentication (that is, xdm was built with HasXdmAuth set to NO), you may be at risk. If your xdm program was built with HasXdmAuth set to YES (-DHASXDMAUTH passed on the compiler command line), your system is not vulnerable; the DES code is used to generate cryptographically secure keys.

XDM-AUTHORIZATION-1

The X server does not correctly check the XDM-AUTHORIZATION-1 data and can be fooled into accepting invalid data. A user who can sniff the encrypted authorization data of a valid connection can create fake authorization data that the X server will not reject as a replay and not reject as a fake. If you do not use XDM-AUTHORIZATION-1, you are not vulnerable in this way.

A review of the code has also turned up the following minor security weaknesses:

The X server only keeps the replay cache for XDM-AUTHORIZATION-1 for the same amount of time as the data is valid, so even a slight backward change of the clock opens a window for replays. Since some systems do not have the adjtime() system call, setting the clock backward may be necessary.
Memory containing keys is not zeroed before being freed. It may be possible to recover keys from core dumps, swap space, or uninitialized memory.
The authority files written by xdm to pass to a local X server may contain keys based on the system time. Since the files are in a readable directory, the time used to generate the key can be guessed in part by observing the write time of the authority file.

Fixing these problems will NOT introduce any incompatibilities. Patched and unpatched xdm and X server programs will interoperate.

II. Impact

Remote attackers can connect to X displays and read potentially sensitive data such as passwords.

III. Solution

Patch or Upgrade

Contact your vendor to determine if a patch or upgrade is necessary. Due to the relative age of this report, we have not notified individual vendors. See VB-95:08.X_Authentication_Vul for more information.

Tunnel X connections over SSH

Encrypting X traffic will protect authorization data from being sniffed on the network. Using SSH does not prevent other local users from discovering X authentication data.

Systems Affected

Vendor	Status	Date Notified	Date Updated
IBM	Vulnerable	5-Sep-2000

References

http://www.cert.org/vendor_bulletins/VB-95:08.X_Authentication_Vul

Credit

This document was written by Cory F Cohen.

Other Information

Date Public:	98-05-21
Date First Published:	2003-07-18
Date Last Updated:	2004-02-23
CERT Advisory:
CVE-ID(s):
NVD-ID(s):
US-CERT Technical Alerts:
Metric:	14.06
Document Revision:	17

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Get Adobe Reader