[Note: Document reformated for mailing by jya@pipeline.com. If in doubt contact CIAC for original: ciac.llnl.gov:/pub/ciac/bulletin/f-fy95/f-09.ciac.(doc).] ________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ _________________________________________________________ INFORMATION BULLETIN Unix /bin/mail Vulnerabilities January 27, 1995 1030 PST Number F-09 _________________________________________________________ PROBLEM: The Unix /bin/mail utility contains security vulnerabilities. PLATFORMS: DEC OSF/1 1.2, 1.3, and 2.0 DEC Ultrix 4.3, 4.3A, and 4.4 SCO Unix System V/386 Release 3.2 OS Version 4.2 SCO Open Desktop Lite Release 3.0 SCO Open Desktop Release 3.0 SCO Open Server Enterprise System Release 3.0 SCO Open Server Network System Release 3.0 Solbourne OS4.1x SunOS 4.x DAMAGE: Local users may gain privileged (root) access. SOLUTION: Apply appropriate vendor patch as described below. _________________________________________________________ VULNERABILITY ASSESSMENT The vulnerabilities in the /bin/mail program have been openly discussed in several Internet forums, and automated scripts exploiting the vulnerabilities have been widely distributed. These tools have been used in many recent attacks. CIAC recommends sites install these patches as soon as possible. _________________________________________________________ Critical Information about Unix /bin/mail Vulnerabilities The /bin/mail utility on several Unix versions based on BSD 4.3 Unix contain a security vulnerability. The vulnerability is the result of race conditions that exist during the delivery of messages to local users. These race conditions will allow intruders to create or modify files on the system, resulting in privileged access to the system. Below is a summary of systems known to be either vulnerable or not vulnerable. If your vendor's name is not listed, please contact the vendor or CIAC for more information. Vendor or Source Status ---------------- ------------ Apple Computer, Inc. Not vulnerable Berkeley SW Design, Inc. (BSDI) Not vulnerable Cray Research, Inc. Not vulnerable Data General Corp. Not vulnerable Digital Equipment Corp. Vulnerable FreeBSD Not vulnerable Harris Not vulnerable IBM Not vulnerable NetBSD Not vulnerable NeXT, Inc. Not vulnerable Pyramid Not vulnerable The Santa Cruz Operation (SCO) Vulnerable Solbourne (Grumman) Vulnerable Sun Microsystems, Inc. SunOS 4.x vulnerable Solaris 2.x not vulnerable Patch Information ----------------- DEC The /bin/mail patch is a part of a comprehensive Security Enhanced Kit that addresses other security problems as well. This kit was released on May 17, 1994 and was described in DEC Security Advisory #0505 and CIAC Notes 94-03. OSF/1 users should upgrade to a minimum of version 2.0 and install Security Enhanced Kit CSCPAT_4061 v1.0. Ultrix users should upgrade to at least version 4.4 and install Security Enhanced Kit CSCPAT_4060 v1.0. Both kits are available from your Digital support channel or electronically by request via DSNlink. SCO Vulnerabilities in SCO's /bin/mail utility are removed by applying SCO's Support Level Supplement (SLS) uod392a. It is available via anonymous FTP from ftp.sco.com in the /SLS directory: Description Filename MD5 Checksum ----------- ------------ -------------------------------- Disk image uod392a.Z 2c26669d89f61174f751774115f367a5 Cover letter uod392a.ltr.Z 52db39424d5d23576e065af2b80aee49 Solbourne Grumman System Support Corporation now performs all Solbourne software and hardware support. Please contact them for further information: E-mail: support@nts.gssc.com Phone: 1-800-447-2861 FTP: ftp.nts.gssc.com Sun Sun has made patches available to remove vulnerabilities in /bin/mail. These patches address all vulnerabilities CIAC has seen exploited to date, and CIAC recommends they be installed. However, the patches will be updated again in the near future to remove additional vulnerabilities that have recently come to light. CIAC will announce the availability of the new patches when they are released. The patches may be obtained from your local Sun Answer Center or through anonymous FTP from sunsolve1.sun.com in the /pub/patches directory: SunOS Filename MD5 Checksum ------- --------------- -------------------------------- 4.1.x 100224-13.tar.Z 90a507017a1a40c4622b3f1f00ce5d2d 4.1.3U1 101436-08.tar.Z 0e64560edc61eb4b3da81a932e8b11e1 Alternative Solution -------------------- For those sites unable to obtain a vendor patch From owner-cypherpunks Fri Jan 27 13:19:28 1995 Return-Path: <owner-cypherpunks> Received: by toad.com id AA15273; Fri, 27 Jan 95 13:19:28 PST Received: from gateway.informix.com by toad.com id AA15259; Fri, 27 Jan 95 13:19:22 PST Received: from informix.com (infmx.informix.com) by gateway.informix.com (4.1/SMI-4.1) id AA10439; Fri, 27 Jan 95 13:19:16 PST Received: from carbon.informix.com by informix.com (4.1/SMI-4.1) id AA02110; Fri, 27 Jan 95 13:19:08 PST Received: by carbon.informix.com (5.0/SMI-SVR4) id AA00461; Fri, 27 Jan 1995 13:19:01 +0800 Date: Fri, 27 Jan 1995 13:19:01 +0800 From: jamesd@com.informix.com Message-Id: <9501272119.AA00461@carbon.informix.com> Subject: Oops, Correction: one big error in "Even more unix holy war." Apparently-To: perry@imsi.com Apparently-To: sdw@lig.net Apparently-To: wmo@digibd.com Apparently-To: cypherpunks@toad.com Content-Length: 2646 Sender: owner-cypherpunks@toad.com Precedence: bulk I wrote:
The great strength is of course symbolic debugging -- you can single step your compiled code, and see it displayed symbolicly, with the symbols and statements of your source code, and with the contents memory displayed in terms of your source code variables.
On this I was of course totally wrong: Unix has symbolic debugging equal to DOS/Windows. I was under the false impression that it only had C code interpretation. This is an error -- what I said was true for C++, but then in Windows we too are forced to primarily use interpretation to debug C++. C++ symbolic debuggers are not up to acceptable capabilities in either system. Sorry. But my statement concerning internationalization and resource files was correct. Unix has no equivalent of App Studio, etc. I have made a little tour of people in my company who work on both unix and Windows. I (fortunately) work primarily on Windows, as you may have guessed. The company I presently work for is making a tool they call Window Painter. This is in some respects similar to App Studio. It works with their unix database language. But it is no App Studio, as the unix folk who are working on it freely admit, those few of them that have used App Studio. Most of my correspondents had replies along the lines of "Huh -- internationalization -- what source code tools could possibly help you with internationalization." Others listed irregular bands of random unix tools which are essentially irrelevant to the problem of internationalization. Most international unix programs have string files that the compiled program refers to a string by a number, and a font size by a number, and the position of the button on screen by a number -- site customizable information, Xdefaults, *.cfg This is functionally equivalent to the Windows Resource file, in that in principle one can keep translatable elements separate from source code. But is certainly not equivalent in ease of use. One can do the job, but in essense one does it by hand. Resource files, and dialog box editing tools such as App Studio, provide a clean separation between visual user interface elements that typically require translation, and functiona code that does not. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd@netcom.com