Vulnerability Note VU#12212
Weaknesses in MIT magic cookie and XDM X Windows authorization
MIT magic cookie and XDM authorization contain vulnerabilities that could allow remote attackers to connect to X displays.
Two widely used X Window System authorization schemes have weaknesses in their sample implementations.
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.
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:
Fixing these problems will NOT introduce any incompatibilities. Patched and unpatched xdm and X server programs will interoperate.
- 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.
Remote attackers can connect to X displays and read potentially sensitive data such as passwords.
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.
If you are a vendor and your product is affected, let
|Vendor||Status||Date Notified||Date Updated|
|IBM||Affected||-||05 Sep 2000|
This document was written by Cory F Cohen.
21 May 98
Date First Published:
18 Jul 2003
Date Last Updated:
23 Feb 2004
If you have feedback, comments, or additional information about this vulnerability, please send us email.