From owner-freebsd-security Sun Feb 18 00:45:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA02903 for security-outgoing; Sun, 18 Feb 1996 00:45:43 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA02893 for ; Sun, 18 Feb 1996 00:45:36 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id KAA18356; Sun, 18 Feb 1996 10:44:48 +0200 (SAT) Message-Id: <199602180844.KAA18356@grumble.grondar.za> To: Peter Wemm cc: security@FreeBSD.ORG Subject: Re: kerberos4/eBones security hole... Date: Sun, 18 Feb 1996 10:44:46 +0200 From: Mark Murray Sender: owner-security@FreeBSD.ORG Precedence: bulk Peter Wemm wrote: > Anybody want to bet on whether this is another > random-number-that's-not-quite-so-random problem? :-) I was beginning to think so. If so, we have the answer - /dev/random. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Wed Feb 21 15:13:50 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA07981 for security-outgoing; Wed, 21 Feb 1996 15:13:50 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA07975 Wed, 21 Feb 1996 15:13:39 -0800 (PST) Received: by sequent.kiae.su id AA09209 (5.65.kiae-2 ); Thu, 22 Feb 1996 02:03:00 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Thu, 22 Feb 96 02:02:59 +0300 Received: (from ache@localhost) by ache.dialup.ru (8.7.3/8.7.3) id CAA04753; Thu, 22 Feb 1996 02:02:31 +0300 (MSK) To: current@freebsd.org, dyson@freebsd.org, security@freebsd.org Message-Id: Organization: Olahm Ha-Yetzirah Date: Thu, 22 Feb 1996 02:02:30 +0300 (MSK) X-Mailer: Mail/@ [v2.42 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Serious error in pipe code (v1.12), affects 'ssh' Lines: 13 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk Due to error in pipe code 'scp' from 'ssh' package not always work with file size >= 8192 bytes, it hangs forever, here ps lines: 112 4678 167 0 -6 0 176 588 pipdwt S v3 0:00.06 scp 111 dt 0 4679 4678 0 2 0 640 1156 select S v3 0:00.61 /usr/local/bin/ssh -x -a -oFallBackToRsh dt scp -t . BTW, it always work with file sizes < 8192. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Thu Feb 22 13:51:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA21856 for security-outgoing; Thu, 22 Feb 1996 13:51:46 -0800 (PST) Received: from kremvax.demos.su (root@ns.demos.su [194.87.0.9]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA21846 for ; Thu, 22 Feb 1996 13:51:36 -0800 (PST) Received: by kremvax.demos.su (8.6.12/D) from ache.dialup.ru [194.87.17.241] with SMTP id AAA14654; Fri, 23 Feb 1996 00:46:50 +0300 Message-Id: <2.2.32.19960222214653.00678294@dt.demos.su> X-Sender: ache@dt.demos.su X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Feb 1996 00:46:53 +0300 To: mark@grondar.za, security@freebsd.org From: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage)" Subject: SSLeay library as port? Sender: owner-security@freebsd.org Precedence: bulk What do you think about it? I doubt it can be integrated to main tree due to RSAREF/RC4/IDEA problems, but having it as port looks safe in all senses. Next step I think will be Apache-SSL. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Thu Feb 22 17:53:05 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA08491 for security-outgoing; Thu, 22 Feb 1996 17:53:05 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA08484 for ; Thu, 22 Feb 1996 17:52:56 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.3/nervosa.com.2) with SMTP id RAA12361 for ; Thu, 22 Feb 1996 17:52:31 -0800 (PST) Date: Thu, 22 Feb 1996 17:52:30 -0800 (PST) From: invalid opcode To: freebsd-security@freebsd.org Subject: BoS: (fwd) CERT Advisory CA-96.04 - Corrupt Information from Network Servers (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk This is from Best of Security, as a result of this, sendmail has been upgraded to 8.7.4 == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == ---------- Forwarded message ---------- Date: Thu, 22 Feb 1996 15:58:36 -0600 (CST) From: Noam Freedman To: best-of-security@suburbia.net Subject: BoS: (fwd) CERT Advisory CA-96.04 - Corrupt Information from Network Servers ============================================================================= CERT(sm) Advisory CA-96.04 February 22, 1996 Topic: Corrupt Information from Network Servers ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of intruders exploiting systems by corrupting data provided by a Domain Name Service (DNS) server. Although these reports have focused only on DNS, this vulnerability could apply to any network service from which data is received and subsequently used. Section III.A contains a pointer to two subroutines that address the DNS problem. These subroutines, written in the C programming language, can be used to validate host names and IP addresses according to RFCs 952 and 1123, as well as names containing characters drawn from common practice, namely "_" and "/". In the specific case of sendmail, the problem has already been addressed by patches (see Section III.B). As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-96.04.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description Information provided by an information server may be of a form that could cause programs to operate in unexpected ways. The subroutines and programs transferring data from that information server could check the data for correctness of form; however, programs that *use* that data are ultimately responsible for ensuring adherence to the documents that define the correct form. For example, consider a program that uses the host name returned by gethostbyname() as part of the string given to the popen() or system() subroutines. Because gethostbyname() may use an information server beyond your control, the data returned could be of a form that causes the popen() or system() subroutines to execute other commands besides the command specified by that program. This advisory speaks to a specific instance of a problem caused by the information returned by DNS, but information from any server should be checked for validity. Examples of other information servers are YP, NIS, NIS+, and netinfo. II. Impact Programs that do not check data provided by information servers may operate in unpredictable ways and give unexpected results. In particular, exploitation of this vulnerability may allow remote access by unauthorized users. Exploitation can also lead to root access by both local and remote users. III. Solution For programs that you write or have written, consider integrating the general solution in Section A below. In the specific case of the sendmail mail delivery program, Eric Allman, the original author of sendmail, has produced patches that address the problem. Section B provides details about these, along with vendor information and additional steps you should take to protect sendmail. A. General solution for Internet host names Use the host name and IP address validation subroutines available at the locations listed below. Include them in all programs that use the result of the host name lookups in any way. ftp://info.cert.org/pub/tools/ValidateHostname/IsValid.c ftp://ftp.cert.dfn.de/pub/tools/net/ValidateHostname/IsValid.c Checksum: MD5 (IsValid.c) = 9456f2f5dcb226eaa19a72256c8d1922 The IsValid.c file contains code for the IsValidHostname and IsValidIPAddress subroutines. This code can be used to check host names and IP addresses for validity according to RFCs 952 and 1123, well as names containing characters drawn from common practice, namely "_" and "/". B. Specific solutions in the case of sendmail Install a patch from your vendor when it becomes available (see B.1) or install Eric Allman's patch (B.2). In both cases, install the sendmail restricted shell program (B.3). 1. Install a patch from your vendor. Below is a summary of the vendors who have reported status to us as of the date of this advisory. More complete information is provided in the appendix of this advisory and reproduced in the CA-96.04.README file. We will update the README file as we receive more information. If your vendor's name is not on this list, please contact the vendor directly. Vendor or Source Status ---------------- ------------ Eric Allman Patches available. Hewlett-Packard Co. Vulnerable, watch readme file for updates. IBM Corporation Working on fixes for sendmail. Silicon Graphics Inc. Patch planned. 2. Install a patch to sendmail. If you are presently running sendmail 8.6.12, there is a patch that makes version 8.6.13. Similarly, if you are presently running sendmail 8.7.3, there is a patch that makes version 8.7.4. The patches are available for anonymous FTP from ftp://info.cert.org/pub/tools/sendmail/ ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/ ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/ Checksums for the 8.6.13 release: MD5 (sendmail.8.6.13.base.tar.Z) = e8cf3ea19876d9b9def5c0bcb793d241 MD5 (sendmail.8.6.13.cf.tar.Z) = 4492026fa9e750cd33974322cb5a6fb9 MD5 (sendmail.8.6.13.misc.tar.Z) = 7ec5d31656e93e08a3892f0ae542b674 MD5 (sendmail.8.6.13.xdoc.tar.Z) = e4d3caebcdc4912ed2ecce1a77e45712 Checksum for the 8.6.13 patch: MD5 (sendmail.8.6.13.patch) = 6390b792cb5513ff622da8791d6d2073 Checksum for the 8.7.4 release: MD5 (sendmail.8.7.4.tar.Z) = 4bf774a12752497527aae11e2bdbab36 Checksum for the 8.7.4 patch: MD5 (sendmail.8.7.4.patch) = ef828ad91fe56e4eb6b0cacced864cd5 3. Run smrsh as additional protection for sendmail. With all versions of sendmail, we recommend that you install and use the sendmail restricted shell program (smrsh). We urge you to do this whether you use the vendor's supplied sendmail, install sendmail yourself, or patch an earlier version of sendmail. Beginning with version 8.7.1, smrsh is included in the sendmail distribution, in the subdirectory smrsh. See the RELEASE_NOTES file for a description of how to integrate smrsh into your sendmail configuration file. --------------------------------------------------------------------------- The CERT Coordination Center thanks Eric Allman of Pangaea Reference Systems, Andrew Gross of San Diego Supercomputer Center, Eric Halil of AUSCERT, Wolfgang Ley of DFN-CERT, and Paul Vixie for their support in the development of this advisory. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). 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 To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request@cert.org CERT publications, information about FIRST representatives, and other security-related information are available for anonymous FTP from ftp://info.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce Copyright 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. ......................................................................... Appendix A: Vendor Information Current as of February 22, 1996 See CA-96.04.README for updated information. Below is information we have received from vendors concerning the vulnerability described in this advisory. If you do not see your vendor's name, please contact the vendor directly for information. ----------------------- Eric Allman (original author of sendmail) Install a patch to sendmail. If you are presently running sendmail 8.6.12, there is a patch that makes version 8.6.13. Similarly, if you are presently running sendmail 8.7.3, there is a patch that makes version 8.7.4. The patches are available for anonymous FTP from ftp://info.cert.org/pub/tools/sendmail/ ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/ ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/ Checksums for the 8.6.13 release: MD5 (sendmail.8.6.13.base.tar.Z) = e8cf3ea19876d9b9def5c0bcb793d241 MD5 (sendmail.8.6.13.cf.tar.Z) = 4492026fa9e750cd33974322cb5a6fb9 MD5 (sendmail.8.6.13.misc.tar.Z) = 7ec5d31656e93e08a3892f0ae542b674 MD5 (sendmail.8.6.13.xdoc.tar.Z) = e4d3caebcdc4912ed2ecce1a77e45712 Checksum for the 8.6.13 patch: MD5 (sendmail.8.6.13.patch) = 6390b792cb5513ff622da8791d6d2073 Checksum for the 8.7.4 release: MD5 (sendmail.8.7.4.tar.Z) = 4bf774a12752497527aae11e2bdbab36 Checksum for the 8.7.4 patch: MD5 (sendmail.8.7.4.patch) = ef828ad91fe56e4eb6b0cacced864cd5 ---------------------- Hewlett-Packard Company Vulnerable, watch readme file for updates. ---------------------- IBM Corporation IBM is working on fixes for sendmail. ---------------------- Silicon Graphics Inc. At the time of writing of this document, a patch is planned for IRIX versions 5.2, 5.3, 6.0, 6.0.1 and 6.1 for this issue. This patch along with previous SGI Advisories and security patches can be obtained via anonymous FTP from sgigate.sgi.com or its mirror, ftp.sgi.com. SGI security patches and advisories are provided freely to all interested parties. The advisories and patches can be found in either the ~ftp/patches or ~ftp/security directories along with more current pertinent information. For assistance obtaining or working with security patches, please contact your SGI support provider. From owner-freebsd-security Thu Feb 22 17:53:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA08598 for security-outgoing; Thu, 22 Feb 1996 17:53:52 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA08529 for ; Thu, 22 Feb 1996 17:53:14 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.3/nervosa.com.2) with SMTP id RAA12380 for ; Thu, 22 Feb 1996 17:53:05 -0800 (PST) Date: Thu, 22 Feb 1996 17:53:05 -0800 (PST) From: invalid opcode To: freebsd-security@freebsd.org Subject: BoS: ASR --- Remote Pcnfsd Exploit (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk As below. == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == ---------- Forwarded message ---------- Date: Thu, 22 Feb 1996 10:39:44 -0700 From: mcpheea@cadvision.com To: best-of-security@suburbia.net Subject: BoS: ASR --- Remote Pcnfsd Exploit Avalon Security Research Release 1996.1 (pcnfsd) The following uuencoded attachment is a copy of the remote exploit for rpc.pcnfsd. The semantics to the bug as well as a suggested fix were released via the list on 02/13/96. If you for some reason missed this this mail, it has been packaged with this release. If you are not on the ASR mailing list you may subscribe by sending mail to mcpheea@cadvision.com with word 'SUB' or 'sub' in the body. Note: When subscribing the word sub should be the only non-whitespace on the line. Avalon Security Research All replies should be directed to mcpheea@cadvision.com begin 644 slugger2.tar M2!297-E87)C:`H@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@(%)E;&5A`H*("`@069F96-T.B!296UO=&4@871T86-K97)S(&UA M>2!E>&5C=71E(&%N(&%R8FET2!C;VUM86YD(&%S(')O;W0@;VX@"B`@ M("`@("`@("`@=&AE('1A2!C86QL('1O(&ET(&EN M('!R7W-T87)T("AP8VYF2!U;F1E"X@($%34B!W96QC;VUE7-T96US+@H*("`@ M4V]U2!B92!D:7)E8W1E9"!T;R!M8W!H965A M0&-A9'9I2X@(`I.;W1E.B`@=VAE;B!S=6)S8W)I8FEN9R!T:&4@=V]R9"!S=6(@ M``````````````````` M```````````````````````````````````````````````````````````` M````````````````````````````````````````````("`@-S4U(``@("`@ M(#`@`"`@("`@,2``("`@("`@(#,P,38@(#8Q,3(P-#4S-C,@("`U-#4W`"`` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````````````````"\J(&UY M<&-N9G-D+G@*("H@0GD@2!N;R!I9&5A('=H>2!T:&ES(&ES(&AEPH@("!04U]215-?3TL],"P*("`@ M4%-?4D537T%,4D5!1%D],2P@("`@("`@("`@+RH@86QR96%D>2!Q=65U960@ M*B\@("`*("`@4%-?4D537TY53$P],BP*("`@4%-?4D537TY/7T9)3$4],RP* M("`@4%-?4D537T9!24P]-`I].PH@"F-O;G-T(%5315),14X@/2`S,CL*8V]N M7!E M9&5F('-T7-E;&8\55-%4DQ%3CX["G1Y<&5D968@7-E;&8@86%?:61E;G0["B`@ M(&=E;G-TPH@ M("!E;G5M(&%R'!L;VET('1O(&9A:6PN"B`J($EF(')P8RYP M8VYF2!I7,@9F%I;"!A;F0@<')I;G0@=&AE(&5R7,@=&EM97,@;W5T(&]N="!I="=S('!R7W-T87)T(&-A M;&P@8F5C875S92!R<&,N<&-N9G-D"B`J("`@(&1I97,@8F5F;W)E(&ET(&=E M=',@82!C:&%N8V4@=&\@"!F;W(@=&AI2!S;6%L;"!F;W(@ M=&AE('!R7W-T87)T(&-A;&PN"B`J"B`J("HJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BH*("H*("H@5&AI2!R97-P;VYS:6)I;&ET>2!F;W(@=&AE('5S90H@*B`@("!O M7,O=&EM92YH/@HC:6YC;'5D92`\2!R M<&-G96X@*B\*(`H@"FEN="!M86EN*&%R9V,L(&%R9W8I"FEN="!APH@("`*("`@8VAAR`@<')I;G1F*")C;VUM86YD(&UU2`] M($%&7TE.150["B`@(&1A6AOT$Z/21( M3TU%?2XN)$$N+B1[07UB:6XD>T%]'!L;VET+"`@:70@&EN9R!T:&ES+B`@*B\*"B`@("\J('-I M;7!L92!M:6YDR`@<')I;G1F*")%; Thu, 22 Feb 1996 18:14:57 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id SAA12870 for ; Thu, 22 Feb 1996 18:14:54 -0800 (PST) Date: Thu, 22 Feb 1996 18:14:53 -0800 (PST) From: invalid opcode To: freebsd-security@freebsd.org Subject: Alert: UDP Port Denial-of-Service Attack (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk As below. == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == ---------- Forwarded message ---------- Date: Thu, 8 Feb 1996 13:29:07 +1494730 (EST) From: Christopher Klaus To: alert@iss.net Subject: Alert: UDP Port Denial-of-Service Attack ============================================================================= CERT(sm) Advisory CA-96.01 February 8, 1996 Topic: UDP Port Denial-of-Service Attack ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of programs that launch denial-of-service attacks by creating a "UDP packet storm" either on a system or between two systems. An attack on one host causes that host to perform poorly. An attack between two hosts can cause extreme network congestion in addition to adversely affecting host performance. The CERT staff recommends disabling unneeded UDP services on each host, in particular the chargen and echo services, and filtering these services at the firewall or Internet gateway. Because the UDP port denial-of-service attacks typically involve IP spoofing, we encourage you to follow the recommendations in advisory CA-95:01 and CA-95:01.README. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-96.01.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description When a connection is established between two UDP services, each of which produces output, these two services can produce a very high number of packets that can lead to a denial of service on the machine(s) where the services are offered. Anyone with network connectivity can launch an attack; no account access is needed. For example, by connecting a host's chargen service to the echo service on the same or another machine, all affected machines may be effectively taken out of service because of the excessively high number of packets produced. In addition, if two or more hosts are so connected, the intervening network may also become congested and deny service to all hosts whose traffic traverses that network. II. Impact Anyone with network connectivity can cause a denial of service. This attack does not enable them to gain additional access. III. Solution We recommend taking all the steps described below. 1. Disable and filter chargen and echo services. This attack is most readily exploited using the chargen or echo services, neither of which is generally needed as far as we are aware. We recommend that you disable both services on the host and filter them at the firewall or Internet gateway. To disable these services on a host, it is necessary to edit the inetd configuration file and cause inetd to begin using the new configuration. Exactly how to do this is system dependent so you should check your vendor's documentation for inetd(8); but on many UNIX systems the steps will be as follows: (1) Edit the inetd configuration file (e.g. /etc/inetd.conf). (2) Comment out the echo, chargen, and other UDP services not used. (3) Cause the inetd process to reread the configuration file (e.g., by sending it a HUP signal). 2. Disable and filter other unused UDP services. To protect against similar attacks against other services, we recommend - disabling all unused UDP services on hosts and - blocking at firewalls all UDP ports less than 900 with the exception of specific services you require, such as DNS (port 53). 3. If you must provide external access to some UDP services, consider using a proxy mechanism to protect that service from misuse. Techniques to do this are discussed in Chapter 8, "Configuring Internet Services," in _Building Internet Firewalls_ by Chapman and Zwicky (see Section IV below). 4. Monitor your network. If you do provide external UDP services, we recommend monitoring your network to learn which systems are using these services and to monitor for signs of misuse. Tools for doing so include Argus, tcpdump, and netlog. Argus is available from ftp://lancaster.andrew.cmu.edu/pub/argus-1.5/argus-1.5.tar.gz MD5 (argus-1.5.tar.gz) = 9c7052fb1742f9f6232a890267c03f3c Note that Argus requires the TCP wrappers to install: ftp://info.cert.org/pub/tools/tcp_wrappers/tcp_wrappers_7.2.tar.Z MD5 (tcp_wrappers_7.2.tar.Z) = 883d00cbd2dedd9bfc783b7065740e74 tcpdump is available from ftp://ftp.ee.lbl.gov/tcpdump-3.0.2.tar.Z MD5 (tcpdump-3.0.2.tar.Z) = c757608d5823aa68e4061ebd4753e591 Note that tcpdump requires libpcap, available at ftp://ftp.ee.lbl.gov/libpcap-0.0.6.tar.Z MD5 (libpcap-0.0.6.tar.Z) = cda0980f786932a7e2eebfb2641aa7a0 netlog is available from ftp://net.tamu.edu/pub/security/TAMU/netlog-1.2.tar.gz MD5 (netlog-1.2.tar.gz) = 1dd62e7e96192456e8c75047c38e994b 5. Take steps against IP spoofing. Because IP spoofing is typically involved in UDP port denial-of-service attacks, we encourage you to follow the guidance in advisory CA-95:01 and CA-95:01.README, available from ftp://info.cert.org/pub/cert_advisories/CA-95:01.IP.spoofing ftp://info.cert.org/pub/cert_advisories/CA-95:01.README IV. Sources of further information about packet filtering For a general packet-filtering recommendations, see ftp://info.cert.org/pub/tech_tips/packet_filtering For in-depth discussions of how to configure your firewall, see _Firewalls and Internet Security: Repelling the Wily Hacker_ William R. Cheswick and Steven M. Bellovin Addison-Wesley Publishing Company, 1994 ISBN 0-201-63357 _Building Internet Firewalls_ Brent Chapman and Elizabeth D. Zwicky O'Reilly & Associates, Inc., 1995 ISBN 1-56592-124-0 --------------------------------------------------------------------------- The CERT Coordination Center staff thanks Peter D. Skopp of Columbia University for reporting the vulnerability and Steve Bellovin of AT&T Bell Labs for his support in responding to this problem. --------------------------------------------------------------------------- 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). 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 To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request@cert.org CERT publications, information about FIRST representatives, and other security-related information are available for anonymous FTP from ftp://info.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce Copyright 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. -- Christopher William Klaus Voice: (404)252-7270. Fax: (404)252-2427 Internet Security Systems, Inc. "Internet Scanner finds Ste. 115, 5871 Glenridge Dr, Atlanta, GA 30328 your network security holes Web: http://iss.net/ Email: cklaus@iss.net before the hackers do." From owner-freebsd-security Thu Feb 22 19:03:17 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA14438 for security-outgoing; Thu, 22 Feb 1996 19:03:17 -0800 (PST) Received: from cocoa.ops.neosoft.com (root@cocoa.ops.neosoft.com [206.109.5.227]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA14431 for ; Thu, 22 Feb 1996 19:03:10 -0800 (PST) Received: (from dbaker@localhost) by cocoa.ops.neosoft.com (8.7.3/8.6.12) id VAA00333; Thu, 22 Feb 1996 21:02:46 -0600 (CST) Date: Thu, 22 Feb 1996 21:02:46 -0600 (CST) From: Daniel Baker X-Sender: dbaker@cocoa.ops.neosoft.com To: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage)" cc: mark@grondar.za, security@FreeBSD.org Subject: Re: SSLeay library as port? In-Reply-To: <2.2.32.19960222214653.00678294@dt.demos.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org Precedence: bulk I have gotten the apache-ssl port working and have made a certifiate and all. Works fine on FreeBSD On Fri, 23 Feb 1996, =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) wrote: > What do you think about it? I doubt it can be integrated to main tree > due to RSAREF/RC4/IDEA problems, but having it as port looks safe > in all senses. > > Next step I think will be Apache-SSL. > -- > Andrey A. Chernov : And I rest so composedly, /Now, in my bed, > ache@astral.msk.su : That any beholder /Might fancy me dead - > http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead > RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 > > Daniel Baker - Daniel@Cuckoo.COM "Uhhhhhhh, thank you, drive through please" From owner-freebsd-security Thu Feb 22 22:00:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA13611 for security-outgoing; Thu, 22 Feb 1996 22:00:55 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA13605 for ; Thu, 22 Feb 1996 22:00:48 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id HAA25584; Fri, 23 Feb 1996 07:59:54 +0200 (SAT) Message-Id: <199602230559.HAA25584@grumble.grondar.za> To: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage)" cc: mark@grondar.za, security@freebsd.org Subject: Re: SSLeay library as port? Date: Fri, 23 Feb 1996 07:59:51 +0200 From: Mark Murray Sender: owner-security@freebsd.org Precedence: bulk "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage)" wrote: > What do you think about it? I doubt it can be integrated to main tree > due to RSAREF/RC4/IDEA problems, but having it as port looks safe > in all senses. I will be importing it this weekend. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Thu Feb 22 22:22:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA14679 for security-outgoing; Thu, 22 Feb 1996 22:22:09 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA14620 for ; Thu, 22 Feb 1996 22:20:37 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id IAA25726; Fri, 23 Feb 1996 08:17:56 +0200 (SAT) Message-Id: <199602230617.IAA25726@grumble.grondar.za> To: Daniel Baker cc: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage)" , mark@grondar.za, security@FreeBSD.org Subject: Re: SSLeay library as port? Date: Fri, 23 Feb 1996 08:17:55 +0200 From: Mark Murray Sender: owner-security@FreeBSD.org Precedence: bulk Daniel Baker wrote: > I have gotten the apache-ssl port working and have made a certifiate > and all. > > Works fine on FreeBSD What version of apache? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Thu Feb 22 23:26:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA16983 for security-outgoing; Thu, 22 Feb 1996 23:26:43 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA16972 for ; Thu, 22 Feb 1996 23:26:33 -0800 (PST) Received: by sequent.kiae.su id AA04945 (5.65.kiae-2 ); Fri, 23 Feb 1996 10:18:21 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Fri, 23 Feb 96 10:18:20 +0300 Received: (from ache@localhost) by ache.dialup.ru (8.7.3/8.7.3) id KAA00255; Fri, 23 Feb 1996 10:12:00 +0300 (MSK) To: Daniel Baker , Mark Murray Cc: security@FreeBSD.org References: <199602230617.IAA25726@grumble.grondar.za> In-Reply-To: <199602230617.IAA25726@grumble.grondar.za>; from Mark Murray at Fri, 23 Feb 1996 08:17:55 +0200 Message-Id: Organization: Olahm Ha-Yetzirah Date: Fri, 23 Feb 1996 10:12:00 +0300 (MSK) X-Mailer: Mail/@ [v2.42 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: SSLeay library as port? Lines: 18 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org Precedence: bulk In message <199602230617.IAA25726@grumble.grondar.za> Mark Murray writes: >Daniel Baker wrote: >> I have gotten the apache-ssl port working and have made a certifiate >> and all. >> >> Works fine on FreeBSD >What version of apache? Look at www.apache.org, there is poiner to Apache-SSL. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Fri Feb 23 01:47:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA23792 for security-outgoing; Fri, 23 Feb 1996 01:47:48 -0800 (PST) Received: from zip.io.org (root@zip.io.org [198.133.36.80]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA23786 for ; Fri, 23 Feb 1996 01:47:44 -0800 (PST) Received: (from taob@localhost) by zip.io.org (8.6.12/8.6.12) id EAA03240; Fri, 23 Feb 1996 04:11:14 -0500 Date: Fri, 23 Feb 1996 04:11:14 -0500 (EST) From: Brian Tao To: FREEBSD-SECURITY-L Subject: Informing users of cracked passwords? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk What is generally the best approach to handling a situation in an ISP where a large of number of users (e.g., over 1000) are found to have vulnerable passwords? We ran Crack on our master.passwd for a week or so, and after the dust settled, over 1700 accounts were exposed. This is what we did: 1) Gave no warning to our users (we didn't want to alert hackers to our crackdown on bad passwords) 2) Installed a new passwd binary linked with libcrack 3) Expired all affected passwords and set home directories to mode 000 (mainly to deny access to the .rhosts file and public_html directory 4) Required that new passwords be provided via voice call to our customer support desk From previous discussions in security-related newsgroups, I am under the impression that the best policy for a public-access site is a clean sweep like this. No warning off the impending cut-off date, and force the user to specify a better password. Does anyone have any counter-advice to the above method? -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-security Fri Feb 23 02:01:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA24563 for security-outgoing; Fri, 23 Feb 1996 02:01:21 -0800 (PST) Received: from haywire.DIALix.COM (root@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA24555 for ; Fri, 23 Feb 1996 02:01:14 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.6.12/8.6.12) id SAA26122 for freebsd-security@freebsd.org; Fri, 23 Feb 1996 18:02:37 +0800 Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-security@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-security@freebsd.org Date: 23 Feb 96 10:00:07 GMT From: peter@jhome.DIALix.COM (Peter Wemm) Message-ID: Organization: DIALix Services, Perth, Australia. References: Subject: Re: BoS: (fwd) CERT Advisory CA-96.04 - Corrupt Information from Network Servers (fwd) Sender: owner-security@freebsd.org Precedence: bulk coredump@nervosa.com (invalid opcode) writes: >This is from Best of Security, as a result of this, sendmail has been >upgraded to 8.7.4 >== Chris Layne ============================================================== >== coredump@nervosa.com ================= http://www.nervosa.com/~coredump == >---------- Forwarded message ---------- >Date: Thu, 22 Feb 1996 15:58:36 -0600 (CST) >From: Noam Freedman >To: best-of-security@suburbia.net >Subject: BoS: (fwd) CERT Advisory CA-96.04 - Corrupt Information from Network Servers >============================================================================= >CERT(sm) Advisory CA-96.04 >February 22, 1996 BTW, I already updated the one in -current to 8.7.4 (from 8.7.3) a few hours after Eric Allman released it. I'm looking at the -stable one now.. -Peter From owner-freebsd-security Fri Feb 23 07:36:05 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA15629 for security-outgoing; Fri, 23 Feb 1996 07:36:05 -0800 (PST) Received: from rk.ios.com (rk.ios.com [198.4.75.55]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA15597 for ; Fri, 23 Feb 1996 07:35:59 -0800 (PST) Received: (from rashid@localhost) by rk.ios.com (8.6.11/8.6.9) id KAA08081; Fri, 23 Feb 1996 10:35:30 -0500 From: Rashid Karimov Message-Id: <199602231535.KAA08081@rk.ios.com> Subject: Re: Informing users of cracked passwords? To: taob@io.org (Brian Tao) Date: Fri, 23 Feb 1996 10:35:30 -0500 (EST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from "Brian Tao" at Feb 23, 96 04:11:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG Precedence: bulk Hi there folx, > > What is generally the best approach to handling a situation in an > ISP where a large of number of users (e.g., over 1000) are found to > have vulnerable passwords? Oh boy ! :) It happens all the time - some clients ( probably 3-4%) who know how to use passwd program , have access to the shell and don;t realize the vulnerability they get by using weak passwords - just change it - to the most popular ones. Happens all the time. I remember passwd program on SCO - that was really perfect thing! Admin could force users to change passwds regularly( bad for ISP), make him use only _generated passwords , old passwords and their variation couldn't be used also. Expiration is definitely not the way to go - since a lot of clients use shell _very occasionally , and what will happen is they won't be able to use POP3 ( precious Eudora :), ftp will fail etc. > > We ran Crack on our master.passwd for a week or so, and after the > dust settled, over 1700 accounts were exposed. This is what we did: > > 1) Gave no warning to our users (we didn't want to alert hackers to > our crackdown on bad passwords) > > 2) Installed a new passwd binary linked with libcrack > > 3) Expired all affected passwords and set home directories to mode > 000 (mainly to deny access to the .rhosts file and public_html > directory > > 4) Required that new passwords be provided via voice call to our > customer support desk > > From previous discussions in security-related newsgroups, I am > under the impression that the best policy for a public-access site > is a clean sweep like this. No warning off the impending cut-off > date, and force the user to specify a better password. Looks like the way to go with 1000 accounts. Is there a passwd program which will force person to use one of the generated passwords ? I think it would be very useful ... Rashid From owner-freebsd-security Fri Feb 23 07:37:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA15750 for security-outgoing; Fri, 23 Feb 1996 07:37:52 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA15742 for ; Fri, 23 Feb 1996 07:37:45 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA03433; Fri, 23 Feb 1996 10:37:33 -0500 Date: Fri, 23 Feb 1996 10:37:33 -0500 From: "Garrett A. Wollman" Message-Id: <9602231537.AA03433@halloran-eldar.lcs.mit.edu> To: invalid opcode Cc: freebsd-security@freebsd.org, cert@cert.org Subject: Alert: UDP Port Denial-of-Service Attack (fwd) In-Reply-To: References: Sender: owner-security@freebsd.org Precedence: bulk < said: [Regarding CA-96.01] > The CERT staff recommends disabling unneeded UDP services on each host, in > particular the chargen and echo services, and filtering these services at the > firewall or Internet gateway. I have been aware of this problem for more than a year now, and a former graduate student colleague of mine for much longer than that. In late 1994, I took steps to ensure that FreeBSD is not vulnerable to this problem to the same extent as other systems, as FreeBSD's inetd will refuse to respond to requests for ``internal'' services that appear to be coming from ports of other ``internal'' services (those being in particular `echo', `daytime', `chargen', and `discard'). Note in particular the following changes (being the security fixes in inetd that I am aware of): revision 1.11 date: 1996/02/07 17:15:01; author: wollman; state: Exp; lines: +3 -1 Call setsockopt(SO_PRIVSTATE) to renounce SS_PRIV on all the sockets we create. (Nothing being called from inetd should use it anyway, but you can never be too careful.) Translate the man page back into -mdoc. ---------------------------- revision 1.4 date: 1994/12/21 19:08:45; author: wollman; state: Exp; lines: +63 -17 Disable UDP service looping attack. ---------------------------- The second change is the relevant one to this case, and may be of value to users in campus environments or other situations where firewalling is impractical. The following patch should apply to most 4.4BSD-derived inetd programs: =================================================================== RCS file: /home/ncvs/src/usr.sbin/inetd/inetd.c,v retrieving revision 1.3 retrieving revision 1.4 diff -c -r1.3 -r1.4 *** inetd.c 1994/09/11 11:16:32 1.3 --- inetd.c 1994/12/21 19:08:45 1.4 *************** *** 39,45 **** #ifndef lint /* from: @(#)inetd.c 8.4 (Berkeley) 4/13/94"; */ ! static char RCSid[] = "$Id"; #endif /* not lint */ /* --- 39,46 ---- #ifndef lint /* from: @(#)inetd.c 8.4 (Berkeley) 4/13/94"; */ ! static char inetd_c_rcsid[] = ! "$Id: inetd.c,v 1.4 1994/12/21 19:08:45 wollman Exp $"; #endif /* not lint */ /* *************** *** 1084,1089 **** --- 1085,1112 ---- exit(0); } + int check_loop(sin, sep) + struct sockaddr_in *sin; + struct servtab *sep; + { + struct servtab *se2; + + for (se2 = servtab; se2; se2 = se2->se_next) { + if (!se2->se_bi || se2->se_socktype != SOCK_DGRAM) + continue; + + if (sin->sin_port == se2->se_ctrladdr.sin_port) { + syslog(LOG_WARNING, + "%s/%s:%s/%s loop request REFUSED from %s", + sep->se_service, sep->se_proto, + se2->se_service, se2->se_proto, + inet_ntoa(sin->sin_addr)); + return 1; + } + } + return 0; + } + /* ARGSUSED */ void echo_dg(s, sep) /* Echo service -- echo data back */ *************** *** 1092,1103 **** { char buffer[BUFSIZE]; int i, size; ! struct sockaddr sa; ! size = sizeof(sa); ! if ((i = recvfrom(s, buffer, sizeof(buffer), 0, &sa, &size)) < 0) return; ! (void) sendto(s, buffer, i, 0, &sa, sizeof(sa)); } /* ARGSUSED */ --- 1115,1132 ---- { char buffer[BUFSIZE]; int i, size; ! struct sockaddr_in sin; ! size = sizeof(sin); ! if ((i = recvfrom(s, buffer, sizeof(buffer), 0, ! (struct sockaddr *)&sin, &size)) < 0) return; ! ! if (check_loop(&sin, sep)) ! return; ! ! (void) sendto(s, buffer, i, 0, (struct sockaddr *)&sin, ! sizeof(sin)); } /* ARGSUSED */ *************** *** 1186,1192 **** int s; struct servtab *sep; { ! struct sockaddr sa; static char *rs; int len, size; char text[LINESIZ+2]; --- 1215,1221 ---- int s; struct servtab *sep; { ! struct sockaddr_in sin; static char *rs; int len, size; char text[LINESIZ+2]; *************** *** 1196,1203 **** rs = ring; } ! size = sizeof(sa); ! if (recvfrom(s, text, sizeof(text), 0, &sa, &size) < 0) return; if ((len = endring - rs) >= LINESIZ) --- 1225,1236 ---- rs = ring; } ! size = sizeof(sin); ! if (recvfrom(s, text, sizeof(text), 0, ! (struct sockaddr *)&sin, &size) < 0) ! return; ! ! if (check_loop(&sin, sep)) return; if ((len = endring - rs) >= LINESIZ) *************** *** 1210,1216 **** rs = ring; text[LINESIZ] = '\r'; text[LINESIZ + 1] = '\n'; ! (void) sendto(s, text, sizeof(text), 0, &sa, sizeof(sa)); } /* --- 1243,1250 ---- rs = ring; text[LINESIZ] = '\r'; text[LINESIZ + 1] = '\n'; ! (void) sendto(s, text, sizeof(text), 0, ! (struct sockaddr *)&sin, sizeof(sin)); } /* *************** *** 1255,1268 **** struct servtab *sep; { long result; ! struct sockaddr sa; int size; ! size = sizeof(sa); ! if (recvfrom(s, (char *)&result, sizeof(result), 0, &sa, &size) < 0) return; result = machtime(); ! (void) sendto(s, (char *) &result, sizeof(result), 0, &sa, sizeof(sa)); } /* ARGSUSED */ --- 1289,1308 ---- struct servtab *sep; { long result; ! struct sockaddr_in sin; int size; ! size = sizeof(sin); ! if (recvfrom(s, (char *)&result, sizeof(result), 0, ! (struct sockaddr *)&sin, &size) < 0) ! return; ! ! if (check_loop(&sin, sep)) return; + result = machtime(); ! (void) sendto(s, (char *) &result, sizeof(result), 0, ! (struct sockaddr *)&sin, sizeof(sin)); } /* ARGSUSED */ *************** *** 1288,1303 **** { char buffer[256]; time_t clock; ! struct sockaddr sa; int size; clock = time((time_t *) 0); ! size = sizeof(sa); ! if (recvfrom(s, buffer, sizeof(buffer), 0, &sa, &size) < 0) return; (void) sprintf(buffer, "%.24s\r\n", ctime(&clock)); ! (void) sendto(s, buffer, strlen(buffer), 0, &sa, sizeof(sa)); } /* --- 1328,1349 ---- { char buffer[256]; time_t clock; ! struct sockaddr_in sin; int size; clock = time((time_t *) 0); ! size = sizeof(sin); ! if (recvfrom(s, buffer, sizeof(buffer), 0, ! (struct sockaddr *)&sin, &size) < 0) return; + + if (check_loop(&sin, sep)) + return; + (void) sprintf(buffer, "%.24s\r\n", ctime(&clock)); ! (void) sendto(s, buffer, strlen(buffer), 0, ! (struct sockaddr *)&sin, sizeof(sin)); } /* -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-security Fri Feb 23 09:23:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA22991 for security-outgoing; Fri, 23 Feb 1996 09:23:52 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA22969 for ; Fri, 23 Feb 1996 09:23:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.4/8.6.10) with SMTP id JAA27776; Fri, 23 Feb 1996 09:22:49 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199602231722.JAA27776@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: Informing users of cracked passwords? In-reply-to: Your message of "Fri, 23 Feb 96 04:11:14 EST." Date: Fri, 23 Feb 96 09:22:49 -0800 X-Mts: smtp Sender: owner-security@FreeBSD.org Precedence: bulk Brian Tao wrote: > What is generally the best approach to handling a situation in an > ISP where a large of number of users (e.g., over 1000) are found to > have vulnerable passwords? > > We ran Crack on our master.passwd for a week or so, and after the > dust settled, over 1700 accounts were exposed. This is what we did: > > 1) Gave no warning to our users (we didn't want to alert hackers to > our crackdown on bad passwords) > > 2) Installed a new passwd binary linked with libcrack > > 3) Expired all affected passwords and set home directories to mode > 000 (mainly to deny access to the .rhosts file and public_html > directory One could use TCP/Wrapper to restrict the effectiveness of "r" commands to hosts that you trust thereby negating any entries users have put in their .rhosts files of hosts that you don't trust. > > 4) Required that new passwords be provided via voice call to our > customer support desk > > From previous discussions in security-related newsgroups, I am > under the impression that the best policy for a public-access site > is a clean sweep like this. No warning off the impending cut-off > date, and force the user to specify a better password. > > Does anyone have any counter-advice to the above method? > -- > Brian Tao (BT300, taob@io.org) > Systems Administrator, Internex Online Inc. > "Though this be madness, yet there is method in't" > > Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Fri Feb 23 09:46:23 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA25033 for security-outgoing; Fri, 23 Feb 1996 09:46:23 -0800 (PST) Received: from zip.io.org (root@zip.io.org [198.133.36.80]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA25025 for ; Fri, 23 Feb 1996 09:46:20 -0800 (PST) Received: (from taob@localhost) by zip.io.org (8.6.12/8.6.12) id MAA00100; Fri, 23 Feb 1996 12:45:42 -0500 Date: Fri, 23 Feb 1996 12:45:42 -0500 (EST) From: Brian Tao To: cschuber@orca.gov.bc.ca cc: FREEBSD-SECURITY-L Subject: Re: Informing users of cracked passwords? In-Reply-To: <199602231722.JAA27776@passer.osg.gov.bc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org Precedence: bulk On Fri, 23 Feb 1996, Cy Schubert - BCSC Open Systems Group wrote: > > One could use TCP/Wrapper to restrict the effectiveness of "r" commands to hosts > that you trust thereby negating any entries users have put in their .rhosts > files of hosts that you don't trust. I have tcpd running here, but it only refuses connects for hosts with no reverse DNS or with mismatched forward/reverse records. Since a lot of our users telnet in from elsewhere, I can't maintain a list of "trusted" hosts (this is for an ISP, after all). I could disable .rhosts, but that raises another question. Is it better to allow users to rlogin from an untrusted host to your system, or to force them to authenticate themselves each time and have cleartext passwords flying over the network? It would be so much easier if access was only through modem dialup, and we didn't have to rely on NFS or a distributed password system, or give shell access, etc., etc. :-/ -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-security Fri Feb 23 10:00:02 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA25793 for security-outgoing; Fri, 23 Feb 1996 10:00:02 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA25744 for ; Fri, 23 Feb 1996 09:59:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.4/8.6.10) with SMTP id JAA27883; Fri, 23 Feb 1996 09:57:46 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199602231757.JAA27883@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Brian Tao cc: cschuber@orca.gov.bc.ca, FREEBSD-SECURITY-L Subject: Re: Informing users of cracked passwords? In-reply-to: Your message of "Fri, 23 Feb 96 12:45:42 EST." Date: Fri, 23 Feb 96 09:57:46 -0800 X-Mts: smtp Sender: owner-security@FreeBSD.org Precedence: bulk > On Fri, 23 Feb 1996, Cy Schubert - BCSC Open Systems Group wrote: > > > > One could use TCP/Wrapper to restrict the effectiveness of "r" commands to hosts > > that you trust thereby negating any entries users have put in their .rhosts > > files of hosts that you don't trust. > > I have tcpd running here, but it only refuses connects for hosts > with no reverse DNS or with mismatched forward/reverse records. Since > a lot of our users telnet in from elsewhere, I can't maintain a list > of "trusted" hosts (this is for an ISP, after all). > > I could disable .rhosts, but that raises another question. Is it > better to allow users to rlogin from an untrusted host to your system, > or to force them to authenticate themselves each time and have > cleartext passwords flying over the network? > > It would be so much easier if access was only through modem > dialup, and we didn't have to rely on NFS or a distributed password > system, or give shell access, etc., etc. :-/ You're obviously using TCPD to monitor connections, excluding those connections that are caught by the PARANOID mode code. You could, for example, maintain a simple hosts.allow: ALL EXCEPT rlogind rshd rexecd fingerd: ALL rlogind rshd rexecd: .io.org These two lines restrict rlogin, rsh, and rexec to hosts within the io.org domain while allowing connections to all other services from anywhere in the world. > -- > Brian Tao (BT300, taob@io.org) > Systems Administrator, Internex Online Inc. > "Though this be madness, yet there is method in't" > Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Fri Feb 23 13:32:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA12921 for security-outgoing; Fri, 23 Feb 1996 13:32:41 -0800 (PST) Received: from teamos2.org (NS.TEAMOS2.ORG [205.233.74.98]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA12894 for ; Fri, 23 Feb 1996 13:32:28 -0800 (PST) Received: (from james@localhost) by teamos2.org (8.6.12/8.6.12) id QAA12976; Fri, 23 Feb 1996 16:33:39 -0500 Date: Fri, 23 Feb 1996 16:33:37 -0500 (EST) From: James FitzGibbon To: Rashid Karimov cc: Brian Tao , freebsd-security@FreeBSD.ORG Subject: Re: Informing users of cracked passwords? In-Reply-To: <199602231535.KAA08081@rk.ios.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk On Fri, 23 Feb 1996, Rashid Karimov wrote: > Looks like the way to go with 1000 accounts. > Is there a passwd program which will force person > to use one of the generated passwords ? I think it > would be very useful ... There's an excellent passwd replacement written in PERL that's part of chapter 6 of "Programming Perl". It does bad words, pattern matching, checking against reversed logins, other people's logins, GECOS fields, etc. Being PERL, it could easily be changed to generation of passwords (if that's what you want - I personally don't like it). I believe one can get the source to the programs in that book as a tar file - the perl FAQ has the location j. ---------------------------------------------------------------------------- James FitzGibbon james@teamos2.org TeamOS/2 Online admin Voice:(416)410-0100 Fax:(416)410-0100 ---------------------------------------------------------------------------- From owner-freebsd-security Fri Feb 23 17:31:13 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA29208 for security-outgoing; Fri, 23 Feb 1996 17:31:13 -0800 (PST) Received: from anna.az.com (root@anna.az.com [204.57.139.9]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA29200 for ; Fri, 23 Feb 1996 17:31:10 -0800 (PST) Received: (from yankee@localhost) by anna.az.com (8.6.12/8.6.12) id RAA02660; Fri, 23 Feb 1996 17:32:53 -0800 Date: Fri, 23 Feb 1996 17:32:52 -0800 (PST) From: "az.com" To: freebsd-security@freebsd.org Subject: Re: Alert: UDP Port Denial-of-Service Attack (fwd) In-Reply-To: <9602231537.AA03433@halloran-eldar.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk Regarding the udp denial-of-services attack issues and the discussions of disabling chargen, daytime, echo, etc. Do the similar entries in /etc/inetd.conf that use the same names but are listed as tcp services apply in any way to this as well? What adverse affects would there be to nukeing them all, both the udp and tcp services? While were at it... May I make a suggestion to anyone listening as well... (Cisco?, Wellfleet?, Livingston?) Routers and/or firewall specific devices should be (are they?) programmed with a choke option that looks for and allows a listing of top talkers via snmp in terms of ip address in a similar way one would use a network general to look at top talking macs on a lan. Also the router code should have a choke option to dial down allocated bandwidth to a particular ip address if it goes psycho. The idea here would be able to visually see at a glance a traffic count by ip out of a defined tolerance level. It would just be plain nice to see top ip talkers from out there period. I don't know what *your* experiencing out there, but the internet is getting increasingly nasty and we're going to all (isp's and government computers) need some really sophisticated tools shortly. From owner-freebsd-security Fri Feb 23 17:32:53 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA29469 for security-outgoing; Fri, 23 Feb 1996 17:32:53 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA29462 for ; Fri, 23 Feb 1996 17:32:51 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id RAA01657; Fri, 23 Feb 1996 17:32:29 -0800 (PST) Date: Fri, 23 Feb 1996 17:32:29 -0800 (PST) From: invalid opcode To: James FitzGibbon cc: Rashid Karimov , Brian Tao , freebsd-security@FreeBSD.ORG Subject: Re: Informing users of cracked passwords? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk On Fri, 23 Feb 1996, James FitzGibbon wrote: > On Fri, 23 Feb 1996, Rashid Karimov wrote: > > > Looks like the way to go with 1000 accounts. > > Is there a passwd program which will force person > > to use one of the generated passwords ? I think it There is also a program called passwd+ that can do plenty of this kind of stuff, and can be configured to do custom rules, etc. == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == From owner-freebsd-security Fri Feb 23 20:37:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA01274 for security-outgoing; Fri, 23 Feb 1996 20:37:56 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA01269 for ; Fri, 23 Feb 1996 20:37:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id VAA14882; Fri, 23 Feb 1996 21:37:20 -0700 Message-Id: <199602240437.VAA14882@rover.village.org> To: "az.com" Subject: Re: Alert: UDP Port Denial-of-Service Attack (fwd) Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of Fri, 23 Feb 1996 17:32:52 PST Date: Fri, 23 Feb 1996 21:37:20 -0700 From: Warner Losh Sender: owner-security@FreeBSD.ORG Precedence: bulk : Regarding the udp denial-of-services attack issues and the discussions of : disabling chargen, daytime, echo, etc. : : Do the similar entries in /etc/inetd.conf that use the same names but are : listed as tcp services apply in any way to this as well? : : What adverse affects would there be to nukeing them all, both the udp and : tcp services? You'd not have these services :-) Usually the daytime service can be moderately useful, since it doesn't suffer from the bombing problems (sure, you can get it to generate a packet, but it will be only one). The real problem is with the services that generate an infinite stream of data and/or can be piped into one another. Discard isn't likely to be a problem, since it throws everything away. UDP is, at present, the only thing impacted. It only takes one rogue packet to set them jabbering at each other (which is one reason we don't allow any IP packets with "src" of one of our netblock through our firewall). I don't see how a TCP attack could succeed given the three way handshake that is required by TCP to establish a connection. Somebody prove me wrong :-). Warner From owner-freebsd-security Sat Feb 24 08:44:50 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA21354 for security-outgoing; Sat, 24 Feb 1996 08:44:50 -0800 (PST) Received: from cocoa.ops.neosoft.com (root@cocoa.ops.neosoft.com [206.109.5.227]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA21347 for ; Sat, 24 Feb 1996 08:44:47 -0800 (PST) Received: (from dbaker@localhost) by cocoa.ops.neosoft.com (8.7.3/8.6.12) id KAA03320; Sat, 24 Feb 1996 10:44:03 -0600 (CST) Date: Sat, 24 Feb 1996 10:43:59 -0600 (CST) From: Daniel Baker X-Sender: dbaker@cocoa.ops.neosoft.com To: Mark Murray cc: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage)" , mark@grondar.za, security@FreeBSD.org Subject: Re: SSLeay library as port? In-Reply-To: <199602230617.IAA25726@grumble.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org Precedence: bulk apache 1.0.2 With the SSL patch and such.. Daniel On Fri, 23 Feb 1996, Mark Murray wrote: > Daniel Baker wrote: > > I have gotten the apache-ssl port working and have made a certifiate > > and all. > > > > Works fine on FreeBSD > > What version of apache? > > M > -- > Mark Murray > 46 Harvey Rd, Claremont, Cape Town 7700, South Africa > +27 21 61-3768 GMT+0200 > Finger mark@grondar.za for PGP key > Daniel Baker - Daniel@Cuckoo.COM "Uhhhhhhh, thank you, drive through please" From owner-freebsd-security Sat Feb 24 13:58:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA21413 for security-outgoing; Sat, 24 Feb 1996 13:58:59 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA21406 for ; Sat, 24 Feb 1996 13:58:55 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id XAA20012; Sat, 24 Feb 1996 23:57:22 +0200 (SAT) Message-Id: <199602242157.XAA20012@grumble.grondar.za> To: Daniel Baker cc: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage)" , security@FreeBSD.org Subject: Re: SSLeay library as port? Date: Sat, 24 Feb 1996 23:57:20 +0200 From: Mark Murray Sender: owner-security@FreeBSD.org Precedence: bulk Daniel Baker wrote: > apache 1.0.2 > > With the SSL patch and such.. SSLeay-0.5.1b - KYEO... M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Sat Feb 24 14:10:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA22808 for security-outgoing; Sat, 24 Feb 1996 14:10:46 -0800 (PST) Received: from zap.io.org (root@zap.io.org [198.133.36.81]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA22780 for ; Sat, 24 Feb 1996 14:10:42 -0800 (PST) Received: (from taob@localhost) by zap.io.org (8.6.12/8.6.12) id RAA00397; Sat, 24 Feb 1996 17:10:31 -0500 Date: Sat, 24 Feb 1996 17:10:31 -0500 (EST) From: Brian Tao To: FREEBSD-SECURITY-L Subject: Suspicious symlinks in /tmp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk I know I've read about this kind of hacking attempt before, but I can't seem to locate the information I had on this particular style. It looks like a botched attempt though, by someone who probably read about this vulnerability in a cracker 'zine or CERT/8lgm/bugtraq report. # cd /tmp ; ls -l passwd* lrwxrwxrwt 1 bin user 21 Feb 24 17:04 passwd-link.19573 -> /tmp/passwd-dir.19573 lrwxrwxrwt 1 bin user 21 Feb 24 17:04 passwd-link.20196 -> /tmp/passwd-dir.20196 lrwxrwxrwt 1 bin user 21 Feb 24 17:04 passwd-link.20543 -> /tmp/passwd-dir.20543 Could someone refresh my memory? -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-security Sat Feb 24 22:48:00 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA16707 for security-outgoing; Sat, 24 Feb 1996 22:48:00 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA16702 for ; Sat, 24 Feb 1996 22:47:56 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id WAA06594 for ; Sat, 24 Feb 1996 22:47:54 -0800 (PST) Date: Sat, 24 Feb 1996 22:47:54 -0800 (PST) From: invalid opcode To: freebsd-security@freebsd.org Subject: Draft SET Standard/specs now online at MC and Visa (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk Could be of some use == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == ---------- Forwarded message ---------- Date: Sat, 24 Feb 1996 17:08:01 -0500 (EST) From: H Morrow Long To: sneakers@CS.YALE.EDU Subject: Draft SET Standard/specs now online at MC and Visa The new SET (Secure Electronic Transaction) draft standard/ specs are now online at VISA and Mastercard for downloading. The draft docs were just released yesterday (Feb 23). The docs are available in Word and Postscript file formats for Windows, Unix and the Mac. Check out: http://www.mastercard.com/set/set.htm http://www.visa.com:80/cgi-bin/vee/sf/standard.html?2+0 The Web pages also have information on how to subscribe to the set-discuss mailing list. - Morrow