From owner-freebsd-security Sun Mar 2 00:21:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA28746 for security-outgoing; Sun, 2 Mar 1997 00:21:24 -0800 (PST) Received: from obiwan.aceonline.com.au (obiwan.aceonline.com.au [203.103.90.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA28740 for ; Sun, 2 Mar 1997 00:21:19 -0800 (PST) Received: from localhost (adrian@localhost) by obiwan.aceonline.com.au (8.8.5/8.8.5) with SMTP id WAA02064; Sun, 2 Mar 1997 22:24:28 +0800 (WST) Date: Sun, 2 Mar 1997 22:24:27 +0800 (WST) From: Adrian Chadd To: Joerg Wunsch cc: dillon@best.net, security@freebsd.org Subject: Re: disallow setuid root shells? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Matt Dillon wrote: > > > One thing I would like to see is a mount flag to disable suid-root and > > sgid-wheel binaries, but allow suid-(nonroot) and sgid-(nonwheel) > > binaries. Probably any ISP who runs shell accounts would love an > > option like that. > > For what reason? The users normally don't have a need to create > setuid programs, so why can't you mount /home nosuid? OTOH, system > partitions (like /usr) are required to allow suid root binaries > anyway. > > Btw., suidperl should honor the nosuid flag. > Well, thinking about it, thats right - thinking about the "bin" group owning most binaries, if you can't get a root suid shell, get a "bin" one *grin*. mounting /usr/home nosuid and noexec is a bloody execellent security thing IMHO. Cya. Adrian From owner-freebsd-security Mon Mar 3 03:23:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA22426 for security-outgoing; Mon, 3 Mar 1997 03:23:05 -0800 (PST) Received: from roundtable.cif.rochester.edu (sadmin@roundtable.cif.rochester.edu [128.151.220.14]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA22421 for ; Mon, 3 Mar 1997 03:23:03 -0800 (PST) Received: (from sadmin@localhost) by roundtable.cif.rochester.edu (8.8.5/8.8.3) id GAA28613 for freebsd-security@freebsd.org; Mon, 3 Mar 1997 06:22:34 -0500 (EST) From: Security Administrator Message-Id: <199703031122.GAA28613@roundtable.cif.rochester.edu> Subject: rebooting problems To: freebsd-security@freebsd.org (FreeBSD Security) Date: Mon, 3 Mar 1997 06:22:34 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A quick question: Every five to six days or so my 2.1.7-based system reboots. There doesn't seem to be ANYTHING present in the logs to explain this phenomena. Everything seems to be stable and then it suddenly reboots. If this is something that someone else has confronted, I would love to know how you mended the problems. My system is a P6-200 with an Adaptec 2940 Ultra SCSI-III controller, 128 Megs of EDO mem, and 256 Megs of swap that has been evenly split between two SCSI-III drives. I did have sound support compiled in at one point, but the system was totally unstable. Josh Pincus -- System Security Administrator Computer Interest Floor University of Rochester Rochester, NY 14627 sadmin@roundtable.cif.rochester.edu From owner-freebsd-security Mon Mar 3 08:14:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA10035 for security-outgoing; Mon, 3 Mar 1997 08:14:53 -0800 (PST) Received: from obiwan.TerraNova.net (root@obiwan.TerraNova.net [205.152.26.129]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA10024 for ; Mon, 3 Mar 1997 08:14:45 -0800 (PST) Received: from eye (coolholio@eye.yam.leet.cause.i.idle.in.teensysop.org [205.152.26.130]) by obiwan.TerraNova.net (8.8.5/TerraNovaNet) with SMTP id LAA16901; Mon, 3 Mar 1997 11:15:16 -0500 (EST) Message-ID: <331AF8B9.C03@TerraNova.net> Date: Mon, 03 Mar 1997 11:13:45 -0500 From: Travis Mikalson Reply-To: bofh@TerraNova.net Organization: TerraNovaNet X-Mailer: Mozilla 3.0Gold (WinNT; I) MIME-Version: 1.0 To: Security Administrator CC: FreeBSD Security Subject: Re: rebooting problems References: <199703031122.GAA28613@roundtable.cif.rochester.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Security Administrator wrote: > > A quick question: > > Every five to six days or so my 2.1.7-based system reboots. There doesn't seem to be ANYTHING present in the logs to explain this phenomena. Everything seems to be stable and then it suddenly reboots. > > If this is something that someone else has confronted, I would love to know how you mended the problems. I'm running 2.1.5 on a 6x86/P166+ with a 2940UW and two SCSI drives Mine rebooted every 1-6 days; it had a bad motherboard and/or processor Another of its symptoms was the fact that make world would either fail or the system would crash, I once had a kernel compile fail as well I replaced my board and processor and everything was fine > My system is a P6-200 with an Adaptec 2940 Ultra SCSI-III controller, 128 Megs > of EDO mem, and 256 Megs of swap that has been evenly split between two > SCSI-III drives. I did have sound support compiled in at one point, but the > system was totally unstable. Try removing/swapping hardware until you can complete a make world.. starting with the sound card Travis -- -=--==--===---====----======------=======------- TerraNovaNet Internet Services - Key Largo, FL Voice: (305)453-4011 Fax: (305)451-5991 http://www.TerraNova.net -------=======------======----====---===--==--=- Always remember that you are unique. Just like everyone else. From owner-freebsd-security Mon Mar 3 10:41:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA19928 for security-outgoing; Mon, 3 Mar 1997 10:41:10 -0800 (PST) Received: from eyelab.psy.msu.edu (eyelab.psy.msu.edu [35.8.64.179]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA19921 for ; Mon, 3 Mar 1997 10:41:07 -0800 (PST) Received: from eyelab3.psy.msu.edu (eyelab3.psy.msu.edu [35.8.64.180]) by eyelab.psy.msu.edu (8.8.5/8.8.5) with SMTP id NAA06151 for ; Mon, 3 Mar 1997 13:40:11 -0500 (EST) Message-Id: <3.0.1.32.19970303134010.006f4790@eyelab.msu.edu> X-Sender: root@eyelab.msu.edu X-Mailer: Windows Eudora Pro Version 3.0.1 beta 13 (32) Date: Mon, 03 Mar 1997 13:40:10 -0500 To: freebsd-security@freebsd.org From: Gary Schrock Subject: Re: rebooting problems In-Reply-To: <199703031122.GAA28613@roundtable.cif.rochester.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 06:22 AM 3/3/97 -0500, you wrote: >Every five to six days or so my 2.1.7-based system reboots. There doesn't seem to be ANYTHING present in the logs to explain this phenomena. Everything seems to be stable and then it suddenly reboots. >My system is a P6-200 with an Adaptec 2940 Ultra SCSI-III controller, 128 Megs Hmm, I've noticed this type of thing on a mud machine that I'm an admin of. We had occaisional problems before moving to 2.1.7, but it seems to be more frequent since. I had a reason to suspect that it might be related to the scsi card (we've got a 2940 in the machine) (of course, I can't remember off the top of my head why it was that I suspected the scsi card :P ). I've noticed a bunch of changes recently to the driver for that card in the stable branch, many even since we upgraded, so I'm wondering it it might be worthwhile to try recompiling the driver with these new changes. Our machine is a P5-166, 64 megs of ram, adaptec 2940, a PCI SMC EtherPower ethernet card. Gary Schrock root@eyelab.msu.edu From owner-freebsd-security Mon Mar 3 13:13:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA28113 for security-outgoing; Mon, 3 Mar 1997 13:13:17 -0800 (PST) Received: from anugpo.anu.edu.au (anugpo.anu.edu.au [150.203.2.6]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA28098 for ; Mon, 3 Mar 1997 13:13:08 -0800 (PST) Received: from bohm.anu.edu.au (root@bohm.anu.edu.au [150.203.21.88]) by anugpo.anu.edu.au (8.8.5/8.8.3) with SMTP id IAA10129 for ; Tue, 4 Mar 1997 08:12:56 +1100 (EST) Received: from totoro by bohm.anu.edu.au (SMI-8.6/SMI-SVR4) id IAA06914; Tue, 4 Mar 1997 08:12:50 +1100 Message-Id: <3.0.32.19970303081513.007018bc@student.anu.edu.au> X-Sender: s3080696@student.anu.edu.au (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 03 Mar 1997 08:15:17 +1000 To: freebsd-security@FreeBSD.ORG (FreeBSD Security) From: James Seng Subject: Re: rebooting problems Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am running my 2.1.6-based server and it would reboot itself automatically every now and then. The server is a Pentium-166, 128Mb RAM, 512Mb swap (and with AHC2940 too..hmmm). The kernel is compiled to the minimum removing all unneccessary devices. I wrote some script to check on the system status every minute and it is found that the system is perfectly fine when it reboots. ie, the CPU load is less than 1, the free RAM is over 30Mb, the swap isnt even used! It just reboot out of the blue. On the other two 2.1.6-base server however (with a similar setup), which is less heavy on RAM, it doesnt appears to have this problem. Neither does it appears on my 2.1.5-base server. All three machines has the same hardware (right down the harddisk and monitor). Even the kernal config file used is the same.... It is driving me crazy *sigh* -James Seng At 06:22 AM 3/3/97 -0500, Security Administrator wrote: >A quick question: > >Every five to six days or so my 2.1.7-based system reboots. There doesn't seem to be ANYTHING present in the logs to explain this phenomena. Everything seems to be stable and then it suddenly reboots. > >If this is something that someone else has confronted, I would love to know how you mended the problems. > >My system is a P6-200 with an Adaptec 2940 Ultra SCSI-III controller, 128 Megs >of EDO mem, and 256 Megs of swap that has been evenly split between two >SCSI-III drives. I did have sound support compiled in at one point, but the >system was totally unstable. > >Josh Pincus >-- >System Security Administrator >Computer Interest Floor >University of Rochester >Rochester, NY 14627 >sadmin@roundtable.cif.rochester.edu > > From owner-freebsd-security Mon Mar 3 13:56:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA01027 for security-outgoing; Mon, 3 Mar 1997 13:56:06 -0800 (PST) Received: from postoffice.cso.uiuc.edu (postoffice.cso.uiuc.edu [128.174.5.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA00979 for ; Mon, 3 Mar 1997 13:55:55 -0800 (PST) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [128.174.83.167]) by postoffice.cso.uiuc.edu (8.8.5/8.8.5) with SMTP id PAA86222; Mon, 3 Mar 1997 15:55:12 -0600 Received: by alecto.physics.uiuc.edu (940816.SGI.8.6.9/940406.SGI) id PAA04864; Mon, 3 Mar 1997 15:51:06 -0600 From: igor@alecto.physics.uiuc.edu (Igor Roshchin) Message-Id: <199703032151.PAA04864@alecto.physics.uiuc.edu> Subject: Re: rebooting problems To: jseng@pobox.org.sg (James Seng) Date: Mon, 3 Mar 1997 15:51:06 -0600 (CST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <3.0.32.19970303081513.007018bc@student.anu.edu.au> from "James Seng" at Mar 3, 97 08:15:17 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 1. I don't think this is relevant to SECURITY, so, it should not be on this list. Agree ? 2. Even if this were relevant to security, I think, there is no need for everybody (I believe, many people have or had these problems) to post their configuration and moan about it. It does not seem to add too much information after a few have been posted. 3. Recently ( about a month ago or later), there was a thread about this in comp.unix.bsd.freebsd.misc Somebody, I believe, Joerg, mentioned that most of such problems are due to the hardware problems. 4. I myself had a similar problem. (the same symptoms: no records in /var/log/messages, looks like there is enough memory and swap, but I couldn't make world, or compile anything reasonably big..) It's gone after I replaced the memory chips. I believe, there are places more appropriate for this issues, as soon as we found that it is not security-relevant thing. REgards, IgoR > > I am running my 2.1.6-based server and it would reboot itself automatically > every now and then. The server is a Pentium-166, 128Mb RAM, 512Mb swap (and > with AHC2940 too..hmmm). The kernel is compiled to the minimum removing all > unneccessary devices. > > I wrote some script to check on the system status every minute and it is > found that the system is perfectly fine when it reboots. ie, the CPU load > is less than 1, the free RAM is over 30Mb, the swap isnt even used! It just > reboot out of the blue. > > On the other two 2.1.6-base server however (with a similar setup), which is > less heavy on RAM, it doesnt appears to have this problem. Neither does it > appears on my 2.1.5-base server. All three machines has the same hardware > (right down the harddisk and monitor). Even the kernal config file used is > the same.... > > It is driving me crazy *sigh* > > -James Seng > > At 06:22 AM 3/3/97 -0500, Security Administrator wrote: > >A quick question: > > > >Every five to six days or so my 2.1.7-based system reboots. There doesn't > seem to be ANYTHING present in the logs to explain this phenomena. > Everything seems to be stable and then it suddenly reboots. > > > >If this is something that someone else has confronted, I would love to > know how you mended the problems. > > > >My system is a P6-200 with an Adaptec 2940 Ultra SCSI-III controller, 128 > Megs > >of EDO mem, and 256 Megs of swap that has been evenly split between two > >SCSI-III drives. I did have sound support compiled in at one point, but the > >system was totally unstable. > > > >Josh Pincus > >-- > >System Security Administrator > >Computer Interest Floor > >University of Rochester > >Rochester, NY 14627 > >sadmin@roundtable.cif.rochester.edu > > > > > From owner-freebsd-security Tue Mar 4 07:17:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26094 for security-outgoing; Tue, 4 Mar 1997 07:17:34 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26086 for ; Tue, 4 Mar 1997 07:17:29 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id QAA29125 for security@freebsd.org; Tue, 4 Mar 1997 16:15:54 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id QAA11611 for ; Tue, 4 Mar 1997 16:18:58 +0100 (MET) Message-Id: <3.0.32.19970304161858.00c3c710@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 04 Mar 1997 16:19:00 +0100 To: security@freebsd.org From: Eivind Eklund Subject: Old imapd, ipop2d, ipop3d Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yesterday, a security hole allowing remote root was discovered in imapd, ipop2 and ipop3d (NOT popper). If you are running versions of these older than 4.1-BETA (eg, the versions enclosed with 2.1.0 (and 2.1.5?)), it is a _very_ good idea to upgrade to the version presently in the ports collection. The executables in question is in /usr/local/libexec/{imapd,ipop2d,ipop3d} - if these are old (not from 1997) you are certain to be afflicted with the bug. (Does this belong in freebsd-announce? RedHat put out an announcement...) Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org From owner-freebsd-security Wed Mar 5 11:09:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA05471 for security-outgoing; Wed, 5 Mar 1997 11:09:09 -0800 (PST) Received: from snail.slow.net (lancelot@snail.slow.net [204.50.80.175]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA05464 for ; Wed, 5 Mar 1997 11:08:54 -0800 (PST) Received: (from lancelot@localhost) by snail.slow.net (8.8.5/8.7.3) id OAA17341; Wed, 5 Mar 1997 14:08:21 -0500 (EST) Date: Wed, 5 Mar 1997 14:08:16 -0500 (EST) From: Sire Lancelot du Lac To: freebsd-security@freebsd.org Subject: FreeBSD lpd Security Vulnerability (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Christian Doucet lancelot@slow.net work: +1 514 728 1618 Freelance "Sysadmin-Programmer-UNIX-Internet" guru! home: +1 514 728 1618 Y'a rien de plus troublant qu'un trou noir. -- Sol (Marc Favreau) This sentance has threee errors. -- trurl@yakko.nceye.net This sentence no verb. -- someone The answer to life, the universe and sendmail is 25 -- chimmy@knott12.ncl.ac.uk ---------- Forwarded message ---------- Date: Wed, 5 Mar 1997 00:32:02 -0700 From: Oliver Friedrichs To: BUGTRAQ@NETSPACE.ORG Subject: FreeBSD lpd Security Vulnerability ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######. Secure Networks Inc. Security Advisory March 5, 1997 FreeBSD lpd Security Vulnerability There is a serious security vulnerability in all FreeBSD lpd implementations This vulnerability allows remote users to gain unauthorized root access to any system allowing connections to the line printer daemon (lpd). A user is not required to be in lpd's access list (/etc/hosts.lpd) to exploit this vulnerability, as the problem occurs while lpd is attempting to determine whether the host is permitted to connect. Problem Description ~~~~~~~~~~~~~~~~~~~ The vulnerability is present in the source file lib/libc/net/rcmd.c, which contains the function __ivaliduser(). This function is used by the line printer daemon (lpd) to determine whether the user connecting to the daemon is in it's access list (contained in /etc/hosts.lpd). When performing a domain name lookup on the connecting IP address, the resulting response is copied into a fixed size buffer of size MAXHOSTNAMELEN (256 bytes). Since DNS responses containing a hostname and domain name are currently allowed to exceed 256 bytes, overflow can occur. The faulty code follows: if ((hp = gethostbyaddr((char *)&raddr, sizeof(u_long), AF_INET)) == NULL) return (-1); strcpy(hname, hp->h_name); The string copy is done without any bounds checking. Corrected code looks as follows: if ((hp = gethostbyaddr((char *)&raddr, sizeof(u_long), AF_INET)) == NULL) return (-1); strncpy(hname, hp->h_name, sizeof(hname)); hname[sizeof(hname)-1] = '\0'; Vulnerable Systems ~~~~~~~~~~~~~~~~~~ This security vulnerability only applies to the FreeBSD operating system. FreeBSD 2.1.5 is vulnerable FreeBSD 2.1.6 is vulnerable FreeBSD 2.1.7 is vulnerable FreeBSD 2.2 Gamma is vulnerable FreeBSD 2.2 is not vulnerable FreeBSD -current is vulnerable for dates prior to February 25, 1997 Corrected in -current, and -stable as of February 25, 1997. Workaround ~~~~~~~~~~ If the system in question does not require the use of printing services, lpd should be removed or commented out from the system startup file /etc/rc. If you require the use of printing services, this vulnerability can be fixed by applying the following patch to lib/libc/net/rcmd.c. This patch has been known to apply to all FreeBSD 2.x systems. --- CUT HERE --- *** libc/lib/net/rcmd.c.old Tue Feb 25 15:33:42 1997 --- libc/lib/net/rcmd.c Tue Feb 25 15:33:56 1997 *************** *** 377,383 **** if ((hp = gethostbyaddr((char *)&raddr, sizeof(u_long), AF_INET)) == NULL) return (-1); ! strcpy(hname, hp->h_name); while (fgets(buf, sizeof(buf), hostf)) { p = buf; --- 377,384 ---- if ((hp = gethostbyaddr((char *)&raddr, sizeof(u_long), AF_INET)) == NULL) return (-1); ! strncpy(hname, hp->h_name, sizeof(hname)); ! hname[sizeof(hname)-1] = '\0'; while (fgets(buf, sizeof(buf), hostf)) { p = buf; --- CUT HERE --- At this point, libc will have to be recompiled. lpd is shipped dynamically linked under FreeBSD, therefore the fix will take effect without recompiling lpd itself. Attributions ~~~~~~~~~~~~ Information about FreeBSD can be found at http://www.freebsd.org You can contact the author of this advisory at oliver@secnet.com Type Bits/KeyID Date User ID pub 1024/0E7BBA7D 1996/09/18 Oliver Friedrichs -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAzJATn0AAAEEAJeGbZyoCw14fCoAMeBRKiZ3L6JMbd9f4BtwdtYTwD42/Uz1 A/4UiRJzRLGhARpt1J06NVQEKXQDbejxGIGzAGTcyqUCKH6yNAncqoep3+PKIQJd Kd23buvbk7yUgyVlqQHDDsW0zMKdlSO7rYByT6zsW0Rv5JmHJh/bLKAOe7p9AAUR tCVPbGl2ZXIgRnJpZWRyaWNocyA8b2xpdmVyQHNlY25ldC5jb20+iQCVAwUQMkBO fR/bLKAOe7p9AQEBOAQAkTXiBzf4a31cYYDFmiLWgXq0amQ2lsamdrQohIMEDXe8 45SoGwBzXHVh+gnXCQF2zLxaucKLG3SXPIg+nJWhFczX2Fo97HqdtFmx0Y5IyMgU qRgK/j8KyJRdVliM1IkX8rf3Bn+ha3xn0yrWlTZMF9nL7iVPBsmgyMOuXwZ7ZB8= =xq4f -----END PGP PUBLIC KEY BLOCK----- Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networks Inc, 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" From owner-freebsd-security Wed Mar 5 12:48:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA11210 for security-outgoing; Wed, 5 Mar 1997 12:48:25 -0800 (PST) Received: from narcissus.ml.org (root@brosenga.Pitzer.edu [134.173.120.201]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA11204 for ; Wed, 5 Mar 1997 12:48:22 -0800 (PST) Received: from localhost (ben@localhost) by narcissus.ml.org (8.7.5/8.7.3) with SMTP id MAA14913; Wed, 5 Mar 1997 12:48:07 -0800 (PST) Date: Wed, 5 Mar 1997 12:48:07 -0800 (PST) From: Snob Art Genre To: Sire Lancelot du Lac cc: freebsd-security@freebsd.org Subject: Re: FreeBSD lpd Security Vulnerability (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there a patch for -stable? The patch included with the advisory wasn't applicable on my system. Ben "You have your mind on computers, it seems." From owner-freebsd-security Wed Mar 5 15:51:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA20927 for security-outgoing; Wed, 5 Mar 1997 15:51:09 -0800 (PST) Received: from ns2.harborcom.net (root@ns2.harborcom.net [206.158.4.4]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA20922 for ; Wed, 5 Mar 1997 15:51:04 -0800 (PST) Received: from localhost (bradley@localhost) by ns2.harborcom.net (8.8.5/8.8.4) with SMTP id SAA28736; Wed, 5 Mar 1997 18:50:59 -0500 (EST) Date: Wed, 5 Mar 1997 18:50:58 -0500 (EST) From: Bradley Dunn X-Sender: bradley@ns2.harborcom.net To: Snob Art Genre cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD lpd Security Vulnerability (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 5 Mar 1997, Snob Art Genre wrote: > Is there a patch for -stable? The patch included with the advisory > wasn't applicable on my system. http://freebsd.org/cgi/cvsweb.cgi/src/lib/libc/net/rcmd.c?r1=1.3.4.4&r2=1.3.4.5 From owner-freebsd-security Wed Mar 5 22:26:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA20996 for security-outgoing; Wed, 5 Mar 1997 22:26:32 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA20941 for ; Wed, 5 Mar 1997 22:26:22 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0w2Wct-00032Z-00; Wed, 5 Mar 1997 23:26:03 -0700 To: Bradley Dunn Subject: Re: FreeBSD lpd Security Vulnerability (fwd) Cc: Snob Art Genre , freebsd-security@freebsd.org In-reply-to: Your message of "Wed, 05 Mar 1997 18:50:58 EST." References: Date: Wed, 05 Mar 1997 23:26:03 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message Bradley Dunn writes: : On Wed, 5 Mar 1997, Snob Art Genre wrote: : > Is there a patch for -stable? The patch included with the advisory : > wasn't applicable on my system. : : http://freebsd.org/cgi/cvsweb.cgi/src/lib/libc/net/rcmd.c?r1=1.3.4.4&r2=1.3.4.5 Apply the following patch, rebuild libc and install the shared library. Since lpd is dynamically linked, this will fix the problem. Index: rcmd.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/net/rcmd.c,v retrieving revision 1.3.4.4 retrieving revision 1.3.4.5 diff -u -r1.3.4.4 -r1.3.4.5 - --- rcmd.c 1997/02/09 06:57:54 1.3.4.4 +++ rcmd.c 1997/02/26 06:14:11 1.3.4.5 @@ -377,7 +377,8 @@ if ((hp = gethostbyaddr((char *)&raddr, sizeof(u_long), AF_INET)) == NULL) return (-1); - - strcpy(hname, hp->h_name); + strncpy(hname, hp->h_name, sizeof(hname)); + hname[sizeof(hname) - 1] = '\0'; while (fgets(buf, sizeof(buf), hostf)) { p = buf; Warner P.S. since I'm pgp signing this, saying "sed -e 's/^- //'" now might save me some mail later. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMx5jc9xynu/2qPVhAQEzWgQAnKsS8iVWiaFHp5FYcB/wK6/nJLjVy+WD Z9thkQpeLLO3+MO/B4S2rHBn9gxAXWgxl+43d1irrEMk21bQkNQsr1yAwTS/sujP 1Tf5J9sAydF/vy+uAUjFKmsrSqc2q0ykz8G3zk1ila/ykR8GHH4t+e74y4oSvHB6 XS89DGLDzEE= =U0q7 -----END PGP SIGNATURE----- From owner-freebsd-security Thu Mar 6 06:30:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA20635 for security-outgoing; Thu, 6 Mar 1997 06:30:54 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA20527 for ; Thu, 6 Mar 1997 06:29:31 -0800 (PST) Received: from mail.fasts.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0w2eAh-00091RC; Thu, 6 Mar 97 06:29 PST Received: (qmail 1332 invoked from network); 6 Mar 1997 16:25:57 -0000 Received: from unknown (HELO cabby.fasts.com) (unknown) by unknown with SMTP; 6 Mar 1997 16:25:57 -0000 Message-ID: <331ED3ED.4950@fasts.com> Date: Thu, 06 Mar 1997 16:25:49 +0200 From: Victor Rotanov Organization: FASTS Ltd. X-Mailer: Mozilla 4.0b2 (Win95; I) MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Hack attempts on our server. X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello. It seems that our server has been hacked two days ago. # last | grep 159.148.112.21 vitjok ttyp6 159.148.112.21 Tue Mar 4 11:48 - 11:49 (00:00) ftp ftp 159.148.112.21 Tue Mar 4 10:58 - 11:04 (00:05) Any ideas? Thanks, bye. vitjok From owner-freebsd-security Thu Mar 6 11:14:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA05254 for security-outgoing; Thu, 6 Mar 1997 11:14:28 -0800 (PST) Received: from clunix.msu.edu (clunix.cl.msu.edu [35.9.6.4]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA05215 for ; Thu, 6 Mar 1997 11:14:16 -0800 (PST) Received: by clunix.msu.edu (AIX 3.2/UCB 5.64/4.03) id AA21857; Thu, 6 Mar 1997 14:14:03 -0500 From: budzyn@clunix.cl.msu.edu (Joe Budzyn) Message-Id: <9703061914.AA21857@clunix.msu.edu> Subject: Re: FreeBSD lpd Security Vulnerability (fwd) To: freebsd-security@freebsd.org Date: Thu, 6 Mar 1997 14:14:03 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Apply the following patch, rebuild libc and install the shared > library. Since lpd is dynamically linked, this will fix the problem. > > Index: rcmd.c > =================================================================== > RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/net/rcmd.c,v > retrieving revision 1.3.4.4 > retrieving revision 1.3.4.5 > diff -u -r1.3.4.4 -r1.3.4.5 > - --- rcmd.c 1997/02/09 06:57:54 1.3.4.4 > +++ rcmd.c 1997/02/26 06:14:11 1.3.4.5 > @@ -377,7 +377,8 @@ > if ((hp = gethostbyaddr((char *)&raddr, sizeof(u_long), > AF_INET)) == NULL) > return (-1); > - - strcpy(hname, hp->h_name); > + strncpy(hname, hp->h_name, sizeof(hname)); > + hname[sizeof(hname) - 1] = '\0'; > > while (fgets(buf, sizeof(buf), hostf)) { > p = buf; When this patch is applied, nslookup breaks. It needs to be recompiled to work. Is there anything else that might break? Joe Budzyn From owner-freebsd-security Thu Mar 6 11:50:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA07155 for security-outgoing; Thu, 6 Mar 1997 11:50:00 -0800 (PST) Received: from spitfire.ecsel.psu.edu (spitfire.ecsel.psu.edu [146.186.218.51]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA07138 for ; Thu, 6 Mar 1997 11:49:40 -0800 (PST) Received: (qmail 3106 invoked by uid 1000); 6 Mar 1997 19:48:33 -0000 Message-ID: <19970306194833.3105.qmail@spitfire.ecsel.psu.edu> To: budzyn@clunix.cl.msu.edu (Joe Budzyn) cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD lpd Security Vulnerability (fwd) In-reply-to: Your message of "Thu, 06 Mar 1997 14:14:03 EST." <9703061914.AA21857@clunix.msu.edu> Date: Thu, 06 Mar 1997 14:48:32 -0500 From: Dan Cross Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > When this patch is applied, nslookup breaks. It needs to be recompiled to > work. Is there anything else that might break? I doubt the two are related. Did you upgrade anything else in your source tree between the time you installed and the time you rebuilt libc? - Dan C. From owner-freebsd-security Thu Mar 6 11:50:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA07240 for security-outgoing; Thu, 6 Mar 1997 11:50:12 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA07196 for ; Thu, 6 Mar 1997 11:50:03 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id UAA09729; Thu, 6 Mar 1997 20:49:03 +0100 (MET) From: Guido van Rooij Message-Id: <199703061949.UAA09729@gvr.win.tue.nl> Subject: Re: FreeBSD lpd Security Vulnerability (fwd) In-Reply-To: <9703061914.AA21857@clunix.msu.edu> from Joe Budzyn at "Mar 6, 97 02:14:03 pm" To: budzyn@clunix.cl.msu.edu (Joe Budzyn) Date: Thu, 6 Mar 1997 20:49:03 +0100 (MET) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Joe Budzyn wrote: > > When this patch is applied, nslookup breaks. It needs to be recompiled to > work. Is there anything else that might break? Excuse me??? Why do you think nslokup would break? I don;t recall nslookup calling rcmd? -Guido From owner-freebsd-security Thu Mar 6 11:56:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA07637 for security-outgoing; Thu, 6 Mar 1997 11:56:12 -0800 (PST) Received: from clunix.msu.edu (clunix.cl.msu.edu [35.9.6.4]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA07617 for ; Thu, 6 Mar 1997 11:56:05 -0800 (PST) Received: by clunix.msu.edu (AIX 3.2/UCB 5.64/4.03) id AA21858; Thu, 6 Mar 1997 14:55:05 -0500 From: budzyn@clunix.cl.msu.edu (Joe Budzyn) Message-Id: <9703061955.AA21858@clunix.msu.edu> Subject: Re: FreeBSD lpd Security Vulnerability (fwd) To: tenser@spitfire.ecsel.psu.edu (Dan Cross) Date: Thu, 6 Mar 1997 14:55:04 -0500 (EST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <19970306194833.3105.qmail@spitfire.ecsel.psu.edu> from "Dan Cross" at Mar 6, 97 02:48:32 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > When this patch is applied, nslookup breaks. It needs to be recompiled to > > work. Is there anything else that might break? > > I doubt the two are related. Did you upgrade anything else in your source > tree between the time you installed and the time you rebuilt libc? > > - Dan C. > > I had previously done a make world with the latest 2.1.7 code. After the patch and libc recompile, nslookup broke. Simply recompiling nslookup fixed it. I did nothing else to the source inbetween. Joe From owner-freebsd-security Thu Mar 6 13:23:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA12447 for security-outgoing; Thu, 6 Mar 1997 13:23:19 -0800 (PST) Received: from spitfire.ecsel.psu.edu (qmailr@spitfire.ecsel.psu.edu [146.186.218.51]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA12440 for ; Thu, 6 Mar 1997 13:23:14 -0800 (PST) Received: (qmail 3591 invoked by uid 1000); 6 Mar 1997 21:21:07 -0000 Message-ID: <19970306212107.3590.qmail@spitfire.ecsel.psu.edu> To: budzyn@clunix.cl.msu.edu (Joe Budzyn) cc: freebsd-security@freebsd.org Subject: Re: FreeBSD lpd Security Vulnerability (fwd) In-reply-to: Your message of "Thu, 06 Mar 1997 14:55:04 EST." <9703061955.AA21858@clunix.msu.edu> Date: Thu, 06 Mar 1997 16:21:07 -0500 From: Dan Cross Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > When this patch is applied, nslookup breaks. It needs to be recompiled to > > work. Is there anything else that might break? > > I doubt the two are related. Did you upgrade anything else in your source > tree between the time you installed and the time you rebuilt libc? I had previously done a make world with the latest 2.1.7 code. After the patch and libc recompile, nslookup broke. Simply recompiling nslookup fixed it. I did nothing else to the source inbetween. That's incredibly odd. Nslookup(1) doesn't touch rcmd.c at all. Not to belabour the point, but are you absolutely SURE that nothing else touched the source tree in between the time you did the make world and when you applied the patch to rcmd.c? I'm not saying I don't believe you, I just can't fathom how Warner's change could have bothered nslookup(1) at all... :-) I'm betting there's another explanation... - Dan C. From owner-freebsd-security Thu Mar 6 20:58:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA14213 for security-outgoing; Thu, 6 Mar 1997 20:58:30 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA14178 for ; Thu, 6 Mar 1997 20:58:16 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.7.3) id QAA04754; Fri, 7 Mar 1997 16:15:42 +1100 (EST) Date: Fri, 7 Mar 1997 16:15:41 +1100 (EST) From: "Daniel O'Callaghan" To: freebsd-security@freebsd.org Subject: 4.4BSD NFS File Handles (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Thu, 6 Mar 1997 21:02:36 -0700 From: David Sacerdote To: BUGTRAQ@NETSPACE.ORG Subject: 4.4BSD NFS File Handles ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######. Secure Networks Inc. Security Advisory March 7, 1997 4.4BSD NFS File Handles There is a serious vulnerability in 4.4BSD and derivatives which allows unprivileged users to obtain valid NFS file handles. A NFS file handle will permit a user to, at the least, obtain access as any non-root user to the filesystem, and possibly obtain root privileges. Problem Description ~~~~~~~~~~~~~~~~~~~ The problem occurs due to the fact that unprivileged users are able to obtain all information required to generate NFS file handles. In addition to returning traditional information, such as the creation time, size, inode number and last modification time, the 4.4BSD stat(2) system call and related functions return a field called st_gen. The st_gen field is a 4 byte value which is different for each item on the filesystem. The st_gen value is used as a generation number to make NFS file handles difficult to guess. Unfortunately, because all information used to generate a file handle is availible to users, a user can generate file handles identical to those given to NFS client hosts accessing file systems on the local server. Because a file handle is all that is needed to mount a filesystem, a user can then mount any exported filesystems, performing arbitrary filesystem operations as any non-root user, assuming they are on a host in the server's export list. Such access will commonly result in the user obtaining root privileges. The incorrect code in the vn_stat() function, called by stat(2) reads: ... sb->st_gen = vap->va_gen; sb->st_blocks = vap->va_bytes / S_BLKSIZE; return (0); } It should be noted that in the above source code, all information from the generation number is pulled out and given to the user. A correct implementation will only permit root users to access this number, as shown in the following example source code: ... sb->st_flags = vap->va_flags; if (suser(p->p_ucred, &p->p_acflag)) { sb->st_gen = 0; } else { sb->st_gen = vap->va_gen; } sb->st_blocks = vap->va_bytes / S_BLKSIZE; return (0); } This will cause the st_gen field of the stat structure returned to unprivileged users to be zero, thus preventing ordinary users from determining file handles simply from the information returned by stat(2). Impact ~~~~~~ Individuals with shell access to a NFS server or client can obtain access to the NFS server as any non-root user. This will usually lead to root compromise. Vulnerable Systems ~~~~~~~~~~~~~~~~~~ 4.4BSDLite2 appears vulnerable based on source inspection only. BSD/OS 2.0 is vulnerable BSD/OS 2.1 is vulnerable BSD/OS 3.0 is vulnerable FreeBSD 2.1.5 is vulnerable FreeBSD 2.1.6 is vulnerable FreeBSD 2.1.7 is vulnerable NetBSD 1.2 appears vulnerable based on source inspection only. OpenBSD 2.0 is vulnerable. OpenBSD-current obtained on 14 February 1997 or earlier is vulnerable. OpenBSD-current obtained later than February 14 is not vulnerable. Workaround ~~~~~~~~~~ If you are running a NFS server on your 4.4BSD system, or using a 4.4BSD system as a NFS client, we suggest modifying your kernel so that stat(2), and lstat(2) do not provide st_gen to unprivileged users. You should also modify any system calls which return the same information as the above functions, but which exist solely for backwards compatibility with 4.3BSD. Finally, the generation numbers assigned to new inodes should be nonguessable. Vendors are strongly urged to provide a utility to enable administrators to re-randomize the generation numbers when they suspect that file handles have been comprimised. A program to randomize generation numbers on 4.4BSD derived file systems can be obtained at ftp://ftp.secnet.com/pub/tools/bsd-fsirand/fsirand.tar.gz. WARNING: The above fsirand program has been tested on various 4.4BSD derived operating systems and has performed without problems. With this in mind, there is absolutely no guarantee that this program will work correctly on your file systems, and users should back up all data prior to randomizing generation numbers. The author assumes no liability. To initially verify that fsirand will work correctly, a user may want to create a file system on a floppy drive and test the fsirand program on that file system. --- BSD/OS: Contact BSDi for a fix. A fix will be availible shortly after the release of this advisory. BSDI patches can be obtained by ftping to ftp://ftp.bsdi.com/pub/patches or by mailing patches@bsdi.com. The fsirand program has been tested on BSD/OS 2.1 and has functioned without any problems. --- FreeBSD and NetBSD: Back up your system. Then apply the included patch, then recompile your kernel and reboot in single user mode. At this point the fsirand program should be run on all exported file systems. Once complete, reboot to multi-user mode. It would be a good idea to run fsirand on all file systems, in the event that some may be exported in the future. --- OpenBSD: Back up your system. Then use anoncvs to upgrade your system to OpenBSD-current, recompile your kernel, and reboot in single user mode. Run the fsirand program which is part of OpenBSD in order to randomize generation numbers for pre-existing filesystems. Finally reboot to multi-user mode. The following diffs are to the 4.4BSDLite2 vfs_vnops.c, and prevent users from using stat(2) and related system calls for obtaining file handle generation numbers. *** vfs_vnops.c Thu Mar 6 21:37:16 1997 --- vfs_vnops.c.orig Thu Mar 6 21:34:53 1997 *************** *** 344,350 **** sb->st_ctimespec = vap->va_ctime; sb->st_blksize = vap->va_blocksize; sb->st_flags = vap->va_flags; ! sb->st_gen = vap->va_gen; sb->st_blocks = vap->va_bytes / S_BLKSIZE; return (0); } --- 344,354 ---- sb->st_ctimespec = vap->va_ctime; sb->st_blksize = vap->va_blocksize; sb->st_flags = vap->va_flags; ! if (suser (p->u_cred, &p->p_acflag)) { ! sb->st_gen = 0; ! } else { ! sb->st_gen = vap->va_gen; ! } sb->st_blocks = vap->va_bytes / S_BLKSIZE; return (0); } Additional Information ~~~~~~~~~~~~~~~~~~~~~~ If you have any questions about this advisory, feel free to mail me at davids@secnet.com. The following PGP key is for davids@secnet.com, should you wish to encrypt any message traffic to me.: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzJ4qJAAAAEEAOgB7mooQ6NgzcUSIehKUufGsyojutC7phVXZ+p8FnHLLZNB BLQEtj5kmfww2A2pR29q4rgPeqEUOjWPlLNdSLby3NI8yKz1AQSQLHAwIDXt/lku 8QXClaV6pNIaQSN8cnyyvjH6TYF778yZhYz0mwLqW6dU5whHtP93ojDw1UhtAAUR tCtEYXZpZCBTYWNlcmRvdGUgPGRhdmlkc0BzaWxlbmNlLnNlY25ldC5jb20+ =LtL9 -----END PGP PUBLIC KEY BLOCK----- Many thanks to Theo Deraadt for initially alerting us to this problem, which was discovered by David Mazieres . Many thanks to Keith Bostic for discussions and the suggestions which led to the included fix for vfs_vnops.c. The fsirand program was largely written by Todd Miller . Information about BSD/OS can be found at http://www.bsdi.com. Information about FreeBSD can be found at http://www.freebsd.org Information about NetBSD can be found at http://www.netbsd.org Information about OpenBSD can be found at http://www.openbsd.org Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networks Inc, 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 http://www.secnet.com/sni-advisories or via ftp at ftp://ftp.secnet.com/pub/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" From owner-freebsd-security Thu Mar 6 22:03:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA17228 for security-outgoing; Thu, 6 Mar 1997 22:03:38 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA17190; Thu, 6 Mar 1997 22:02:50 -0800 (PST) From: Mike Pritchard Message-Id: <199703070602.WAA17190@freefall.freebsd.org> Subject: Re: 4.4BSD NFS File Handles (fwd) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Thu, 6 Mar 1997 22:02:49 -0800 (PST) Cc: freebsd-security@freebsd.org In-Reply-To: from "Daniel O'Callaghan" at Mar 7, 97 04:15:41 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Daniel O'Callaghan wrote: > > In addition to returning traditional information, such as the creation time, > size, inode number and last modification time, the 4.4BSD stat(2) system > call and related functions return a field called st_gen. The st_gen field > is a 4 byte value which is different for each item on the filesystem. I've worked on other systems in the past where we only returned st_gen if the caller was root. If I remember right, the last time I looked at how the kernel assigned generation number, it didn't do a very good job of it (they were pretty predictable). We should probaby change them to use the random() kernel function. -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-security Thu Mar 6 22:06:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA17396 for security-outgoing; Thu, 6 Mar 1997 22:06:19 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA17385 for ; Thu, 6 Mar 1997 22:06:14 -0800 (PST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id AAA23594; Fri, 7 Mar 1997 00:06:13 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.5/8.8.2) id AAA19792; Fri, 7 Mar 1997 00:06:13 -0600 (CST) Message-ID: <19970307000612.34391@Jupiter.Mcs.Net> Date: Fri, 7 Mar 1997 00:06:12 -0600 From: Karl Denninger To: "Daniel O'Callaghan" Cc: freebsd-security@freebsd.org Subject: Re: 4.4BSD NFS File Handles (fwd) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: ; from Daniel O'Callaghan on Fri, Mar 07, 1997 at 04:15:41PM +1100 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, Mar 07, 1997 at 04:15:41PM +1100, Daniel O'Callaghan wrote: > > > ---------- Forwarded message ---------- > Date: Thu, 6 Mar 1997 21:02:36 -0700 > From: David Sacerdote > To: BUGTRAQ@NETSPACE.ORG > Subject: 4.4BSD NFS File Handles > > ###### ## ## ###### > ## ### ## ## > ###### ## # ## ## > ## ## ### ## > ###### . ## ## . ######. > > Secure Networks Inc. > > Security Advisory > March 7, 1997 > > 4.4BSD NFS File Handles > I have just sent in a PR on this for FreeBSD-Current 3.x. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > From owner-freebsd-security Thu Mar 6 22:44:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA19730 for security-outgoing; Thu, 6 Mar 1997 22:44:55 -0800 (PST) Received: from itu.cc.jyu.fi (root@itu.cc.jyu.fi [130.234.40.21]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA19694 for ; Thu, 6 Mar 1997 22:44:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by itu.cc.jyu.fi (8.8.4/8.8.4) with ESMTP id IAA20640 for ; Fri, 7 Mar 1997 08:44:01 +0200 Date: Fri, 7 Mar 1997 08:44:01 +0200 (EET) From: Seppo Kallio To: freebsd-security@freebsd.org Subject: XFree86 + startx In-Reply-To: <331ED3ED.4950@fasts.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is this a known bug/feature: We have some FreeBSD + Linux workstations running FreeBSD 2.2 and Linux RedHat 4.1. I think both have same security problem in XFree: First, asume one logins on the console into the workstation in ascii mode (not using xdm) and then startx X by giving startx command. Second after that someone is making remote login (telnet or rlogin) to the same workstation. Now the last one can use the screen as he/she likes by defining setenv DISPLAY nodename:0.0 (or maybe even setenv DISPLAY :0.0). The user can spy all keystrokes, see full screen etc. If the first user types passwds etc. the second can see them. We have corrected this by adding X authorization to the startx script: 1. about at line #23: serverargs="-auth $HOME/.Xauthority" (was serverargs="") 2. add before xinit start: xauth add :0 . `mcookie` xauth add `hostname`:0 . `mcookie` (3. xinit can be started using exec) Seppo Kallio kallio@cc.jyu.fi Computing Center Fax +358-14-603611 U of Jyväskylä 62.14N 25.44E PL 35, 40351 Jyväskylä, Finland http://www.jyu.fi/~kallio From owner-freebsd-security Thu Mar 6 23:19:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA21732 for security-outgoing; Thu, 6 Mar 1997 23:19:39 -0800 (PST) Received: from big-O.math.psu.edu (nbppp33.cac.psu.edu [128.118.140.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA21721; Thu, 6 Mar 1997 23:19:27 -0800 (PST) Received: (from tenser@localhost) by big-O.math.psu.edu (8.8.5/8.8.5) id CAA02781; Fri, 7 Mar 1997 02:13:57 -0500 (EST) Date: Fri, 7 Mar 1997 02:13:57 -0500 (EST) From: Dan Cross Message-Id: <199703070713.CAA02781@big-O.math.psu.edu> To: FreeBSD-gnats-submit@freebsd.org, security@freebsd.org Subject: Workaround for NFS filehandle bug. Reply-To: tenser@big-O.math.psu.edu X-send-pr-version: 3.2 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Submitter-Id: current-users >Originator: Dan Cross >Organization: Penn State University >Confidential: no >Synopsis: Fix for the NFS filehandle bug. >Severity: critical >Priority: high >Category: kern >Release: FreeBSD 3.0-CURRENT i386 >Class: change-request >Environment: This is from 3.0-current, kernel cvsup'ed as of today. >Description: Workaround for the NFS filehandle thingy. A better solution which really randomizes the filehandles would be better. :-) Then again, I shouldn't talk, since I'm not really all that familiar with the NFS implementation... This is basically what was in the advisory, but in diff format. >How-To-Repeat: See the BoS posting. >Fix: *** vfs_vnops.c 1997/02/22 09:39:36 1.30 --- vfs_vnops.c 1997/03/07 07:07:16 *************** *** 411,417 **** sb->st_ctimespec = vap->va_ctime; sb->st_blksize = vap->va_blocksize; sb->st_flags = vap->va_flags; ! sb->st_gen = vap->va_gen; #if (S_BLKSIZE == 512) /* Optimize this case */ sb->st_blocks = vap->va_bytes >> 9; --- 411,420 ---- sb->st_ctimespec = vap->va_ctime; sb->st_blksize = vap->va_blocksize; sb->st_flags = vap->va_flags; ! if (suser(p->p_ucred, &p->p_acflag)) ! sb->st_gen = 0; ! else ! sb->st_gen = vap->va_gen; #if (S_BLKSIZE == 512) /* Optimize this case */ sb->st_blocks = vap->va_bytes >> 9; From owner-freebsd-security Thu Mar 6 23:27:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA22322 for security-outgoing; Thu, 6 Mar 1997 23:27:54 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA22317 for ; Thu, 6 Mar 1997 23:27:49 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id SAA05596; Fri, 7 Mar 1997 18:18:25 +1100 Date: Fri, 7 Mar 1997 18:18:25 +1100 From: Bruce Evans Message-Id: <199703070718.SAA05596@godzilla.zeta.org.au> To: danny@panda.hilink.com.au, mpp@freefall.freebsd.org Subject: Re: 4.4BSD NFS File Handles (fwd) Cc: freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I've worked on other systems in the past where we only returned >st_gen if the caller was root. Why return it at all? It is not used by any application in /usr/src. Don't apply the suggested patch without fixing it. It sets the ASU accounting flag for all processes with euid root just for calling stat(). It has style bugs. Bruce From owner-freebsd-security Thu Mar 6 23:40:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA23104 for security-outgoing; Thu, 6 Mar 1997 23:40:09 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA23010; Thu, 6 Mar 1997 23:39:45 -0800 (PST) From: Mike Pritchard Message-Id: <199703070739.XAA23010@freefall.freebsd.org> Subject: Re: 4.4BSD NFS File Handles (fwd) To: bde@zeta.org.au (Bruce Evans) Date: Thu, 6 Mar 1997 23:39:45 -0800 (PST) Cc: danny@panda.hilink.com.au, freebsd-security@freebsd.org In-Reply-To: <199703070718.SAA05596@godzilla.zeta.org.au> from "Bruce Evans" at Mar 7, 97 06:18:25 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > > >I've worked on other systems in the past where we only returned > >st_gen if the caller was root. > > Why return it at all? It is not used by any application in /usr/src. It was actually useful for some in-house root only application we had. It was also useful for debugging purposes for for a root user to be able to run a little program that that dumped out the stat structure. I can examplin the application in some detail if anyone is interested, but I would hate to seest_gen not be returned at all, since there are some uses for it. -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-security Thu Mar 6 23:52:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA24106 for security-outgoing; Thu, 6 Mar 1997 23:52:54 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA24098 for ; Thu, 6 Mar 1997 23:52:49 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id IAA01682; Fri, 7 Mar 1997 08:52:18 +0100 (MET) From: Guido van Rooij Message-Id: <199703070752.IAA01682@gvr.win.tue.nl> Subject: Re: 4.4BSD NFS File Handles (fwd) In-Reply-To: <199703070602.WAA17190@freefall.freebsd.org> from Mike Pritchard at "Mar 6, 97 10:02:49 pm" To: mpp@freefall.freebsd.org (Mike Pritchard) Date: Fri, 7 Mar 1997 08:52:18 +0100 (MET) Cc: danny@panda.hilink.com.au, freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Pritchard wrote: > Daniel O'Callaghan wrote: > > > > In addition to returning traditional information, such as the creation time, > > size, inode number and last modification time, the 4.4BSD stat(2) system > > call and related functions return a field called st_gen. The st_gen field > > is a 4 byte value which is different for each item on the filesystem. > > I've worked on other systems in the past where we only returned > st_gen if the caller was root. > > If I remember right, the last time I looked at how the kernel > assigned generation number, it didn't do a very good job > of it (they were pretty predictable). We should probaby > change them to use the random() kernel function. I also want to have the fsirand stuff. That should be enough. Perhaps it should even be built in newfs. -Guido From owner-freebsd-security Fri Mar 7 06:30:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA15408 for security-outgoing; Fri, 7 Mar 1997 06:30:24 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA15394 for ; Fri, 7 Mar 1997 06:30:21 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA26267; Fri, 7 Mar 1997 09:30:13 -0500 Date: Fri, 7 Mar 1997 09:30:13 -0500 From: Garrett Wollman Message-Id: <9703071430.AA26267@halloran-eldar.lcs.mit.edu> To: "Daniel O'Callaghan" Cc: freebsd-security@freebsd.org Subject: 4.4BSD NFS File Handles (fwd) In-Reply-To: References: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > if (suser(p->p_ucred, &p->p_acflag)) { > sb->st_gen = 0; > } else { > sb->st_gen = vap->va_gen; > } This test is bogus. The problem is that is causes p_acflag to get the ``used superuser privileges'' bit set every time a root process calls stat(). Since most processes call stat() at least once in their lifetime, this would make p_acflag completely useless. I'm certainly willing to live with not making this information available through the stat(2) interface at all. Any process with appropriate privilege can simply read the information off the disk anyway, so I don't see any benefit in having it here. (A process with appropriate privilege can also call getfh(2) and parse the returned handle.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Fri Mar 7 07:28:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA20528 for security-outgoing; Fri, 7 Mar 1997 07:28:59 -0800 (PST) Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA20521 for ; Fri, 7 Mar 1997 07:28:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by chrome.jdl.com (8.8.4/8.8.4) with SMTP id JAA06704 for ; Fri, 7 Mar 1997 09:27:21 -0600 (CST) Message-Id: <199703071527.JAA06704@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: localhost [127.0.0.1] didn't use HELO protocol To: security@freebsd.org Subject: Security problem with imapd and ipop3d Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Compiler-Motto: Wintermute is dead. Long live Wintermute. Date: Fri, 07 Mar 1997 09:27:21 -0600 From: Jon Loeliger Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Security, Don't know if you guys saw this or were already aware, but you guys over there in FreeBSD Land might want to know too. Although not strictly FreeBSD in origin, there are FreeBSD packages to which this applies.... Do what thou wilt with this. jdl ---------------------------------------------------------------- Date--Sun, 2 Mar 1997 21:42:14 -0700 From--David Sacerdote Secure Networks Inc. Security Advisory March 2, 1997 Buffer Overflow in imapd and ipop3d A vulnerability exists within Mark Crispin's mail server toolkit that will allow arbitrary individuals to obtain root access to servers running imapd and ipop3d. This vulnerability is present in both the POP3 and IMAP2bis servers included in the PINE distribution, as well as the IMAP2bis and IMAP4 servers included in Mr. Crispin's IMAP toolkit. Technical Details ~~~~~~~~~~~~~~~~~ The vulnerable mail servers call a library routine to affect a Unix "login", authenticating the user against it's password. A stack overrun exists in this routine. In essence this will allow any client with the ability to attempt a login to enter an overly long username to cause arbitrary machine code to execute. Both the POP and IMAP servers Mr. Crispin distributes discard supervisory privileges sometime after this authentication phase. Unfortunately, the overflow occurs before this happens, and the vulnerability will thus allow an attacker superuser access. The problematic routine is server_login(), which is in "log_xxx.c" in the OS-dependent code tree of the server source distribution. The problem occurs due to the routine's attempt to allow a case insensitive match on the username, which it does by copying the username provided to the routine into an automatic variable in the routine's stack. The username buffer is MAILTMPLEN long, which defaults to 1024 bytes. Unfortunately, the server's input buffer is greater than this, allowing a remote client to feed the routine a username greater than 1024 bytes. If the excess characters in this username contain a valid virtual memory address, the routine will overwrite it's stack frame when copying the username, causing the return from the routine to jump to an unexpected location. Interestingly, the buffer is converted to lowercase after being copied. This provides a slight technical challenge, as the machine code required to take over the server contains uppercase characters. However, modifications to the "standard" stack overrun exploit code to reverse the affects of this lowercasing were trivial. On i386 4.4BSD, the VM address required to redirect server_login()'s return need not contain uppercase characters. The flawed code reads: long server_login (char *user, char *pass, int argc, char *argv[]) { char tmp[MAILTMPLEN]; struct passwd *pw = getpwnam (user); /* allow case-independent match */ if(!pw) pw = getpwnam (lcase (strcpy (tmp, user))); } Impact ~~~~~~ Remote individuals, who do not have a valid username and password for the mail server, can obtain root access to systems running a vulnerable IMAP or POP server. Vulnerable Systems ~~~~~~~~~~~~~~~~~~ Any system running Mark Crispin's POP or IMAP server, of a release earlier than 4.1beta is vulnerable. To determine whether your system is vulnerable, telnet to ports 109, 110, 143 and 220. If you see a banner looking like: * OK example.com IMAP2bis Service 7.8(92) at Mon, 3 Mar 1997 12:00:00 -0500 (EST) or: * OK example.com IMAP4 v10.00 server ready or: +OK example.com POP3 3.0(10) w/IMAP client (Report problems in this server to MRC@CAC.Washington.edu) at Mon, 3 Mar 1998 12:00:00 -0500 (EST) Then your system is vulnerable. If you see "POP3 3.3" or "IMAP4rev1" or later, your POP or IMAP server is not vulnerable. POP servers not derived from Mark Crispin's code, including the somewhat confusingly named "pop3d" from the University of California at Davis are not vulnerable to the attack described in this advisory. Similarly, the University of California at Berkeley popper, and derived POP servers, including the Qualcomm popper, are not vulnerable to this attack. Fix Information ~~~~~~~~~~~~~~~ As a temporary workaround, you can disable the POP and IMAP services in /etc/inetd.conf, and then kill and restart inetd. You can fix the problem in the source yourself, by changing the server_login() function to read: char tmp[MAILTMPLEN]; struct passwd *pw = getpwnam (user); if(!pw) { strncpy(tmp, user, MAILTMPLEN - 1); pw = getpwnam(lcase(tmp)); Or, as a final option, you can switch to the IMAP 4.1 beta distribution, which can be found at ftp://ftp.cac.washington.edu/mail/imap.tar.Z. Additional Information ~~~~~~~~~~~~~~~~~~~~~~ If you have any questions about this advisory, feel free to contact me, by sending mail to davids@secnet.com If you wish to encrypt your messages to me, feel free to use the following PGP public key. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzJ4qJAAAAEEAOgB7mooQ6NgzcUSIehKUufGsyojutC7phVXZ+p8FnHLLZNB BLQEtj5kmfww2A2pR29q4rgPeqEUOjWPlLNdSLby3NI8yKz1AQSQLHAwIDXt/lku 8QXClaV6pNIaQSN8cnyyvjH6TYF778yZhYz0mwLqW6dU5whHtP93ojDw1UhtAAUR tCtEYXZpZCBTYWNlcmRvdGUgPGRhdmlkc0BzaWxlbmNlLnNlY25ldC5jb20+ =LtL9 -----END PGP PUBLIC KEY BLOCK----- Further information about the Interactive Mail Aaccess Protocol can be found in RFCs 1731, 1732, 1733, 2060, 2061, 2062, 2086, 2087, 2088, and 2095. Further information about the Post Office Protocol can be found in RFCs 1939 and 1957. Copies of RFCs can be found at http://ds.internic.net/rfc/rfcXXXX.txt For further information about Secure Networks Inc, including product information, past advisories, and papers, see http://www.secnet.com If you wish to obtain Secure Networks advisories via our mailing list, please send mail to sni-advisories-request@secnet.com, with a single line reading: subscribe sni-advisories Copyright ~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networks Inc, and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given. imapd and ipop3d fall under the following license: Copyright 1997 by the University of Washington Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appears in all copies and that both the above copyright notice and this permission notice appear in supporting documentation, and that the name of the University of Washington not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. This software is made available "as is", and THE UNIVERSITY OF WASHINGTON DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, WITH REGARD TO THIS SOFTWARE, INCLUDING WITHOUT LIMITATION ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND IN NO EVENT SHALL THE UNIVERSITY OF WASHINGTON BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. From owner-freebsd-security Fri Mar 7 11:09:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA07568 for security-outgoing; Fri, 7 Mar 1997 11:09:40 -0800 (PST) Received: from atena.eurocontrol.fr (atena.uneec.eurocontrol.fr [147.196.69.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA07556 for ; Fri, 7 Mar 1997 11:09:10 -0800 (PST) Received: by atena.eurocontrol.fr; (5.65v3.2/1.3/10May95) id AA22922; Fri, 7 Mar 1997 20:09:03 +0100 Received: (from roberto@localhost) by caerdonn.eurocontrol.fr (8.8.5/caerdonn-1.1) id UAA22217; Fri, 7 Mar 1997 20:09:03 +0100 (CET) Message-Id: <19970307200903.47617@caerdonn.eurocontrol.fr> Date: Fri, 7 Mar 1997 20:09:03 +0100 From: Ollivier Robert To: security@freebsd.org Subject: Fwd: Bug in connect() for aix 4.1.4 ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.62-1-4,6-11 X-Operating-System: FreeBSD 3.0-CURRENT Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can someone try this on a *non critical* FreeBSD system ? I can crash HP-UX 9.05 and 10.20 easily with it... -----Forwarded message from Cahya Wirawan ----- Date: Wed, 5 Mar 1997 13:23:54 +0100 From: Cahya Wirawan Subject: Bug in connect() for aix 4.1.4 ? To: BUGTRAQ@NETSPACE.ORG Can someone tell me why this simple tcp program crashes aix 4.1.4 . I run this program as a normal user, and the second connect crashes aix. is it just connect's old bug from aix ? i have tried it in aix 3.2 but it works only in 4.1.4. _____________________________________________________________________ #include #include #include #include #include #include main() { int sock; struct sockaddr_in server; struct hostent *hp; sock = socket(AF_INET, SOCK_STREAM, 0); /* or sock = socket(AF_INET, SOCK_STREAM, 6); */ hp = gethostbyname("localhost"); bcopy((char*)hp->h_addr, (char*)&server.sin_addr, hp->h_length); server.sin_family = AF_INET; server.sin_port = 23; connect(sock, (struct sockaddr *)&server, sizeof server); shutdown(sock, 2); server.sin_port = 24; connect(sock, (struct sockaddr *)&server, sizeof server); } _________________________________________________________________________ Cahya Wirawan. -----End of forwarded message----- -- Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr From owner-freebsd-security Fri Mar 7 21:47:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA24084 for security-outgoing; Fri, 7 Mar 1997 21:47:14 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA24077 for ; Fri, 7 Mar 1997 21:47:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id QAA11155; Sat, 8 Mar 1997 16:43:27 +1100 Date: Sat, 8 Mar 1997 16:43:27 +1100 From: Bruce Evans Message-Id: <199703080543.QAA11155@godzilla.zeta.org.au> To: roberto@eurocontrol.fr, security@freebsd.org Subject: Re: Fwd: Bug in connect() for aix 4.1.4 ? Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Can someone try this on a *non critical* FreeBSD system ? I can crash HP-UX >9.05 and 10.20 easily with it... > >-----Forwarded message from Cahya Wirawan ----- > >Date: Wed, 5 Mar 1997 13:23:54 +0100 >From: Cahya Wirawan >Subject: Bug in connect() for aix 4.1.4 ? >To: BUGTRAQ@NETSPACE.ORG > >Can someone tell me why this simple tcp program crashes aix 4.1.4 . >I run this program as a normal user, and the second connect crashes aix. >is it just connect's old bug from aix ? i have tried it in aix 3.2 >but it works only in 4.1.4. It doesn't crash, but ktracing it produces a sparse file of length 4GB-2. Bruce From owner-freebsd-security Fri Mar 7 22:14:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA26048 for security-outgoing; Fri, 7 Mar 1997 22:14:56 -0800 (PST) Received: from saguaro.flyingfox.com (saguaro.flyingfox.com [204.188.109.253]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA26036 for ; Fri, 7 Mar 1997 22:14:53 -0800 (PST) Received: (from jas@localhost) by saguaro.flyingfox.com (8.6.12/8.6.10) id WAA02292; Fri, 7 Mar 1997 22:09:34 -0800 Date: Fri, 7 Mar 1997 22:09:34 -0800 From: Jim Shankland Message-Id: <199703080609.WAA02292@saguaro.flyingfox.com> To: roberto@eurocontrol.fr, security@freebsd.org Subject: Re: Fwd: Bug in connect() for aix 4.1.4 ? Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Definitely didn't crash my 2.2-GAMMA system; even after fixing the bug with the missing htons in the sin_port assignments. Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Sat Mar 8 15:41:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA07925 for security-outgoing; Sat, 8 Mar 1997 15:41:58 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA07892; Sat, 8 Mar 1997 15:40:43 -0800 (PST) From: Mike Pritchard Message-Id: <199703082340.PAA07892@freefall.freebsd.org> Subject: Re: 4.4BSD NFS File Handles (fwd) To: guido@gvr.win.tue.nl (Guido van Rooij) Date: Sat, 8 Mar 1997 15:40:43 -0800 (PST) Cc: danny@panda.hilink.com.au, freebsd-security@freebsd.org In-Reply-To: <199703070752.IAA01682@gvr.win.tue.nl> from "Guido van Rooij" at Mar 7, 97 08:52:18 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Guido van Rooij wrote: > > Mike Pritchard wrote: > > If I remember right, the last time I looked at how the kernel > > assigned generation number, it didn't do a very good job > > of it (they were pretty predictable). We should probaby > > change them to use the random() kernel function. > > I also want to have the fsirand stuff. That should be enough. Perhaps > it should even be built in newfs. -- We also need to remove the code in ffs_alloc that sets the generation number = the current time if it is currently less than the current time. Right now, you can pretty much guess the generation number by loking at a files ctime and mtime fields. If the gen number isn't equal to one of those, then it is usually within some small delta of them. -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-security Sat Mar 8 16:05:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA08843 for security-outgoing; Sat, 8 Mar 1997 16:05:31 -0800 (PST) Received: from cwsys.cwent.com (0@cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA08831 for ; Sat, 8 Mar 1997 16:05:23 -0800 (PST) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id PAA06109; Sat, 8 Mar 1997 15:43:31 -0800 (PST) Message-Id: <199703082343.PAA06109@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd006106; Sat Mar 8 23:43:22 1997 Reply-to: cys@mailhost.wlc.com X-Mailer: MH To: Ollivier Robert cc: security@freebsd.org Subject: Re: Fwd: Bug in connect() for aix 4.1.4 ? In-reply-to: Your message of "Fri, 07 Mar 1997 20:09:03 +0100." <19970307200903.47617@caerdonn.eurocontrol.fr> Date: Sat, 08 Mar 1997 15:43:22 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Can someone try this on a *non critical* FreeBSD system ? I can crash HP-UX > 9.05 and 10.20 easily with it... It doesn't affect 2.1.6. > > -----Forwarded message from Cahya Wirawan ----- > > Date: Wed, 5 Mar 1997 13:23:54 +0100 > From: Cahya Wirawan > Subject: Bug in connect() for aix 4.1.4 ? > To: BUGTRAQ@NETSPACE.ORG > > Can someone tell me why this simple tcp program crashes aix 4.1.4 . > I run this program as a normal user, and the second connect crashes aix. > is it just connect's old bug from aix ? i have tried it in aix 3.2 > but it works only in 4.1.4. > > _____________________________________________________________________ > > #include > #include > #include > #include > #include > #include > > main() > { > int sock; > struct sockaddr_in server; > struct hostent *hp; > > sock = socket(AF_INET, SOCK_STREAM, 0); > /* or sock = socket(AF_INET, SOCK_STREAM, 6); */ > hp = gethostbyname("localhost"); > bcopy((char*)hp->h_addr, (char*)&server.sin_addr, hp->h_length); > server.sin_family = AF_INET; > server.sin_port = 23; > connect(sock, (struct sockaddr *)&server, sizeof server); > shutdown(sock, 2); > server.sin_port = 24; > connect(sock, (struct sockaddr *)&server, sizeof server); > } > > > _________________________________________________________________________ > Cahya Wirawan. > > -----End of forwarded message----- > > -- > Ollivier ROBERT -=- Eurocontrol EEC/TS -=- Ollivier.Robert@eurocontrol.fr > > Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it."