search menu icon-carat-right cmu-wordmark

CERT Coordination Center

Weaknesses in MIT magic cookie and XDM X Windows authorization

Vulnerability Note VU#12212

Original Release Date: 2003-07-18 | Last Revised: 2004-02-23


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:

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


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.

Vendor Information

Expand all


Updated:  September 05, 2000



Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.


The CERT/CC has no additional comments at this time.

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

CVSS Metrics

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A



This document was written by Cory F Cohen.

Other Information

CVE IDs: None
Severity Metric: 14.06
Date Public: 1998-05-21
Date First Published: 2003-07-18
Date Last Updated: 2004-02-23 22:03 UTC
Document Revision: 17

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.