-------- From academic-firewalls-owner@net.tamu.edu Mon Nov 20 22:33:41 1995 X-Sender: swift@tamiya.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: academic-firewalls@net.tamu.edu, ids@uow.edu.au, Date: Mon, 20 Nov 1995 20:28:19 -0800 From: fisher@bill.llnl.gov (John M. Fisher) (by way of uncl@llnl.gov (Frank Swift at)) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: CIAC Bulletin G-4: X Authentication Vulnerability - -----BEGIN PGP SIGNED MESSAGE----- __________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN X Authentication Vulnerability November 20, 1995 22:00 GMT Number G-04 _________________________________________________________________________________ PROBLEM: A bug exists in the X authorization scheme which can allow remote users unauthorized access to an X display. PLATFORM: Multiple - see below. DAMAGE: Access to an X display can lead to the obtaining of passwords or other personal information. SOLUTION: Apply either the fix or the patch described below. - - --------------------------------------------------------------------------------- VULNERABILITY This is a serious vulnerability. Systems have been compromised ASSESSMENT: and an exploitation program has been circulated within the intruder community. - - --------------------------------------------------------------------------------- The X Consortium has made public a vulnerability in the X Authorization software. Below is the information they have released. [ Start X Consortium Release ] 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 - [ End X Consortium Release ] _______________________________________________________________________________ CIAC wishes to acknowledge the contributions of the X Consortium for information contained in this bulletin. _______________________________________________________________________________ CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy. CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE and DOE contractors, and CIAC can be contacted at: Voice: +1 510-422-8193 FAX: +1 510-423-8002 STU-III: +1 510-423-2604 E-mail: ciac@llnl.gov For emergencies and off-hour assistance, DOE and DOE contractor sites may contact CIAC 24-hours a day. During off hours (5PM - 8AM PST), call the CIAC voice number 510-422-8193 and leave a message, or call 800-759-7243 (800-SKY-PAGE) to send a Sky Page. CIAC has two Sky Page PIN numbers, the primary PIN number, 8550070, is for the CIAC duty person, and the secondary PIN number, 8550074 is for the CIAC Project Leader. Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://ciac.llnl.gov/ Anonymous FTP: ciac.llnl.gov (128.115.19.53) Modem access: +1 (510) 423-4753 (14.4K baud) +1 (510) 423-3331 (9600 baud) CIAC has several self-subscribing mailing lists for electronic publications: 1. CIAC-BULLETIN for Advisories, highest priority - time critical information and Bulletins, important computer security information; 2. CIAC-NOTES for Notes, a collection of computer security articles; 3. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI) software updates, new features, distribution and availability; 4. SPI-NOTES, for discussion of problems and solutions regarding the use of SPI products. Our mailing lists are managed by a public domain software package called ListProcessor, which ignores E-mail header subject lines. To subscribe (add yourself) to one of our mailing lists, send the following request as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES, SPI-ANNOUNCE or SPI-NOTES for list-name and valid information for LastName FirstName and PhoneNumber when sending E-mail to ciac-listproc@llnl.gov: subscribe list-name LastName, FirstName PhoneNumber e.g., subscribe ciac-notes OUHara, Scarlett W. 404-555-1212 x36 You will receive an acknowledgment containing address, initial PIN, and information on how to change either of them, cancel your subscription, or get help. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending email to docserver@first.org with an empty subject line and a message body containing the line: send first-contacts. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC) (F-23) Protecting IBM AIX Systems Against SATAN (F-24) Protecting SGI IRIX Systems Against SATAN (F-25) Cisco IOS Router Software Vulnerability (F-26) OSF/DCE Security Hole (F-27) Incorrect Permissions on /tmp (F-28) Vulnerability in SunOS 4.1.* Sendmail (-oR option) (F-28) Vulnerability in SunOS 4.1.* Sendmail (-oR option) (G-1) Telnetd Vulnerability (G-2) SunOS 4.1.X Loadmodule Vulnerability (G-3) AOLGOLD Trojan Program RECENT CIAC NOTES ISSUED (Previous Notes available from CIAC) Notes 07 - 3/29/95 A comprehensive review of SATAN Notes 08 - 4/4/95 A Courtney update Notes 09 - 4/24/95 More on the "Good Times" virus urban legend Notes 10 - 6/16/95 Discusses the PKZ300B Trojan, Logdaemon/FreeBSD vulnerability in S/Key, EBOLA Virus Hoax, and Caibua Virus Notes 11 - 7/31/95 Features include a Virus Update, Hats Off to Administrators, America On-Line Virus Scare, SPI 3.2.2 Released, The Die_Hard Virus Notes 12 - 9/12/95 Features include discussions on securely configuring Public Telnet Services, X Windows and announces the beta release of Merlin, describes the Microsoft Word Macro Viruses, and examines allegations of Inappropriate Data Collection in Win95 - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMLD9k7nzJzdsy3QZAQFNdQQAuaJ919Q+hDH3KLsII6icOooDverD2Jdb vJi45le/8r6m9Xx9RCKZt7zgy+oSQQ5oxTmAZikIWRfPRfao78b1jukbF0dYl60S h0h7EHM+2JwqTuhFZT52bPCS/V+biekjVtLMF7/exEzM/+xQnW0Eb54Gzyq9cu96 LqZH0/9RUcI= =Lpad - -----END PGP SIGNATURE----- -------- From academic-firewalls-owner@net.tamu.edu Tue Nov 21 12:45:06 1995 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Date: Tue, 21 Nov 95 14:41:36 PST From: ifua25@cpvcba07.corpoven.pdv.com Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu subscribe academic-firewalls -------- From academic-firewalls-owner@net.tamu.edu Tue Nov 21 15:01:49 1995 Organization: Auckland Institute of Technology X-Mailer: Pegasus Mail for Windows (v2.10) Date: Wed, 22 Nov 1995 09:56:49 GMT+1200 From: "Lenny Bielski" Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: test Testing. Gabagabagaba, if we can dream it, we can build it. Comeon what are we waiting for. - -------------------------- Email: lbielski@ait.ac.nz Network Adminstrator/Postmaster Auckland Institute of Technology Web page: http://www.ait.ac.nz/~lbielski Talkd: lenny@hades.ait.ac.nz Phone: +64 9 3079999 Ext 8054 Fax: +64 9 3079901 -------- From academic-firewalls-owner@net.tamu.edu Wed Nov 22 15:45:56 1995 Organization: Auckland Institute of Technology X-Mailer: Pegasus Mail for Windows (v2.10) Date: Thu, 23 Nov 1995 10:40:04 GMT+1200 From: "Lenny Bielski" Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: PROXY's Question the Datagram Hi I am a little confused as to what Proxy's actually do to the TCP/IP datagram. I assume that the proxy server (application gateway) will change the source field, however what other fields (if any) does it change in the datagram to uniquely identify the proxy for that user/packet/service. Also are the changes made by the application gateway to the Datagram variable. I mean does it change field marker offsets within the datagram anywhere? Gabagabagaba, if we can dream it, we can build it. Comeon what are we waiting for. - -------------------------- Email: lbielski@ait.ac.nz Network Adminstrator/Postmaster Auckland Institute of Technology Web page: http://www.ait.ac.nz/~lbielski Talkd: lenny@hades.ait.ac.nz Phone: +64 9 3079999 Ext 8054 Fax: +64 9 3079901 -------- From academic-firewalls-owner@net.tamu.edu Wed Nov 22 17:16:46 1995 In-Reply-To: from "Lenny Bielski" at Nov 22, 95 09:56:49 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Date: Wed, 22 Nov 1995 17:04:23 -0500 (EST) From: mako!tim@netcom.com (Tim Shelling) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: test > > Gabagabagaba, if we can dream it, we can build it. And someone else can crack it. - -- Tim Shelling | tim@atldev.com | 404-628-3301 | SKYPAGE: 1197696 Atlanta Development Center | 2675 Paces Ferry Rd. NW, Atlanta, GA 30339 "The *who* of Pooh?" -------- From academic-firewalls-owner@net.tamu.edu Thu Nov 23 16:26:52 1995 In-Reply-To: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 23 Nov 1995 16:21:46 -0600 (CST) From: Doug Hughes Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: PROXY's Question the Datagram On Thu, 23 Nov 1995, Lenny Bielski wrote: > Hi > > I am a little confused as to what Proxy's actually do to the TCP/IP > datagram. > > I assume that the proxy server (application gateway) will change the > source field, however what other fields (if any) does it change in the datagram to > uniquely identify the proxy for that user/packet/service. > > Also are the changes made by the application gateway to the Datagram variable. > I mean does it change field marker offsets within the datagram > anywhere? > At its simplest, the proxy just changes the source and forwards the query on to the destination, and vice-versa with the reply. However, you could setup a proxy to do other things special to the packet if you wanted to. ____________________________________________________________________________ Doug Hughes Engineering Network Services System/Net Admin Auburn University doug@eng.auburn.edu Pro is to Con as progress is to congress -------- From academic-firewalls-owner@net.tamu.edu Fri Nov 24 07:56:45 1995 In-Reply-To: from "Doug Hughes" at Nov 23, 95 04:21:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Date: Fri, 24 Nov 1995 08:51:21 -0500 (EST) From: Mike Shaver Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: PROXY's Question the Datagram Doug Hughes mumbled something vague about: > On Thu, 23 Nov 1995, Lenny Bielski wrote: > > Hi > > > > I am a little confused as to what Proxy's actually do to the TCP/IP > > datagram. > > > > I assume that the proxy server (application gateway) will change the > > source field, however what other fields (if any) does it change > > in the datagram to uniquely identify the proxy for that > > user/packet/service. > > > > Also are the changes made by the application gateway to the > > Datagram variable. > > I mean does it change field marker offsets within the datagram > > anywhere? > > At its simplest, the proxy just changes the source and forwards the query > on to the destination, and vice-versa with the reply. However, you could > setup a proxy to do other things special to the packet if you wanted to. I always thought proxies worked at the application layer, and thus wouldn't do anything internal to the packet, but would rather create a new packet with the same (or perhaps slightly modified) data and send that on to the real destination. Actually, since most proxies are TCP-based, they don't even worry about the packet model. They get data from one stream, process it somehow, and then send data to another stream. Mike -------- From academic-firewalls-owner@net.tamu.edu Fri Nov 24 14:27:51 1995 Cc: academic-firewalls@net.tamu.edu In-Reply-To: <199511241351.IAA13446@schoolnet.carleton.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 24 Nov 1995 14:23:03 -0600 (CST) From: Doug Hughes Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: PROXY's Question the Datagram On Fri, 24 Nov 1995, Mike Shaver wrote: > Doug Hughes mumbled something vague about: > > At its simplest, the proxy just changes the source and forwards the query > > on to the destination, and vice-versa with the reply. However, you could > > setup a proxy to do other things special to the packet if you wanted to. > > I always thought proxies worked at the application layer, and thus > wouldn't do anything internal to the packet, but would rather create a > new packet with the same (or perhaps slightly modified) data and send > that on to the real destination. They can work at any layer they're designed to work on (usually at or above Network layer). > > Actually, since most proxies are TCP-based, they don't even worry > about the packet model. They get data from one stream, process it > somehow, and then send data to another stream. > > yes! and at its most basic level of processing, all that is changed is the source address (that of the proxy host). Examples of proxys Proxy ARP (at network layer) proxy http (TCP) proxy ftp (TCP) proxy snmp (UDP) proxy rpc (TCP/UDP) proxy X11 (application/presentation) ____________________________________________________________________________ Doug Hughes Engineering Network Services System/Net Admin Auburn University doug@eng.auburn.edu Pro is to Con as progress is to congress -------- From academic-firewalls-owner@net.tamu.edu Sat Nov 25 11:59:13 1995 In-Reply-To: from "Doug Hughes" at Nov 24, 95 02:23:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Date: Sat, 25 Nov 1995 12:53:44 -0500 (EST) From: Mike Shaver Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: PROXY's Question the Datagram Doug Hughes mumbled something vague about: > Examples of proxys > Proxy ARP (at network layer) This isn't really the same kind of proxy, is it? We were talking about proxies whereby one system connects to another through a proxy, not where one system is permanently emulating another. (That was confusing... there is, in my mind, a very clear difference between the meaning of "proxy" in "proxy ARP" and the meaning of "proxy" in "FTP proxy".) > proxy ftp (TCP) FTP proxies have to muck with the application layer, though. Mike -------- From academic-firewalls-owner@net.tamu.edu Sat Nov 25 16:18:26 1995 Date: Sat, 25 Nov 95 16:13:43 CST From: doug@eng.auburn.edu (Doug Hughes) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: PROXY's Question the Datagram > >Doug Hughes mumbled something vague about: >> Examples of proxys >> Proxy ARP (at network layer) > >This isn't really the same kind of proxy, is it? We were talking >about proxies whereby one system connects to another through a proxy, >not where one system is permanently emulating another. (That was >confusing... there is, in my mind, a very clear difference between the >meaning of "proxy" in "proxy ARP" and the meaning of "proxy" in "FTP >proxy".) > The implementation isn't the same, but the reason behind it is. Some machine acts as a gateway for another machine (or groups of machines) in contacting a third machine(s) on the other side of the gateway. >> proxy ftp (TCP) > >FTP proxies have to muck with the application layer, though. > Very true. FTP is a strange critter to be sure. :)