From owner-freebsd-security Sun Feb 16 03:25:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA25318 for security-outgoing; Sun, 16 Feb 1997 03:25:40 -0800 (PST) Received: from blah.rotterdam.luna.net (blah.rotterdam.luna.net [194.151.24.42]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA25309 for ; Sun, 16 Feb 1997 03:25:32 -0800 (PST) Received: (from stefan@localhost) by blah.rotterdam.luna.net (8.8.5/8.8.5) id MAA05786; Sun, 16 Feb 1997 12:20:06 +0100 (MET) Message-ID: <19970216122006.SK38705@blah.rotterdam.luna.net> Date: Sun, 16 Feb 1997 12:20:06 +0100 From: stefan.arentz@luna.net (Stefan Arentz) To: security@FreeBSD.ORG Subject: Re: blowfish passwords in FreeBSD References: <199702140811.CAA26293@main.gbdata.com> <199702141016.LAA20635@bcv64s3e.vz.cit.alcatel.fr> X-Mailer: Mutt 0.60 Mime-Version: 1.0 Organization: Luna Internet In-Reply-To: <199702141016.LAA20635@bcv64s3e.vz.cit.alcatel.fr>; from Luc.LEWY on Feb 14, 1997 11:16:09 +0100 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Both Dr Dobbs articles were written by Bruce Scheier and were published in: April 95, page 38 September 95, page 137 - Stefan Luc.LEWY writes: > Gary Clark II wrote: > > > > Did they post the location of any white papers? I'd like to read about > > it. > > mm.. > DrDobbs Journal write a very good article on this subject few years > ago.. I'll post its reference when I'll find it again.. > > > Gary > > fifi... > -- > Guezou "fifi..." Philippe email: guezou_p@epita.fr > pguezou@iway.fr > luc.lewy@vz.cit.alcatel.fr From owner-freebsd-security Sun Feb 16 06:12:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA06107 for security-outgoing; Sun, 16 Feb 1997 06:12:48 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA06096 for ; Sun, 16 Feb 1997 06:12:40 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id PAA12443; Sun, 16 Feb 1997 15:12:30 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id PAA13514; Sun, 16 Feb 1997 15:12:15 +0100 Received: (from pb@localhost) by fasterix.frmug.fr.net (8.7.5/8.7.3-fasterix-960828) id PAA03534; Sun, 16 Feb 1997 15:10:38 +0100 (MET) Message-ID: <19970216151037.OE63475@@> Date: Sun, 16 Feb 1997 15:10:37 +0100 From: pb@fasterix.freenix.fr (Pierre Beyssac) To: rkw@dataplex.net (Richard Wackerbarth) Cc: phk@critter.dk.tfs.com (Poul-Henning Kamp), security@FreeBSD.ORG Subject: Re: changing password... References: X-Mailer: Mutt 0.59.1e Mime-Version: 1.0 In-Reply-To: ; from Richard Wackerbarth on Feb 15, 1997 21:03:53 -0600 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth writes: > This proposal would allow it. > > login: my_name > passwd: Clear_text_1 > > passwd -c $n$Hash_of_Clear_text_2$ > > [real work here] > logoff It shouldn't be that simple. You have to request the old password first, or...: passwd -c $n$Hash_of_Clear_text_2$ [real work here] [coffee break] passwd -c $n$Hash_of_something_else_by_somebody_else$ [end coffee break] [real work here] logoff You've just been stolen your account. This pretty much defeats the whole interest of -c, which is to allow a portable way to change the encrypted password. -- Pierre Beyssac pb@fasterix.frmug.fr.net pb@fasterix.freenix.fr {Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher Free domains: http://www.eu.org/ or mail dns-manager@EU.org From owner-freebsd-security Sun Feb 16 06:39:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA06841 for security-outgoing; Sun, 16 Feb 1997 06:39:08 -0800 (PST) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA06834; Sun, 16 Feb 1997 06:38:57 -0800 (PST) Received: (from davidn@localhost) by labs.usn.blaze.net.au (8.8.5/8.8.5) id BAA04399; Mon, 17 Feb 1997 01:38:46 +1100 (EST) Message-ID: <19970217013846.36579@usn.blaze.net.au> Date: Mon, 17 Feb 1997 01:38:46 +1100 From: David Nugent To: Giles Lean Cc: phk@freebsd.org, security@freebsd.org Subject: Re: changing password... References: <14434.856046887@critter.dk.tfs.com> <199702152347.KAA01118@nemeton.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61 In-Reply-To: <199702152347.KAA01118@nemeton.com.au>; from Giles Lean on Feb 02, 1997 at 10:47:16AM Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Feb 02, 1997 at 10:47:16AM, Giles Lean wrote: > > $ passwd -c phk > > Please enter encrypted password: $1$8cEEj84y$GCYmM39miP8Fc9K8iAHTI/ > > Please reenter: $1$8cEEj84y$GCYmM39miP8Fc9K8iAHTI/ > > $ > > Yes please! I'm tired of working out how different Unix flavours lock > the password database when writing localised adduser scripts. Actually, that's why pw(8) exists. But it doesn't (yet) have the above facility. FWIW, it was added to the impending 2.1.7 a week or so ago. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-security Sun Feb 16 09:45:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA14847 for security-outgoing; Sun, 16 Feb 1997 09:45:40 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA14842 for ; Sun, 16 Feb 1997 09:45:33 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id SAA12172; Sun, 16 Feb 1997 18:47:21 +0100 (MET) From: Mikael Karpberg Message-Id: <199702161747.SAA12172@ocean.campus.luth.se> Subject: Re: blowfish passwords in FreeBSD To: brandon@cold.org (Brandon Gillespie) Date: Sun, 16 Feb 1997 18:47:20 +0100 (MET) Cc: security@freebsd.org In-Reply-To: from Brandon Gillespie at "Feb 14, 97 01:48:14 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Brandon Gillespie: > > I have your scheme commit-ready now. It looks like we'll have too merge > > in this as well. > > Actually, I'd like to also submit a patch for 'passwd' that reads > something like /etc/passwd.conf for a 'preference', where the file simply > contains 'best' 'DES' or a $x$ prefix. If it is 'best' it'll use the > best/latest algorithm, DES is obvious, otherwise it just prefixes the > '$x$' string in the file to the salt. I'd like this because for me, I > have many older DES passwords from upgrades, and I'd like to migrate to > better passwords but right now if DES exists as an option, it is always > given encryption preference in 'passwd'.. At least some of that seems like a great idea. I mean... Why not have the fields use $name$salt$passwd$ ? Where name is the name of the encryption used? $1$ really says nothing. And then you would never have the problem with different OSes having different numbering. the name stays the same, right? bfish, des, md5, etc... Sure, to be backward compatible after changing, you could just make "1" alias for "md5" and "2" alias for "bfish", but that's no biggie. And it could be solved with symlinks for this idea: How about having dynamically linked crypt routines, that follow some API, and are loaded by name? Like.... Umm... have /etc/crypt/ contain maybe a settings file, and then also some .so files, that are loaded when needed and then kept in memory. Normally you could have /etc/crypt/md5.so and maybe /etc/crypt/des.so, if you add the des package. Also you would have symlink 1.so -> md5.so, and it would be quite easy if you, for example, had a file with blowfish passwords from OpenBSD that you wanted to use. Just do: "cd /etc/crypt/ ; cp ..../blowfish.so blowfish.so ; ln -s blowfish.so 2.so" Then copy the passwd file, and make the .db files, and it Just Works. If loading the .so file set in $name$ field failed, crypt could just return a string like "****************", which is not likely to match anything, or simply return NULL. Maybe not a completely thought through idea, but... would something like it work? /Mikael From owner-freebsd-security Sun Feb 16 12:14:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA23823 for security-outgoing; Sun, 16 Feb 1997 12:14:03 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA23813 for ; Sun, 16 Feb 1997 12:13:59 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id PAA08067; Sun, 16 Feb 1997 15:14:31 -0500 (EST) Date: Sun, 16 Feb 1997 15:14:31 -0500 (EST) From: Mark Mayo To: Warner Losh cc: Poul-Henning Kamp , security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 15 Feb 1997, Warner Losh wrote: > In message <11871.855990294@critter.dk.tfs.com> Poul-Henning Kamp writes: > : Theo belives he can export anything just because he is in Canada. > > He can. That's what Candian law states. He's looked into it. More > importantly, others unrelated to the OpenBSD project have looked into > it and have recieved the necessary permissions to export their > cryptographic code. This is true: Item 1000 in the ECL is a General Technology Note (GTN) and a General Software Note (GSN). These notes permit the export of "software" or "technology" that is "in the public domain", and also permit the export of "basic scientific research". "In the public domain" simply means that there are no distribution restrictions. FreeBSD applies, I believe. Since I am Canadian, it is legal for me to export Cryptography (with the exception of a few countries..) software and 'technology'. I would certainly be willing to distribute FreeBSD software on my server - including DES (the Canadian version). On that note, I'm a little curious.. our laws state that the exprted software must be >50% Canadian Content... The DES package, for example, is only 15% US, so it can be exported (along with Kerberos, and SFS). I wonder how they define Canadian content... Okay, I live in Canada.. what if I gave access to my 'canadian machines' to US developers - would the final code be considered Canadian? It was developed "in Canada", since the machines on are Canadian soil. I'm going to check into this, since it could be a great way to get around moronic US export laws! Perhaps the bodies must me in Canada as well - I'll check. At any rate, it only applies in the case that US developers work on cryptography software - since the US has prosecuted Canadians for exporting US cryptography, the government warns. If people from more enlightened governments develop on Canadian machines, everything is okay and I can export to my hearts content. Sort of similar to the Canada/Cuba thing and the US gov. bitching about extradited US property being 'illegally' used by Canadian business (tell ya' what, if America gives back the British capitals seized during the American revolution, Canada/Cuba will give back the US capitals seized during the Cuban revolution...). Anways, I'm going to research the Canadian export laws some more, and see how anal my gov. really is. It might be necessary to move the main FreeBSD distribution out of the US if the US gov. doesn't smarten up soon. A site in Europe and one in Canada would server both continents. -Mark ---------------------------------------------------------------------------- Mark Mayo mark@quickweb.com RingZero Comp. http://vinyl.quickweb.com/mark ---------------------------------------------------------------------------- "I prefer tongue-tied knowledge to ignorant loquacity." Cicero (106-43 B.C.) From owner-freebsd-security Sun Feb 16 13:07:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA27109 for security-outgoing; Sun, 16 Feb 1997 13:07:01 -0800 (PST) Received: from cwsys.cwent.com (cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27104 for ; Sun, 16 Feb 1997 13:06:56 -0800 (PST) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id NAA03252; Sun, 16 Feb 1997 13:05:16 -0800 (PST) Message-Id: <199702162105.NAA03252@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd003247; Sun Feb 16 21:05:09 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: Xmh To: Bruce Evans cc: dufault@hda.com, roberto@keltia.freenix.fr, freebsd-security@FreeBSD.org Subject: Re: buffer overruns In-reply-to: Your message of "Tue, 11 Feb 1997 12:23:40 +1100." <199702110123.MAA28254@godzilla.zeta.org.au> Date: Sun, 16 Feb 1997 13:05:08 -0800 From: Cy Schubert Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >Has anyone seen modifications to gcc to generate guard bands around > >automatics and stack check sequences? The automatics can be checked > >when they come into / go out of existence, and stack integrity at > >return time. It won't stop the exploits, but it will make them > >harder, and you will get "security" dumps from setuid programs if > >you require that setuid programs be compiled that way (and linked > >against a separate "secure" library compiled that way also). > > I haven't seen anything. Perhaps something could be hacked into > the existing profiling support. I added a -mprofiler-epilogue > call to FreeBSD's gcc. It results in calls to a profiling function > `mexitcount' before each normal function returns. This would be > a good to check the return address and other stuff in the caller's > frame. What about the bounds-checking gcc? Would that be a place to start? You can get it from ftp://dse.doc.ic.ac.uk/pub/misc/bcc/. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Sun Feb 16 13:28:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA28411 for security-outgoing; Sun, 16 Feb 1997 13:28:35 -0800 (PST) Received: from relay.nuxi.com (nuxi.ucdavis.edu [128.120.37.176]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA28071; Sun, 16 Feb 1997 13:20:38 -0800 (PST) Received: from dragon.nuxi.com (reqb-055.ucdavis.edu [128.120.254.55]) by relay.nuxi.com (8.8.4/8.6.12) with ESMTP id NAA03127; Sun, 16 Feb 1997 13:20:44 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.5/8.7.3) id VAA08208; Sun, 16 Feb 1997 21:20:31 GMT Message-ID: <19970216132031.XX10822@dragon.nuxi.com> Date: Sun, 16 Feb 1997 13:20:31 -0800 From: obrien@NUXI.com (David O'Brien) To: freebsd-security@freebsd.org, stable@freebsd.org Cc: core@freebsd.org Subject: (fwd) Re: Shell Access X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Disclaimer: Mutt Bites! Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is from CalWeb ISP in Sacramento CA. They were running 2.1-STABLE on the shell account machines. They are now running 2.2-970207-GAMMA. This ISP's resonce to the setlocale vulnerability was to shut off shell accounts for several days (and w/o notice to it's customers). -- forwarded message -- Path: calweb!not-for-mail From: rdugaue@calweb.com (Robert Du Gaue) Newsgroups: calweb.general Subject: Re: Shell Access Date: 7 Feb 1997 15:49:30 GMT Organization: CalWeb Internet Services, Inc. Lines: 19 Message-ID: <5dfiua$j37$1@news.calweb.com> References: <32FADDA2.8FF@calweb.com> NNTP-Posting-Host: web1.calweb.com X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] Xref: calweb calweb.general:634 Steve Phariss (rebo@calweb.com) wrote: : Can we have more details on the shell access??? : : Motd 02/07/97: : : > 02/07/97 Shell logins are disabled until a new security : > release is made available. We appologize : > for the inconvenience. : > : : Any idea how long till access is going to be restored? A new security release for the OS is expected within the next couple of days (rumor has it 'anytime', maybe today). -------------------------------------------------------------------------- Robert Du Gaue - rdugaue@calweb.com http://www.calweb.com President, CalWeb Internet Services Inc. (916) 641-9320 -------------------------------------------------------------------------- -- end of forwarded message -- From owner-freebsd-security Sun Feb 16 13:36:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA28864 for security-outgoing; Sun, 16 Feb 1997 13:36:09 -0800 (PST) Received: from kirk.edmweb.com (kirk.edmweb.com [204.244.190.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA28857 for ; Sun, 16 Feb 1997 13:36:06 -0800 (PST) Received: from bitbucket (bluesmoke.edmweb.com [204.244.190.8]) by kirk.edmweb.com (8.8.5/8.7.3) with ESMTP id NAA11506; Sun, 16 Feb 1997 13:35:42 -0800 (PST) Received: from localhost by bitbucket with smtp id m0vwEFA-000CEdC (Debian Smail-3.2 1996-Jul-4 #2); Sun, 16 Feb 1997 13:35:32 -0800 (PST) Date: Sun, 16 Feb 1997 13:35:30 -0800 (PST) From: Steve Reid X-Sender: steve@bluesmoke To: Mark Mayo cc: Warner Losh , Poul-Henning Kamp , security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > : Theo belives he can export anything just because he is in Canada. > > > > He can. That's what Candian law states. He's looked into it. [snip] > Item 1000 in the ECL is a General Technology Note (GTN) and a General > Software Note (GSN). These notes permit the export of "software" or > "technology" that is "in the public domain", and also permit the export of > "basic scientific research". "In the public domain" simply means that > there are no distribution restrictions. FreeBSD applies, I believe. Marc Plumb has done some research into Canada's laws. Take a look at http://insight.mcmaster.ca/org/efc/pages/doc/crypto-export.html Has Theo had any problems travelling in the US? print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0 Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA07249 for security-outgoing; Sun, 16 Feb 1997 16:02:31 -0800 (PST) Received: from blah.rotterdam.luna.net (blah.rotterdam.luna.net [194.151.24.42]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA07244 for ; Sun, 16 Feb 1997 16:02:27 -0800 (PST) Received: (from stefan@localhost) by blah.rotterdam.luna.net (8.8.5/8.8.5) id AAA06942; Mon, 17 Feb 1997 00:57:15 +0100 (MET) Message-ID: <19970217005715.SA06934@blah.rotterdam.luna.net> Date: Mon, 17 Feb 1997 00:57:15 +0100 From: stefan.arentz@luna.net (Stefan Arentz) To: security@freebsd.org Subject: Re: (fwd) Re: Shell Access References: <19970216132031.XX10822@dragon.nuxi.com> X-Mailer: Mutt 0.60 Mime-Version: 1.0 Organization: Luna Internet In-Reply-To: <19970216132031.XX10822@dragon.nuxi.com>; from David O'Brien on Feb 16, 1997 13:20:31 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk And now for something complete different: Isn't it possible to block root hacks with a wrapper around the kernel's setuid()/seteuid()/setgid()/setegid() system call implementation that can deny the call on basis of the user id that is requesting the change of credentials? I know this is a partial solution, but even only blocking changes to root will probably help a lot. The code could be extended to log requests like this; if you setup syslog to log to a central machine then you can very easily detect them. Am I missing something here, or does this sound reasonable? - Stefan David O'Brien writes: > This is from CalWeb ISP in Sacramento CA. They were running 2.1-STABLE > on the shell account machines. They are now running 2.2-970207-GAMMA. > > This ISP's resonce to the setlocale vulnerability was to shut off shell > accounts for several days (and w/o notice to it's customers). > > -- forwarded message -- > Path: calweb!not-for-mail > From: rdugaue@calweb.com (Robert Du Gaue) > Newsgroups: calweb.general > Subject: Re: Shell Access > Date: 7 Feb 1997 15:49:30 GMT > Organization: CalWeb Internet Services, Inc. > Lines: 19 > Message-ID: <5dfiua$j37$1@news.calweb.com> > References: <32FADDA2.8FF@calweb.com> > NNTP-Posting-Host: web1.calweb.com > X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] > Xref: calweb calweb.general:634 > > Steve Phariss (rebo@calweb.com) wrote: > : Can we have more details on the shell access??? > : > : Motd 02/07/97: > : > : > 02/07/97 Shell logins are disabled until a new security > : > release is made available. We appologize > : > for the inconvenience. > : > > : > : Any idea how long till access is going to be restored? > > A new security release for the OS is expected within the next > couple of days (rumor has it 'anytime', maybe today). > > -------------------------------------------------------------------------- > Robert Du Gaue - rdugaue@calweb.com http://www.calweb.com > President, CalWeb Internet Services Inc. (916) 641-9320 > -------------------------------------------------------------------------- > -- end of forwarded message -- -- Stefan Arentz - Technical Director - Luna Internet stefan.arentz@luna.net / +31 (0)10 4656232 To err is human, to forgive is Not Company Policy. From owner-freebsd-security Sun Feb 16 17:01:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA10452 for security-outgoing; Sun, 16 Feb 1997 17:01:30 -0800 (PST) Received: from relay.nuxi.com (nuxi.ucdavis.edu [128.120.37.176]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA10284; Sun, 16 Feb 1997 16:59:00 -0800 (PST) Received: from dragon.nuxi.com ([207.211.82.25]) by relay.nuxi.com (8.8.4/8.6.12) with ESMTP id QAA03837; Sun, 16 Feb 1997 16:59:11 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.5/8.7.3) id AAA08697; Mon, 17 Feb 1997 00:58:30 GMT Message-ID: <19970216165828.NN28029@dragon.nuxi.com> Date: Sun, 16 Feb 1997 16:58:28 -0800 From: obrien@NUXI.com (David O'Brien) To: freebsd-security@freebsd.org, stable@freebsd.org Cc: core@freebsd.org Subject: Re: (fwd) Re: Shell Access References: <19970216132031.XX10822@dragon.nuxi.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Disclaimer: Mutt Bites! Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 In-Reply-To: <19970216132031.XX10822@dragon.nuxi.com>; from David O'Brien on Feb 16, 1997 13:20:31 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David O'Brien writes: > This is from CalWeb ISP in Sacramento CA. They were running 2.1-STABLE > on the shell account machines. They are now running 2.2-970207-GAMMA. > > This ISP's resonce to the setlocale vulnerability was to shut off shell > accounts for several days (and w/o notice to it's customers). Looking at this again, I'm afraid it could be a slant agaist CalWeb. It wasn't. Rather I was just passing along what one ISP felt nessicary to do in responce to things. I've also heard, the accounts were turned for about 24 hours. > -- forwarded message -- > Path: calweb!not-for-mail > From: rdugaue@calweb.com (Robert Du Gaue) > Newsgroups: calweb.general > Subject: Re: Shell Access > Date: 7 Feb 1997 15:49:30 GMT > Organization: CalWeb Internet Services, Inc. > Lines: 19 > Message-ID: <5dfiua$j37$1@news.calweb.com> > References: <32FADDA2.8FF@calweb.com> > NNTP-Posting-Host: web1.calweb.com > X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] > Xref: calweb calweb.general:634 > > Steve Phariss (rebo@calweb.com) wrote: > : Can we have more details on the shell access??? > : > : Motd 02/07/97: > : > : > 02/07/97 Shell logins are disabled until a new security > : > release is made available. We appologize > : > for the inconvenience. > : > > : > : Any idea how long till access is going to be restored? > > A new security release for the OS is expected within the next > couple of days (rumor has it 'anytime', maybe today). > > -------------------------------------------------------------------------- > Robert Du Gaue - rdugaue@calweb.com http://www.calweb.com > President, CalWeb Internet Services Inc. (916) 641-9320 > -------------------------------------------------------------------------- > -- end of forwarded message -- From owner-freebsd-security Sun Feb 16 18:13:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA14267 for security-outgoing; Sun, 16 Feb 1997 18:13:04 -0800 (PST) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA14262 for ; Sun, 16 Feb 1997 18:13:00 -0800 (PST) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id SAA18122; Sun, 16 Feb 1997 18:12:18 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id SAA09309; Sun, 16 Feb 1997 18:12:17 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.4/8.8.4) id SAA23186; Sun, 16 Feb 1997 18:12:12 -0800 (PST) From: Don Lewis Message-Id: <199702170212.SAA23186@salsa.gv.tsc.tdk.com> Date: Sun, 16 Feb 1997 18:12:12 -0800 In-Reply-To: Cy Schubert "Re: buffer overruns" (Feb 16, 1:05pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: cschuber@uumail.gov.bc.ca, Bruce Evans Subject: Re: buffer overruns Cc: dufault@hda.com, roberto@keltia.freenix.fr, freebsd-security@FreeBSD.org Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Feb 16, 1:05pm, Cy Schubert wrote: } Subject: Re: buffer overruns } } What about the bounds-checking gcc? Would that be a place to start? } You can get it from ftp://dse.doc.ic.ac.uk/pub/misc/bcc/. I'm using it for something right now, but it's not a general purpose solution. It doesn't get along very well with signals. Your code will run about 20 times slower. It works really well in those cases where your software manages to corrupt large parts of its memory before finally core dumping, so that you can't figure out what caused the initial problem by pointing gdb at the core dump. --- Truck From owner-freebsd-security Sun Feb 16 19:30:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA18187 for security-outgoing; Sun, 16 Feb 1997 19:30:36 -0800 (PST) Received: from cwsys.cwent.com (cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA18181 for ; Sun, 16 Feb 1997 19:30:31 -0800 (PST) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id TAA14440; Sun, 16 Feb 1997 19:29:30 -0800 (PST) Message-Id: <199702170329.TAA14440@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd014436; Mon Feb 17 03:29:21 1997 Reply-to: cys@mailhost.wlc.com X-Mailer: Xmh To: Poul-Henning Kamp cc: Jason Fesler , security@freebsd.org Subject: Re: changing password... In-reply-to: Your message of "Sun, 16 Feb 1997 01:28:37 +0100." <14683.856052917@critter.dk.tfs.com> Date: Sun, 16 Feb 1997 19:29:21 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In message <3.0.1.32.19970215160537.006e1dec@pop.calweb.com>, Jason Fesler wr ites: > >At 11:48 PM 2/15/97 +0100, Poul-Henning Kamp wrote: > >> > >>Why don't we have an option for /usr/bin/passwd to input a precoded > >>password ? > > > >Hmm, I thought that's what we use chpass for ... :-) > >It is willing to take a command-line encrypted password for > >the argument. I'm using it on a www password change routine. > > Yes, but only root can use the -p option on chpass, right ? Why not create an optional setuid root front end to chpass that does this. A simple Perl script would suffice. Why make the base code more complex when we don't need to? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Mon Feb 17 09:24:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA28707 for security-outgoing; Mon, 17 Feb 1997 09:24:16 -0800 (PST) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA28700 for ; Mon, 17 Feb 1997 09:24:13 -0800 (PST) Received: from nemeton.UUCP (Unemeton@localhost) by perki0.connect.com.au with UUCP id EAA19455 (8.7.6h/IDA-1.6); Tue, 18 Feb 1997 04:22:39 +1100 (EST) X-Authentication-Warning: perki0.connect.com.au: Unemeton set sender to giles@nemeton.com.au using -f Received: from localhost.nemeton.com.au (localhost.nemeton.com.au [127.0.0.1]) by nemeton.com.au (8.8.5/8.8.5) with SMTP id UAA18958; Mon, 17 Feb 1997 20:49:20 +1100 (EST) Message-Id: <199702170949.UAA18958@nemeton.com.au> To: stefan.arentz@luna.net (Stefan Arentz) cc: security@freebsd.org Subject: Re: (fwd) Re: Shell Access In-reply-to: <19970217005715.SA06934@blah.rotterdam.luna.net> Date: Mon, 17 Feb 1997 20:49:20 +1100 From: Giles Lean Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 17 Feb 1997 00:57:15 +0100 Stefan Arentz wrote: > Isn't it possible to block root hacks with a wrapper around the kernel's > setuid()/seteuid()/setgid()/setegid() system call implementation that > can deny the call on basis of the user id that is requesting the change > of credentials? Rather than do this, take the setuid bits off the things you want to protect and use a program supporting explicit access lists and logging to run these programs. (Think 'sudo', 'priv' etc.) In the case of commercial OSes, lots of things with setuid bits set don't need to be setuid since it doesn't make sense for anyone other than root to run them. (Minor success report: I've had two setuid bits removed from HP-UX. :-) Giles From owner-freebsd-security Mon Feb 17 11:11:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA07352 for security-outgoing; Mon, 17 Feb 1997 11:11:17 -0800 (PST) Received: from saguaro.flyingfox.com (saguaro.flyingfox.com [204.188.109.253]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA07332 for ; Mon, 17 Feb 1997 11:11:12 -0800 (PST) Received: (from jas@localhost) by saguaro.flyingfox.com (8.6.12/8.6.10) id LAA14225; Mon, 17 Feb 1997 11:06:05 -0800 Date: Mon, 17 Feb 1997 11:06:05 -0800 From: Jim Shankland Message-Id: <199702171906.LAA14225@saguaro.flyingfox.com> To: imp@village.org, phk@critter.dk.tfs.com Subject: Re: blowfish passwords in FreeBSD Cc: lithium@cia-g.com, security@FreeBSD.org Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp writes: > I have personally witnessed a P5/60 with a ISA card with some > ASIC's break a well chosen password that was DES encrypted > using bruteforce. > > It took slightly less than 3 hours. Hmm. 2^56 possible keys, so on average, you'd need to try 2^55 keys. Say it takes 2^14 seconds (that's a little more than three hours, but about right); then this board was doing 2^41 encryptions per second, or roughly 2 million per microsecond. Now *that's* what I call brute force :-). How much does this ISA card with the ASICs cost :-)? (If I've erred in this analysis, I'd be happy to stand corrected.) Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Mon Feb 17 12:15:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA11527 for security-outgoing; Mon, 17 Feb 1997 12:15:59 -0800 (PST) Received: from fusion.gage.com (brimstone.gage.com [205.217.2.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA11515 for ; Mon, 17 Feb 1997 12:15:52 -0800 (PST) Received: (from mail@localhost) by fusion.gage.com (8.8.3/8.8.4) id OAA13645; Mon, 17 Feb 1997 14:15:41 -0600 (CST) Received: from octopus.gage.com(158.60.57.50) by fusion.gage.com via smap (V2.0beta) id xma013641; Mon, 17 Feb 97 14:15:40 -0600 Received: from squid.gage.com (squid [158.60.57.101]) by octopus.gage.com (8.7.5/8.7.3) with SMTP id OAA01624; Mon, 17 Feb 1997 14:15:39 -0600 (CST) Received: from schemer by squid.gage.com (NX5.67e/NX3.0S) id AA06596; Mon, 17 Feb 97 14:15:38 -0600 Message-Id: <9702172015.AA06596@squid.gage.com> Received: by schemer.gage.com (NX5.67g/NX3.0X) id AA03328; Mon, 17 Feb 97 14:15:37 -0600 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) In-Reply-To: <199702171906.LAA14225@saguaro.flyingfox.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.146.2) From: Ben Black Date: Mon, 17 Feb 97 14:15:37 -0600 To: Jim Shankland Subject: Re: blowfish passwords in FreeBSD Cc: imp@village.org, phk@critter.dk.tfs.com, lithium@cia-g.com, security@freebsd.org References: <199702171906.LAA14225@saguaro.flyingfox.com> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Hmm. 2^56 possible keys, so on average, you'd need to try 2^55 keys. >Say it takes 2^14 seconds (that's a little more than three hours, but about right); then this board was doing 2^41 encryptions per second, >or roughly 2 million per microsecond. he didn't say it averaged 3 hours. he said it took it 3 hour on a specific key. b3n From owner-freebsd-security Mon Feb 17 12:21:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA11990 for security-outgoing; Mon, 17 Feb 1997 12:21:21 -0800 (PST) Received: from grackle.grondar.za (+RQIeqik5IghWYtvGTckemwg0mamF/Fn@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA11982 for ; Mon, 17 Feb 1997 12:21:11 -0800 (PST) Received: from grackle.grondar.za (yvAWFqaqcJHm9XVsPeMWNGYbXOdMsku9@localhost [127.0.0.1]) by grackle.grondar.za (8.8.5/8.8.4) with ESMTP id WAA03755; Mon, 17 Feb 1997 22:20:07 +0200 (SAT) Message-Id: <199702172020.WAA03755@grackle.grondar.za> X-Mailer: exmh version 2.0gamma 1/27/96 To: Mikael Karpberg cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Feb 1997 22:20:03 +0200 From: Mark Murray Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg wrote: > At least some of that seems like a great idea. > I mean... Why not have the fields use $name$salt$passwd$ ? > Where name is the name of the encryption used? $1$ really says nothing. > And then you would never have the problem with different OSes having > different numbering. the name stays the same, right? bfish, des, md5, etc... > Sure, to be backward compatible after changing, you could just make > "1" alias for "md5" and "2" alias for "bfish", but that's no biggie. > And it could be solved with symlinks for this idea. I like this, In fact Brandon is coding it up. > How about having dynamically linked crypt routines, that follow some API, > and are loaded by name? Like.... Umm... have /etc/crypt/ contain maybe a > settings file, and then also some .so files, that are loaded when needed > and then kept in memory. This will take some repair. IIRC, JDP has offered to do this. > Normally you could have /etc/crypt/md5.so and maybe /etc/crypt/des.so, if you > add the des package. Also you would have symlink 1.so -> md5.so, and it > would be quite easy if you, for example, had a file with blowfish passwords > from OpenBSD that you wanted to use. Just do: > "cd /etc/crypt/ ; cp ..../blowfish.so blowfish.so ; ln -s blowfish.so 2.so" > Then copy the passwd file, and make the .db files, and it Just Works. This come perilously close to breaking the "static only" link that some fols want exclusively in /bin/sbin. > If loading the .so file set in $name$ field failed, crypt could just return > a string like "****************", which is not likely to match anything, or > simply return NULL. _*MAJOR*_ security hole. Do you want an algorithm that you can break in with straight away? This is it. The essence of crypt is that you are _*NOT*_ allowed to deduce the password from the output. > Maybe not a completely thought through idea, but... would something like it > work? You'll have to go back to the man pages for crypt, and see what errors it is allowed to return: NONE. The best I can think of in the case of an error (and I do not like the idea) is UUENCODEd rubbish from /dev/random. I think this is making it too complicated, and opening up avenues of attack. Out of my thumb, here is an attack - a user supplied foocrypt.so, supplying whatever password it found for root, and ignoring its input. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-security Mon Feb 17 12:26:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA12227 for security-outgoing; Mon, 17 Feb 1997 12:26:58 -0800 (PST) Received: from grackle.grondar.za (SFmh/w3F+zp9KVXXBsU8cLpjkD+lPtjF@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA12219 for ; Mon, 17 Feb 1997 12:26:54 -0800 (PST) Received: from grackle.grondar.za (IyoBDZ9BucTK7xolgTCfw91q09lZ8cdi@localhost [127.0.0.1]) by grackle.grondar.za (8.8.5/8.8.4) with ESMTP id WAA03791; Mon, 17 Feb 1997 22:25:09 +0200 (SAT) Message-Id: <199702172025.WAA03791@grackle.grondar.za> X-Mailer: exmh version 2.0gamma 1/27/96 To: Mark Mayo cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Feb 1997 22:25:05 +0200 From: Mark Murray Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark Mayo wrote: > Anways, I'm going to research the Canadian export laws some more, and see > how anal my gov. really is. It might be necessary to move the main FreeBSD > distribution out of the US if the US gov. doesn't smarten up soon. A site > in Europe and one in Canada would server both continents. Um - there is already a distribution of crypto for FreeBSD (DES/Kerberos) that is _IDENTICAL_ to the USA code. Apart from a short break (FBSD2.0) this has been going since about (?) 1993. (Are you there, Geoff?) Most Non-USA sites mirror this code. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-security Mon Feb 17 13:09:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA15145 for security-outgoing; Mon, 17 Feb 1997 13:09:47 -0800 (PST) Received: from saguaro.flyingfox.com (saguaro.flyingfox.com [204.188.109.253]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA15140 for ; Mon, 17 Feb 1997 13:09:43 -0800 (PST) Received: (from jas@localhost) by saguaro.flyingfox.com (8.6.12/8.6.10) id NAA14500; Mon, 17 Feb 1997 13:04:21 -0800 Date: Mon, 17 Feb 1997 13:04:21 -0800 From: Jim Shankland Message-Id: <199702172104.NAA14500@saguaro.flyingfox.com> To: black@gage.com, jas@flyingfox.COM Subject: Re: blowfish passwords in FreeBSD Cc: imp@village.org, lithium@cia-g.com, phk@critter.dk.tfs.com, security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From black@gage.com Mon Feb 17 12:11:49 1997 Return-Path: black@gage.com Received: (from smap@localhost) by saguaro.flyingfox.com (8.6.12/8.6.10) id MAA14448 for ; Mon, 17 Feb 1997 12:11:48 -0800 Received: from brimstone.gage.com(205.217.2.10) by saguaro.flyingfox.com via smap (V1.3) id sma014446; Mon Feb 17 12:11:39 1997 Received: (from mail@localhost) by fusion.gage.com (8.8.3/8.8.4) id OAA13645; Mon, 17 Feb 1997 14:15:41 -0600 (CST) Received: from octopus.gage.com(158.60.57.50) by fusion.gage.com via smap (V2.0beta) id xma013641; Mon, 17 Feb 97 14:15:40 -0600 Received: from squid.gage.com (squid [158.60.57.101]) by octopus.gage.com (8.7.5/8.7.3) with SMTP id OAA01624; Mon, 17 Feb 1997 14:15:39 -0600 (CST) Received: from schemer by squid.gage.com (NX5.67e/NX3.0S) id AA06596; Mon, 17 Feb 97 14:15:38 -0600 Message-Id: <9702172015.AA06596@squid.gage.com> Received: by schemer.gage.com (NX5.67g/NX3.0X) id AA03328; Mon, 17 Feb 97 14:15:37 -0600 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) In-Reply-To: <199702171906.LAA14225@saguaro.flyingfox.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.146.2) From: Ben Black Date: Mon, 17 Feb 97 14:15:37 -0600 To: Jim Shankland Subject: Re: blowfish passwords in FreeBSD Cc: imp@village.org, phk@critter.dk.tfs.com, lithium@cia-g.com, security@freebsd.org References: <199702171906.LAA14225@saguaro.flyingfox.com> Status: R [I wrote:] > Hmm. 2^56 possible keys, so on average, you'd need to try > 2^55 keys. Say it takes 2^14 seconds (that's a little more > than three hours, but about right); then this board was doing > 2^41 encryptions per second, or roughly 2 million per > microsecond. Ben Black writes: > he didn't say it averaged 3 hours. he said it took it 3 hour > on a specific key. OK. Suppose the machine got very lucky, and happened to hit the right key after searching only 1/2^15 of the key space. The chances of getting this lucky are about 1 in 30,000. Then the machine did 2^41 encryptions in 2^14 seconds, or 2^27 encryptions per second, or about 128 per microsecond. Still not too shabby, and I still want to know how much this board costs :-). It is, of course, always possible to guess the right password the very first time, thereby cracking the account in well under a second. This will work even on an old 386 box lying around your lab, and does not require a card with ASICs. All you need is very good luck :-). Whether this says anything meaningful about the cryptographic strength of DES is debatable. Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Mon Feb 17 13:12:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA15456 for security-outgoing; Mon, 17 Feb 1997 13:12:48 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA15449 for ; Mon, 17 Feb 1997 13:12:45 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id QAA10967; Mon, 17 Feb 1997 16:13:08 -0500 (EST) Date: Mon, 17 Feb 1997 16:13:08 -0500 (EST) From: Mark Mayo To: Mark Murray cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: <199702172025.WAA03791@grackle.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 17 Feb 1997, Mark Murray wrote: > Mark Mayo wrote: > > Anways, I'm going to research the Canadian export laws some more, and see > > how anal my gov. really is. It might be necessary to move the main FreeBSD > > distribution out of the US if the US gov. doesn't smarten up soon. A site > > in Europe and one in Canada would server both continents. > > Um - there is already a distribution of crypto for FreeBSD (DES/Kerberos) > that is _IDENTICAL_ to the USA code. Apart from a short break (FBSD2.0) > this has been going since about (?) 1993. (Are you there, Geoff?) > > Most Non-USA sites mirror this code. For DES, yes.... I wasn't really thinking abut the DES distribution, but for future crypto distributions. The problem is that the 'main' FreeBSD distribution site (ftp.freebsd.org) cannot export DES or other crypto software to other coutries - for people in other parts of the world, who perhaps aren't aware of the problems with the US gov.'s export laws right now, it can be a little confusing when tey are told at install time that because they don't live in the US they can't install DES/Kerberos... I guess maybe the FTP install could be setup to automagically use a non-US server when the user picks a sensitive crypto package? Just some thoughts anyways.. Hopefully when the US gov. sees that the 40-bit key was cracked in 3 hours, and the 48-bit key in a couple weeks, maybe they'll realize how far they have their heads up their asses and will stop these silly export restrictions on hard-crypto.. -mark > > M > -- > Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 > This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE > > From owner-freebsd-security Mon Feb 17 13:42:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA17319 for security-outgoing; Mon, 17 Feb 1997 13:42:24 -0800 (PST) Received: from fusion.gage.com (brimstone.gage.com [205.217.2.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA17312 for ; Mon, 17 Feb 1997 13:42:19 -0800 (PST) Received: (from mail@localhost) by fusion.gage.com (8.8.3/8.8.4) id PAA14403; Mon, 17 Feb 1997 15:42:13 -0600 (CST) Received: from octopus.gage.com(158.60.57.50) by fusion.gage.com via smap (V2.0beta) id xma014396; Mon, 17 Feb 97 15:41:59 -0600 Received: from squid.gage.com (squid [158.60.57.101]) by octopus.gage.com (8.7.5/8.7.3) with SMTP id PAA02035; Mon, 17 Feb 1997 15:41:59 -0600 (CST) Received: from schemer by squid.gage.com (NX5.67e/NX3.0S) id AA07110; Mon, 17 Feb 97 15:41:58 -0600 Message-Id: <9702172141.AA07110@squid.gage.com> Received: by schemer.gage.com (NX5.67g/NX3.0X) id AA03376; Mon, 17 Feb 97 15:41:58 -0600 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) In-Reply-To: <199702172104.NAA14500@saguaro.flyingfox.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.146.2) From: Ben Black Date: Mon, 17 Feb 97 15:41:56 -0600 To: Jim Shankland Subject: Re: blowfish passwords in FreeBSD Cc: security@freebsd.org References: <199702172104.NAA14500@saguaro.flyingfox.com> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >It is, of course, always possible to guess the right password the >very first time, thereby cracking the account in well under a second. or guessing it in the first few million tries, thereby cracking the account in 3 hours. >This will work even on an old 386 box lying around your lab, and >does not require a card with ASICs. All you need is very good luck :-). >Whether this says anything meaningful about the cryptographic >strength of DES is debatable. the cryptographic strength of DES is already debatable. the differential cryptanalysis of DES by shamir was met by certain folks involved in the creation of the lucifer and DES ciphers with the statement that they knew about differential cryptanalysis of DES 20 years ago. i am also of the mind that NSA doesn't allow the export of any encryption it can't break. b3n From owner-freebsd-security Mon Feb 17 13:53:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA17982 for security-outgoing; Mon, 17 Feb 1997 13:53:10 -0800 (PST) Received: from ns.cococo.net (apache@ns.cococo.net [206.100.242.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA17970 for ; Mon, 17 Feb 1997 13:53:06 -0800 (PST) Received: from localhost (apache@localhost) by ns.cococo.net (8.8.5/) with SMTP id QAA18726 for ; Mon, 17 Feb 1997 16:56:45 -0500 Date: Mon, 17 Feb 1997 16:56:45 -0500 (EST) From: Apache Mailing List To: security@FreeBSD.org Subject: How is 2.1.7 coming along? In-Reply-To: <199702172020.WAA03755@grackle.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Has anybody heard any due dates for 2.1.7, it was a hot topic for a week or 2 and haven't heard anything in about a week. Any updates? Later Kelley From owner-freebsd-security Mon Feb 17 13:59:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA18371 for security-outgoing; Mon, 17 Feb 1997 13:59:40 -0800 (PST) Received: from sneezy.sri.com (sneezy.sri.com [128.18.40.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA18364 for ; Mon, 17 Feb 1997 13:59:35 -0800 (PST) Received: from swift.rmlnet by sneezy.sri.com (SMI-8.6/SMI-SVR4) id NAA21983; Mon, 17 Feb 1997 13:56:58 -0800 Received: by swift.rmlnet (SMI-8.6/SMI-SVR4) id NAA25999; Mon, 17 Feb 1997 13:59:43 -0800 Date: Mon, 17 Feb 1997 13:59:43 -0800 Message-Id: <199702172159.NAA25999@swift.rmlnet> From: Nate Williams To: Adam Shostack Cc: mal@bengt.algonet.se (Mats Lofkvist), freebsd-security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: <199702142347.SAA18988@homeport.org> References: <199702142048.VAA08594@bengt> <199702142347.SAA18988@homeport.org> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Its also worth noting that hashes are designed to be one way > functions, ciphers like Blowfish are not. Though they can be > converted back and forth, there can be subtilties that should be > addressed. If so, then we can't export BlowFish (legally) from the U.S. Nate From owner-freebsd-security Mon Feb 17 14:07:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA18900 for security-outgoing; Mon, 17 Feb 1997 14:07:27 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA18885 for ; Mon, 17 Feb 1997 14:07:19 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id XAA21730; Mon, 17 Feb 1997 23:09:41 +0100 (MET) From: Mikael Karpberg Message-Id: <199702172209.XAA21730@ocean.campus.luth.se> Subject: Re: blowfish passwords in FreeBSD To: mark@grondar.za (Mark Murray) Date: Mon, 17 Feb 1997 23:09:41 +0100 (MET) Cc: security@freebsd.org In-Reply-To: <199702172020.WAA03755@grackle.grondar.za> from Mark Murray at "Feb 17, 97 10:20:03 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Mark Murray: > Mikael Karpberg wrote: > > At least some of that seems like a great idea. > > I mean... Why not have the fields use $name$salt$passwd$ ? > > Where name is the name of the encryption used? $1$ really says nothing. > > And then you would never have the problem with different OSes having > > different numbering. the name stays the same, right? [...] > > "cd /etc/crypt/ ; cp ..../blowfish.so blowfish.so ; ln -s blowfish.so 2.so" > > Then copy the passwd file, and make the .db files, and it Just Works. > > This come perilously close to breaking the "static only" link that some > fols want exclusively in /bin/sbin. Umm... could you elaborate on this? I don't think I got it :-) > > If loading the .so file set in $name$ field failed, crypt could just return > > a string like "****************", which is not likely to match anything, or > > simply return NULL. > > _*MAJOR*_ security hole. Do you want an algorithm that you can break in > with straight away? This is it. The essence of crypt is that you are > _*NOT*_ allowed to deduce the password from the output. Just a suggestion. Returning NULl may NOT be the brightest of ideas, I guess. That would just clear the way for some nice random segfaults. :-) However, I don't see how returning something like "************" could in any way result in a security hole. Crypt can not normally return such a string, or can it? I may be wrong, but I've always been taught to put an asterisk fisrt in people's passwords to keep them from logging in. Well, I just put one asterisk there, not a whole bunch. So it can't match that. And it you import a passwd entry with an unknown encryption name, then crypt will just return "**************", which will not match the hashed password for that entry, and therefor the person simply can not log in. At least not until you install that encryption. Then people change their password with "passwd", you could just use the crypt protocol chosen in /etc/crypt/conf (or whatever it would be called). Did I miss something? > > Maybe not a completely thought through idea, but... would something like it > > work? > > You'll have to go back to the man pages for crypt, and see what > errors it is allowed to return: NONE. The best I can think of > in the case of an error (and I do not like the idea) is UUENCODEd > rubbish from /dev/random. I think this is making it too complicated, > and opening up avenues of attack. Out of my thumb, here is an attack > - a user supplied foocrypt.so, supplying whatever password it found > for root, and ignoring its input. I'm not saying crypt should return an error, but rather a string which it could never return, and one which is never found in the password field, and therefor you don't get a match, and can't log in. Returning something random COULD potentially get the user in on luck. Bad idea, no? Also, if the admin uses a random .so for crypt from John D. Hacker, then... Well... He's basically in trouble anyway, I'd say. /Mikael From owner-freebsd-security Mon Feb 17 14:23:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA20195 for security-outgoing; Mon, 17 Feb 1997 14:23:30 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA20176 for ; Mon, 17 Feb 1997 14:23:22 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id XAA21874; Mon, 17 Feb 1997 23:25:20 +0100 (MET) From: Mikael Karpberg Message-Id: <199702172225.XAA21874@ocean.campus.luth.se> Subject: Re: blowfish passwords in FreeBSD To: mark@quickweb.com (Mark Mayo) Date: Mon, 17 Feb 1997 23:25:20 +0100 (MET) Cc: security@freebsd.org In-Reply-To: from Mark Mayo at "Feb 17, 97 04:13:08 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Mark Mayo: [...] > For DES, yes.... I wasn't really thinking abut the DES distribution, but > for future crypto distributions. The problem is that the 'main' FreeBSD > distribution site (ftp.freebsd.org) cannot export DES or other crypto > software to other coutries - for people in other parts of the world, who > perhaps aren't aware of the problems with the US gov.'s export laws right > now, it can be a little confusing when tey are told at install time that > because they don't live in the US they can't install DES/Kerberos... I > guess maybe the FTP install could be setup to automagically use a non-US > server when the user picks a sensitive crypto package? That would be GREAT! If nothing else, when you choose DES, just pop up a requester and say "Are you within the USA? (Yes/No/Cancel)" and default it to cancel. I for one haven't bothered to install DES because it seems too much of a hassle. If you could just say "No, I'm not from the USA" and have sysinstall try a few Non-US sites and get the DES if you tried to install from a site called .edu/.us or .org/.com known to be US, or so. I dunno. Something at least. Something the user basically just have to say "No, I'm not from the USA" to, and it would do the rest. Period. Jordan? :-) Just my $0.02... /Mikael From owner-freebsd-security Mon Feb 17 15:22:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA23689 for security-outgoing; Mon, 17 Feb 1997 15:22:48 -0800 (PST) Received: from postoffice.cso.uiuc.edu (postoffice.cso.uiuc.edu [128.174.5.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA23663 for ; Mon, 17 Feb 1997 15:22:43 -0800 (PST) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [128.174.83.167]) by postoffice.cso.uiuc.edu (8.8.5/8.8.5) with SMTP id RAA107268; Mon, 17 Feb 1997 17:22:32 -0600 Received: by alecto.physics.uiuc.edu (940816.SGI.8.6.9/940406.SGI) id RAA20938; Mon, 17 Feb 1997 17:19:01 -0600 From: igor@alecto.physics.uiuc.edu (Igor Roshchin) Message-Id: <199702172319.RAA20938@alecto.physics.uiuc.edu> Subject: Re: How is 2.1.7 coming along? To: apache@cococo.net (Apache Mailing List) Date: Mon, 17 Feb 1997 17:19:01 -0600 (CST) Cc: security@freebsd.org In-Reply-To: from "Apache Mailing List" at Feb 17, 97 04:56:45 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Has anybody heard any due dates for 2.1.7, it was a hot topic for a > week or 2 and haven't heard anything in about a week. Any updates? > > Later > Kelley > > Is not is out there ??? Or, if not, what is there ? 2.1.7-RELEASE FreeBSD 2.1.7-RELEASE #0: Wed Feb 12 23:19:52 EST 1997 (That's what I've compiled from the sources updated by sup.) IgoR From owner-freebsd-security Mon Feb 17 15:27:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA24042 for security-outgoing; Mon, 17 Feb 1997 15:27:20 -0800 (PST) Received: from gadget.nla.gov.au (gadget.nla.gov.au [203.4.201.52]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA24022 for ; Mon, 17 Feb 1997 15:27:13 -0800 (PST) Received: from localhost (cmakin@localhost) by gadget.nla.gov.au (8.8.4/8.8.4) with SMTP id KAA00569; Tue, 18 Feb 1997 10:26:55 +1100 (EST) X-Authentication-Warning: gadget.nla.gov.au: cmakin owned process doing -bs Date: Tue, 18 Feb 1997 10:26:54 +1100 (EST) From: Carl Makin To: Mark Mayo cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 17 Feb 1997, Mark Mayo wrote: > Just some thoughts anyways.. Hopefully when the US gov. sees that the > 40-bit key was cracked in 3 hours, and the 48-bit key in a couple weeks, > maybe they'll realize how far they have their heads up their asses and > will stop these silly export restrictions on hard-crypto.. Don't be silly. Its *exactly* the reason the restrictions are there in the first place. The US government seems to believe (a) noone outside of the US can write code and (b) noone outside of the US Government should have secure communications. You need to convince your government that the restrictions are having no effect on security while they are hurting the US dominance in trade. :) Carl. -- Carl Makin (VK1KCM) C.Makin@nla.gov.au 'Work +61 6 262 1576' "Speaking for myself only!" 'If you want to make your spouse pay attention to what you say... Talk in your sleep!' From owner-freebsd-security Mon Feb 17 15:44:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA24916 for security-outgoing; Mon, 17 Feb 1997 15:44:41 -0800 (PST) Received: from cold.org (cold.org [206.81.134.103]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA24910 for ; Mon, 17 Feb 1997 15:44:36 -0800 (PST) Received: from localhost (brandon@localhost) by cold.org (8.8.5/8.8.3) with SMTP id QAA13620 for ; Mon, 17 Feb 1997 16:44:49 -0700 (MST) Date: Mon, 17 Feb 1997 16:44:49 -0700 (MST) From: Brandon Gillespie To: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: <199702172225.XAA21874@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > That would be GREAT! If nothing else, when you choose DES, just pop up a > requester and say "Are you within the USA? (Yes/No/Cancel)" and default > it to cancel. I for one haven't bothered to install DES because it seems > too much of a hassle. If you could just say "No, I'm not from the USA" and > have sysinstall try a few Non-US sites and get the DES if you tried to > install from a site called .edu/.us or .org/.com known to be US, or so. > I dunno. Something at least. Something the user basically just have to say > "No, I'm not from the USA" to, and it would do the rest. Period. > Jordan? :-) I think also that people should be more educated on why they should want DES. I personally picked DES initially because it was something I recognized, and I had no idea what FreeBSD did without it (I didn't realize MD5 was just used instead--and soon SHA-1). Perhaps explaining that the ONLY REASON you would really even want DES is when either using network services that assumes it, with other boxes (i.e. yp) or when upgrading an old DES based box. SHA-1 is much MUCH better. -Brandon Gillespie From owner-freebsd-security Mon Feb 17 15:50:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA25278 for security-outgoing; Mon, 17 Feb 1997 15:50:19 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA25271 for ; Mon, 17 Feb 1997 15:50:13 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id SAA11342; Mon, 17 Feb 1997 18:50:52 -0500 (EST) Date: Mon, 17 Feb 1997 18:50:52 -0500 (EST) From: Mark Mayo To: Carl Makin cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 18 Feb 1997, Carl Makin wrote: > > On Mon, 17 Feb 1997, Mark Mayo wrote: > > > Just some thoughts anyways.. Hopefully when the US gov. sees that the > > 40-bit key was cracked in 3 hours, and the 48-bit key in a couple weeks, > > maybe they'll realize how far they have their heads up their asses and > > will stop these silly export restrictions on hard-crypto.. > > Don't be silly. Its *exactly* the reason the restrictions are there in > the first place. The US government seems to believe (a) noone outside of > the US can write code and (b) noone outside of the US Government should > have secure communications. > > You need to convince your government that the restrictions are having no > effect on security while they are hurting the US dominance in trade. :) Fist of all, just for the record, the US sure as hell ain't my government!! I'm a proud Canadian - true to the bone :-) It seems to me the reason the US gov. won't let hard-crypto out of the country is cause they don't want anything getting out that they can't crack - i.e. 40,48-bit RC4 and DES. Luckily, my government is too cheap to buy computers that could crack any encryption, so they don't bother restricting any strength of cryptography :-) It's pointless! Aside creating more jobs in Canada for crypto programmers, the US laws, whether I'm American or not, are a big pain in the ass for me. You should have seen the bloody nightmare I just had to go through to get a 128-bit SSL key from RSA!!! And Canada is allowed to import strong-crypto from the US!! Christ, I thought I was going to have to fly down to the US and have my identity verified with a retina scan or something. Talk about paranoid: "You mean you want a 128-bit key and you don't live in America? Oh my. We'll get back to you..". I did get the key, but it took 1.5 months.. Blowfish, for example, can't be exported outside of Canada and the US - and if US ctizens code it, how is the rest of the FreeBSD world going to get it?? -Mark > > Carl. > > -- > Carl Makin (VK1KCM) > C.Makin@nla.gov.au 'Work +61 6 262 1576' "Speaking for myself only!" > 'If you want to make your spouse pay attention to what you say... > Talk in your sleep!' > From owner-freebsd-security Mon Feb 17 21:12:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA17889 for security-outgoing; Mon, 17 Feb 1997 21:12:50 -0800 (PST) Received: from minor.stranger.com (stranger.vip.best.com [204.156.129.250]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA17881 for ; Mon, 17 Feb 1997 21:12:43 -0800 (PST) Received: from dog.farm.org (dog.farm.org [207.111.140.47]) by minor.stranger.com (8.6.12/8.6.12) with ESMTP id VAA14658; Mon, 17 Feb 1997 21:27:25 -0800 Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id VAA09296; Mon, 17 Feb 1997 21:16:22 -0800 (PST) Date: Mon, 17 Feb 1997 21:16:22 -0800 (PST) From: Dmitry Kohmanyuk Message-Id: <199702180516.VAA09296@dog.farm.org> To: karpen@ocean.campus.luth.se (Mikael Karpberg) Cc: freebsd-security@freebsd.org Subject: Re: blowfish passwords in FreeBSD Newsgroups: cs-monolit.gated.lists.freebsd.security Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199702172225.XAA21874@ocean.campus.luth.se> you wrote: > According to Mark Mayo: > [...] > > For DES, yes.... I wasn't really thinking abut the DES distribution, but > > for future crypto distributions. The problem is that the 'main' FreeBSD > > distribution site (ftp.freebsd.org) cannot export DES or other crypto > > software to other coutries - for people in other parts of the world, who > > perhaps aren't aware of the problems with the US gov.'s export laws right > > now, it can be a little confusing when tey are told at install time that > > because they don't live in the US they can't install DES/Kerberos... I > > guess maybe the FTP install could be setup to automagically use a non-US > > server when the user picks a sensitive crypto package? > That would be GREAT! If nothing else, when you choose DES, just pop up a > requester and say "Are you within the USA? (Yes/No/Cancel)" and default > it to cancel. I for one haven't bothered to install DES because it seems Just a minor nit. Being _within_ USA and being subject to USA cryptoexport laws can be not the same. I am not U.S. citizen - just working there, and because of that, don't want to use U.S. sites regardless. Now, what about if I install software on machine outside the U.S. if I am U.S. citizen? or if I not? The legal warning should be more detailed. > too much of a hassle. If you could just say "No, I'm not from the USA" and > have sysinstall try a few Non-US sites and get the DES if you tried to > install from a site called .edu/.us or .org/.com known to be US, or so. > I dunno. Something at least. Something the user basically just have to say > "No, I'm not from the USA" to, and it would do the rest. Period. > Jordan? :-) I think that just having main repository into a normal country can be a better option. Sadly, most normal countries have poorer Internet connectivity. -- "There must be some part of the brain that only activates when you learn UNIX." From owner-freebsd-security Mon Feb 17 22:16:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA02275 for security-outgoing; Mon, 17 Feb 1997 22:16:52 -0800 (PST) Received: from grackle.grondar.za (Z+lLO0npl7KXvvr2aTLCNjlJIAB3iDDB@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA02232 for ; Mon, 17 Feb 1997 22:16:45 -0800 (PST) Received: from grackle.grondar.za (lceu7a7vZh0TMZepxV4k3THq0uVbjhCI@localhost [127.0.0.1]) by grackle.grondar.za (8.8.5/8.8.4) with ESMTP id IAA05643; Tue, 18 Feb 1997 08:16:31 +0200 (SAT) Message-Id: <199702180616.IAA05643@grackle.grondar.za> X-Mailer: exmh version 2.0gamma 1/27/96 To: Mikael Karpberg cc: mark@grondar.za (Mark Murray), security@freebsd.org Subject: Re: blowfish passwords in FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Feb 1997 08:16:25 +0200 From: Mark Murray Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg wrote: > According to Mark Murray: > > This come perilously close to breaking the "static only" link that some > > fols want exclusively in /bin/sbin. > > Umm... could you elaborate on this? I don't think I got it :-) Sure :-). The "rule" in [Free]BSD is that the applets in /bin and /sbin are statically linked (no dynamic objects) so that a sysadmin can have a system in single-user mode with no /usr, and still be running. With the dynamicically linked crypt objects approach, it is possible to break this if we are not _very_ careful. (I like the idea BTW, but I think it must be kept in check) > > > a string like "****************", which is not likely to match anything, or > > > simply return NULL. > > > > _*MAJOR*_ security hole. Do you want an algorithm that you can break in > > with straight away? This is it. The essence of crypt is that you are > > _*NOT*_ allowed to deduce the password from the output. > > Just a suggestion. Returning NULl may NOT be the brightest of ideas, I guess. > That would just clear the way for some nice random segfaults. :-) > However, I don't see how returning something like "************" could in > any way result in a security hole. Crypt can not normally return such It provides a way of getting crypt tp provide a given output given no knowledge of the input. Crypt's strength is its very _unpredictable_ outputs, and the fact that you _cannot_ produce a given output by manipulating the inputs. > a string, or can it? I may be wrong, but I've always been taught to put an > asterisk fisrt in people's passwords to keep them from logging in. Well, > I just put one asterisk there, not a whole bunch. So it can't match that. > And it you import a passwd entry with an unknown encryption name, then > crypt will just return "**************", which will not match the hashed > password for that entry, and therefor the person simply can not log in. No, but someone just has to crash crypt() in the same way to get the same output. Bingo! they are in. > At least not until you install that encryption. Then people change their > password with "passwd", you could just use the crypt protocol chosen in > /etc/crypt/conf (or whatever it would be called). Did I miss something? Yup! M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-security Mon Feb 17 23:08:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA02631 for security-outgoing; Mon, 17 Feb 1997 23:08:58 -0800 (PST) Received: from grackle.grondar.za (IKklbqpEok+lfGH7ITA2jjBRwZvKCcL+@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA02603 for ; Mon, 17 Feb 1997 23:08:49 -0800 (PST) Received: from grackle.grondar.za (6gpPV3vEJLEYy72XzI+eekDjw1NqqWgy@localhost [127.0.0.1]) by grackle.grondar.za (8.8.5/8.8.4) with ESMTP id JAA05826; Tue, 18 Feb 1997 09:08:25 +0200 (SAT) Message-Id: <199702180708.JAA05826@grackle.grondar.za> X-Mailer: exmh version 2.0gamma 1/27/96 To: Mark Mayo cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Feb 1997 09:08:18 +0200 From: Mark Murray Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark Mayo wrote: > Blowfish, for example, can't be exported outside of Canada and the US - > and if US ctizens code it, how is the rest of the FreeBSD world going to > get it?? Well, one of us competent programmers from South Africa or anywhere else in the world will have to do it. No problem. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-security Mon Feb 17 23:22:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA03918 for security-outgoing; Mon, 17 Feb 1997 23:22:07 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA03913 for ; Mon, 17 Feb 1997 23:22:03 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vwjrv-0002hg-00; Tue, 18 Feb 1997 00:21:39 -0700 To: igor@alecto.physics.uiuc.edu (Igor Roshchin) Subject: Re: How is 2.1.7 coming along? Cc: apache@cococo.net (Apache Mailing List), security@freebsd.org In-reply-to: Your message of "Mon, 17 Feb 1997 17:19:01 CST." <199702172319.RAA20938@alecto.physics.uiuc.edu> References: <199702172319.RAA20938@alecto.physics.uiuc.edu> Date: Tue, 18 Feb 1997 00:21:38 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702172319.RAA20938@alecto.physics.uiuc.edu> Igor Roshchin writes: : Is not is out there ??? : Or, if not, what is there ? : : 2.1.7-RELEASE FreeBSD 2.1.7-RELEASE #0: Wed Feb 12 23:19:52 EST 1997 : (That's what I've compiled from the sources updated by sup.) I think it was just marked a few minutes ago... Warner From owner-freebsd-security Mon Feb 17 23:25:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA04104 for security-outgoing; Mon, 17 Feb 1997 23:25:13 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA04099 for ; Mon, 17 Feb 1997 23:25:10 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vwjv0-0002n5-00; Tue, 18 Feb 1997 00:24:50 -0700 To: Mark Mayo Subject: Re: blowfish passwords in FreeBSD Cc: Carl Makin , security@freebsd.org In-reply-to: Your message of "Mon, 17 Feb 1997 18:50:52 EST." References: Date: Tue, 18 Feb 1997 00:24:49 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Mark Mayo writes: : Blowfish, for example, can't be exported outside of Canada and the US - : and if US ctizens code it, how is the rest of the FreeBSD world going to : get it?? If Canadians write it, then it can be exported outside of Canada. If Canadian citizens add just a little bit to it, then likewise. That's the whole point of the URL that I wrote. Iff it is free source code. That's why Theo is in Canada distributing OpenBSD with blowfish. Warner From owner-freebsd-security Mon Feb 17 23:25:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA04177 for security-outgoing; Mon, 17 Feb 1997 23:25:58 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA04169 for ; Mon, 17 Feb 1997 23:25:55 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vwjvj-0002od-00; Tue, 18 Feb 1997 00:25:35 -0700 To: Mikael Karpberg Subject: Re: blowfish passwords in FreeBSD Cc: mark@quickweb.com (Mark Mayo), security@freebsd.org In-reply-to: Your message of "Mon, 17 Feb 1997 23:25:20 +0100." <199702172225.XAA21874@ocean.campus.luth.se> References: <199702172225.XAA21874@ocean.campus.luth.se> Date: Tue, 18 Feb 1997 00:25:35 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702172225.XAA21874@ocean.campus.luth.se> Mikael Karpberg writes: : install from a site called .edu/.us or .org/.com known to be US, or so. .EDU, .COM and .ORG are international. Do a whois on msi-uk.com sometime :-) Warner From owner-freebsd-security Mon Feb 17 23:32:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA04177 for security-outgoing; Mon, 17 Feb 1997 23:25:58 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA04169 for ; Mon, 17 Feb 1997 23:25:55 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vwjvj-0002od-00; Tue, 18 Feb 1997 00:25:35 -0700 To: Mikael Karpberg Subject: Re: blowfish passwords in FreeBSD Cc: mark@quickweb.com (Mark Mayo), security@freebsd.org In-reply-to: Your message of "Mon, 17 Feb 1997 23:25:20 +0100." <199702172225.XAA21874@ocean.campus.luth.se> References: <199702172225.XAA21874@ocean.campus.luth.se> Date: Tue, 18 Feb 1997 00:25:35 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702172225.XAA21874@ocean.campus.luth.se> Mikael Karpberg writes: : install from a site called .edu/.us or .org/.com known to be US, or so. .EDU, .COM and .ORG are international. Do a whois on msi-uk.com sometime :-) Warner From owner-freebsd-security Tue Feb 18 00:33:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA08550 for security-outgoing; Tue, 18 Feb 1997 00:33:35 -0800 (PST) Received: from ferret (ferret.slip.net [207.171.193.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA08541 for ; Tue, 18 Feb 1997 00:33:31 -0800 (PST) Received: from [207.171.196.58] [207.171.196.58] by ferret with smtp (Exim 1.598 #1) id 0vwkzM-00009m-00; Tue, 18 Feb 1997 00:33:25 -0800 X-Sender: leonard@slip.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Feb 1997 00:33:30 -0800 To: security@freefall.freebsd.org From: leonardc9@usa.net (Leonard Chung) Subject: Re: security-digest V3 #23 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Just a minor nit. Being _within_ USA and being subject to USA cryptoexport >laws can be not the same. I am not U.S. citizen - just working there, >and because of that, don't want to use U.S. sites regardless. >Now, what about if I install software on machine outside the U.S. if I am >U.S. citizen? or if I not? The legal warning should be more detailed. FWIW, if I remember correctly from reading some of the PGP FAQs, it would be legal for a US citizen to install the software on a machine outside of the US as there are personal use exclusions. I'm not exactly sure of the details of it, but I know that you are allowed to bring the software along and install it on systems *for your own personal use* and not giving it to others. Leonard -- Leonard Chung Support the Blue Ribbon Campaign for free speech online () http://www.eff.org/blueribbon.html /\ "Those who will not reason perish in the act. Those who will not act, perish for that reason." - W. H. Auden From owner-freebsd-security Tue Feb 18 00:40:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA10250 for security-outgoing; Tue, 18 Feb 1997 00:40:08 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA10198 for ; Tue, 18 Feb 1997 00:40:01 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id TAA26546; Tue, 18 Feb 1997 19:43:13 +1100 (EST) Date: Tue, 18 Feb 1997 19:43:12 +1100 (EST) From: "Daniel O'Callaghan" To: Mark Murray cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: <199702180708.JAA05826@grackle.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 18 Feb 1997, Mark Murray wrote: > Mark Mayo wrote: > > Blowfish, for example, can't be exported outside of Canada and the US - > > and if US ctizens code it, how is the rest of the FreeBSD world going to > > get it?? > > Well, one of us competent programmers from South Africa or anywhere else > in the world will have to do it. I'm sure Eric A. Young, from Australia would be happy to do so, too. Guess what the eay in 'SSLeay' stands for... Danny From owner-freebsd-security Tue Feb 18 00:42:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA11257 for security-outgoing; Tue, 18 Feb 1997 00:42:42 -0800 (PST) Received: from vector.jhs.no_domain (slip139-92-4-66.mu.de.ibm.net [139.92.4.66]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA10362; Tue, 18 Feb 1997 00:40:24 -0800 (PST) Received: (from jhs@localhost) by vector.jhs.no_domain (8.7.5/8.6.9) id TAA02087; Mon, 17 Feb 1997 19:19:45 +0100 (MET) Date: Mon, 17 Feb 1997 19:19:45 +0100 (MET) Message-Id: <199702171819.TAA02087@vector.jhs.no_domain> To: security-officer@freebsd.org cc: security@freebsd.org, core@freebsd.org Subject: I guess we need to read all code, not just SUID stuff ! From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Email: jhs@freebsd.org, Fallback: jhs@gil.physik.rwth-aachen.de X-Organization: Vector Systems Ltd. X-Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Tel: +49.89.268616 X-Fax: +49.89.2608126 X-Web: http://www.freebsd.org/~jhs/ Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk security-officer@freebsd.org cc security@freebsd.org,core@freebsd.org PS best leave jhs@freebsd.org on cc line, as not sure if I'm on the security@freebsd.org list. I'm hoping to be told I'm wrong below, I'll be disappointed (& others more so) if I'm right :-) ..... Ref. the the freefall break in, & the planting of trojans, in bin path, & possible planting of trojans in src/ & intention to read code for manipulation ... We presumably don't need to just read the SUID stuff, we need to read all 120M of src/ :-( because one could for instance go hack a non SUID prog like /bin/ls so that (if getuid != 0) do a normal ls else { ls ; /* so no one notices differenr behaviour, then */ do some nasty security thing; } So one thinks we only need to read all SUID 0 stuff _&_ anything that uses getuid(), but Worse ... what if there's some hacked utility like ls or who, that root will someday use, that does: { do a normal ls type thing ; (void) { (maybe fork) and do a devilish thing, that will silently fail if invoked by a normal user, but that will succeed with something nasty, if invoked by root. } } notice no getuid or suid above !, so we're back to the whole of src/ :-( I know this will be unpopular, particularly with John Dyson et al, who's busy commiting away at the 4.4 lite 2 stuff, ... but if we really do have to go & read all 120M of src/, wouldn't it be a lot better :- - rebuilding freefall from a known good CD, - reloading the CVS tree from a 3 or 4 week old tape (or rebuilding it from ctms applied to a cvs tree from up to about 3 weeks ago, - then extracting the src/, - then doing a parallel { let john & co recommit the 4.4 fixes & things, let loose the code readers just on the suid 0 stuff } it'd be a _lot_ less work than having to read the whole of src/ If that's the way we need to go, the sooner we stop committers from doing work they'll need to repeat, the less agravation for them ? Someone tell me I'm wrong ! I hope I'm wrong :-) I want to be wrong, but I'd prefer to know why :-) (PS I'll volunteer for some small part of the `read', but my car's just broken down & I need to spend time finding a job, so I'd prefer something smallish to check.) Julian --- Julian H. Stacey http://www.freebsd.org/~jhs/ From owner-freebsd-security Tue Feb 18 01:06:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA15896 for security-outgoing; Tue, 18 Feb 1997 01:06:51 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA15582; Tue, 18 Feb 1997 01:04:48 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id BAA02472; Tue, 18 Feb 1997 01:04:46 -0800 (PST) To: "Julian H. Stacey" cc: security-officer@freebsd.org, security@freebsd.org, core@freebsd.org Subject: Re: I guess we need to read all code, not just SUID stuff ! In-reply-to: Your message of "Mon, 17 Feb 1997 19:19:45 +0100." <199702171819.TAA02087@vector.jhs.no_domain> Date: Tue, 18 Feb 1997 01:04:46 -0800 Message-ID: <2468.856256686@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > We presumably don't need to just read the SUID stuff, > we need to read all 120M of src/ :-( We need to read all 120M of src, and that project is already underway. See http://www.freebsd.org/auditors.html for the latest roster. Freefall has also been completely rebuilt and numerous measures taken. Don't think we haven't thought of all the scenarios you raised and probably a good 2 dozen you didn't. :-) There is no one more paranoid that we are at the moment, and with unfortunate good reason. Jordan From owner-freebsd-security Tue Feb 18 01:10:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA16656 for security-outgoing; Tue, 18 Feb 1997 01:10:58 -0800 (PST) Received: from grackle.grondar.za (jw/Q3/+aSxgq3efW88MvdHyRi3ewauQ+@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA16640 for ; Tue, 18 Feb 1997 01:10:48 -0800 (PST) Received: from grackle.grondar.za (Qu+eP5rhalrqBjJpBieEyehIEnf/XlI2@localhost [127.0.0.1]) by grackle.grondar.za (8.8.5/8.8.4) with ESMTP id LAA06142; Tue, 18 Feb 1997 11:09:05 +0200 (SAT) Message-Id: <199702180909.LAA06142@grackle.grondar.za> To: "Daniel O'Callaghan" cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD Date: Tue, 18 Feb 1997 11:07:45 +0200 From: Mark Murray Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Daniel O'Callaghan" wrote: > I'm sure Eric A. Young, from Australia would be happy to do so, too. > Guess what the eay in 'SSLeay' stands for... Its already there. It needs to be turned into a one-way hash to be useful (and exportable?) for crypt() use. Take a look at the FreeBSD maintainer for the SSLeay port... It's me! M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-security Tue Feb 18 03:24:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA27793 for security-outgoing; Tue, 18 Feb 1997 03:24:28 -0800 (PST) Received: from eel.dataplex.net (eel.dataplex.net [208.2.87.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA27771; Tue, 18 Feb 1997 03:24:19 -0800 (PST) Received: from [208.2.87.3] (shrimp [208.2.87.3]) by eel.dataplex.net (8.7.5/8.6.9) with ESMTP id FAA06842; Tue, 18 Feb 1997 05:24:16 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199702171819.TAA02087@vector.jhs.no_domain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Feb 1997 05:17:47 -0600 To: "Julian H. Stacey" From: Richard Wackerbarth Subject: Re: I guess we need to read all code, not just SUID stuff ! Cc: security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I'm hoping to be told I'm wrong below, >I'll be disappointed (& others more so) if I'm right :-) ..... > >Ref. the the freefall break in, & the planting of trojans, in bin path, >& possible planting of trojans in src/ >& intention to read code for manipulation ... > >We presumably don't need to just read the SUID stuff, >we need to read all 120M of src/ :-( Although it is certainly a good idea to review all the source code, an uncompromised archive of the ctm's does provide a shortcut because it is a sequence of "diff"s. If you assume that the source free from trojans on Date X, you need only look at the changes since then. You might be able to "read" the deltas directly or you could at least use them as a filter to eliminate all the programs which have had no changes at all. Unfortunately, "Date X" might be, (something, I'm not up on classical history) BC :-( The full audit needs to be done periodically as a safety precaution. From owner-freebsd-security Tue Feb 18 06:10:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA05543 for security-outgoing; Tue, 18 Feb 1997 06:10:20 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA05522 for ; Tue, 18 Feb 1997 06:10:09 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id PAA00954; Tue, 18 Feb 1997 15:11:17 +0100 (MET) From: Mikael Karpberg Message-Id: <199702181411.PAA00954@ocean.campus.luth.se> Subject: Re: blowfish passwords in FreeBSD To: imp@village.org (Warner Losh) Date: Tue, 18 Feb 1997 15:11:16 +0100 (MET) Cc: security@FreeBSD.org In-Reply-To: from Warner Losh at "Feb 18, 97 00:25:35 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Warner Losh: > In message <199702172225.XAA21874@ocean.campus.luth.se> Mikael Karpberg writes: > : install from a site called .edu/.us or .org/.com known to be US, or so. > > .EDU, .COM and .ORG are international. Do a whois on msi-uk.com > sometime :-) I know there are .com and .org addresses outside US, which is why I said "or .org/.com known to be US"... but .edu and .us should be us only, no? (Hmm.. Maybe .edu in canada too?) /Mikael From owner-freebsd-security Tue Feb 18 06:45:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA07459 for security-outgoing; Tue, 18 Feb 1997 06:45:05 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA07438 for ; Tue, 18 Feb 1997 06:44:54 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id PAA01193; Tue, 18 Feb 1997 15:46:01 +0100 (MET) From: Mikael Karpberg Message-Id: <199702181446.PAA01193@ocean.campus.luth.se> Subject: Re: blowfish passwords in FreeBSD To: mark@grondar.za (Mark Murray) Date: Tue, 18 Feb 1997 15:46:01 +0100 (MET) Cc: security@freebsd.org In-Reply-To: <199702180616.IAA05643@grackle.grondar.za> from Mark Murray at "Feb 18, 97 08:16:25 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Mark Murray: > Mikael Karpberg wrote: [... About how crypt should fail if it doesn't find the encryption lib...] > > > > a string like "****************", which is not likely to match > > > > anything, or simply return NULL. > > > > > > _*MAJOR*_ security hole. Do you want an algorithm that you can break in > > > with straight away? This is it. The essence of crypt is that you are > > > _*NOT*_ allowed to deduce the password from the output. > > > > Just a suggestion. Returning NULL may NOT be the brightest of ideas, > > I guess. > > That would just clear the way for some nice random segfaults. :-) > > However, I don't see how returning something like "************" could in > > any way result in a security hole. Crypt can not normally return such > > It provides a way of getting crypt tp provide a given output given no > knowledge of the input. Crypt's strength is its very _unpredictable_ > outputs, and the fact that you _cannot_ produce a given output by > manipulating the inputs. I must say, I have NO idea how you mean this. Either you are very confused, or I am very confused. One of the two, and I don't know which. :-) First of all, so what is crypt returns something predictable for a certain input? Crypt's strength might be that you can't get the output you want by tweaking th input, BUT... what has that got to do with it? The point is that even if you know you can get crypt to return "************", it's really not going to do you any good, is it? If you could, by just entering a certain password, make crypt produce that string (and you couldn't. You would need to also set the salt, etc, meaning you have to write a c program to do it. And why bother comparing strings, then, when you can just succeed?) it would do you no good at all, since login (or whatever program you use for trying to hack root) would compare the output against the password in the /etc/master.passwd file, and that will never _be_ "***********", so you will never get a match anyway, and failing a match, login will be refused. Where did I err in thinking this (if I did)? Second, after some "research" (actually reading the manpage for crypt) I found this in crypt's manpage: "The function crypt() returns a pointer to the encrypted value on success and NULL on failure." Note: Or NULL on failure. I didn't think it could return that. That changes things; it _is_ TRT to return NULL if you don't find the lib for a choosen encryption. So that should be the end of that. :-) > > a string, or can it? I may be wrong, but I've always been taught to put an > > asterisk fisrt in people's passwords to keep them from logging in. Well, > > I just put one asterisk there, not a whole bunch. So it can't match that. > > And it you import a passwd entry with an unknown encryption name, then > > crypt will just return "**************", which will not match the hashed > > password for that entry, and therefor the person simply can not log in. > > No, but someone just has to crash crypt() in the same way to get the same > output. Bingo! they are in. How do you crash crypt? And what do you gain from making it reutn "**********" when that will never match anything? Hmmm.... > > At least not until you install that encryption. Then people change their > > password with "passwd", you could just use the crypt protocol chosen in > > /etc/crypt/conf (or whatever it would be called). Did I miss something? > > Yup! I don't think so... Or I'm dumb enough not to notice. :-) /Mikael From owner-freebsd-security Tue Feb 18 07:02:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA08292 for security-outgoing; Tue, 18 Feb 1997 07:02:34 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA08287 for ; Tue, 18 Feb 1997 07:02:30 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id QAA01275; Tue, 18 Feb 1997 16:01:03 +0100 (MET) From: Mikael Karpberg Message-Id: <199702181501.QAA01275@ocean.campus.luth.se> Subject: Re: blowfish passwords in FreeBSD To: dk+@ua.net Date: Tue, 18 Feb 1997 16:01:03 +0100 (MET) Cc: freebsd-security@freebsd.org In-Reply-To: <199702180516.VAA09296@dog.farm.org> from Dmitry Kohmanyuk at "Feb 17, 97 09:16:22 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Dmitry Kohmanyuk: > In article <199702172225.XAA21874@ocean.campus.luth.se> you wrote: [...] > I think that just having main repository into a normal country can be a > better option. Sadly, most normal countries have poorer Internet > connectivity. Try scandinavia. As far as I know all the scandinavian countries have very good internet connectivity. Ok... Sometimes the US link is not the best, but then again, that is not scandinavia having a bad connection to internet. It's US having a bad connection to the internet. ;-) Meaning, if the US-Europe link sucks, it's neither sides fault, really. And wouldn't i be better to ahve the main repository outside US, and having that mirrored into the machine that today is the main repository. That seems more logical, no? And have all encryption things written outside the US, so that it can be downloaded by everyone. As far as I understand, there's no problem importing encryption stuff into the US, is it? It seems to me that moving the main repository would be the easiest and most logical solution, since we could add all the encryption we wanted, then, without any problems. /Mikael From owner-freebsd-security Tue Feb 18 07:31:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA10134 for security-outgoing; Tue, 18 Feb 1997 07:31:56 -0800 (PST) Received: from grackle.grondar.za (iIl2mAu7gTCaBGssAycMeZeH8TKFSBtm@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA10118 for ; Tue, 18 Feb 1997 07:31:46 -0800 (PST) Received: from grackle.grondar.za (ujzeR1ZvgUfJ3nOmNG3nRnRUZawKjEuB@localhost [127.0.0.1]) by grackle.grondar.za (8.8.5/8.8.4) with ESMTP id RAA07047; Tue, 18 Feb 1997 17:31:04 +0200 (SAT) Message-Id: <199702181531.RAA07047@grackle.grondar.za> To: Mikael Karpberg cc: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD Date: Tue, 18 Feb 1997 17:31:01 +0200 From: Mark Murray Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg wrote: > I must say, I have NO idea how you mean this. Either you are very confused, > or I am very confused. One of the two, and I don't know which. :-) > > First of all, so what is crypt returns something predictable for a certain > input? Crypt's strength might be that you can't get the output you want by > tweaking th input, BUT... what has that got to do with it? The point is > that even if you know you can get crypt to return "************", it's > really not going to do you any good, is it? If you could, by just entering > a certain password, make crypt produce that string (and you couldn't. You > would need to also set the salt, etc, meaning you have to write a c program > to do it. And why bother comparing strings, then, when you can just succeed?) > it would do you no good at all, since login (or whatever program you use > for trying to hack root) would compare the output against the password > in the /etc/master.passwd file, and that will never _be_ "***********", so > you will never get a match anyway, and failing a match, login will be refused . > Where did I err in thinking this (if I did)? OK - here's the attack: Our luser has fouled up his system a bit (this is a prerequisite), so that he has passwords that are your default *************. The attacker notices the foul-up, guesses there are ********** passwords, and trys to get in. He should be able to get login to execute crypt("***************", "rubbish password typed at passwd:prompt") to return "***************", IOW the same "crypted" password as the passwd file. This lets him in. If this happens to th root account, he is in. > Second, after some "research" (actually reading the manpage for crypt) > I found this in crypt's manpage: > "The function crypt() returns a pointer to the encrypted value on success > and NULL on failure." > > Note: Or NULL on failure. I didn't think it could return that. That changes > things; it _is_ TRT to return NULL if you don't find the lib for a > choosen encryption. So that should be the end of that. :-) Fair enough. > How do you crash crypt? And what do you gain from making it reutn "********** " > when that will never match anything? Hmmm.... If the dynamic linking of crypt types is too fragile, it will be too easy to force an error. If crypt _previously_ returned a "*************", and now can do it by generating an error, it will match. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-security Tue Feb 18 08:08:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA11899 for security-outgoing; Tue, 18 Feb 1997 08:08:28 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id IAA11890; Tue, 18 Feb 1997 08:08:18 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA22136; Tue, 18 Feb 1997 11:08:08 -0500 Date: Tue, 18 Feb 1997 11:08:08 -0500 From: Garrett Wollman Message-Id: <9702181608.AA22136@halloran-eldar.lcs.mit.edu> To: phk@FreeBSD.ORG Cc: security@FreeBSD.ORG Subject: changing password... In-Reply-To: <14434.856046887@critter.dk.tfs.com> References: <14434.856046887@critter.dk.tfs.com> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > Why don't we have an option for /usr/bin/passwd to input a precoded > password ? Because that option is in chpass(1). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Tue Feb 18 10:34:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA20437 for security-outgoing; Tue, 18 Feb 1997 10:34:22 -0800 (PST) Received: from bofh.cybercity.dk (bofh.cybercity.dk [195.8.128.254]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA20412 for ; Tue, 18 Feb 1997 10:34:15 -0800 (PST) Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.133.247]) by bofh.cybercity.dk (8.8.3/8.7.3) with ESMTP id TAA04026; Tue, 18 Feb 1997 19:36:42 +0100 (MET) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.2/8.8.2) with ESMTP id TAA21203; Tue, 18 Feb 1997 19:36:31 +0100 (MET) To: Mikael Karpberg cc: dk+@ua.net, freebsd-security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-reply-to: Your message of "Tue, 18 Feb 1997 16:01:03 +0100." <199702181501.QAA01275@ocean.campus.luth.se> Date: Tue, 18 Feb 1997 19:36:31 +0100 Message-ID: <21201.856290991@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702181501.QAA01275@ocean.campus.luth.se>, Mikael Karpberg writes >Try scandinavia. As far as I know all the scandinavian countries have >very good internet connectivity. Ok... Sometimes the US link is not the best, >but then again, that is not scandinavia having a bad connection to internet. >It's US having a bad connection to the internet. ;-) This reminds me of the "British attitude": "There is a storm in the channel, the continent is cut off" >no problem importing encryption stuff into the US, is it? It seems to me >that moving the main repository would be the easiest and most logical >solution, since we could add all the encryption we wanted, then, without >any problems. Well, if you can provide us with as well connected a machine, this may indeed become reality, but until now, we have had no sufficiently good offers for resources. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-security Tue Feb 18 11:06:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA22298 for security-outgoing; Tue, 18 Feb 1997 11:06:08 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA22257; Tue, 18 Feb 1997 11:05:53 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id OAA13768; Tue, 18 Feb 1997 14:04:15 -0500 (EST) Date: Tue, 18 Feb 1997 14:04:15 -0500 (EST) From: Mark Mayo To: Mikael Karpberg cc: dk+@ua.net, freebsd-security@freebsd.org, www@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: <199702181501.QAA01275@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 18 Feb 1997, Mikael Karpberg wrote: > According to Dmitry Kohmanyuk: > > In article <199702172225.XAA21874@ocean.campus.luth.se> you wrote: > [...] > > I think that just having main repository into a normal country can be a > > better option. Sadly, most normal countries have poorer Internet > > connectivity. > > Try scandinavia. As far as I know all the scandinavian countries have > very good internet connectivity. Ok... Sometimes the US link is not the best, > but then again, that is not scandinavia having a bad connection to internet. > It's US having a bad connection to the internet. ;-) > Meaning, if the US-Europe link sucks, it's neither sides fault, really. That's why OpenBSD is in Canada. The links from Canada to the US are just as fast as if I were in the US (for example, I have a T1 from rogers network services, who have multiple T3's straight off the Chicago NAP - my connection to the US is just as fast as any US T1..). Scandanavia is certainly a good choice for Europe. I think Germany's net connections are decent as well.. France's connections seem to really blow. > And wouldn't i be better to ahve the main repository outside US, and having > that mirrored into the machine that today is the main repository. That seems > more logical, no? I think that might not be a bad idea. The problem, of course, is who is willing to donate the bandwidth aside from Walnut Creek CDROM to hold the main freebsd distribution? I know I would have no problems donating machine time, but I can't afford to give away too much of my bandwidth - it's just too bloody expensive, and my profit margins are already next to zero! I would like to know how much bandwidth (approx.) is used by FreeBSD, so I've cc'ed this to www@freebsd.org for an opinion. And have all encryption things written outside the US, > so that it can be downloaded by everyone. As far as I understand, there's > no problem importing encryption stuff into the US, is it? It seems to me > that moving the main repository would be the easiest and most logical > solution, since we could add all the encryption we wanted, then, without > any problems. > Well, something I'm certainly willing to do is provide development account on a machine here in Canada - I'm checking into the laws in detail right now, but it might be a way for the crypto stuff to not be of US origin, which would make it exportable... (mail me privately with PGP to discuss this matter further). -Mark > /Mikael > ---------------------------------------------------------------------------- Mark Mayo mark@quickweb.com RingZero Comp. http://vinyl.quickweb.com/mark ---------------------------------------------------------------------------- "I prefer tongue-tied knowledge to ignorant loquacity." Cicero (106-43 B.C.) From owner-freebsd-security Tue Feb 18 12:42:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA29933 for security-outgoing; Tue, 18 Feb 1997 12:42:19 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA29924 for ; Tue, 18 Feb 1997 12:42:13 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id VAA20625 for ; Tue, 18 Feb 1997 21:42:04 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id VAA06446 for security@FreeBSD.ORG; Tue, 18 Feb 1997 21:41:49 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id UAA09468; Tue, 18 Feb 1997 20:42:04 +0100 (CET) Message-ID: <19970218204204.XV00531@keltia.freenix.fr> Date: Tue, 18 Feb 1997 20:42:04 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: security@freebsd.org Subject: Re: blowfish passwords in FreeBSD References: <199702181411.PAA00954@ocean.campus.luth.se> X-Mailer: Mutt 0.60,1-3,9 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2999 In-Reply-To: <199702181411.PAA00954@ocean.campus.luth.se>; from Mikael Karpberg on Feb 18, 1997 15:11:16 +0100 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Mikael Karpberg: > I know there are .com and .org addresses outside US, which is why I said > "or .org/.com known to be US"... but .edu and .us should be us only, no? No, there are -- very few -- .EDU in France (mostly from private schools). .US is USA only as it is using the ISO code for it and the rules are defined by RFC-1480. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #39: Sun Feb 2 22:12:44 CET 1997 From owner-freebsd-security Tue Feb 18 13:31:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA02788 for security-outgoing; Tue, 18 Feb 1997 13:31:23 -0800 (PST) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA02781 for ; Tue, 18 Feb 1997 13:31:15 -0800 (PST) Received: from nemeton.UUCP (Unemeton@localhost) by perki0.connect.com.au with UUCP id IAA13641 (8.7.6h/IDA-1.6); Wed, 19 Feb 1997 08:30:49 +1100 (EST) X-Authentication-Warning: perki0.connect.com.au: Unemeton set sender to giles@nemeton.com.au using -f Received: from localhost.nemeton.com.au (localhost.nemeton.com.au [127.0.0.1]) by nemeton.com.au (8.8.5/8.8.5) with SMTP id HAA14294; Wed, 19 Feb 1997 07:57:18 +1100 (EST) Message-Id: <199702182057.HAA14294@nemeton.com.au> To: Warner Losh cc: Mikael Karpberg , mark@quickweb.com (Mark Mayo), security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-reply-to: Date: Wed, 19 Feb 1997 07:57:18 +1100 From: Giles Lean Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 18 Feb 1997 00:25:35 -0700 Warner Losh wrote: > In message <199702172225.XAA21874@ocean.campus.luth.se> Mikael Karpberg writes: > : install from a site called .edu/.us or .org/.com known to be US, or so. > > .EDU, .COM and .ORG are international. Do a whois on msi-uk.com > sometime :-) All domains are international. I have a '.au' host in the USA, and hundreds of '.se' hosts in Australia. You are somewhat better off relying on IP address (assuming that you can get the information on who is nominally where) but even this doesn't help a lot. Giles From owner-freebsd-security Tue Feb 18 14:43:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA06499 for security-outgoing; Tue, 18 Feb 1997 14:43:32 -0800 (PST) Received: from gadget.nla.gov.au (gadget.nla.gov.au [203.4.201.52]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA06490 for ; Tue, 18 Feb 1997 14:43:22 -0800 (PST) Received: from localhost (cmakin@localhost) by gadget.nla.gov.au (8.8.4/8.8.4) with SMTP id JAA10242 for ; Wed, 19 Feb 1997 09:40:56 +1100 (EST) X-Authentication-Warning: gadget.nla.gov.au: cmakin owned process doing -bs Date: Wed, 19 Feb 1997 09:40:56 +1100 (EST) From: Carl Makin Reply-To: Carl Makin To: freebsd-security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 18 Feb 1997, Mark Mayo wrote: > That's why OpenBSD is in Canada. The links from Canada to the US are just > as fast as if I were in the US (for example, I have a T1 from rogers > network services, who have multiple T3's straight off the Chicago NAP - my > connection to the US is just as fast as any US T1..). Scandanavia is This to throw a can amoungst the pigeons! Even if the code is not of US origin, if the links it is being passed over go through US territory does that make it subject to US restrictions. >From previous incidents it would seem that the US government thinks so. I just remember an incident when money was being sent from Australia to Korea (I think) for helping blind ppl and it went through a US bank. It was seized by the US govt as the US had restrictions on what could be sent to that country (which Australia didn't). I believe that took a high level diplomatic exchange to resolve. Seeing as most of Australia's Internet links go via the US then would that make it illegal (in the US) for us to retrieve DES stuff from Canada? Carl. -- Carl Makin (VK1KCM) C.Makin@nla.gov.au 'Work +61 6 262 1576' "Speaking for myself only!" 'If you want to make your spouse pay attention to what you say... Talk in your sleep!' From owner-freebsd-security Tue Feb 18 15:43:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA10304 for security-outgoing; Tue, 18 Feb 1997 15:43:53 -0800 (PST) Received: from dedicavia.inetcan.net (dedicavia.inetcan.net [206.186.215.200]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA10299 for ; Tue, 18 Feb 1997 15:43:48 -0800 (PST) Received: from localhost (dreamer@localhost) by dedicavia.inetcan.net (8.7.6/8.7.3) with SMTP id QAA01343; Tue, 18 Feb 1997 16:43:08 -0700 Date: Tue, 18 Feb 1997 16:43:07 -0700 (MST) From: Digital Dreamer To: Mikael Karpberg cc: dk+@ua.net, freebsd-security@freebsd.org Subject: Re: blowfish passwords in FreeBSD In-Reply-To: <199702181501.QAA01275@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 18 Feb 1997, Mikael Karpberg wrote: > According to Dmitry Kohmanyuk: > > In article <199702172225.XAA21874@ocean.campus.luth.se> you wrote: > [...] > > I think that just having main repository into a normal country can be a > > better option. Sadly, most normal countries have poorer Internet > > connectivity. > > Try scandinavia. As far as I know all the scandinavian countries have > very good internet connectivity. Ok... Sometimes the US link is not the best, > but then again, that is not scandinavia having a bad connection to internet. > It's US having a bad connection to the internet. ;-) .. Why not just use Canada? Canada's internet connectivity is more or less the same as that of the US (for obvious reasons), but it is exempt from those wonderful export laws. The fact that Canada is part of ITAR might come in handy somehow, too. dreamer From owner-freebsd-security Tue Feb 18 15:56:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA11130 for security-outgoing; Tue, 18 Feb 1997 15:56:58 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA11115 for ; Tue, 18 Feb 1997 15:56:41 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id LAA00423; Wed, 19 Feb 1997 11:00:31 +1100 (EST) Date: Wed, 19 Feb 1997 11:00:30 +1100 (EST) From: "Daniel O'Callaghan" To: Carl Makin cc: freebsd-security@FreeBSD.ORG Subject: Re: blowfish passwords in FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 19 Feb 1997, Carl Makin wrote: > On Tue, 18 Feb 1997, Mark Mayo wrote: > > This to throw a can amoungst the pigeons! Even if the code is not of US > origin, if the links it is being passed over go through US territory does > that make it subject to US restrictions. > > >From previous incidents it would seem that the US government thinks so. > > I just remember an incident when money was being sent from Australia to > Korea (I think) for helping blind ppl and it went through a US bank. It > was seized by the US govt as the US had restrictions on what could be sent > to that country (which Australia didn't). I believe that took a high > level diplomatic exchange to resolve. That is why Luxembourg and Switzerland exist. (Tongue somewhat in cheek, no flames please.) > Seeing as most of Australia's Internet links go via the US then would that > make it illegal (in the US) for us to retrieve DES stuff from Canada? This is very much an arguable point, and I think the FBI might have given up here. You don't see many people being prosecuted for fetching ssh from Finland, or SSLeay from Australia or PGP from New Zealand, no matter where they are. Danny From owner-freebsd-security Tue Feb 18 17:36:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA19513 for security-outgoing; Tue, 18 Feb 1997 17:36:15 -0800 (PST) Received: from enteract.com (root@enteract.com [206.54.252.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19501 for ; Tue, 18 Feb 1997 17:36:08 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id TAA12057 for freebsd-security@freebsd.org; Tue, 18 Feb 1997 19:34:12 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199702190134.TAA12057@enteract.com> Subject: Security problem in FreeBSD /sbin/init To: freebsd-security@freebsd.org Date: Tue, 18 Feb 1997 19:34:11 -0600 (CST) Reply-To: tqbf@enteract.com X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This problem will probably be picked up by the sweeping audit of your code base, but I figured I'd alert you to it anyways. FreeBSD, in revisions up to and including -current, has a stack overrun in /sbin/init. The affected routines are "start_getty()" and "start_window_system()", both of which can be tricked into reading an overly large "type" entry from the /etc/ttys file (which is copied into an array on the stack used to hold the "TERM" environment variable for a subsequent execve() call). This overflow is only exploitable if you control /etc/ttys. On almost all systems, this means it's only an issue if you're root. Unfortunately, this is a serious issue in init's case. Unbeknownst to many, init (or, more specifically, PID 1) can change the securelevel arbitrarily in 4.4BSD systems. The purpose of securelevels is to "secure the system from root", disabling the modification of crucial system binaries. The "immutable" flag depends on this concept. This overflow provides intruders with a means to evade the immutable (or append-only, or any other securelevel-dependant concept) mechanism. Given my relative unfamiliarity with the FreeBSD CVS "protocol", such as it is, I'll leave it for another developer to fix this. The problem is an unchecked string copy in both routines, and can easily be resolved by sticking an "n" in the strcpy() function call. Good luck with the audit. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?" From owner-freebsd-security Tue Feb 18 19:51:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA28761 for security-outgoing; Tue, 18 Feb 1997 19:51:57 -0800 (PST) Received: from cwsys.cwent.com (0@cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA28736 for ; Tue, 18 Feb 1997 19:51:44 -0800 (PST) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id TAA01277; Tue, 18 Feb 1997 19:51:02 -0800 (PST) Message-Id: <199702190351.TAA01277@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd001274; Wed Feb 19 03:50:52 1997 Reply-to: cys@mailhost.wlc.com X-Mailer: Xmh To: tqbf@enteract.com cc: freebsd-security@freebsd.org Subject: Re: Security problem in FreeBSD /sbin/init In-reply-to: Your message of "Tue, 18 Feb 1997 19:34:11 CST." <199702190134.TAA12057@enteract.com> Date: Tue, 18 Feb 1997 19:50:52 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > This problem will probably be picked up by the sweeping audit of your code > base, but I figured I'd alert you to it anyways. > > FreeBSD, in revisions up to and including -current, has a stack overrun in > /sbin/init. The affected routines are "start_getty()" and > "start_window_system()", both of which can be tricked into reading an > overly large "type" entry from the /etc/ttys file (which is copied into an > array on the stack used to hold the "TERM" environment variable for a > subsequent execve() call). > > This overflow is only exploitable if you control /etc/ttys. On almost all > systems, this means it's only an issue if you're root. > > Unfortunately, this is a serious issue in init's case. Unbeknownst to > many, init (or, more specifically, PID 1) can change the securelevel > arbitrarily in 4.4BSD systems. The purpose of securelevels is to "secure > the system from root", disabling the modification of crucial system > binaries. The "immutable" flag depends on this concept. This overflow > provides intruders with a means to evade the immutable (or append-only, or > any other securelevel-dependant concept) mechanism. > > Given my relative unfamiliarity with the FreeBSD CVS "protocol", such as > it is, I'll leave it for another developer to fix this. The problem is an > unchecked string copy in both routines, and can easily be resolved by > sticking an "n" in the strcpy() function call. > > Good luck with the audit. I don't think this is a security problem since /sbin/init has permissions of 500 and /etc/ttys has permissions of 644. Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Tue Feb 18 20:12:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA29864 for security-outgoing; Tue, 18 Feb 1997 20:12:20 -0800 (PST) Received: from mail.calweb.com (mail.calweb.com [208.131.56.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA29844 for ; Tue, 18 Feb 1997 20:12:09 -0800 (PST) Received: from hell.gigo.com (hell.gigo.com [207.173.133.59]) by mail.calweb.com (8.8.5/8.8.5) with SMTP id UAA22157 for ; Tue, 18 Feb 1997 20:11:23 -0800 (PST) Message-Id: <3.0.1.32.19970218200814.006e5118@pop.calweb.com> X-Sender: jfesler@pop.calweb.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 18 Feb 1997 20:08:14 -0800 To: security@freebsd.org From: Jason Fesler Subject: Coredumps and setuids .. interesting.. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I found this to be rather interesting.. I didn't realize that linux and solaris refused to core dump setuid programs. This could be a rather good thing should it find it's way into *bsd.. >Date: Tue, 18 Feb 1997 19:59:37 -0500 >Reply-To: Simon Karpen >From: Simon Karpen >Subject: Re: FreeBSD,rlogin and coredumps. >To: BUGTRAQ@NETSPACE.ORG > >The problem is not in screen; it's in the operating system. >Linux is truly not vulnerable as it does not allow >coredumps of setuid root programs. > >The BSDs (at least FreeBSD) appear to still do this for some >inane reason. Even SunOS 4.x doesn't coredump setuid progs, and >I wouldn't exactly call it secure. > >On Tue, 18 Feb 1997, Nathan Torkington wrote: >> It's possible to send a signal 11 to the latest version of screen >> (3.7.2) and make it coredump with the master.passwd file in memory. >> I'm using FreeBSD 2.1.5-RELEASE. > >Simon Karpen >karpes@rpi.edu, slk@acm.rpi.edu, slk@karpes.stu.rpi.edu >"Down, not Across" > > From owner-freebsd-security Tue Feb 18 21:44:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA04317 for security-outgoing; Tue, 18 Feb 1997 21:44:54 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA04311 for ; Tue, 18 Feb 1997 21:44:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id VAA10377; Tue, 18 Feb 1997 21:45:56 -0800 (PST) Message-Id: <199702190545.VAA10377@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Jason Fesler cc: security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-reply-to: Your message of "Tue, 18 Feb 1997 20:08:14 PST." <3.0.1.32.19970218200814.006e5118@pop.calweb.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 18 Feb 1997 21:45:56 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I found this to be rather interesting.. I didn't realize >that linux and solaris refused to core dump setuid programs. >This could be a rather good thing should it find it's way >into *bsd.. Hmmm. Either my replies aren't getting through to bugtraq, or people are just ignoring them. As of FreeBSD 2.1.6 and newer versions, we don't core dump for setuid processes. It's been this way for nearly a year in -current, but the change didn't get merged into the 2.1.x branch until after the 2.1.5 release...that was an oversight. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Tue Feb 18 21:52:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA04807 for security-outgoing; Tue, 18 Feb 1997 21:52:22 -0800 (PST) Received: from enteract.com (root@enteract.com [206.54.252.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA04800 for ; Tue, 18 Feb 1997 21:52:15 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id XAA12266; Tue, 18 Feb 1997 23:51:51 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199702190551.XAA12266@enteract.com> Subject: Re: Security problem in FreeBSD /sbin/init To: cys@mailhost.wlc.com Date: Tue, 18 Feb 1997 23:51:50 -0600 (CST) Cc: tqbf@enteract.com, freebsd-security@freebsd.org Reply-To: tqbf@enteract.com In-Reply-To: <199702190351.TAA01277@cwsys.cwent.com> from "Cy Schubert" at Feb 18, 97 07:50:52 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I don't think this is a security problem since /sbin/init has permissions > of 500 and /etc/ttys has permissions of 644. You're missing the point. This is not a "get-root" bug. This is a vulnerability that will allow an intruder that has already gained illicit root access to evade "securelevels", which, among other things, prevent modifications to the running kernel and to critical system binaries by root. The status of the files are irrelevant unless they're immutable. Many, many systems (several of mine included) rely on this mechanism to ensure that, even if root is somehow comprimised, the system cannot be transperantly modified to permit indefinite, undetectable future access by the attacker. Code exists and is being circulated that will allow intruders to circumvent virtually every publically-available method of intrusion detection; an attacker that controls the running kernel can prevent the maintainers of the system from verifying it's integrity, even cryptographically, without physically removing the storage media and mounting it in a "clean" machine. Obviously, it's fairly important that this be fixed immediately, and that word is spread immediately so that people who have taken these measures to protect their systems are aware of the potential for silent comprimise. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?" From owner-freebsd-security Tue Feb 18 22:54:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA07975 for security-outgoing; Tue, 18 Feb 1997 22:54:32 -0800 (PST) Received: from saguaro.flyingfox.com (saguaro.flyingfox.com [204.188.109.253]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA07970 for ; Tue, 18 Feb 1997 22:54:29 -0800 (PST) Received: (from jas@localhost) by saguaro.flyingfox.com (8.6.12/8.6.10) id WAA16181; Tue, 18 Feb 1997 22:49:22 -0800 Date: Tue, 18 Feb 1997 22:49:22 -0800 From: Jim Shankland Message-Id: <199702190649.WAA16181@saguaro.flyingfox.com> To: dg@root.com, jfesler@calweb.com Subject: Re: Coredumps and setuids .. interesting.. Cc: security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman writes, re coredumping setuid processes: > Hmmm. Either my replies aren't getting through to bugtraq, or > people are just ignoring them. As of FreeBSD 2.1.6 and newer > versions, we don't core dump for setuid processes. It's been > this way for nearly a year in -current, but the change didn't > get merged into the 2.1.x branch until after the 2.1.5 > release...that was an oversight. Actually, an old 2.1.0-RELEASE source tree I have lying around indicates that core is not dumped for setuid processes: /* * Dump core, into a file named "progname.core", unless the process was * setuid/setgid. */ int coredump(p) register struct proc *p; { [...] if (pcred->p_svuid != pcred->p_ruid || pcred->p_svgid != pcred->p_rgid) return (EFAULT); And I tried it out on an old laptop that still has 2.1.0-951104-SNAP, and it wouldn't dump the core of a setuid process. (I don't have a 2.1.5 system to try it out on.) Was this, perhaps, a bug that was introduced in 2.1.5, then fixed in 2.1.6? Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Tue Feb 18 23:15:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA09092 for security-outgoing; Tue, 18 Feb 1997 23:15:28 -0800 (PST) Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [163.195.220.170]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09083 for ; Tue, 18 Feb 1997 23:15:23 -0800 (PST) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.8.5/8.8.5) id JAA22361; Wed, 19 Feb 1997 09:14:38 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199702190714.JAA22361@oskar.nanoteq.co.za> Subject: Re: Coredumps and setuids .. interesting.. In-Reply-To: <199702190649.WAA16181@saguaro.flyingfox.com> from Jim Shankland at "Feb 18, 97 10:49:22 pm" To: jas@flyingfox.COM (Jim Shankland) Date: Wed, 19 Feb 1997 09:14:38 +0200 (SAT) Cc: security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > David Greenman writes, re coredumping setuid processes: > > > Hmmm. Either my replies aren't getting through to bugtraq, or > > people are just ignoring them. As of FreeBSD 2.1.6 and newer > > versions, we don't core dump for setuid processes. It's been > > this way for nearly a year in -current, but the change didn't > > get merged into the 2.1.x branch until after the 2.1.5 > > release...that was an oversight. This is weird ... I have a 2.1.0 machine that I upgraded to a 2.1.6.1 machine just before 2.1.6 was "freezed". I tried the rlogin coredump thingy and it did work. I could see ALL the users AND their passwords :/ > And I tried it out on an old laptop that still has 2.1.0-951104-SNAP, > and it wouldn't dump the core of a setuid process. (I don't have > a 2.1.5 system to try it out on.) Then it gor broke somewhere again ? Reinier From owner-freebsd-security Tue Feb 18 23:56:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA10940 for security-outgoing; Tue, 18 Feb 1997 23:56:33 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA10935 for ; Tue, 18 Feb 1997 23:56:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id XAA11039; Tue, 18 Feb 1997 23:57:08 -0800 (PST) Message-Id: <199702190757.XAA11039@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Reinier Bezuidenhout cc: jas@flyingfox.COM (Jim Shankland), security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-reply-to: Your message of "Sat, 19 Feb 1997 09:14:38 +0200." <199702190714.JAA22361@oskar.nanoteq.co.za> From: David Greenman Reply-To: dg@root.com Date: Tue, 18 Feb 1997 23:57:08 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> David Greenman writes, re coredumping setuid processes: >> >> > Hmmm. Either my replies aren't getting through to bugtraq, or >> > people are just ignoring them. As of FreeBSD 2.1.6 and newer >> > versions, we don't core dump for setuid processes. It's been >> > this way for nearly a year in -current, but the change didn't >> > get merged into the 2.1.x branch until after the 2.1.5 >> > release...that was an oversight. > >This is weird ... I have a 2.1.0 machine that I upgraded to a >2.1.6.1 machine just before 2.1.6 was "freezed". I tried the >rlogin coredump thingy and it did work. I could see ALL the >users AND their passwords :/ I've explained this several times already, but here goes again: There was a bug in the kernel where it didn't pass the P_SUGID flag onto the child of a fork. rlogin is a special case setuid binary in that it forks and doesn't follow that with an exec. The child process was then vulnerable to being killed in a way that would cause a core dump. Everyone prior to you who has looked at the resulting core file (me included) has found that it contained only the encrypted password for the user's own account, and not any others. I'm rather surprised that you are saying that it contains other users' encrypted passwords... In any case, that bug has been fixed in 2.1.7 and later versions of FreeBSD. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Wed Feb 19 00:57:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA13113 for security-outgoing; Wed, 19 Feb 1997 00:57:11 -0800 (PST) Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [163.195.220.170]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA13108 for ; Wed, 19 Feb 1997 00:57:03 -0800 (PST) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.8.5/8.8.5) id KAA26329; Wed, 19 Feb 1997 10:56:12 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199702190856.KAA26329@oskar.nanoteq.co.za> Subject: Re: Coredumps and setuids .. interesting.. In-Reply-To: <199702190757.XAA11039@root.com> from David Greenman at "Feb 18, 97 11:57:08 pm" To: dg@root.com Date: Wed, 19 Feb 1997 10:56:11 +0200 (SAT) Cc: jas@flyingfox.COM, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi ... > > I've explained this several times already, but here goes again: > > There was a bug in the kernel where it didn't pass the P_SUGID flag onto > the child of a fork. rlogin is a special case setuid binary in that it forks > and doesn't follow that with an exec. The child process was then vulnerable > to being killed in a way that would cause a core dump. Everyone prior to you > who has looked at the resulting core file (me included) has found that it > contained only the encrypted password for the user's own account, and not > any others. I'm rather surprised that you are saying that it contains other > users' encrypted passwords... > In any case, that bug has been fixed in 2.1.7 and later versions of > FreeBSD. > Sorry for letting you repeat it for the 64 234 time :) :) Why I posted this is that I though someone said it was fixed in 2.1.6, but I was wrong since I noticed (tested) it on 2.1.7 and later and it does NOT work there. I do have a strings rlogin.core and in there are ALL the users and their encrypted passwords, I can mail it ... but would rather not :) ... but seeing that 2.1.7 has been released, there is no point in worrying about this anymore ... right ? Thanx for your time Reinier From owner-freebsd-security Wed Feb 19 04:28:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA20187 for security-outgoing; Wed, 19 Feb 1997 04:28:10 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA20182 for ; Wed, 19 Feb 1997 04:28:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id EAA11960; Wed, 19 Feb 1997 04:28:55 -0800 (PST) Message-Id: <199702191228.EAA11960@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Reinier Bezuidenhout cc: jas@flyingfox.COM, security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-reply-to: Your message of "Sat, 19 Feb 1997 10:56:11 +0200." <199702190856.KAA26329@oskar.nanoteq.co.za> From: David Greenman Reply-To: dg@root.com Date: Wed, 19 Feb 1997 04:28:55 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Why I posted this is that I though someone said it was fixed in 2.1.6, >but I was wrong since I noticed (tested) it on 2.1.7 and later and >it does NOT work there. It was sort of fixed in 2.1.6 - coredumps of 'normal' setuid programs are prevented, but rlogin is a special case that still could coredump (the original parent can't, but the child it forks can). This was fixed in 2.1.7. >mail it ... but would rather not :) ... but seeing that 2.1.7 >has been released, there is no point in worrying about this anymore >... right ? Right. If people chose not to upgrade to 2.1.7, then they've got bigger security holes to worry about. :-) -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Wed Feb 19 04:37:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA20488 for security-outgoing; Wed, 19 Feb 1997 04:37:10 -0800 (PST) Received: from magrathea.chance.ru (root@magrathea.chance.ru [194.58.86.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA20482 for ; Wed, 19 Feb 1997 04:37:02 -0800 (PST) Received: (from caseq@localhost) by magrathea.chance.ru (8.6.12/8.6.12) id PAA10870; Wed, 19 Feb 1997 15:34:56 +0300 From: Andrew Kosyakov Message-Id: <199702191234.PAA10870@magrathea.chance.ru> Subject: Re: Coredumps and setuids .. interesting.. To: rbezuide@oskar.nanoteq.co.za (Reinier Bezuidenhout) Date: Wed, 19 Feb 1997 15:34:56 +0300 (MSK) Cc: dg@root.com, jas@flyingfox.COM, security@freebsd.org In-Reply-To: <199702190856.KAA26329@oskar.nanoteq.co.za> from "Reinier Bezuidenhout" at Feb 19, 97 10:56:11 am Organization: Chance Publishing House X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quoting Reinier Bezuidenhout: > > to being killed in a way that would cause a core dump. Everyone prior to you > > who has looked at the resulting core file (me included) has found that it > > contained only the encrypted password for the user's own account, and not > > any others. I'm rather surprised that you are saying that it contains other > > users' encrypted passwords... > and in there are ALL the users and their encrypted passwords, I can > mail it ... but would rather not :) ... but seeing that 2.1.7 Perhaps, many people fixed their libc since that similar case with wu-ftpd. The solution is to patch dbm code the zero out all memory being free()'d, so that when password database is closed by endpwent() called from some getpwname(), all passwords (except the one being returned) are erased from memory. The following changes were suggested by someone from OpenBSD project, but still work great for FreeBSD (the file in question is in /usr/src/lib/libc/db/hash/): --- hash_buf.c.old Tue Oct 15 14:24:48 1996 +++ hash_buf.c Tue Oct 15 14:24:13 1996 @@ -324,7 +324,10 @@ /* Check if we are freeing stuff */ if (do_free) { if (bp->page) + { + memset(bp->page,0,hashp->BSIZE); free(bp->page); + } BUF_REMOVE(bp); free(bp); bp = LRU; -- Sincerely yours /&rew *** Andrew V. Kosyakov, Chance Publishing House, System Administrator caseq@chance.ru, 2:5030/31@Fidonet.Org, +7(812)210-8046 PGP key fingerprint: BA A8 48 20 E4 AE 9C 52 C5 5F C3 B8 1E 67 2C BF From owner-freebsd-security Wed Feb 19 04:54:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA21045 for security-outgoing; Wed, 19 Feb 1997 04:54:21 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA21039 for ; Wed, 19 Feb 1997 04:54:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id EAA12072; Wed, 19 Feb 1997 04:54:41 -0800 (PST) Message-Id: <199702191254.EAA12072@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Andrew Kosyakov cc: rbezuide@oskar.nanoteq.co.za (Reinier Bezuidenhout), jas@flyingfox.COM, security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-reply-to: Your message of "Wed, 19 Feb 1997 15:34:56 +0300." <199702191234.PAA10870@magrathea.chance.ru> From: David Greenman Reply-To: dg@root.com Date: Wed, 19 Feb 1997 04:54:41 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Perhaps, many people fixed their libc since that similar case with wu-ftpd. >The solution is to patch dbm code the zero out all memory being free()'d, so >that when password database is closed by endpwent() called from some >getpwname(), all passwords (except the one being returned) are erased from >memory. The following changes were suggested by someone from OpenBSD project, >but still work great for FreeBSD (the file in question is in >/usr/src/lib/libc/db/hash/): No, this isn't a good solution. It only deals with one type of sensitive data (encrypted passwords), and doesn't really "solve" the problem (e.g. you could still get it to coredump prior to it having a chance to zero everything out). The only "correct" solution is to not allow processes with potentially sensitive data (setuid, setgid) to coredump in the first place. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Wed Feb 19 05:21:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA22006 for security-outgoing; Wed, 19 Feb 1997 05:21:06 -0800 (PST) Received: from magrathea.chance.ru (root@magrathea.chance.ru [194.58.86.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA21983 for ; Wed, 19 Feb 1997 05:20:57 -0800 (PST) Received: (from caseq@localhost) by magrathea.chance.ru (8.6.12/8.6.12) id QAA11111; Wed, 19 Feb 1997 16:20:07 +0300 From: Andrew Kosyakov Message-Id: <199702191320.QAA11111@magrathea.chance.ru> Subject: Re: Coredumps and setuids .. interesting.. To: dg@root.com Date: Wed, 19 Feb 1997 16:20:07 +0300 (MSK) Cc: rbezuide@oskar.nanoteq.co.za, jas@flyingfox.COM, security@freebsd.org In-Reply-To: <199702191254.EAA12072@root.com> from "David Greenman" at Feb 19, 97 04:54:41 am Organization: Chance Publishing House X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quoting David Greenman: > >The solution is to patch dbm code the zero out all memory being free()'d, so > >that when password database is closed by endpwent() called from some > No, this isn't a good solution. It only deals with one type of sensitive > data (encrypted passwords), and doesn't really "solve" the problem (e.g. Well, I'm not proclaiming this to be the panacea, and, in fact, this often (but not always) solves the problem not only for password database, but for any data stored in 'hash' dbm format. And, certainly, it _helped_ against *fptd/rlogin/screen vulnerabilities and didn't broke anything except from one of my friend's poorly written program which relied on data being in core after data base's been closed :-) > you could still get it to coredump prior to it having a chance to zero > everything out). Why, it would be unwise of it to close data base before dropping root privileges (and in this case it will be impossible at all), and I won't be able to send any signal to it unless it drops privileges. The case when it dumps core due to some memory fault still remains, but it will probably be serious hole itself. And I think we'll agree on that BOTH measures should be taken. > The only "correct" solution is to not allow processes with potentially > sensitive data (setuid, setgid) to coredump in the first place. You should also remember processes started as root and used set*id() to drop privileges, such as ftpd. -- Sincerely yours /&rew *** Andrew V. Kosyakov, Chance Publishing House, System Administrator caseq@chance.ru, 2:5030/31@Fidonet.Org, +7(812)210-8046 PGP key fingerprint: BA A8 48 20 E4 AE 9C 52 C5 5F C3 B8 1E 67 2C BF From owner-freebsd-security Wed Feb 19 05:37:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA22704 for security-outgoing; Wed, 19 Feb 1997 05:37:08 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA22694 for ; Wed, 19 Feb 1997 05:37:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id FAA12198; Wed, 19 Feb 1997 05:37:20 -0800 (PST) Message-Id: <199702191337.FAA12198@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Andrew Kosyakov cc: rbezuide@oskar.nanoteq.co.za, jas@flyingfox.COM, security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-reply-to: Your message of "Wed, 19 Feb 1997 16:20:07 +0300." <199702191320.QAA11111@magrathea.chance.ru> From: David Greenman Reply-To: dg@root.com Date: Wed, 19 Feb 1997 05:37:20 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >for any data stored in 'hash' dbm format. And, certainly, it _helped_ >against *fptd/rlogin/screen vulnerabilities and didn't broke anything It breaks performance when you have to zero out every bit of information you get from a database. People might actually want their .db programs to run *fast*, and this isn't a way to acheive that. >> you could still get it to coredump prior to it having a chance to zero >> everything out). >Why, it would be unwise of it to close data base before dropping root >privileges (and in this case it will be impossible at all), and I won't be >able to send any signal to it unless it drops privileges. The case when it A process running with set*id privileges doesn't mean that it can't receive signals while it has them effective. In fact it can, the only requirement is that the real uid of the process and the uid of the process sending the signal be the same, and they will be in either case. >> The only "correct" solution is to not allow processes with potentially >> sensitive data (setuid, setgid) to coredump in the first place. >You should also remember processes started as root and used set*id() to >drop privileges, such as ftpd. Anything that does a seteuid will have the P_SUGID flag set internally, and thus coredumps are prevented. If the process starts out as root and doesn't issue any set*id calls, then the corefile will be owned by root with no access to anyone...so there isn't a vulnerability in either case. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Wed Feb 19 06:26:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA25166 for security-outgoing; Wed, 19 Feb 1997 06:26:31 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA25161 for ; Wed, 19 Feb 1997 06:26:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id GAA12408; Wed, 19 Feb 1997 06:24:57 -0800 (PST) Message-Id: <199702191424.GAA12408@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Andrew Kosyakov , rbezuide@oskar.nanoteq.co.za, jas@flyingfox.COM, security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-reply-to: Your message of "Wed, 19 Feb 1997 05:37:20 PST." <199702191337.FAA12198@root.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 19 Feb 1997 06:24:57 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>Why, it would be unwise of it to close data base before dropping root >>privileges (and in this case it will be impossible at all), and I won't be >>able to send any signal to it unless it drops privileges. The case when it > > A process running with set*id privileges doesn't mean that it can't receive >signals while it has them effective. In fact it can, the only requirement is >that the real uid of the process and the uid of the process sending the >signal be the same, and they will be in either case. A correction...the signal sender need only match *either* the real or effective uid of the signal receiver. From the manual page: For a process to have permission to send a signal to a process designated by pid, the real or effective user ID of the receiving process must match that of the sending process or the user must have appropriate privileges (such as given by a set-user-ID program or the user is the super-user). A single exception is the signal SIGCONT, which may always be sent to any descendant of the current process. I actually didn't know it was this open until I read the manual page. I believe this behavior is required by POSIX, so it's not likely something that we would want to change. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Wed Feb 19 07:03:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26702 for security-outgoing; Wed, 19 Feb 1997 07:03:50 -0800 (PST) Received: from magrathea.chance.ru (root@magrathea.chance.ru [194.58.86.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA26695 for ; Wed, 19 Feb 1997 07:03:41 -0800 (PST) Received: (from caseq@localhost) by magrathea.chance.ru (8.6.12/8.6.12) id SAA11558; Wed, 19 Feb 1997 18:01:25 +0300 From: Andrew Kosyakov Message-Id: <199702191501.SAA11558@magrathea.chance.ru> Subject: Re: Coredumps and setuids .. interesting.. To: dg@root.com Date: Wed, 19 Feb 1997 18:01:24 +0300 (MSK) Cc: rbezuide@oskar.nanoteq.co.za, jas@flyingfox.COM, security@freebsd.org In-Reply-To: <199702191337.FAA12198@root.com> from "David Greenman" at Feb 19, 97 05:37:20 am Organization: Chance Publishing House X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quoting David Greenman: > >for any data stored in 'hash' dbm format. And, certainly, it _helped_ > >against *fptd/rlogin/screen vulnerabilities and didn't broke anything > It breaks performance when you have to zero out every bit of information > you get from a database. People might actually want their .db programs to > run *fast*, and this isn't a way to acheive that. Not that it was meant to :) But this argument looks weak to me -- how much performance degrade do you except form zeroing the page being released, considering that almost every page should be read from disk and sometimes written back, which is *much* more expensive operation. > >> you could still get it to coredump prior to it having a chance to zero > >> everything out). > >Why, it would be unwise of it to close data base before dropping root > >privileges (and in this case it will be impossible at all), and I won't be Arrggh, I meant "dropping privileges before closing base". > >able to send any signal to it unless it drops privileges. The case when it > A process running with set*id privileges doesn't mean that it can't receive > signals while it has them effective. In fact it can, the only requirement is > that the real uid of the process and the uid of the process sending the > signal be the same, and they will be in either case. BTW, running tests on 2.1.0 I couldn't make my test program (which only did gets() call to pause) dump core _if_ it was setuid. However, rlogin and screen do coredump. Is there an explanation to this fact? > Anything that does a seteuid will have the P_SUGID flag set internally, and > thus coredumps are prevented. If the process starts out as root and doesn't > issue any set*id calls, then the corefile will be owned by root with no > access to anyone...so there isn't a vulnerability in either case. Great... for a long term solution :) And is there any patch available for those, who still run 2.1.*? If no, I believe that one-line patch to libc will still protect them from at least 3 vulnerabilities.. -- Sincerely yours /&rew *** Andrew V. Kosyakov, Chance Publishing House, System Administrator caseq@chance.ru, 2:5030/31@Fidonet.Org, +7(812)210-8046 PGP key fingerprint: BA A8 48 20 E4 AE 9C 52 C5 5F C3 B8 1E 67 2C BF From owner-freebsd-security Wed Feb 19 09:38:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA05697 for security-outgoing; Wed, 19 Feb 1997 09:38:32 -0800 (PST) Received: from saguaro.flyingfox.com (saguaro.flyingfox.com [204.188.109.253]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA05692 for ; Wed, 19 Feb 1997 09:38:30 -0800 (PST) Received: (from jas@localhost) by saguaro.flyingfox.com (8.6.12/8.6.10) id JAA16579; Wed, 19 Feb 1997 09:32:00 -0800 Date: Wed, 19 Feb 1997 09:32:00 -0800 From: Jim Shankland Message-Id: <199702191732.JAA16579@saguaro.flyingfox.com> To: caseq@magrathea.chance.ru, dg@root.com, jas@flyingfox.COM, rbezuide@oskar.nanoteq.co.za, security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman writes: > A correction...the signal sender need only match *either* the real or > effective uid of the signal receiver.... > > I actually didn't know it was this open until I read the manual page. I > believe this behavior is required by POSIX, so it's not likely something > that we would want to change. It's not only a standard, it's even useful. Think of a non-privileged client process that runs a setuid-somebody (not necessarily root) server process for, say, database access. The server process, being privileged, has unfettered access to the database, but permission-checks accesses requested of it by the client. The client may still want to signal the server process to abort a long-running query, for example. Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Wed Feb 19 10:26:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA09854 for security-outgoing; Wed, 19 Feb 1997 10:26:01 -0800 (PST) Received: from ns.cococo.net (apache@ns.cococo.net [206.100.242.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA09848 for ; Wed, 19 Feb 1997 10:25:55 -0800 (PST) Received: from localhost (apache@localhost) by ns.cococo.net (8.8.5/) with SMTP id NAA24766; Wed, 19 Feb 1997 13:29:49 -0500 Date: Wed, 19 Feb 1997 13:29:48 -0500 (EST) From: Apache Mailing List To: Reinier Bezuidenhout cc: security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-Reply-To: <199702190856.KAA26329@oskar.nanoteq.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 19 Feb 1997, Reinier Bezuidenhout wrote: > > Why I posted this is that I though someone said it was fixed in 2.1.6, > but I was wrong since I noticed (tested) it on 2.1.7 and later and > it does NOT work there. > Could someone point me to where 2.1.7 is located, please... I go to the web site and it says 2.1.7 will be released shortly. I have a couple of machines I want to install it on and I can't find it. Sorry for the stupid question, but I can't find it. Later Kelley From owner-freebsd-security Wed Feb 19 11:21:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA12936 for security-outgoing; Wed, 19 Feb 1997 11:21:56 -0800 (PST) Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA12931 for ; Wed, 19 Feb 1997 11:21:49 -0800 (PST) Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.4/8.8.4) with ESMTP id OAA19515 for ; Wed, 19 Feb 1997 14:21:30 -0500 (EST) Received: from alsatian.cslab.vt.edu (alsatian.cslab.vt.edu [198.82.184.11]) by sable.cc.vt.edu (8.8.4/8.8.4) with SMTP id OAA06557 for ; Wed, 19 Feb 1997 14:21:30 -0500 (EST) Received: from husky.cslab.vt.edu by alsatian.cslab.vt.edu (5.65v3.2/1.1.10.5/18Sep96-0417PM) id AA31599; Wed, 19 Feb 1997 14:21:30 -0500 From: Jeff Aitken Received: by husky.cslab.vt.edu (5.65v3.2/1.1.10.5/22Aug96-1216PM) id AA11901; Wed, 19 Feb 1997 14:21:29 -0500 Message-Id: <9702191921.AA11901@husky.cslab.vt.edu> Subject: pronouncable password generator To: security@freebsd.org Date: Wed, 19 Feb 1997 14:21:29 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I vaugely recall someone posting the source code to a very simple pronouncable password generator some time ago, but I can't seem to find any reference to it any more (the only thing I found on www.freebsd.org was a reference to npasswd, which AFAIK doesn't do this). Anyone know of such a beast? --Jeff From owner-freebsd-security Wed Feb 19 12:21:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA16197 for security-outgoing; Wed, 19 Feb 1997 12:21:56 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA16189 for ; Wed, 19 Feb 1997 12:21:44 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vxIVb-0006Jf-00; Wed, 19 Feb 1997 13:20:55 -0700 To: Andrew Kosyakov Subject: Re: Coredumps and setuids .. interesting.. Cc: rbezuide@oskar.nanoteq.co.za (Reinier Bezuidenhout), dg@root.com, jas@flyingfox.COM, security@freebsd.org In-reply-to: Your message of "Wed, 19 Feb 1997 15:34:56 +0300." <199702191234.PAA10870@magrathea.chance.ru> References: <199702191234.PAA10870@magrathea.chance.ru> Date: Wed, 19 Feb 1997 13:20:55 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702191234.PAA10870@magrathea.chance.ru> Andrew Kosyakov writes: : --- hash_buf.c.old Tue Oct 15 14:24:48 1996 : +++ hash_buf.c Tue Oct 15 14:24:13 1996 : @@ -324,7 +324,10 @@ : /* Check if we are freeing stuff */ : if (do_free) { : if (bp->page) : + { : + memset(bp->page,0,hashp->BSIZE); : free(bp->page); : + } : BUF_REMOVE(bp); : free(bp); : bp = LRU; I think this is an excellent idea, but an incomplete one. I think that we should do this, but hack the db code so that you have to request that this be done. Then the pw routines would set this flag. Testing this flag is very cheap and no one would notice. This would also firewall the pw database somewhat at a very low cost. I agree that keeping this from coredumping in the first place is by far the best solution, limiting the damage when there are bugs in the kernel should be done when the cost can be shown to be small for those programs that use the same feature, but don't need the protection. --- hash_buf.c.old Tue Oct 15 14:24:48 1996 +++ hash_buf.c Tue Oct 15 14:24:13 1996 @@ -324,7 +324,10 @@ /* Check if we are freeing stuff */ if (do_free) { if (bp->page) + { + if (bp->flags & ZERO_ON_FREE) + memset(bp->page,0,hashp->BSIZE); free(bp->page); + } BUF_REMOVE(bp); free(bp); bp = LRU; with other changes to propigate this flag, define it, that I've not yet done. Comments? Warner From owner-freebsd-security Wed Feb 19 13:35:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA20473 for security-outgoing; Wed, 19 Feb 1997 13:35:26 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA20466 for ; Wed, 19 Feb 1997 13:35:20 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id OAA20339; Wed, 19 Feb 1997 14:34:48 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id OAA01080; Wed, 19 Feb 1997 14:32:14 -0700 (MST) Date: Wed, 19 Feb 1997 14:32:13 -0700 (MST) From: Marc Slemko To: Andrew Kosyakov cc: security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-Reply-To: <199702191234.PAA10870@magrathea.chance.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 19 Feb 1997, Andrew Kosyakov wrote: > Quoting Reinier Bezuidenhout: > > > > to being killed in a way that would cause a core dump. Everyone prior to you > > > who has looked at the resulting core file (me included) has found that it > > > contained only the encrypted password for the user's own account, and not > > > any others. I'm rather surprised that you are saying that it contains other > > > users' encrypted passwords... > > and in there are ALL the users and their encrypted passwords, I can > > mail it ... but would rather not :) ... but seeing that 2.1.7 > Perhaps, many people fixed their libc since that similar case with wu-ftpd. > The solution is to patch dbm code the zero out all memory being free()'d, so > that when password database is closed by endpwent() called from some > getpwname(), all passwords (except the one being returned) are erased from > memory. The following changes were suggested by someone from OpenBSD project, > but still work great for FreeBSD (the file in question is in > /usr/src/lib/libc/db/hash/): > > > --- hash_buf.c.old Tue Oct 15 14:24:48 1996 > +++ hash_buf.c Tue Oct 15 14:24:13 1996 > @@ -324,7 +324,10 @@ > /* Check if we are freeing stuff */ > if (do_free) { > if (bp->page) > + { > + memset(bp->page,0,hashp->BSIZE); > free(bp->page); > + } > BUF_REMOVE(bp); > free(bp); > bp = LRU; > David has already responded about why it isn't the best solution, but please check the list archives archives for previous discussion on the same issue. BTDT: ---------------------------- revision 1.1.1.1.6.4 date: 1996/10/18 19:57:28; author: guido; state: Exp; lines: +1 -3 Backout bzero patch. ---------------------------- revision 1.1.1.1.6.3 date: 1996/10/17 18:27:58; author: guido; state: Exp; lines: +3 -1 When freeing buffers in the db routines, also zeroize them This should solve the bug where a coredumping ftpd reveals encrypted passwords. Obtained from: OpenBSD ---------------------------- It was decided this was the wrong fix. I agree. Warner's suggestion of adding to the API to allow a process to specify if they want it is fine, but non-portable and only solves very specific problems; ie. the process has to know to do it. I'm not sure it is worth it since you have to fix the problem some other way anyway for all the other programs. OTOH, being paranoid is good except when it isn't and I don't see a huge thing against Warner's suggestion. It may well be possible to find ways other than core dumps to get access to the memory image through bugs in ftpd. From owner-freebsd-security Wed Feb 19 22:04:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA20238 for security-outgoing; Wed, 19 Feb 1997 22:04:22 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA20225 for ; Wed, 19 Feb 1997 22:04:17 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vxRbs-0006vF-00; Wed, 19 Feb 1997 23:04:00 -0700 To: Marc Slemko Subject: Re: Coredumps and setuids .. interesting.. Cc: Andrew Kosyakov , security@freebsd.org In-reply-to: Your message of "Wed, 19 Feb 1997 14:32:13 MST." References: Date: Wed, 19 Feb 1997 23:04:00 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Marc Slemko writes: : OTOH, being paranoid is good except when it isn't and I don't see a huge : thing against Warner's suggestion. It may well be possible to find ways : other than core dumps to get access to the memory image through bugs in : ftpd. Or via the ptrace api, or via some new feature that someone adds to procfs that lets you attach to a process' address space, or any other number of other things which seem like a good idea at the time, but introduce more holes. Warner From owner-freebsd-security Thu Feb 20 03:13:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA06328 for security-outgoing; Thu, 20 Feb 1997 03:13:01 -0800 (PST) Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA06312 for ; Thu, 20 Feb 1997 03:12:58 -0800 (PST) Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id MAA02115; Thu, 20 Feb 1997 12:12:52 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma002021; Thu Feb 20 12:12:02 1997 Received: from bsd.lss.cp.philips.com (bsd.lss.cp.philips.com [130.144.199.33]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970214) with SMTP id MAA23864; Thu, 20 Feb 1997 12:12:02 +0100 Received: by bsd.lss.cp.philips.com (8.8.3/1.63) id MAA23985; Thu, 20 Feb 1997 12:12:01 +0100 (MET) From: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) Message-Id: <199702201112.MAA23985@bsd.lss.cp.philips.com> Subject: Re: pronouncable password generator To: jaitken@cslab.vt.edu (Jeff Aitken) Date: Thu, 20 Feb 1997 12:12:01 +0100 (MET) Cc: security@freebsd.org In-Reply-To: <9702191921.AA11901@husky.cslab.vt.edu> from Jeff Aitken at "Feb 19, 97 02:21:29 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jeff Aitken wrote: > I vaugely recall someone posting the source code to a very simple > pronouncable password generator some time ago, but I can't seem to find > any reference to it any more (the only thing I found on www.freebsd.org > was a reference to npasswd, which AFAIK doesn't do this). > > Anyone know of such a beast? Look on the web for fips181 E.g.: ftp://ftp.uni-stuttgart.de/pub/doc/security/fips181.txt -Guido From owner-freebsd-security Thu Feb 20 03:31:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA07026 for security-outgoing; Thu, 20 Feb 1997 03:31:47 -0800 (PST) Received: from magrathea.chance.ru (root@magrathea.chance.ru [194.58.86.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA07018 for ; Thu, 20 Feb 1997 03:31:42 -0800 (PST) Received: (from caseq@localhost) by magrathea.chance.ru (8.6.12/8.6.12) id OAA14947; Thu, 20 Feb 1997 14:31:06 +0300 From: Andrew Kosyakov Message-Id: <199702201131.OAA14947@magrathea.chance.ru> Subject: Re: Coredumps and setuids .. interesting.. To: imp@village.org (Warner Losh) Date: Thu, 20 Feb 1997 14:31:06 +0300 (MSK) Cc: marcs@znep.com, security@freebsd.org In-Reply-To: from "Warner Losh" at Feb 19, 97 11:04:00 pm Organization: Chance Publishing House X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quoting Warner Losh: > : thing against Warner's suggestion. It may well be possible to find ways > : other than core dumps to get access to the memory image through bugs in > : ftpd. > Or via the ptrace api, or via some new feature that someone adds to > procfs that lets you attach to a process' address space, or any other > number of other things which seem like a good idea at the time, but > introduce more holes. So, you mean that someone may want to add an ability for an unprivileged process to attach to the address space of a privileged process? Well, certainly, there will be such people, but I guess they'll have to break freefall again in order to implement that :-) (sorry if you consider this joke to be rude). And I'd like to ask again: is there an official patch for 2.1.* to disable P_SUGID process to dump core? Many people can't afford to upgrade the whole OS on their production machines :-( -- Sincerely yours /&rew *** Andrew V. Kosyakov, Chance Publishing House, System Administrator caseq@chance.ru, 2:5030/31@Fidonet.Org, +7(812)210-8046 PGP key fingerprint: BA A8 48 20 E4 AE 9C 52 C5 5F C3 B8 1E 67 2C BF From owner-freebsd-security Thu Feb 20 04:01:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA08325 for security-outgoing; Thu, 20 Feb 1997 04:01:14 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA08317 for ; Thu, 20 Feb 1997 04:01:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id EAA25095; Thu, 20 Feb 1997 04:01:27 -0800 (PST) Message-Id: <199702201201.EAA25095@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Andrew Kosyakov cc: imp@village.org (Warner Losh), marcs@znep.com, security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-reply-to: Your message of "Thu, 20 Feb 1997 14:31:06 +0300." <199702201131.OAA14947@magrathea.chance.ru> From: David Greenman Reply-To: dg@root.com Date: Thu, 20 Feb 1997 04:01:27 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >And I'd like to ask again: is there an official patch for 2.1.* to disable >P_SUGID process to dump core? Many people can't afford to upgrade the whole >OS on their production machines :-( The patch is attached. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project Index: sys/kern/kern_exec.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.21.4.6 diff -c -r1.21.4.6 kern_exec.c *** kern_exec.c 1996/06/04 02:11:37 1.21.4.6 --- kern_exec.c 1997/02/19 18:13:53 *************** *** 259,265 **** p->p_ucred->cr_groups[0] = attr.va_gid; p->p_flag |= P_SUGID; } else { ! p->p_flag &= ~P_SUGID; } /* --- 259,267 ---- p->p_ucred->cr_groups[0] = attr.va_gid; p->p_flag |= P_SUGID; } else { ! if (p->p_ucred->cr_uid == p->p_cred->p_ruid && ! p->p_ucred->cr_gid == p->p_cred->p_rgid) ! p->p_flag &= ~P_SUGID; } /* Index: sys/kern/kern_fork.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v retrieving revision 1.12.4.2 retrieving revision 1.12.4.3 diff -c -r1.12.4.2 -r1.12.4.3 *** kern_fork.c 1996/05/02 12:09:04 1.12.4.2 --- kern_fork.c 1997/02/17 10:58:02 1.12.4.3 *************** *** 252,257 **** --- 252,261 ---- p2->p_limit->p_refcnt++; } + /* + * Preserve some flags in subprocess. + */ + p2->p_flag |= p1->p_flag & P_SUGID; if (p1->p_session->s_ttyvp != NULL && p1->p_flag & P_CONTROLT) p2->p_flag |= P_CONTROLT; if (isvfork) From owner-freebsd-security Thu Feb 20 04:43:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA10270 for security-outgoing; Thu, 20 Feb 1997 04:43:19 -0800 (PST) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA10265 for ; Thu, 20 Feb 1997 04:43:12 -0800 (PST) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id EAA24521; Thu, 20 Feb 1997 04:41:33 -0800 (PST) To: Andrew Kosyakov cc: imp@village.org (Warner Losh), marcs@znep.com, security@freebsd.org Subject: Re: Coredumps and setuids .. interesting.. In-reply-to: Your message of "Thu, 20 Feb 1997 14:31:06 +0300." <199702201131.OAA14947@magrathea.chance.ru> Date: Thu, 20 Feb 1997 04:41:33 -0800 Message-ID: <24517.856442493@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > And I'd like to ask again: is there an official patch for 2.1.* to disable > P_SUGID process to dump core? Many people can't afford to upgrade the whole Grab or stay in synchronization with the 2.1-stable sources. :-) Jordan From owner-freebsd-security Thu Feb 20 07:41:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA18428 for security-outgoing; Thu, 20 Feb 1997 07:41:40 -0800 (PST) Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA18402 for ; Thu, 20 Feb 1997 07:41:33 -0800 (PST) Received: from [194.100.45.1] (mac.metis.clinet.fi [194.100.45.1]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id RAA06192 for ; Thu, 20 Feb 1997 17:41:17 +0200 (EET) X-Sender: metis@pop.clinet.fi Message-Id: In-Reply-To: <199702182057.HAA14294@nemeton.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Feb 1997 17:46:33 +0200 To: security@freebsd.org From: Petri Riihikallio Subject: Re: blowfish passwords in FreeBSD Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> : install from a site called .edu/.us or .org/.com known to be US, or so. >> >> .EDU, .COM and .ORG are international. Do a whois on msi-uk.com >> sometime :-) > >All domains are international. I have a '.au' host in the USA, and >hundreds of '.se' hosts in Australia. > >You are somewhat better off relying on IP address (assuming that you >can get the information on who is nominally where) but even this >doesn't help a lot. Wasn't there a field for the ICMB address in domain registrations ? It would be fairly easy to approximate US from the longitude and latitude. Hawaii and Alaska would be treated as exceptions. ;-) Cheers Petri -- Petri.Riihikallio@Metis.fi From owner-freebsd-security Thu Feb 20 09:32:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA25282 for security-outgoing; Thu, 20 Feb 1997 09:32:49 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA25259 for ; Thu, 20 Feb 1997 09:32:43 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id SAA25612 for ; Thu, 20 Feb 1997 18:32:31 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id SAA04003 for security@freebsd.org; Thu, 20 Feb 1997 18:32:25 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id HAA14841; Thu, 20 Feb 1997 07:13:34 +0100 (CET) Message-ID: <19970220071334.SO13587@keltia.freenix.fr> Date: Thu, 20 Feb 1997 07:13:34 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: security@freebsd.org Subject: Re: pronouncable password generator References: <9702191921.AA11901@husky.cslab.vt.edu> X-Mailer: Mutt 0.60,1-3,9 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2999 In-Reply-To: <9702191921.AA11901@husky.cslab.vt.edu>; from Jeff Aitken on Feb 19, 1997 14:21:29 -0500 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Jeff Aitken: > I vaugely recall someone posting the source code to a very simple > pronouncable password generator some time ago, but I can't seem to find > any reference to it any more (the only thing I found on www.freebsd.org > was a reference to npasswd, which AFAIK doesn't do this). I got that a while ago. -rw-r--r-- 1 roberto staff 6675 Sep 8 1995 pwgen.shar.gz It is so small I can send it by mail if you want. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #39: Sun Feb 2 22:12:44 CET 1997 From owner-freebsd-security Thu Feb 20 10:05:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA27039 for security-outgoing; Thu, 20 Feb 1997 10:05:28 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA27034 for ; Thu, 20 Feb 1997 10:05:23 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vxcrh-0007cg-00; Thu, 20 Feb 1997 11:05:05 -0700 To: Andrew Kosyakov Subject: Re: Coredumps and setuids .. interesting.. Cc: marcs@znep.com, security@freebsd.org In-reply-to: Your message of "Thu, 20 Feb 1997 14:31:06 +0300." <199702201131.OAA14947@magrathea.chance.ru> References: <199702201131.OAA14947@magrathea.chance.ru> Date: Thu, 20 Feb 1997 11:05:04 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702201131.OAA14947@magrathea.chance.ru> Andrew Kosyakov writes: : So, you mean that someone may want to add an ability for an : unprivileged process to attach to the address space of a privileged : process? Well, certainly, there will be such people, but I guess : they'll have to break freefall again in order to implement that :-) : (sorry if you consider this joke to be rude). If you look at the ptrace code in 2.1.7 you'll notice that the checks for attaching to a process don't take into account that the process may have once been owned by root. This would allow a person who started, say, ftp to attach to the ftpd process once he'd logged in as himself and grab passwords. The attach functionality in 2.1.7 was broken in other ways, so it wasn't actually enabled, so the 2.1.7 systems aren't volunerable to this attack (and -current does the right thing). While it makes sense to fix these sorts of problems as they are discovered, it also makes sense to destroy sensitive data when you are done with it so that if an unknown system problem exists that causes this information to be disclosed to a third party, the window for doing so is shortened and closed completely for as many of the cases as possible. That's what I'm saying. : And I'd like to ask again: is there an official patch for 2.1.* to disable : P_SUGID process to dump core? Many people can't afford to upgrade the whole : OS on their production machines :-( David already sent this out, but you really should be tracking -stable, or at least upgrade to 2.1.7. Many security related fixes have come down the pipe, some quietly, and you really want to have all of them in a production machine that has users that aren't 100% trusted or that is accessible to the internet. Warner From owner-freebsd-security Thu Feb 20 11:19:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA01357 for security-outgoing; Thu, 20 Feb 1997 11:19:20 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA01344 for ; Thu, 20 Feb 1997 11:19:13 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id OAA20643; Thu, 20 Feb 1997 14:19:47 -0500 (EST) Date: Thu, 20 Feb 1997 14:19:46 -0500 (EST) From: Mark Mayo To: Guido van Rooij cc: Jeff Aitken , security@freebsd.org Subject: Re: pronouncable password generator In-Reply-To: <199702201112.MAA23985@bsd.lss.cp.philips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 20 Feb 1997, Guido van Rooij wrote: > Jeff Aitken wrote: > > I vaugely recall someone posting the source code to a very simple > > pronouncable password generator some time ago, but I can't seem to find > > any reference to it any more (the only thing I found on www.freebsd.org > > was a reference to npasswd, which AFAIK doesn't do this). > > > > Anyone know of such a beast? > > Look on the web for fips181 > > E.g.: > ftp://ftp.uni-stuttgart.de/pub/doc/security/fips181.txt Ouch that's some ugly code... I new I was in trouble as soon as I saw #include and later came across intdos() calls... haven't seen those in a while!! -Mark > > -Guido > ---------------------------------------------------------------------------- Mark Mayo mark@quickweb.com RingZero Comp. http://vinyl.quickweb.com/mark ---------------------------------------------------------------------------- "I prefer tongue-tied knowledge to ignorant loquacity." Cicero (106-43 B.C.) From owner-freebsd-security Fri Feb 21 07:00:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA28616 for security-outgoing; Fri, 21 Feb 1997 07:00:43 -0800 (PST) Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA28608 for ; Fri, 21 Feb 1997 07:00:38 -0800 (PST) Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id PAA21755; Fri, 21 Feb 1997 15:59:11 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma021391; Fri Feb 21 15:58:07 1997 Received: from bsd.lss.cp.philips.com (bsd.lss.cp.philips.com [130.144.199.33]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970214) with SMTP id PAA14687; Fri, 21 Feb 1997 15:58:06 +0100 Received: by bsd.lss.cp.philips.com (8.8.3/1.63) id PAA13100; Fri, 21 Feb 1997 15:58:05 +0100 (MET) From: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) Message-Id: <199702211458.PAA13100@bsd.lss.cp.philips.com> Subject: Re: pronouncable password generator To: mark@quickweb.com (Mark Mayo) Date: Fri, 21 Feb 1997 15:58:05 +0100 (MET) Cc: Guido.vanRooij@nl.cis.philips.com, jaitken@cslab.vt.edu, security@freebsd.org In-Reply-To: from Mark Mayo at "Feb 20, 97 02:19:46 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark Mayo wrote: > Ouch that's some ugly code... I new I was in trouble as soon as I saw > #include > > and later came across intdos() calls... haven't seen those in a while!! > It is easy to circumvent those though. I did it some time ago but have thrown away the whole stuff. -Guido From owner-freebsd-security Fri Feb 21 09:34:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA07493 for security-outgoing; Fri, 21 Feb 1997 09:34:54 -0800 (PST) Received: from phobos.frii.com (phobos.frii.com [204.144.241.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA07487 for ; Fri, 21 Feb 1997 09:34:49 -0800 (PST) From: gnat@frii.com Received: from elara.frii.com (elara.frii.com [204.144.241.9]) by phobos.frii.com (8.8.4/8.8.4) with ESMTP id KAA13833 for ; Fri, 21 Feb 1997 10:34:29 -0700 (MST) Received: (from gnat@localhost) by elara.frii.com (8.8.4/8.6.9) id KAA03840; Fri, 21 Feb 1997 10:34:25 -0700 (MST) Date: Fri, 21 Feb 1997 10:34:25 -0700 (MST) Message-Id: <199702211734.KAA03840@elara.frii.com> To: freebsd-security@freebsd.org Subject: 2.1.7 requires a rebuild of /usr/local binaries? Mime-Version: 1.0 (generated by tm-edit 7.103) Content-Type: text/plain; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've just installed 2.1.7 (upgrading from 2.1.5) on my own machine, prior to upgrading all our servers. The advisory re: the setlocale bug said to rebuild all statically linked binaries and probably all dynamically linked ones too. Going to the 2.1.7-RELEASE/packages directory, however, I see it's just a link to the 2.1.6 packages directory. Does this mean that I don't have to rebuild all my binaries after all? Nat From owner-freebsd-security Fri Feb 21 12:49:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA21787 for security-outgoing; Fri, 21 Feb 1997 12:49:36 -0800 (PST) Received: from narcissus.ml.org (root@brosenga.Pitzer.edu [134.173.120.201]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA21779 for ; Fri, 21 Feb 1997 12:49:34 -0800 (PST) Received: (from ben@localhost) by narcissus.ml.org (8.7.5/8.7.3) id MAA02492; Fri, 21 Feb 1997 12:49:17 -0800 (PST) Date: Fri, 21 Feb 1997 12:49:17 -0800 (PST) From: Snob Art Genre To: gnat@frii.com cc: freebsd-security@FreeBSD.ORG Subject: Re: 2.1.7 requires a rebuild of /usr/local binaries? In-Reply-To: <199702211734.KAA03840@elara.frii.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 21 Feb 1997 gnat@frii.com wrote: > I've just installed 2.1.7 (upgrading from 2.1.5) on my own machine, > prior to upgrading all our servers. The advisory re: the setlocale > bug said to rebuild all statically linked binaries and probably all > dynamically linked ones too. > > Going to the 2.1.7-RELEASE/packages directory, however, I see it's > just a link to the 2.1.6 packages directory. Does this mean that I > don't have to rebuild all my binaries after all? It probably means that the packages were rebuilt as soon as the fix became available. You should still rebuild if you can, because your binaries are linked against libraries which contain the security hole that prompted the release of 2.1.7. > Nat > Ben "You have your mind on computers, it seems." From owner-freebsd-security Sat Feb 22 22:36:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA23497 for security-outgoing; Sat, 22 Feb 1997 22:36:36 -0800 (PST) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA23492; Sat, 22 Feb 1997 22:36:34 -0800 (PST) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id WAA25530; Sat, 22 Feb 1997 22:36:29 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id WAA06143; Sat, 22 Feb 1997 22:36:28 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA22830; Sat, 22 Feb 1997 22:36:27 -0800 (PST) Date: Sat, 22 Feb 1997 22:36:27 -0800 (PST) From: Don Lewis Message-Id: <199702230636.WAA22830@salsa.gv.tsc.tdk.com> To: freebsd-isp@freebsd.org, freebsd-security@freebsd.org Subject: improved setuid and device file checker for /etc/security Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A few weeks ago I solicited input on how to prevent locate.updatedb and /etc/security wasting a lot of time digging around the article spool on our news server. I got a lot of suggestions on different ways to tweak these scripts to prevent this, but the suggestions mostly involved making custom changes to these scripts that would be somewhat of a hassle to maintain. At least in the case of /etc/security, I came up with a scheme that should be a lot more automatic. It's more complete in that it checks filesystems other than UFS, such as NFS, since someone could sneak a setuid executable onto one of these other filesystems. It doesn't check filesystems that are mounted nosuid or noexec, since any setuid executables present on these filesystems aren't a security threat. These two features give you more incentive to mount filesystems nosuid or noexec unless you have a good reason to do otherwise ;-) I also added device file checking (other than their timestamps which tend do get updated). I also supress the checking of the ownerships and permissions on the tty devices, since these devices get chowned and chmoded. --------------------------------- Cut Here --------------------------- echo "checking setuid files:" # don't have ncheck, but this does the equivalent of the commented out block. # note that one of the original problem, the possibility of overrunning # the args to ls, is still here... # MP=`mount | awk '!/\([^(]*(noexec|nosuid)[^(]*\)$/{ print $3 }'` set $MP while test $# -ge 1; do mount=$1 shift find -X $mount -xdev -type f \ \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \ \( -perm -u+s -or -perm -g+s \) | sort done | xargs -n 20 ls -lgTd > $TMP if [ ! -f $LOG/setuid.today ] ; then echo "no $LOG/setuid.today" cp $TMP $LOG/setuid.today fi if cmp $LOG/setuid.today $TMP >/dev/null; then :; else echo "$host setuid diffs:" diff -b $LOG/setuid.today $TMP mv $LOG/setuid.today $LOG/setuid.yesterday mv $TMP $LOG/setuid.today fi rm -f $TMP echo "" echo "" echo "checking device files:" MP=`mount | awk '!/\([^(]*nodev[^(]*\)$/{ print $3 }'` set $MP while test $# -ge 1; do mount=$1 shift find -X $mount -xdev \( -type b -o -type c \) | sort done | xargs -n 20 ls -lgTd | awk '{mode = $1; user = $3; group = $4; if ($11 ~ /\/tty/) { mode = substr(mode, 1, 1) "........."; user = ""; group = ""} printf "%7s %-2s %-8s %-8s %4s %9s %s\n", mode, $2, user, group, $5, $6, $11}' >> $TMP if [ ! -f $LOG/device.today ] ; then echo "no $LOG/device.today" cp $TMP $LOG/device.today fi if cmp $LOG/device.today $TMP >/dev/null; then :; else echo "$host device diffs:" diff -b $LOG/device.today $TMP mv $LOG/device.today $LOG/device.yesterday mv $TMP $LOG/device.today fi rm -f $TMP --------------------------------- Cut Here --------------------------- --- Truck