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
><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.
>
>
>-----------------------------------------------------------------
>
> 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 <ftp://ftp.x.org/contrib/faqs/FAQ.Z> and other
>locations. <http://www.x.org/consortium/news_and_mail.html>
>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