MCI Data Systems Division internetMCI Security Group Incident Response Advisory Report Name: X Consortium - X Authentication Vulnerability Report Number: iMCISE:MIIGS:XVUL:1102:95:P1:R1 Report Date: 11/02/95 Report Format: Full Report Classification: Distribution Unlimited Report Distribution: On File ------------------------------------------------------------------------------- >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 > 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 >. > >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. > > >----------------------------------------------------------------- > > Vendor Status > >The following information was supplied by vendors for this bulletin. >The X Consortium and CERT have not verified this information. > > >Cray Research > >UNICOS 8.0 and 9.0 are not vulnerable. These systems have robust >pseudo-random number generators, making them not vulnerable to the >first problem, and do not support an X server, making them not >vulnerable to the second problem. > > >GSSC (formerly Solbourne) > >Has concluded they are not vulnerable. > > >Hewlett-Packard > >All versions of X on HP-UX 9.x and 10.x (based on X11R5) do not >have the first vulnerability. > > >X Consortium > >(Sample implementation of X.) You can patch X11R6 by applying all >public patches up to and including fix-13. Patches are available >via FTP from ftp.x.org in /pub/R6/fixes/ and from mirroring sites. > >You can check that the X server has fix-13 installed by verifying >that the server has a vendor release number of 6001 or higher. > >General questions about the X Window System can be asked on the >xpert mailing list hosted at x.org. Send a "subscribe" message to >xpert-request@x.org to subscribe. This list is gatewayed with >the comp.windows.x newsgroup. The FAQ for this newsgroup is >available from and other >locations. >describes other newsgroups and mailing lists for the discussion >of issues related to the X Window System. > >Bugs encounted in X Consortium code can be reported to >xbugs@x.org using the format in xc/bug-report. Please see the >X11R6 Release Notes for additional details. > > >XFree86 Project > >The XFree86 Project, Inc has patched binaries for XFree86 version 3.1.2 >running on FreeBSD 1.1.5, FreeBSD 2.0.5, ISC, NetBSD and SVR4. They >are available from ftp://ftp.xfree86.org/pub/XFree86/3.1.2/binaries/. >The files are: > > FreeBSD-1.1.5/X312Sxdm.tgz > FreeBSD-2.0.5/X312Sxdm.tgz > ISC/X312Sxdm.tgz > NetBSD/X312Sxdm.tgz > SVR4/X312Sxdm.tgz > >The MD5 checksums are: > > MD5 (FreeBSD-1.1.5/X312Sxdm.tgz) = 43166109c88fcd623d27de1fa90e8f5b > MD5 (FreeBSD-2.0.5/X312Sxdm.tgz) = 3314a623b2c31a9130445e9237ff65f9 > MD5 (ISC/X312Sxdm.tgz) = e4e16fc5f4d06ad455e572a2e1eb0eb5 > MD5 (NetBSD/X312Sxdm.tgz) = 0bc74cbee0214366ac15658bf5436853 > MD5 (SVR4/X312Sxdm.tgz) = bf5dfea2a86cdf92621421e3f68af203 > >Installation instructions (assuming X312xdm.tgz is in /tmp): > >Kill any xdm processes that are running, then: > > For FreeBSD 1.1.5 and FreeBSD 2.0.5: > > cd /usr > mv X11R6/bin/xdm X11R6/bin/xdm-3.1.2 > chmod 0500 X11R6/bin/xdm-3.1.2 > gzip -d < /tmp/X312xdm.tgz | tar vxf - > > For NetBSD: > > mv /usr/X11R6/bin/xdm /usr/X11R6/bin/xdm-3.1.2 > chmod 0500 /usr/X11R6/bin/xdm-3.1.2 > pkg_add /tmp/X312Sxdm.tgz > > For ISC and SVR4: > > cd /usr/X11R6 > mv bin/xdm bin/xdm-3.1.2 > chmod 0500 bin/xdm-3.1.2 > gzip -d < /tmp/X312xdm.tgz | tar vxf - > > >=========================FORWARDED TEXT ENDS HERE============================= > > >CERT publications, information about FIRST representatives, and >other information related to computer security are available for anonymous >FTP from info.cert.org. > >CERT advisories and bulletins are also posted on the USENET newsgroup >comp.security.announce. If you would like to have future advisories and >bulletins mailed to you or to a mail exploder at your site, please send mail >to cert-advisory-request@cert.org. > >If you wish to send sensitive incident or vulnerability information to >CERT staff by electronic mail, we strongly advise that the e-mail be >encrypted. The CERT Coordination Center can support a shared DES key, PGP >(public key available via anonymous FTP on info.cert.org), or PEM (contact >CERT staff for details). > >Internet email: cert@cert.org >Telephone: +1 412-268-7090 (24-hour hotline) > CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), > and are on call for emergencies during other hours. >Fax: +1 412-268-6989 > >CERT Coordination Center >Software Engineering Institute >Carnegie Mellon University >Pittsburgh, PA 15213-3890 >USA > > > > >CERT is a service mark of Carnegie Mellon University. > > "Success through teamwork" =============================================================================== Dale Drew MCI Telecommunications Manager internetMCI Security Engineering Voice: 703/715-7058 Internet: ddrew@mci.net Fax: 703/715-7066 MCIMAIL: Dale_Drew/644-3335