CERT Vendor-Initiated Bulletin VB-95:08 - X Authentication Vul

CERT Vendor-Initiated Bulletin VB-95:08
November 2, 1995

Topic: X Authentication Vulnerability
Source: X Consortium

To aid in the wide distribution of essential security information, the
CERT Coordination Center is forwarding the following information from
the X Consortium. The X Consortium urges you to act on this
information as soon as possible. X Consortium contact information is
included in the forwarded text below; please contact them if you have
any questions or need further information.

========================FORWARDED TEXT STARTS HERE============================

Two widely used X Window System authorization schemes have weaknesses
in the sample implementation. These weaknesses could allow
unauthorized remote users to connect to X displays and are present in
X11 Release 6 and earlier releases of the X11 sample implementation.

There are reports that systems have been broken into using at
least one of these weaknesses and that there are now exploit
programs available in the intruder community.

MIT-MAGIC-COOKIE-1 Description:

On systems on which xdm is built without the HasXdmAuth config option,
the MIT-MAGIC-COOKIE-1 key generated by xdm may be guessable.

If you use MIT-MAGIC-COOKIE-1 to authenticate X connections, and
your keys are generated by xdm, and xdm does not also support
XDM-AUTHORIZATION-1 authentication (that is, your X tree was not
built with the HasXdmAuth config option), you may be at risk.

On systems with poor pseudo-random number generators, the key may be
guessable by remote users. On other systems, users with access to the
file system where xdm stores its keys for use by local servers may be
able to use information in the file system to guess the key.

If your xdm program was built with HasXdmAuth set to YES (the compiler
command line includes the -DHASXDMAUTH flag), MIT-MAGIC-COOKIE-1 keys
generated by xdm are not vulnerable; the DES code is used to generate
cryptographically secure keys.

Impact

Remote users anywhere on the Internet may be able to connect to your
X display server. It is NOT necessary that they be able to snoop your
key first.

XDM-AUTHORIZATION-1 Description:

The X server does not correctly check the XDM-AUTHORIZATION-1 data and
can be fooled into accepting invalid data.

A user who can snoop the encrypted authorization data of a valid
connection can create fake auth data that the X server will accept.

If you do not use XDM-AUTHORIZATION-1, you are not vulnerable.

Determining whether your server is vulnerable: this problem is fixed
in X servers from the X Consortium with a vendor release number of
6001 or higher.

Impact

Remote users may be able to connect to your X display server.

SOLUTIONS

A. Install a vendor supplied patch if available.

B. If your site is using X11 built from X Consortium X11R6 sources,
install public patch #13. This patch is available via anonymous
FTP from ftp.x.org as the file /pub/R6/fixes/fix-13. It is also
available from the many sites that mirror ftp.x.org. Apply all patches
not already applied, up to and including fix-13. The file xc/bug-report
shows what public patches have been already applied to your source
tree.

The MD5 checksum of fix-13 is as follows:

MD5 (fix-13) = 0d81d843acf803a8bedf90d3a18b9ed6

C. If your site is using an earlier version of the X Consortium's X11,
upgrade to X11R6. Install all patches up to and including fix-13.

D. Work arounds.

1. Building with HasXdmAuth will eliminate the first vulnerability.
The necessary DES code is available for FTP from both inside the
US (for US sites only) and outside (for non-US sites). Read
<ftp://ftp.x.org/pub/R6/xdm-auth/README> for details on obtaining
this code.

2. If you cannot use DES, you can determine your exposure to
remote attackers by testing the strength of your rand() function
using the program rand-test; the source is available as
<ftp://ftp.x.org/pub/DOCS/rand-test/rand-test.c>.

3. Limiting use of X connections using XDM-AUTHORIZATION-1 to trusted
networks will prevent unauthorized parties from snooping X protocol
traffic, thus preventing exploitation of the second vulnerability.

Acknowledgements: The X Consortium would like to thank Chris Hall of
the University of Colorado for analyzing these problems and bringing
them to our attention.