From owner-freebsd-security Sun Jun 2 00:14:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA07101 for security-outgoing; Sun, 2 Jun 1996 00:14:16 -0700 (PDT) Received: from onyx.nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA07095 for ; Sun, 2 Jun 1996 00:14:08 -0700 (PDT) Received: (from coredump@localhost) by onyx.nervosa.com (8.7.5/8.7.3) id AAA04192; Sun, 2 Jun 1996 00:13:43 -0700 (PDT) Date: Sun, 2 Jun 1996 00:13:43 -0700 (PDT) From: "Chris J. Layne" To: freebsd-security@freebsd.org Subject: [linux-security] ext2fs file attributes -- denial-of-service attack (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Could this have any impact on our implementation of ext2fs? == Chris Layne ======================================== Nervosa Computing == == coredump@nervosa.com ================ http://www.nervosa.com/~coredump == ---------- Forwarded message ---------- Date: Thu, 30 May 1996 21:20:46 +0100 (BST) From: Zefram To: linux-security@tarsier.cv.nrao.edu Subject: [linux-security] ext2fs file attributes -- denial-of-service attack All versions so far of the second extended file system (ext2fs) as implemented in the Linux kernel have the following security problem. Any user is permitted to set any file attribute other than `immutable' on files they own. In particular, an unprivileged user can set the `append-only' flag. To do this merely requires the ability to execute arbitrary code -- the flag is set by an ioctl(2) call. The usual way to set these flags is by use of the chattr(8) command. The effects of the append-only flag being set on a file are o No process, even with privileges, may open the file other than in append mode. The file cannot be truncated. o No process, even with privileges, may use link(2), unlink(2) or rename(2) on the file. The flag can be set on a directory in the same way, in which case o No process, even with privileges, may use rename(2) or rmdir(2) on the directory. o No process, even with privileges, may use rename(2), rmdir(2) or unlink(2) on any entry in the directory. The only differences between the effects of the append-only flag and the immutable flag are that an append-only file may be appended to (whereas an immutable file cannot be opened for writing at all), and an append-only directory may have new entries added to it (whereas an immutable directory can't be modified at all). Note that the immutable flag, because of its extensive effects, can only be set by a privileged process, but the append-only attribute, with most of the same effects, can be set by the owner of the file in question, even if unprivileged. Obviously there are denial-of-service attacks based on this. The most obvious attack is to create a very large file in /tmp and make it append-only -- any root-run program intended to clear /tmp will fail unless it knows to remove the flag. Even if it does know, there is a race condition, as the flag cannot be cleared simultaneously with deletion, but in this case much the same effect could be obtained by merely keeping the file open. Another possible use of this file attribute is to prevent a symbolic link being removed, making some symlink-based attacks that rely on race conditions work deterministically. This is only possible if the attacker owns the directory containing the symlink. In general, anywhere a privileged process assumes it can remove or rename a file owned by any user, that assumption is rendered incorrect if the user can access the file to set the flag. The only possible solution is to modify the semantics of the append-only attribute in the kernel. There are three likely approaches: (1) setting the append-only flag can be limited to privileged processes; (2) the linking-related effects of the flag can be removed, bringing it in line with the description in the chattr man page; (3) the effects of the flag could be made to have no effect on privileged processes. (3) opens some security holes itself, but should be borne in mind. I produced a patch implementing (2) some time ago, but it the relevant kernel developers say that (1) is the preferred approach. -- Andrew Main From owner-freebsd-security Sun Jun 2 13:16:00 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA07589 for security-outgoing; Sun, 2 Jun 1996 13:16:00 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA07582 for ; Sun, 2 Jun 1996 13:15:57 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id NAA03570 for ; Sun, 2 Jun 1996 13:15:54 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA04887; Mon, 3 Jun 1996 05:59:38 +1000 Date: Mon, 3 Jun 1996 05:59:38 +1000 From: Bruce Evans Message-Id: <199606021959.FAA04887@godzilla.zeta.org.au> To: coredump@nervosa.com, freebsd-security@freebsd.org Subject: Re: [linux-security] ext2fs file attributes -- denial-of-service attack (fwd) Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Could this have any impact on our implementation of ext2fs? Not directly. The ext2fs append and immutable flags have ufs semantics under FreeBSD, and the other ext2fs flags have no effect under FreeBSD. However, the ext2fs semantics seem to be the same as the the ufs ones for the common flags, so the bug report may have an impact on CSRG's implementation of ufs :-). There are some implementation bugs in our ext2fs that reduce the problem for our ext2fs. ufs has both user and system immutable and append flags but ext2fs (apparently) has only a system immutable flag and a shared append flag. The ext2fs flags are each mapped to the (user|system) combination of ufs flags, and ext2fs uses ufs_setattr() and ufs_getattr() without special handling for the ext2fs flags. Thus it is possible to fchflags() the flags in the vnode to an unrepresentable value and see the wrong value using fstat(), but denial of service attacks and writing to your own append-only files are prevented by the system append flag being set. >Any user is permitted to set any file attribute other than `immutable' >on files they own. In particular, an unprivileged user can set the >`append-only' flag. To do this merely requires the ability to execute >arbitrary code -- the flag is set by an ioctl(2) call. The usual way >to set these flags is by use of the chattr(8) command. 4.4Lite has a cleaner implementation involving the chflags(2) and fchflags(2) syscalls, and a more naturally named chflags(8) command. >The effects of the append-only flag being set on a file are >o No process, even with privileges, may open the file other than in > append mode. The file cannot be truncated. >o No process, even with privileges, may use link(2), unlink(2) or > rename(2) on the file. >The flag can be set on a directory in the same way, in which case >o No process, even with privileges, may use rename(2) or rmdir(2) on > the directory. >o No process, even with privileges, may use rename(2), rmdir(2) or > unlink(2) on any entry in the directory. >The only differences between the effects of the append-only flag and >the immutable flag are that an append-only file may be appended to >(whereas an immutable file cannot be opened for writing at all), and an >append-only directory may have new entries added to it (whereas an >immutable directory can't be modified at all). This is all the same as in 4.4Lite. >Note that the immutable >flag, because of its extensive effects, can only be set by a privileged >process, but the append-only attribute, with most of the same effects, >can be set by the owner of the file in question, even if unprivileged. 4.4Lite has a separate immutable for users, so the denial of service problems (if any) apply to the immutable flag too. It has a separate append flag for users, so the semantics are clearer and fixing the problem by restricting access is equivalent to dropping support for the user flags. >Obviously there are denial-of-service attacks based on this. The most >obvious attack is to create a very large file in /tmp and make it >append-only -- any root-run program intended to clear /tmp will fail >unless it knows to remove the flag. Even if it does know, there is a Root had better know how to clear flags using chflags -R. FreeBSD's `rm' has been hacked to unconditionally turn off the user append and immutable flags before attempting removals. 4.4Lite2's rm still fails to remove user-append/immutable files. Bruce From owner-freebsd-security Sun Jun 2 19:09:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA25540 for security-outgoing; Sun, 2 Jun 1996 19:09:34 -0700 (PDT) Received: from conundrum.com (conundrum.com [204.92.8.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA25529 for ; Sun, 2 Jun 1996 19:09:28 -0700 (PDT) Received: from localhost (mattp@localhost) by conundrum.com (8.6.12/8.6.12) with SMTP id WAA02051 for ; Sun, 2 Jun 1996 22:10:27 -0400 Date: Sun, 2 Jun 1996 22:10:24 -0400 (EDT) From: Matt of the Long Red Hair To: freebsd-security@freebsd.org Subject: MD5 Crack code Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Someone posted something recently asking for MD5 code for Crack. I've got a hundred or so users on my system here, and would like to be running crack every once in a while on my passwd file. I'm working under the assumption that somebody, sometime, will eventually get a copy of my master.passwd file. I figure I might as well crack my users' passwords before someone else gets the chance. Does anyone out there have a patch or even full source code for a Crack capable of dealing with FreeBSD's MD5 passwd files? Thanks in advance... Matt ----------------------------------------------------------------------------- EMail: mattp@conundrum.com (MP1229) | "Sometime they will Home Page: http://www.io.org/~mattp | give a war and | nobody will come." Children's International Summer Villages | Home Page: http://www.io.org/~mattp/CISV | - Carl Sandburg ----------------------------------------------------------------------------- From owner-freebsd-security Sun Jun 2 21:46:29 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA04246 for security-outgoing; Sun, 2 Jun 1996 21:46:29 -0700 (PDT) Received: from groovy.dreaming.org (groovy.dreaming.org [204.92.5.69]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA04241 for ; Sun, 2 Jun 1996 21:46:26 -0700 (PDT) Received: (from batsy@localhost) by groovy.dreaming.org (8.6.12/8.6.12) id AAA03556; Mon, 3 Jun 1996 00:53:46 -0400 Date: Mon, 3 Jun 1996 00:53:46 -0400 (EDT) From: jamie X-Sender: batsy@groovy.dreaming.org To: Matt of the Long Red Hair cc: freebsd-security@FreeBSD.org Subject: Re: MD5 Crack code 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 > Does anyone out there have a patch or even full source code for a Crack > capable of dealing with FreeBSD's MD5 passwd files? In fact it was me that was posting it. Mind you it was for fear of someone using the getpwent() bug (check CERT archives) using ushadow.c. Someone pointed out that I had nothing to fear from that bug. Mind you I am uncomfortable with the idea that there is one out there and I can't find it. Though someone gaining root access on my machine would make the master.passwd file useless in that they could get whatever they wanted and then leave a trojan, there are other ways to get the master passwd file on FreeBSD. These of course are not specific to FreeBSD but common misconfigurations. (i.e NFS, ftp and the like). I think that public knowledge of the existance of a crack would be far more useful to admins than "security through obscurity". There is a good reference to that in Practical Unix Security (O'rielly & Assoc.) and as I remember, it was not a facourable one A fish walks into a bar, completely skewing all laws of probablility in the universe which, subsequently, implodes. Some Guy Named Jamie batsy@groovy.dreaming.org From owner-freebsd-security Mon Jun 3 05:10:47 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA11133 for security-outgoing; Mon, 3 Jun 1996 05:10:47 -0700 (PDT) Received: from ns1.zygaena.com (ns1.zygaena.com [206.148.80.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA11128 for ; Mon, 3 Jun 1996 05:10:41 -0700 (PDT) Received: (from nobody@localhost) by ns1.zygaena.com (8.7.5/8.7.3) id IAA06840; Mon, 3 Jun 1996 08:10:33 -0400 (EDT) X-Authentication-Warning: ns1.zygaena.com: nobody set sender to using -f Received: from selway.i.com(198.30.169.1) by ns1.zygaena.com via smap (V1.3) id sma006835; Mon Jun 3 08:10:05 1996 Received: (from ewb@localhost) by selway.i.com (8.7.3/8.7.3) id IAA01617; Mon, 3 Jun 1996 08:10:04 -0400 (EDT) Date: Mon, 3 Jun 1996 08:10:04 -0400 (EDT) From: Will Brown Message-Id: <199606031210.IAA01617@selway.i.com> To: freebsd-security@freebsd.org, mattp@conundrum.com Subject: Re: MD5 Crack code Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Trying (and hopefully failing) to Crack passwords is onne thing. An altogether other thing is cleartext passwords flying around on the net. IMHO that is the largest single risk to systems that are not firewalled. Personally I'd love to insist on Skey (or something like it). Seems to me that simply building clients (FTP, telnet, MUA's, etc.) that are "Skey aware" would go a long way. A separate Skey calculator is a level of "complexity" that many naive users seem to balk at. SecurID (for example) may be "better" because it is "two factor" but it seems like they are using that to justify a system that is far more complex than is required (backend relational databases, etc. etc.) Anybody know of work going on in this direction? In particular, cross-platform SKey aware clients? ------------------------============================----------------------- Will Brown ewb@zns.net Professional Web Design Zygaena Network Services http://www.zns.net and Hosting 216-381-6019 (voice) 216-381-6064 (fax) at reasonable prices From owner-freebsd-security Mon Jun 3 07:35:08 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA19167 for security-outgoing; Mon, 3 Jun 1996 07:35:08 -0700 (PDT) Received: from sea.campus.luth.se (sea.campus.luth.se [130.240.193.40]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA19156 for ; Mon, 3 Jun 1996 07:35:02 -0700 (PDT) Received: (from karpen@localhost) by sea.campus.luth.se (8.6.12/8.6.12) id QAA06701 for freebsd-security@FreeBSD.ORG; Mon, 3 Jun 1996 16:35:08 +0200 Message-Id: <199606031435.QAA06701@sea.campus.luth.se> Subject: Re: MD5 Crack code To: freebsd-security@FreeBSD.ORG Date: Mon, 3 Jun 1996 16:35:08 +0200 (MET DST) From: "Mikael Karpberg" In-Reply-To: <199606031210.IAA01617@selway.i.com> from "Will Brown" at Jun 3, 96 08:10:04 am X-Mailer: ELM [version 2.4 PL25 ME8b] 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. > Trying (and hopefully failing) to Crack passwords is onne thing. An > altogether other thing is cleartext passwords flying around on the > net. IMHO that is the largest single risk to systems that are not > firewalled. Agreed, but some passwords that users use could easilly make you shiver for days... ;) > Personally I'd love to insist on Skey (or something like it). Seems to > me that simply building clients (FTP, telnet, MUA's, etc.) that are > "Skey aware" would go a long way. A separate Skey calculator is a > level of "complexity" that many naive users seem to balk at. I'm not aware of how Skey works, I must say. Doesn't it require you to remember one time passwords or something? Seems like a hassle. Please feel free to correct me, since I'm surely a novice when it comes to that. :) > SecurID (for example) may be "better" because it is "two factor" > but it seems like they are using that to justify a system that is far > more complex than is required (backend relational databases, etc. etc.) Never heard of. Short description of what it is? > Anybody know of work going on in this direction? In particular, > cross-platform SKey aware clients? Why not simply something like SSL which is being developed and used a lot just because the WWW is growing with enormous speed? If you have a secure link, there is no need for a lot of hassle. You can send anything over the socket and it'll be safe. Umm.. No? /Mikael From owner-freebsd-security Mon Jun 3 07:54:27 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA20810 for security-outgoing; Mon, 3 Jun 1996 07:54:27 -0700 (PDT) Received: from asterix.insight.co.za (asterix.insight.co.za [196.27.7.9]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA20796 for ; Mon, 3 Jun 1996 07:54:24 -0700 (PDT) Received: by asterix.insight.co.za (Smail3.1.29.1 #1) id m0uQb1P-000vBzC; Mon, 3 Jun 96 16:54 SAT Message-Id: From: jvisagie@insight.co.za (Johann Visagie) Subject: Re: MD5 Crack code To: security@freebsd.org Date: Mon, 3 Jun 1996 16:54:19 +0200 (SAT) In-Reply-To: <199606031435.QAA06701@sea.campus.luth.se> from "Mikael Karpberg" at Jun 3, 96 04:35:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg wrote: > > > Anybody know of work going on in this direction? In particular, > > cross-platform SKey aware clients? > > Why not simply something like SSL which is being developed and used a lot > just because the WWW is growing with enormous speed? If you have a secure > link, there is no need for a lot of hassle. You can send anything over the > socket and it'll be safe. Umm.. No? Alternatively, a lot of work is currently being done on and around ssh. Mostly commercial, though. :-((( The author of ssh wrote to my boss: Tatu Ylonen wrote: > > There will soon be a commercially available library that is intended > exactly for this kind of use. It basically forms an ssh-encrypted > pipe between two applications. It will be available at least for > unix, Windows 3.1, Windows NT, and Windows 95, possibly also > Macintosh. -- V Johann Visagie | Email: jvisagie@insight.co.za | Tel: +27 83 777-4260 From owner-freebsd-security Mon Jun 3 08:10:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA22569 for security-outgoing; Mon, 3 Jun 1996 08:10:42 -0700 (PDT) Received: from sea.campus.luth.se (sea.campus.luth.se [130.240.193.40]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA22561 for ; Mon, 3 Jun 1996 08:10:39 -0700 (PDT) Received: (from karpen@localhost) by sea.campus.luth.se (8.6.12/8.6.12) id RAA06749 for freebsd-security@FreeBSD.ORG; Mon, 3 Jun 1996 17:10:51 +0200 Message-Id: <199606031510.RAA06749@sea.campus.luth.se> Subject: Re: MD5 Crack code To: freebsd-security@FreeBSD.ORG Date: Mon, 3 Jun 1996 17:10:50 +0200 (MET DST) From: "Mikael Karpberg" In-Reply-To: from "Johann Visagie" at Jun 3, 96 04:54:19 pm X-Mailer: ELM [version 2.4 PL25 ME8b] 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 Hello again. > > Why not simply something like SSL which is being developed and used a lot > > just because the WWW is growing with enormous speed? If you have a secure > > link, there is no need for a lot of hassle. You can send anything over the > > socket and it'll be safe. Umm.. No? > > Alternatively, a lot of work is currently being done on and around ssh. > Mostly commercial, though. :-((( The author of ssh wrote to my boss: I know there are at least SSL implementations out there that are free. The specs are free, also. What's "ssh" supposed to stand for and what is it? :-) /Mikael From owner-freebsd-security Mon Jun 3 08:18:50 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA22967 for security-outgoing; Mon, 3 Jun 1996 08:18:50 -0700 (PDT) Received: from epprod.elsevier.co.uk (epprod.elsevier.co.uk [193.131.222.35]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA22962 for ; Mon, 3 Jun 1996 08:18:42 -0700 (PDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by epprod.elsevier.co.uk (8.6.13/8.6.12) with ESMTP id QAA10834 for ; Mon, 3 Jun 1996 16:16:47 +0100 Received: from cadair.elsevier.co.uk (actually host cadair) by snowdon with SMTP (PP); Mon, 3 Jun 1996 16:17:05 +0100 Received: (from dpr@localhost) by cadair.elsevier.co.uk (8.6.12/8.6.12) id QAA03397; Mon, 3 Jun 1996 16:15:57 +0100 Date: Mon, 3 Jun 1996 16:15:57 +0100 Message-Id: <199606031515.QAA03397@cadair.elsevier.co.uk> To: bde@zeta.org.au CC: coredump@nervosa.com, freebsd-security@FreeBSD.org In-reply-to: <199606021959.FAA04887@godzilla.zeta.org.au> (message from Bruce Evans on Mon, 3 Jun 1996 05:59:38 +1000) Subject: Re: [linux-security] ext2fs file attributes -- denial-of-service attack (fwd) From: Paul Richards X-Attribution: Paul X-Mailer: GNU Emacs [19.30.1], RMAIL, Mailcrypt [3.3] Reply-to: p.richards@elsevier.co.uk Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "Bruce" == Bruce Evans writes: Bruce> Root had better know how to clear flags using chflags -R. Bruce> FreeBSD's `rm' has been hacked to unconditionally turn off the Bruce> user append and immutable flags before attempting removals. Bruce> 4.4Lite2's rm still fails to remove user-append/immutable Bruce> files. This doesn't make sense. What's the point of setting the immutable flag on something like the kernel if 'rm' has been hacked to disable it? The normal file permissions would prevent ordinary users from deleting it and the one reason I'd want to set the immutable flag would be to stop me as root doing something stupid to it. From owner-freebsd-security Mon Jun 3 08:41:49 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA24878 for security-outgoing; Mon, 3 Jun 1996 08:41:49 -0700 (PDT) Received: from cs.pdx.edu (root@cs.pdx.edu [204.203.64.22]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA24864 for ; Mon, 3 Jun 1996 08:41:42 -0700 (PDT) Received: from sirius.cs.pdx.edu (root@sirius.cs.pdx.edu [204.203.64.13]) by cs.pdx.edu (8.7.3/CATastrophe-2/10/96-P) with ESMTP id IAA27592; Mon, 3 Jun 1996 08:41:40 -0700 (PDT) for Received: from localhost (jrb@localhost [127.0.0.1]) by sirius.cs.pdx.edu (8.7.3/CATastrophe-9/18/94-C) with ESMTP id IAA04957; Mon, 3 Jun 1996 08:41:38 -0700 (PDT) for Message-Id: <199606031541.IAA04957@sirius.cs.pdx.edu> To: freebsd-security@freebsd.org Subject: anyone working with IPSEC stack? In-reply-to: Your message of "Mon, 03 Jun 1996 16:35:08 +0200." <199606031435.QAA06701@sea.campus.luth.se> Date: Mon, 03 Jun 1996 08:41:37 -0700 From: Jim Binkley Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone taken the Naval Research Labs code for their ip security stack ("security at the network layer", but in fact it's more complicated than that) and ported/munged it into freebsd? Seems I'm about to do that this summer. The following is an overly simplistic explanation of what the NRL stack code does: 1. implements RFCs 1825 ... ;i.e., provides an AH (authentication header) and ESP (I can never remember what ESP stands for, but basically encryption/privacy) between provided ip src and dest 1.1 ah and esp are done for both ipv4 and ipv6, I'm not interested in ipv6 (at the moment, but there is an ipv6 implementation in the code. ah and esp are requirements for ipv6). 2. gives the kernel a new socket mechanism called a key socket so that keys can be associated with 3. includes a tunneling mechanism The particular crypto algorithms found in the stack are AH = keyed md5, and ESP=des-cbc. We will have to upgrade both of the AH and ESP "transforms" (algorithms basically) to SHA and a combined authentication/des algorithm. Whilst I am asking. Has anyone done any work with pc cards that support crypto algorithms, e.g., a des card say? regards, Jim Binkley jrb@cs.pdx.edu From owner-freebsd-security Mon Jun 3 08:54:39 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA25649 for security-outgoing; Mon, 3 Jun 1996 08:54:39 -0700 (PDT) Received: from irbs.irbs.com ([199.182.75.129]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA25643 for ; Mon, 3 Jun 1996 08:54:36 -0700 (PDT) Received: (from jc@localhost) by irbs.irbs.com (8.7.5/8.6.6) id LAA10684 for freebsd-security@FreeBSD.ORG; Mon, 3 Jun 1996 11:54:01 -0400 (EDT) From: John Capo Message-Id: <199606031554.LAA10684@irbs.irbs.com> Subject: Re: MD5 Crack code To: freebsd-security@FreeBSD.ORG Date: Mon, 3 Jun 1996 11:54:01 -0400 (EDT) In-Reply-To: <199606031435.QAA06701@sea.campus.luth.se> from Mikael Karpberg at "Jun 3, 96 04:35:08 pm" X-Mailer: ELM [version 2.4ME+ PL11 (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 Mikael Karpberg writes: > > Agreed, but some passwords that users use could easilly make you shiver > for days... ;) > And Crack's rules find some interesting passwords: [$ock1e$$] RszsHZyTCi.QQ John Capo jc@irbs.com IRBS Engineering FreeBSD Servers and Workstations (954) 792-9551 Unix/Internet Consulting - ISP Solutions From owner-freebsd-security Mon Jun 3 10:15:30 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03980 for security-outgoing; Mon, 3 Jun 1996 10:15:30 -0700 (PDT) Received: from sea.campus.luth.se (sea.campus.luth.se [130.240.193.40]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA03971 for ; Mon, 3 Jun 1996 10:15:27 -0700 (PDT) Received: (from karpen@localhost) by sea.campus.luth.se (8.6.12/8.6.12) id TAA06911 for freebsd-security@FreeBSD.org; Mon, 3 Jun 1996 19:15:38 +0200 Message-Id: <199606031715.TAA06911@sea.campus.luth.se> Subject: Rm (was [linux-security]) To: freebsd-security@FreeBSD.org Date: Mon, 3 Jun 1996 19:15:37 +0200 (MET DST) From: "Mikael Karpberg" In-Reply-To: <199606031515.QAA03397@cadair.elsevier.co.uk> from "Paul Richards" at Jun 3, 96 04:15:57 pm X-Mailer: ELM [version 2.4 PL25 ME8b] 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 > Bruce> Root had better know how to clear flags using chflags -R. > Bruce> FreeBSD's `rm' has been hacked to unconditionally turn off the > Bruce> user append and immutable flags before attempting removals. > Bruce> 4.4Lite2's rm still fails to remove user-append/immutable > Bruce> files. > > This doesn't make sense. What's the point of setting the immutable > flag on something like the kernel if 'rm' has been hacked to disable it? > > The normal file permissions would prevent ordinary users from deleting > it and the one reason I'd want to set the immutable flag would be to > stop me as root doing something stupid to it. If you read Burce's text once more, you'll see he says "user append and immutable flags". USER. That is, if rm is run by ROOT, and only then, will it ignore the USER APPEND and USER IMMUTABLE flags and just delete is anyway. This prevents a user from stopping root's rm, but root can still stop it, since the SUPERUSER APPEND and SUPERUSER IMMUTABLE flags are not ignored. To be exact: if (!uid && /* only if root */ (st_flags & (UF_APPEND|UF_IMMUTABLE)) && !(st_flags & (SF_APPEND|SF_IMMUTABLE))) { /* go ahead */ } /Mikael From owner-freebsd-security Mon Jun 3 10:58:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA06598 for security-outgoing; Mon, 3 Jun 1996 10:58:28 -0700 (PDT) Received: from io.org (io.org [198.133.36.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA06593 for ; Mon, 3 Jun 1996 10:58:26 -0700 (PDT) Received: from zot.io.org (mattp@zot.io.org [198.133.36.82]) by io.org (8.6.12/8.6.12) with SMTP id NAA20329 for ; Mon, 3 Jun 1996 13:58:21 -0400 Date: Mon, 3 Jun 1996 13:55:40 -0400 (EDT) From: Matt of the Long Red Hair To: freebsd-security@freebsd.org Subject: Re: MD5 Crack code In-Reply-To: <199606031435.QAA06701@sea.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 Mon, 3 Jun 1996, Mikael Karpberg wrote: > > Personally I'd love to insist on Skey (or something like it). Seems to > > me that simply building clients (FTP, telnet, MUA's, etc.) that are > > "Skey aware" would go a long way. A separate Skey calculator is a > > level of "complexity" that many naive users seem to balk at. > > I'm not aware of how Skey works, I must say. Doesn't it require you to > remember one time passwords or something? Seems like a hassle. Please > feel free to correct me, since I'm surely a novice when it comes to that. :) I'm no expert on Skey, but I think I have a grasp on its basics. Essentially, yes, it does use one-time passwords. When you choose your origional password, you also give the system a second code which is used as salt for new passwords. The salt and your last password are applied to an algorithm which returns the password you use on your next connection. My personal feeling is that this method goes way above and beyond my requirements. I'd be happy knowing that my users have secure passwords and that things like ssh are keeping others from stealing those passwords. ----------------------------------------------------------------------------- EMail: mattp@io.org (MP1229) | "Sometime they will Home Page: http://www.io.org/~mattp | give a war and | nobody will come." Children's International Summer Villages | Home Page: http://www.io.org/~mattp/CISV | - Carl Sandburg ----------------------------------------------------------------------------- From owner-freebsd-security Mon Jun 3 11:17:55 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA07774 for security-outgoing; Mon, 3 Jun 1996 11:17:55 -0700 (PDT) Received: from mailhub.aros.net (mailhub.aros.net [205.164.111.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA07760 for ; Mon, 3 Jun 1996 11:17:50 -0700 (PDT) Received: from terra.aros.net (terra.aros.net [205.164.111.10]) by mailhub.aros.net (8.7.5/Unknown) with ESMTP id MAA12119; Mon, 3 Jun 1996 12:50:58 -0600 (MDT) Received: (from angio@localhost) by terra.aros.net (8.7.5/8.6.12) id MAA21767; Mon, 3 Jun 1996 12:17:34 -0600 From: Dave Andersen Message-Id: <199606031817.MAA21767@terra.aros.net> Subject: Re: MD5 Crack code To: karpen@sea.campus.luth.se (Mikael Karpberg) Date: Mon, 3 Jun 1996 12:17:34 -0600 (MDT) Cc: freebsd-security@freebsd.org In-Reply-To: <199606031435.QAA06701@sea.campus.luth.se> from "Mikael Karpberg" at Jun 3, 96 04:35:08 pm X-Mailer: ELM [version 2.4 PL25 PGP2] 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 Lo and behold, Mikael Karpberg once said: > > SecurID (for example) may be "better" because it is "two factor" > > but it seems like they are using that to justify a system that is far > > more complex than is required (backend relational databases, etc. etc.) > > Never heard of. Short description of what it is? SecurID is a challenge/response one-time authentication system. You log on, the system tells you the challenge, you enter the challenge in to your SecurID calculator along with your calculator password, the calc. hands you back a response, you type the response in, you're authenticated. Good stuff for high-security applications. > > Anybody know of work going on in this direction? In particular, > > cross-platform SKey aware clients? > > Why not simply something like SSL which is being developed and used a lot > just because the WWW is growing with enormous speed? If you have a secure > link, there is no need for a lot of hassle. You can send anything over the > socket and it'll be safe. Umm.. No? There's still a difference between a one-time password system and a constant password, and for security reasons, the one-time system is preferable if you can abide by the inconvenience of having to use it. Even if life is encrypted, there's always the off chance that someone could: a) steal the original password (social enginnering, actual theft, hacking the password file) b) Use some form of playback attack against the system, because the password doesn't change. Yes, the encryption does, but it's one more level of security. For best results, add water, and let rest for twenty minutes. Use both encryption and a one-time password scheme. -Dave Andersen -- angio@aros.net Complete virtual hosting and business-oriented system administration Internet services. (WWW, FTP, email) http://www.aros.net/ http://www.aros.net/about/virtual "There are only two industries that refer to thier customers as 'users'." From owner-freebsd-security Mon Jun 3 12:49:04 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA13280 for security-outgoing; Mon, 3 Jun 1996 12:49:04 -0700 (PDT) Received: from raptor.cqi.com (root@raptor.cqi.com [205.252.44.227]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA13268 for ; Mon, 3 Jun 1996 12:48:52 -0700 (PDT) Received: from dstang.cqi.com (pm1_05.cqi.com [205.252.44.102]) by raptor.cqi.com (8.6.12/8.6.9) with SMTP id PAA16464 for ; Mon, 3 Jun 1996 15:32:49 -0400 Message-ID: <31B34FC2.192B@sevenlocks.com> Date: Mon, 03 Jun 1996 15:49:06 -0500 From: David Stang Organization: Seven Locks Software, Inc. X-Mailer: Mozilla 2.0 (Win95; U; 16bit) MIME-Version: 1.0 To: security@freebsd.org Subject: SUBSCRIBE freeBSD X-URL: http://www.sevenlocks.com/RecommendedSecuritySites.htm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk SUBSCRIBE freeBSD Yessiree! Please add newsfeed@sevenlocks.com to your remarkable, useful service. Thanks! And feel free to come visit our web site: http://www.sevenlocks.com From owner-freebsd-security Mon Jun 3 15:43:04 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA24209 for security-outgoing; Mon, 3 Jun 1996 15:43:04 -0700 (PDT) Received: from glitnir.cfar.UMD.EDU (glitnir.cfar.umd.edu [128.8.132.40]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA24195 for ; Mon, 3 Jun 1996 15:43:01 -0700 (PDT) Received: by glitnir.cfar.UMD.EDU (8.7.5/UMIACS-0.9/04-05-88) id SAA10718; Mon, 3 Jun 1996 18:42:57 -0400 (EDT) Message-Id: <199606032242.SAA10718@glitnir.cfar.UMD.EDU> To: "Mikael Karpberg" cc: freebsd-security@freebsd.org Subject: Re: MD5 Crack code In-reply-to: Your message of "Mon, 03 Jun 1996 16:35:08 +0200." <199606031435.QAA06701@sea.campus.luth.se> Date: Mon, 03 Jun 1996 18:42:56 -0400 From: He Who Urges Ampersands Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 03 Jun 1996 16:35:08 +0200, karpen@sea.campus.luth.se wrote: > > Personally I'd love to insist on Skey (or something like it). Seems to > > me that simply building clients (FTP, telnet, MUA's, etc.) that are > > "Skey aware" would go a long way. A separate Skey calculator is a > > level of "complexity" that many naive users seem to balk at. > > I'm not aware of how Skey works, I must say. Doesn't it require you to > remember one time passwords or something? Seems like a hassle. Please > feel free to correct me, since I'm surely a novice when it comes to that. :) No, you just have one password. The idea behind s/Key is to avoid having clear-text passwords transmitted over an insecure network. When you log in, the remote machine issues an s/Key challenge, which includes the "sequence number:" the remote machine keeps track of how many times you've successfully logged in. You then need to feed the s/Key challenge (including the sequence number) and your secret password to a local s/Key calculator. It then turns the whole thing into a one-time password, which you then give to the remote machine. Ordinarily, you need a local s/Key calculator handy, or else you need to print out a list of one-time passwords that you can carry around on you. Yes, this is something of a hassle. One hack that we use, which I'd like to include in FreeBSD's 'rlogin' and/or 'telnet', is that, if you type '~@', and the last N characters received from the remote end include an s/Key challenge, then the *local* 'rlogin' will prompt you for a password and run the s/Key calculator for you. In effect, instead of rlogin remotehost suspend key fg you only need to ~@ -- Andrew Arensburger, Systems guy Center for Automation Research arensb@cfar.umd.edu University of Maryland If this isn't war, why is CNN massing on the border? From owner-freebsd-security Mon Jun 3 15:46:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA24596 for security-outgoing; Mon, 3 Jun 1996 15:46:21 -0700 (PDT) Received: from ns1.zygaena.com (ns1.zygaena.com [206.148.80.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA24576 for ; Mon, 3 Jun 1996 15:46:15 -0700 (PDT) Received: (from nobody@localhost) by ns1.zygaena.com (8.7.5/8.7.3) id SAA08853; Mon, 3 Jun 1996 18:46:16 -0400 (EDT) X-Authentication-Warning: ns1.zygaena.com: nobody set sender to using -f Received: from selway.i.com(198.30.169.1) by ns1.zygaena.com via smap (V1.3) id sma008851; Mon Jun 3 18:45:53 1996 Received: (from ewb@localhost) by selway.i.com (8.7.3/8.7.3) id SAA02583; Mon, 3 Jun 1996 18:45:36 -0400 (EDT) Date: Mon, 3 Jun 1996 18:45:36 -0400 (EDT) From: Will Brown Message-Id: <199606032245.SAA02583@selway.i.com> To: angio@aros.net, karpen@sea.campus.luth.se Cc: freebsd-security@freebsd.org Subject: Re: MD5 Crack code Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dave Andersen said: > SecurID is a challenge/response one-time authentication system. You > log on, the system tells you the challenge, you enter the challenge in to > your SecurID calculator along with your calculator password, the calc. > hands you back a response, you type the response in, you're authenticated. > Good stuff for high-security applications. I thought the Security Dynamics card had only an LCD display and no keyboard. It generates a new password every minute. That plus a PIN are used to gain access. So you have to HAVE the card and KNOW the PIN - two factors. Exactly how it stays in time-sync with servers I don't know. Maybe there is more to it... (speak up folks). Yes unfortunately the target customer seems to be high-end security freaks (with $$), not ISPs and the ilk (sigh). This IS a quite accurate description of Skey though, except the "calculator" is a software application (with a resulting reduction in security). Has anyone built a credit-card SKey calculator? >> Why not simply something like SSL which is being developed and used a lot >> just because the WWW is growing with enormous speed? If you have a secure >> link, there is no need for a lot of hassle. You can send anything over the >> socket and it'll be safe. Umm.. No? IF there were SSL-enabled client applications such as FTP, telnet, POP/IMAP mail programs for *all* platforms (well, windoze, 95, NT, and MAC ) and not just for unix then that'd be great (Dave's comments below withstanding). But, the certificate issue and patent issues and legal issues associated with crypto solutions are real problems. I'm hunting for a real-today, practical password protection system, Not the be-all, end-all solution to all privacy and authentication issues. > There's still a difference between a one-time password system and a > constant password, and for security reasons, the one-time system is > preferable if you can abide by the inconvenience of having to use it. > Even if life is encrypted, there's always the off chance that someone > could: > a) steal the original password (social enginnering, actual theft, > hacking the password file) > b) Use some form of playback attack against the system, because the > password doesn't change. Yes, the encryption does, but it's one > more level of security. > > For best results, add water, and let rest for twenty minutes. Use both > encryption and a one-time password scheme. > > -Dave Andersen Skey (which is a one-time password scheme based on MD4) provides ONLY for authentication, not privacy. FreeBSD login already supports it BTW. I view it as weaker than a strong encryption approach but it has some big plusses - it is *not* crypto, so there are no Big Brother restrictions on its use in the Land of the Free (correct me if I'm wrong net.lawyers), and its a LOT simpler, AND it doesn't have to be inconvenient. If Skey's client side was implemented within the clients rather than as a separate calculator application (or hardware) then the clients would be no harder to use than they are now (login: password:) but the passwords would never be transmitted (in fact it would be safe to use one password for multiple servers, and there is nothing extra to remember). To be painfully pedantic, an FTP client (say) with Skey knowledge would observe the challenge (as opposed to normal login:), request the secret seed password from the user (user sees "password:") generate the one-time password using this info and complete the authentication. To the user it looks EXACTLY like a "normal" login. The problem is that there are no Skey clients, just as there are no SSL (or other crypto) clients, for all platforms. I think it would be a lot easier to build the Skey clients then the crypto clients. So why am I not doing it? Thought I'd see if anyone had already, or was contemplating doing so, or could be coerced into it first :) Actually, because re-inventing CuteFTP (eg) just to put in Skey seems silly. More practical to try and get client authors to incorporate Skey. IMHO that simple step away from cleartext passwords would be a big step forward for internet security. ------------------------============================----------------------- Will Brown ewb@zns.net Professional Web Design Zygaena Network Services http://www.zns.net and Hosting 216-381-6019 (voice) 216-381-6064 (fax) at reasonable prices From owner-freebsd-security Mon Jun 3 16:19:36 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA27442 for security-outgoing; Mon, 3 Jun 1996 16:19:36 -0700 (PDT) Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA27437 for ; Mon, 3 Jun 1996 16:19:31 -0700 (PDT) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <26195-0@bunyip.cc.uq.oz.au>; Tue, 4 Jun 1996 09:19:10 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id JAA09666; Tue, 4 Jun 1996 09:19:47 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id XAA17131; Mon, 3 Jun 1996 23:19:46 GMT Message-Id: <199606032319.XAA17131@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: Will Brown cc: security@freebsd.org Subject: Re: MD5 Crack code In-reply-to: Your message of "Mon, 03 Jun 1996 18:45:36 -0400." <199606032245.SAA02583@selway.i.com> X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jun 1996 09:19:44 +1000 From: Stephen Hocking Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Dave Andersen said: > > SecurID is a challenge/response one-time authentication system. You > > log on, the system tells you the challenge, you enter the challenge in to > > your SecurID calculator along with your calculator password, the calc. > > hands you back a response, you type the response in, you're authenticated. > > Good stuff for high-security applications. > > I thought the Security Dynamics card had only an LCD display and no > keyboard. It generates a new password every minute. That plus a PIN > are used to gain access. So you have to HAVE the card and KNOW the PIN > - two factors. Exactly how it stays in time-sync with servers I don't > know. Maybe there is more to it... (speak up folks). Yes > unfortunately the target customer seems to be high-end security > freaks (with $$), not ISPs and the ilk (sigh). > Yes, we must be one of those - my card is turning up in 3 weeks. It was prompted by me announcing to out network guys that I wanted to set up my FreeBSD machine as a PPP server - they freaked. Stephen -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-security Mon Jun 3 16:36:08 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA28107 for security-outgoing; Mon, 3 Jun 1996 16:36:08 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA28059 for ; Mon, 3 Jun 1996 16:35:20 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id JAA02746; Tue, 4 Jun 1996 09:26:10 +0930 From: Michael Smith Message-Id: <199606032356.JAA02746@genesis.atrad.adelaide.edu.au> Subject: Re: MD5 Crack codeu$ To: ewb@zns.net (Will Brown) Date: Tue, 4 Jun 1996 09:26:09 +0930 (CST) Cc: angio@aros.net, karpen@sea.campus.luth.se, freebsd-security@freebsd.org In-Reply-To: <199606032245.SAA02583@selway.i.com> from "Will Brown" at Jun 3, 96 06:45:36 pm 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 Will Brown stands accused of saying: > > I thought the Security Dynamics card had only an LCD display and no > keyboard. It generates a new password every minute. That plus a PIN > are used to gain access. So you have to HAVE the card and KNOW the PIN > - two factors. Exactly how it stays in time-sync with servers I don't > know. Maybe there is more to it... (speak up folks). Yes The way the local security freak described it to me the server will accept results that are either one early or one late, and uses the bias on these to calculate the drift in the clock on each card & thus keep in sync. There's certainly no keypad in any of what he described. > Will Brown ewb@zns.net Professional Web Design -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Mon Jun 3 16:44:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA28521 for security-outgoing; Mon, 3 Jun 1996 16:44:54 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA28514 for ; Mon, 3 Jun 1996 16:44:53 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA30637; Mon, 3 Jun 1996 19:44:35 -0400 Date: Mon, 3 Jun 1996 19:44:35 -0400 From: Garrett Wollman Message-Id: <9606032344.AA30637@halloran-eldar.lcs.mit.edu> To: Will Brown Cc: freebsd-security@FreeBSD.org Subject: Re: MD5 Crack code In-Reply-To: <199606032245.SAA02583@selway.i.com> References: <199606032245.SAA02583@selway.i.com> Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk < said: > To be painfully pedantic, an FTP client (say) with Skey knowledge > would observe the challenge (as opposed to normal login:), request the > secret seed password from the user (user sees "password:") generate > the one-time password using this info and complete the > authentication. To the user it looks EXACTLY like a "normal" login. Well, actually, you want to make it possible for the user to use her own calculator as well in case she is running the client over an insecure remote login. (E.g., when I deposit files from my development machine on freefall, I need to run the calculator on my desktop machine, not the (network-connected) development box.) The IETF is developing a follow-on to S/Key called ``OTP''. I don't know what state it is in right now, but I would hope that they are specifying standard mechanisms to communicate this information over TELNET and FTP connections. > The problem is that there are no Skey clients, just as there are no > SSL (or other crypto) clients, for all platforms. There are clients for Macs and PCs running DOS or Windoze. Those are the only real significant potential problem sources in most organizations... -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-security Mon Jun 3 22:36:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA17302 for security-outgoing; Mon, 3 Jun 1996 22:36:58 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA17296 for ; Mon, 3 Jun 1996 22:36:55 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id HAA00655; Tue, 4 Jun 1996 07:36:50 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id HAA08782; Tue, 4 Jun 1996 07:36:17 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.4/keltia-uucp-2.8) id BAA00415; Tue, 4 Jun 1996 01:12:13 +0200 (MET DST) From: Ollivier Robert Message-Id: <199606032312.BAA00415@keltia.freenix.fr> Subject: Re: MD5 Crack code To: ewb@zns.net (Will Brown) Date: Tue, 4 Jun 1996 01:12:12 +0200 (MET DST) Cc: angio@aros.net, karpen@sea.campus.luth.se, freebsd-security@freebsd.org In-Reply-To: <199606032245.SAA02583@selway.i.com> from Will Brown at "Jun 3, 96 06:45:36 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#2073 X-Mailer: ELM [version 2.4ME+ PL19 (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 It seems that Will Brown said: > keyboard. It generates a new password every minute. That plus a PIN > are used to gain access. So you have to HAVE the card and KNOW the PIN > - two factors. Exactly how it stays in time-sync with servers I don't > know. Maybe there is more to it... (speak up folks). Yes I think there are two versions: 1. one with a keyboard on which you type the challenge and time-based generator, 2. one with only a time-based generator, you type as password what is displayed at the time. > unfortunately the target customer seems to be high-end security > freaks (with $$), not ISPs and the ilk (sigh). I'm wary of the time synchronisation of the SecurID and prefer cryptographic based calculator (such as SecureNetKey and ActiveCard, although ActiveCard is getting worse in matter of usability these days). > in security). Has anyone built a credit-card SKey calculator? STEL, a secure-telnet program made by the italian CERT, has a built-in S/Key calculator which is vey handy. > below withstanding). But, the certificate issue and patent issues and > legal issues associated with crypto solutions are real problems. I agree. The X.509 based key system of SSL is hard to setup and you need to trust the CA... > Skey (which is a one-time password scheme based on MD4) provides ONLY There are versions of SSH using the more secure MD5 and OPIE, the successor of S/Key, can use either. > BTW. I view it as weaker than a strong encryption approach but it has some > big plusses - it is *not* crypto, so there are no Big Brother restrictions > on its use in the Land of the Free (correct me if I'm wrong net.lawyers), > and its a LOT simpler, AND it doesn't have to be inconvenient. It protects your password but not your session. I tend to think you close the door but open the window. I knwo cryptographic solutions have drawbacks (especially here in France) but you cannot go halfway. > Skey. IMHO that simple step away from cleartext passwords would be a > big step forward for internet security. Agreed. "No cleartext passwords thru the Internet" should be a motto for everyone. That's why I use SSH everywhere :-) -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #6: Tue Jun 4 00:25:26 MET DST 1996 From owner-freebsd-security Mon Jun 3 22:48:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA17959 for security-outgoing; Mon, 3 Jun 1996 22:48:59 -0700 (PDT) Received: from bdd.net ([207.61.78.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA17924; Mon, 3 Jun 1996 22:48:54 -0700 (PDT) Received: from localhost (james@localhost) by bdd.net (8.7.5/8.7.3) with SMTP id BAA06981; Tue, 4 Jun 1996 01:48:50 -0400 (EDT) Date: Tue, 4 Jun 1996 01:48:39 -0400 (EDT) From: James FitzGibbon To: security@freebsd.org cc: ports@freebsd.org Subject: Reply from the author of popper at Qualcomm (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I don't know if this thread from Bugtraq has found itself here yet; if so please disregard the vebosity of the message. The quick version of the thread is that Qualcomm's pop server (the "popper" port) can be fed an enourmous number of passwords, trying each in turn until one is successful without causing anything untoward in the logs. Qualcomm has reported that v2.2 of popper addresses these concerns as described below. The port of popper is still at v2.1.4.3, and as I understand it, is vulnerable. -- j. ---------------------------------------------------------------------------- | James FitzGibbon james@nexis.net | | Integrator, The Nexis Group Voice/Fax : 416 410-0100 | ---------------------------------------------------------------------------- ---------- Forwarded message ---------- Date: Mon, 3 Jun 1996 13:35:23 -0600 From: Pete Ashdown Reply-To: Bugtraq List To: Multiple recipients of list BUGTRAQ Subject: Reply from the author of popper at Qualcomm >From: mark@qualcomm.com (Mark Erikson) >Subject: Re: Not so much a bug as a warning of new brute force attack > (fwd) >Cc: "Brett L. Hawn" >Content-Type: text/plain; charset="us-ascii" >Content-Length: 2744 > > > Version 2.2 has some features you might find interesting. > > 1) it blocks access to UIDs less than 11 by default. > 2) if the login fails, it waits 15 seconds and then exits. > 3) it logs all failed login attempts. > > The only other thing I can think of is to add a database which checks > for a number of failed logins and then disable the account if the number > is reached. > > Now, with APOP one can create a longer pass phrase which will > be much more difficult to guess, but the password database will be > independant of the unix account. > > qpopper 2.2 can be retrieved from: > > > > Mark From owner-freebsd-security Tue Jun 4 08:24:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA20758 for security-outgoing; Tue, 4 Jun 1996 08:24:57 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA20734; Tue, 4 Jun 1996 08:24:40 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id IAA06221; Tue, 4 Jun 1996 08:23:26 -0700 (PDT) Message-Id: <199606041523.IAA06221@precipice.shockwave.com> To: James FitzGibbon cc: security@freebsd.org, ports@freebsd.org, pst@precipice.shockwave.com Subject: Re: Reply from the author of popper at Qualcomm (fwd) In-reply-to: Your message of "Tue, 04 Jun 1996 01:48:39 EDT." Date: Tue, 04 Jun 1996 08:23:26 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks, I've just been totally swamped with other things, I'll upgrade the port this week. Paul From owner-freebsd-security Tue Jun 4 11:52:53 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA04437 for security-outgoing; Tue, 4 Jun 1996 11:52:53 -0700 (PDT) Received: from throne.rau.lv (root@throne.rau.lv [159.148.112.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA04388; Tue, 4 Jun 1996 11:52:29 -0700 (PDT) Received: from throne.rau.lv (nick@throne.rau.lv [159.148.112.2]) by throne.rau.lv (8.7.5/8.7.3) with SMTP id VAA06800; Tue, 4 Jun 1996 21:51:41 +0300 (EET DST) Date: Tue, 4 Jun 1996 21:51:41 +0300 (EET DST) From: Nick Matyushenko To: Paul Traina cc: James FitzGibbon , security@FreeBSD.ORG, ports@FreeBSD.ORG, pst@precipice.shockwave.com Subject: Re: Reply from the author of popper at Qualcomm (fwd) In-Reply-To: <199606041523.IAA06221@precipice.shockwave.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 Thanks, just upgraded :) Nick. From owner-freebsd-security Tue Jun 4 12:52:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA08429 for security-outgoing; Tue, 4 Jun 1996 12:52:34 -0700 (PDT) Received: from okjunc.junction.net (root@okjunc.junction.net [199.166.227.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA08409; Tue, 4 Jun 1996 12:52:27 -0700 (PDT) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by okjunc.junction.net (8.6.11/8.6.11) with SMTP id MAA11202; Tue, 4 Jun 1996 12:08:15 -0700 Date: Tue, 4 Jun 1996 12:51:33 -0700 (PDT) From: Michael Dillon To: freebsd-security@freebsd.org cc: freebsd-questions@freebsd.org Subject: FWTK / BSD Checklist (fwd) Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Tue, 4 Jun 1996 13:36:42 -0500 (CDT) From: David Schnardthorst To: firewalls@GreatCircle.COM Subject: FWTK / BSD Checklist A few weeks ago, I answered some replies for people who were installing the Firewall Toolkit on FreeBSD. Due to the overwhelming responses from people interested in receiving this checklist, I have put it at the following URL, http://www.strydr.com/misc/checklists/fwtkchk.html. Thank You, ============================================================================ David Schnardthorst, Systems/Network Eng. * Phone: (314)838-6839 Stryder Communications, Inc. * Fax: (314)838-8527 869 St. Francois * E-Mail: ds3721@strydr.com Florissant, MO 63031 * URL: http://www.strydr.com ============================================================================ From owner-freebsd-security Tue Jun 4 17:31:04 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA25061 for security-outgoing; Tue, 4 Jun 1996 17:31:04 -0700 (PDT) Received: from apollo.intermind.com (apollo.intermind.com [206.40.151.25]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA25046 for ; Tue, 4 Jun 1996 17:30:34 -0700 (PDT) Received: from malkav.intermind.com ([206.40.150.122]) by apollo.intermind.com (post.office MTA v1.9.1 ID# 0-11400) with SMTP id AAA296 for ; Tue, 4 Jun 1996 17:34:28 -0700 Message-Id: <2.2.32.19960605002903.00ad00fc@intermind.com> X-Sender: jnoetzel@intermind.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Jun 1996 17:29:03 -0700 To: freebsd-security@freebsd.org From: jnoetzel@intermind.com (Jeremy Noetzelman) Subject: ISS Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does ISS offer a FreeBSD port, or something of the nature? Jeremy --- Jeremy Noetzelman jnoetzel@intermind.com Operations Specialist Intermind Corporation From owner-freebsd-security Tue Jun 4 17:50:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA25969 for security-outgoing; Tue, 4 Jun 1996 17:50:16 -0700 (PDT) Received: from einstein.technet.sg (ngps@einstein.technet.sg [192.169.33.50]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA25960 for ; Tue, 4 Jun 1996 17:50:14 -0700 (PDT) Received: (from ngps@localhost) by einstein.technet.sg (8.7.3/8.6.9) id IAA15482; Wed, 5 Jun 1996 08:50:10 +0800 (SST) Date: Wed, 5 Jun 1996 08:50:10 +0800 (SST) From: Ng Pheng Siong To: freebsd-security@freebsd.org Subject: Re: syslogd (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Apologies to those who have seen this already. - PS -- Ng Pheng Siong * Finger for PGP key. Pacific Internet Pte Ltd * Singapore 'The meek will inherit the earth, after the rest of us have gone to the stars.' - alt.2600 poster ---------- Forwarded message ---------- Date: Tue, 4 Jun 1996 12:49:16 -0400 From: Jeff Uphoff To: Multiple recipients of list BUGTRAQ Subject: Re: syslogd "PEM" == Perry E Metzger writes: >> >What solutions have people used to restrict which hosts can send stuff >> >to their syslogd? PEM> I hacked NetBSD's syslogd so that with an option it only opens the PEM> unix domain socket and not the UDP socket. The code is in the main PEM> NetBSD sources. Greg Wettstein's newest release (1.3) of syslogd for Linux does not do UDP-based logging unless it is specifically requested on the command-line. Its default mode now is to only do local logging. >From the README.1st file: * By default the syslog daemon doesn't accept any message from the syslog/udp port. To enable this add "-r" to the command-line arguments. Seems like more and more people are starting to worry about this. :)~ --Up. -- Jeff Uphoff - systems/network admin. | juphoff@nrao.edu National Radio Astronomy Observatory | juphoff@bofh.org.uk Charlottesville, VA, USA | jeff.uphoff@linux.org PGP key available at: http://www.cv.nrao.edu/~juphoff/ From owner-freebsd-security Wed Jun 5 14:46:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA08542 for security-outgoing; Wed, 5 Jun 1996 14:46:10 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA08530 for ; Wed, 5 Jun 1996 14:46:05 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id XAA05856; Wed, 5 Jun 1996 23:46:01 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id XAA24938; Wed, 5 Jun 1996 23:45:25 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.4/keltia-uucp-2.8) id IAA02083; Wed, 5 Jun 1996 08:45:41 +0200 (MET DST) From: Ollivier Robert Message-Id: <199606050645.IAA02083@keltia.freenix.fr> Subject: Re: ISS To: jnoetzel@intermind.com (Jeremy Noetzelman) Date: Wed, 5 Jun 1996 08:45:41 +0200 (MET DST) Cc: freebsd-security@freebsd.org In-Reply-To: <2.2.32.19960605002903.00ad00fc@intermind.com> from Jeremy Noetzelman at "Jun 4, 96 05:29:03 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#2073 X-Mailer: ELM [version 2.4ME+ PL19 (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 It seems that Jeremy Noetzelman said: > Does ISS offer a FreeBSD port, or something of the nature? I already asked about it in the beta mailing-list but no answer so far. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #6: Tue Jun 4 00:25:26 MET DST 1996 From owner-freebsd-security Thu Jun 6 09:08:56 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA12134 for security-outgoing; Thu, 6 Jun 1996 09:08:56 -0700 (PDT) Received: from mail.barrnet.net (mail.barrnet.net [131.119.246.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA12129 for ; Thu, 6 Jun 1996 09:08:51 -0700 (PDT) Received: from mail.torfree.net (danforth.torfree.net [199.71.188.17]) by mail.barrnet.net (8.7.5/MAIL-RELAY-LEN) with SMTP id JAA14989 for ; Thu, 6 Jun 1996 09:08:18 -0700 (PDT) Received: from bloor.torfree.net ([199.71.188.18]) by mail.torfree.net (/\==/\ Smail3.1.28.1 #28.6; 16-jun-94) via sendmail with smtp id for ; Thu, 6 Jun 96 12:04 EDT Received: by bloor.torfree.net (Smail3.1.28.1 #6) id m0uRhY6-0002RcC; Thu, 6 Jun 96 12:04 EDT Date: Thu, 6 Jun 1996 12:04:38 -0400 (EDT) From: David Frohlich Subject: Re: ISS To: Ollivier Robert cc: freebsd-security@freebsd.org In-Reply-To: <199606050645.IAA02083@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 5 Jun 1996, Ollivier Robert wrote: > It seems that Jeremy Noetzelman said: > > Does ISS offer a FreeBSD port, or something of the nature? > > I already asked about it in the beta mailing-list but no answer so far. > -- > Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr > FreeBSD keltia.freenix.fr 2.2-CURRENT #6: Tue Jun 4 00:25:26 MET DST 1996 > Theres a patch for ISS 1.3 in the directory /pub/ports (me thinks..) on ftp.iss.net. It patches ISS and NFSBug for FreeBSD From owner-freebsd-security Thu Jun 6 09:51:02 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA14570 for security-outgoing; Thu, 6 Jun 1996 09:51:02 -0700 (PDT) Received: from seine.cs.UMD.EDU (seine.cs.umd.edu [128.8.128.59]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA14564 for ; Thu, 6 Jun 1996 09:50:56 -0700 (PDT) Received: by seine.cs.UMD.EDU (8.7.5/UMIACS-0.9/04-05-88) id MAA05369; Thu, 6 Jun 1996 12:49:56 -0400 (EDT) Date: Thu, 6 Jun 1996 12:49:56 -0400 (EDT) From: rohit@cs.UMD.EDU (Rohit Dube) Message-Id: <199606061649.MAA05369@seine.cs.UMD.EDU> To: freebsd-security@freebsd.org Subject: Firewalls Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I was wondering if there are any reliable firewall products for FreeBSD : free or otherwise. I would appreciate any pointers. Thanks. --rohit. PS: I tried to look for Archives as I am pretty sure this is a FAQ but netscape was too slow ..... Forgive. From owner-freebsd-security Thu Jun 6 10:31:35 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA18568 for security-outgoing; Thu, 6 Jun 1996 10:31:35 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA18563 for ; Thu, 6 Jun 1996 10:31:34 -0700 (PDT) Received: from shogun.tdktca.com ([206.26.1.21]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id KAA22257 for ; Thu, 6 Jun 1996 10:31:33 -0700 Received: from shogun.tdktca.com (daemon@localhost) by shogun.tdktca.com (8.7.2/8.7.2) with ESMTP id MAA02864 for ; Thu, 6 Jun 1996 12:24:47 -0500 (CDT) Received: from orion.fa.tdktca.com ([163.49.131.130]) by shogun.tdktca.com (8.7.2/8.7.2) with SMTP id MAA02859 for ; Thu, 6 Jun 1996 12:24:46 -0500 (CDT) Received: from orion (alex@localhost [127.0.0.1]) by orion.fa.tdktca.com (8.6.12/8.6.9) with SMTP id MAA16302; Thu, 6 Jun 1996 12:29:01 -0500 Message-ID: <31B7155C.18C82B89@fa.tdktca.com> Date: Thu, 06 Jun 1996 12:29:00 -0500 From: Alex Nash Organization: TDK Factory Automation X-Mailer: Mozilla 2.0 (X11; I; Linux 1.2.13 i586) MIME-Version: 1.0 To: Rohit Dube CC: freebsd-security@freebsd.org Subject: Re: Firewalls References: <199606061649.MAA05369@seine.cs.UMD.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Rohit Dube wrote: > > Hi, > > I was wondering if there are any reliable firewall products for FreeBSD : > free or otherwise. > > I would appreciate any pointers. You can use FreeBSD's native firewall support, see: - ipfw(8) - section 6.4 of the FreeBSD Handbook http://www.freebsd.org/handbook/handbook71.html If you are using -stable, keep in mind that a lot of the information contained in the handbook (such as the syntax of ipfw) no longer applies. There's also the TIS Firewall Toolkit: http://www.tis.com Alex From owner-freebsd-security Thu Jun 6 12:08:30 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA26436 for security-outgoing; Thu, 6 Jun 1996 12:08:30 -0700 (PDT) Received: from mailhub.ASG.unb.ca ([198.164.16.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA26287 for ; Thu, 6 Jun 1996 12:08:00 -0700 (PDT) Received: from opie.ASG.unb.ca by mailhub.ASG.unb.ca (AIX 3.2/UCB 5.64/4.03) id AA36909; Thu, 6 Jun 1996 16:08:29 -0300 Date: Thu, 6 Jun 1996 16:08:29 -0300 (ADT) From: Peter Howlett To: Rohit Dube Cc: freebsd-security@freebsd.org Subject: Re: Firewalls In-Reply-To: <199606061649.MAA05369@seine.cs.UMD.EDU> 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, 6 Jun 1996, Rohit Dube wrote: > Hi, > > I was wondering if there are any reliable firewall products for FreeBSD : > free or otherwise. > > I would appreciate any pointers. The Atlantic Systems Group firewall TFS has recently been ported. (to 2.1R) I'm not sure if it is on the ASG home page yet or not. You can check it out at http://www.ASG.unb.ca -------------------------------------------------------------------- Peter Howlett Atlantic Systems Group E-Mail: Peter.Howlett@ASG.unb.ca Fredericton, N.B. Canada http://www.ASG.unb.ca/personal/ph.html Phone: (506) 447-3050 PGP Key ID: 60F2EEC1 Fax: (506) 453-5004 From owner-freebsd-security Thu Jun 6 12:44:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA29761 for security-outgoing; Thu, 6 Jun 1996 12:44:16 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA29753 for ; Thu, 6 Jun 1996 12:44:11 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id VAA08427; Thu, 6 Jun 1996 21:44:05 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id VAA00762; Thu, 6 Jun 1996 21:43:29 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.4/keltia-uucp-2.8) id TAA06911; Thu, 6 Jun 1996 19:08:20 +0200 (MET DST) From: Ollivier Robert Message-Id: <199606061708.TAA06911@keltia.freenix.fr> Subject: Re: ISS To: ag057@freenet.toronto.on.ca (David Frohlich) Date: Thu, 6 Jun 1996 19:08:19 +0200 (MET DST) Cc: freebsd-security@freebsd.org In-Reply-To: from David Frohlich at "Jun 6, 96 12:04:38 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#2073 X-Mailer: ELM [version 2.4ME+ PL19 (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 It seems that David Frohlich said: > Theres a patch for ISS 1.3 in the directory /pub/ports (me thinks..) on > ftp.iss.net. It patches ISS and NFSBug for FreeBSD Hmmm, I was talking about the commercial version (3.0) that just came out for beta testing (no source alas...). Making a port of 1.3 would be a good idea though. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #6: Tue Jun 4 00:25:26 MET DST 1996 From owner-freebsd-security Thu Jun 6 13:08:49 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA01922 for security-outgoing; Thu, 6 Jun 1996 13:08:49 -0700 (PDT) Received: from uu.elvisti.kiev.ua (acc0.elvisti.kiev.ua [193.125.28.132]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA01875 for ; Thu, 6 Jun 1996 13:08:22 -0700 (PDT) Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.129]) by uu.elvisti.kiev.ua (8.7.5/8.7.3) with ESMTP id XAA01273; Thu, 6 Jun 1996 23:12:58 +0300 (EET DST) Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id XAA15990; Thu, 6 Jun 1996 23:12:58 +0300 From: "Andrew V. Stesin" Message-Id: <199606062012.XAA15990@office.elvisti.kiev.ua> Subject: Re: Firewalls To: alex@fa.tdktca.com (Alex Nash) Date: Thu, 6 Jun 1996 23:12:57 +0300 (EET DST) Cc: rohit@cs.UMD.EDU, security@freebsd.org In-Reply-To: <31B7155C.18C82B89@fa.tdktca.com> from "Alex Nash" at Jun 6, 96 12:29:00 pm X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As for my own experience, I'm using IPfilter 3.0.4 in kernel mode and I'm really happy with it. Check http://coombs.anu.edu.au/~avalon -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 "You may delegate authority, but not responsibility." Frank's Management Rule #1. From owner-freebsd-security Fri Jun 7 05:39:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA11829 for security-outgoing; Fri, 7 Jun 1996 05:39:59 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA11810; Fri, 7 Jun 1996 05:39:54 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id FAA19708; Fri, 7 Jun 1996 05:39:23 -0700 (PDT) Message-Id: <199606071239.FAA19708@precipice.shockwave.com> To: security@freebsd.org cc: committer@freebsd.org, core@freebsd.org, hackers@freebsd.org Subject: FreeBSD's /var/mail permissions Date: Fri, 07 Jun 1996 05:39:22 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk General problem: Currently, /var/mail is set 0755 and mail.local is setuid root. Any program which needs to *create* a new file in /var/mail must be setuid root. Any program which wishes to manipulate a user mail file needs no special permissions (other than user permissions). I consider this a generic bug, even though there's a specific reason motivating me to change it. Specific problem: Previous versions of the popper port created a temporary file ".pop.username" in /var/mail as root, and then chowned the file over to the user. This was changed to avoid a potential race condition. The file creation is now done at user level. When I discussed this with the author of popper, he was adamant that /var/mail should be 1755 (ala 4.3BSD) or 775 with a group of mail (ala USG...barf). If popper were the only problem, I'd consider chosing a different directory for this temporary file to be created, such as /var/tmp. This leads to a new set of problems and I consider it less secure than maintaining the file in /var/mail as we have always done. Proposed solution: I'm considering creating group "mail" and going the setgid route, so that a program which creates files in /var/mail can be simply setgid mail. This is a well understood mail directory protection mechanism and employs the "principle of least privilege." Impact: Programs that expect the current semantics will still work just fine (we wouldn't need to change elm or mail.local). All we are doing is allowing setgid mail delivery programs create access to /var/mail. Comments? I hate changing permissions on such a vital hunk of FreeBSD without discussion. Please TRIM THE CC LINE and keep all discussion in security@freebsd.org as opposed to the other lists. Paul From owner-freebsd-security Fri Jun 7 06:07:39 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA13300 for security-outgoing; Fri, 7 Jun 1996 06:07:39 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA13295 for ; Fri, 7 Jun 1996 06:07:37 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id GAA28811; Fri, 7 Jun 1996 06:06:54 -0700 (PDT) Message-Id: <199606071306.GAA28811@precipice.shockwave.com> To: Garrett Wollman cc: Will Brown , freebsd-security@FreeBSD.org Subject: Re: MD5 Crack code In-reply-to: Your message of "Mon, 03 Jun 1996 19:44:35 EDT." <9606032344.AA30637@halloran-eldar.lcs.mit.edu> Date: Fri, 07 Jun 1996 06:06:52 -0700 From: Paul Traina Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk From: Garrett Wollman Subject: Re: MD5 Crack code < said: The IETF is developing a follow-on to S/Key called ``OTP''. I don't know what state it is in right now, but I would hope that they are specifying standard mechanisms to communicate this information over TELNET and FTP connections. Yes, it's still, IMO, kludgy (i.e. you have to look for the right strings, they're now just delimited with []'s as in [98 pr84849 required]) but the good news is they allow the use of SHA or MD5 in addition to the old MD4 in s/key. (nb: I dislike SHA for the same paranoid reasons I dislike 1-DES). I'd like opinions from folks about the switch to OTP. It's where we "should" be going, but there are a lot of utilities out there (such as Fetch for the Macintosh and our own tools) that finally understand and handle s/key properly, as well as windows/macos s/key calculators, and I really don't want to pull the rug out from under anyone. Unfortunately, because the mechanisms are so similar, but a "wee bit" different, it's really a choice of using one or the other unless someone wants to invest a LOT of work. From owner-freebsd-security Fri Jun 7 07:05:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA17011 for security-outgoing; Fri, 7 Jun 1996 07:05:16 -0700 (PDT) Received: from ns1.zygaena.com (ns1.zygaena.com [206.148.80.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA17000 for ; Fri, 7 Jun 1996 07:05:11 -0700 (PDT) Received: (from nobody@localhost) by ns1.zygaena.com (8.7.5/8.7.3) id KAA24788; Fri, 7 Jun 1996 10:05:07 -0400 (EDT) X-Authentication-Warning: ns1.zygaena.com: nobody set sender to using -f Received: from selway.i.com(198.30.169.1) by ns1.zygaena.com via smap (V1.3) id sma024783; Fri Jun 7 10:04:56 1996 Received: (from ewb@localhost) by selway.i.com (8.7.3/8.7.3) id KAA02891; Fri, 7 Jun 1996 10:04:52 -0400 (EDT) Date: Fri, 7 Jun 1996 10:04:52 -0400 (EDT) From: Will Brown Message-Id: <199606071404.KAA02891@selway.i.com> To: pst@shockwave.com Cc: freebsd-security@FreeBSD.org Subject: s/key and OTP [was: MD5 Crack code] Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Paul Traina wrote: > I'd like opinions from folks about the switch to OTP. It's where > we "should" be going, but there are a lot of utilities out there > (such as Fetch for the Macintosh and our own tools) that finally > understand and handle s/key properly, as well as windows/macos > s/key calculators, and I really don't want to pull the rug out from > under anyone. IF s/key is approaching "defacto standardization" then that process should be allowed to continue and OTP should go away. IMHO it is more important that a standard be established and rolled into the *many* different clients on multiple platforms, then to address the minor nits of the standard and thereby delay the arrival of any form of one-time password security. I will withdraw MHO if anyone points out an uncorrectable fatal flaw in s/key that is being addressed by OTP. Ok, md4 may not be as strong as md5, but it is so much better than cleartext that I'd rather have s/key now, then something slightly better N years from now. I like to keep in mind that none of the cryptographic algorithms based on NP hard or NP complete problems are proven secure. And that even if they were, flaws in implementations seem to be nearly impossible to prevent. Not to mention all the other potential ways to crack systems (Crack, social engineering, dumpster diving,...). These facts largely defeat arguments that one algorithm is much "better" than another, esp. as we desparately need to get away from cleartext passwords now. ------------------------============================----------------------- Will Brown ewb@zns.net Professional Web Design Zygaena Network Services http://www.zns.net and Hosting 216-381-6019 (voice) 216-381-6064 (fax) at reasonable prices From owner-freebsd-security Fri Jun 7 08:42:53 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA24505 for security-outgoing; Fri, 7 Jun 1996 08:42:53 -0700 (PDT) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA24493 for ; Fri, 7 Jun 1996 08:42:47 -0700 (PDT) Received: (from softweyr@localhost) by xmission.xmission.com (8.7.5/8.7.5) id JAA14520; Fri, 7 Jun 1996 09:42:09 -0600 (MDT) From: Barnacle Wes Message-Id: <199606071542.JAA14520@xmission.xmission.com> Subject: Re: FreeBSD's /var/mail permissions To: pst@shockwave.com (Paul Traina) Date: Fri, 7 Jun 1996 09:42:08 -0600 (MDT) Cc: security@freebsd.org In-Reply-To: <199606071239.FAA19708@precipice.shockwave.com> from "Paul Traina" at Jun 7, 96 05:39:22 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Proposed solution: > I'm considering creating group "mail" and going the setgid route, > so that a program which creates files in /var/mail can be simply > setgid mail. > > This is a well understood mail directory protection mechanism > and employs the "principle of least privilege." >From a security standpoint, this is a win. If it were only *one* less suid program, it probably wouldn't be worth bothering with, but with the number of MUAs on the average system these days (elm, pine, emacs, mh, xmh, netscape, various X mailers, etc) this is worth doing. Each of these can be changed from suid to sgid as someone is doing a port update. -- Wes Peters | Yes I am a pirate, two hundred years too late Softweyr | The cannons don't thunder, there's nothing to plunder Consulting | I'm an over forty victim of fate... softweyr@xmission.com | Jimmy Buffett From owner-freebsd-security Fri Jun 7 09:01:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA26540 for security-outgoing; Fri, 7 Jun 1996 09:01:01 -0700 (PDT) Received: from sivka.rdy.com (sivka.rdy.com [205.149.182.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA26527 for ; Fri, 7 Jun 1996 09:00:54 -0700 (PDT) Received: from dima@localhost by sivka.rdy.com id IAA03928; (8.7/RDY) Fri, 7 Jun 1996 08:48:17 -0700 (PDT) From: "Dima Ruban" Message-Id: <960607084817.ZM3926@sivka.rdy.com> Date: Fri, 7 Jun 1996 08:48:17 -0700 In-Reply-To: Paul Traina "FreeBSD's /var/mail permissions" (Jun 7, 5:39am) References: <199606071239.FAA19708@precipice.shockwave.com> Organization: HackerDome, Inc. X-Mailer: Z-Mail (4.0b.514 14may96) To: Paul Traina , security@FreeBSD.ORG Subject: Re: FreeBSD's /var/mail permissions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jun 7, 5:39am, Paul Traina wrote: > Subject: FreeBSD's /var/mail permissions > General problem: > Currently, /var/mail is set 0755 and mail.local is setuid root. > Any program which needs to *create* a new file in /var/mail must > be setuid root. Any program which wishes to manipulate a user mail > file needs no special permissions (other than user permissions). > > I consider this a generic bug, even though there's a specific > reason motivating me to change it. > > Specific problem: > Previous versions of the popper port created a temporary file > ".pop.username" in /var/mail as root, and then chowned the file > over to the user. This was changed to avoid a potential race > condition. The file creation is now done at user level. > > When I discussed this with the author of popper, he was adamant > that /var/mail should be 1755 (ala 4.3BSD) or 775 with a group > of mail (ala USG...barf). > > If popper were the only problem, I'd consider chosing a > different directory for this temporary file to be created, such > as /var/tmp. This leads to a new set of problems and I consider > it less secure than maintaining the file in /var/mail as we have > always done. > > Proposed solution: > I'm considering creating group "mail" and going the setgid route, > so that a program which creates files in /var/mail can be simply > setgid mail. Agreed. More than that, something like a year ago (maybe even more) I've created mail group and changed modes on /var/mail. It works just perfect and solve me whole bunch of problems. > > This is a well understood mail directory protection mechanism > and employs the "principle of least privilege." > > Impact: > Programs that expect the current semantics will still work just > fine (we wouldn't need to change elm or mail.local). All we > are doing is allowing setgid mail delivery programs create > access to /var/mail. > > Comments? > > I hate changing permissions on such a vital hunk of FreeBSD without > discussion. Please TRIM THE CC LINE and keep all discussion in > security@freebsd.org as opposed to the other lists. > > Paul > >-- End of excerpt from Paul Traina -- -- dima From owner-freebsd-security Fri Jun 7 09:35:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA29664 for security-outgoing; Fri, 7 Jun 1996 09:35:58 -0700 (PDT) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA29656 for ; Fri, 7 Jun 1996 09:35:46 -0700 (PDT) Received: by sovcom.kiae.su id AA23603 (5.65.kiae-1 for security@freebsd.org); Fri, 7 Jun 1996 19:24:54 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Fri, 7 Jun 96 19:24:54 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id UAA00541 for security@freebsd.org; Fri, 7 Jun 1996 20:19:03 +0400 (MSD) Message-Id: <199606071619.UAA00541@astral.msk.su> Subject: Re: FreeBSD's /var/mail permissions To: security@freebsd.org Date: Fri, 7 Jun 1996 20:19:02 +0400 (MSD) In-Reply-To: <199606071251.FAA25052@precipice.shockwave.com> from "Paul Traina" at "Jun 7, 96 05:51:50 am" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL19 (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 > If popper were the only problem, I'd consider chosing a > different directory for this temporary file to be created, such > as /var/tmp. This leads to a new set of problems and I consider > it less secure than maintaining the file in /var/mail as we have > always done. Not popper only is the problem, I remember that procmail and elm use this feature too (but can work without it too). It is common technique to create temporary mailbox in /var/mail and rename it to actual mailbox. This method avoid complex locking during rewriting window. > Proposed solution: > I'm considering creating group "mail" and going the setgid route, > so that a program which creates files in /var/mail can be simply > setgid mail. > > This is a well understood mail directory protection mechanism > and employs the "principle of least privilege." adduser program MUST create new user mailbox in this case to avoid pre-created mailboxes. Now it only send mail wich can be appended to pre-created mailbox. :-( -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Fri Jun 7 10:06:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA02373 for security-outgoing; Fri, 7 Jun 1996 10:06:48 -0700 (PDT) Received: from uu.elvisti.kiev.ua (acc0.elvisti.kiev.ua [193.125.28.132]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA02328 for ; Fri, 7 Jun 1996 10:06:09 -0700 (PDT) Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.129]) by uu.elvisti.kiev.ua (8.7.5/8.7.3) with ESMTP id TAA26791; Fri, 7 Jun 1996 19:54:48 +0300 (EET DST) Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id TAA24303; Fri, 7 Jun 1996 19:54:47 +0300 From: "Andrew V. Stesin" Message-Id: <199606071654.TAA24303@office.elvisti.kiev.ua> Subject: Re: FreeBSD's /var/mail permissions To: dima@sivka.rdy.com (Dima Ruban) Date: Fri, 7 Jun 1996 19:54:47 +0300 (EET DST) Cc: pst@shockwave.com, security@FreeBSD.ORG In-Reply-To: <960607084817.ZM3926@sivka.rdy.com> from "Dima Ruban" at Jun 7, 96 08:48:17 am X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk # > Proposed solution: # > I'm considering creating group "mail" and going the setgid route, # > so that a program which creates files in /var/mail can be simply # > setgid mail. # # Agreed. More than that, something like a year ago (maybe even more) # I've created mail group and changed modes on /var/mail. It works just perfect # and solve me whole bunch of problems. While you men are on the topic, what about a group "logger" and have /dev/log be 0660 root:logger? instead of 666 root:wheel? (daemon should belong to logger, too) -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 "You may delegate authority, but not responsibility." Frank's Management Rule #1. From owner-freebsd-security Fri Jun 7 10:26:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03827 for security-outgoing; Fri, 7 Jun 1996 10:26:58 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA03820 for ; Fri, 7 Jun 1996 10:26:52 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id KAA01419; Fri, 7 Jun 1996 10:25:37 -0700 (PDT) Message-Id: <199606071725.KAA01419@precipice.shockwave.com> To: Barnacle Wes cc: security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Fri, 07 Jun 1996 09:42:08 MDT." <199606071542.JAA14520@xmission.xmission.com> Date: Fri, 07 Jun 1996 10:25:37 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Correction: Most MUAs do not need write access to this directory, so they are not SUID root. They just work on the files. From: Barnacle Wes Subject: Re: FreeBSD's /var/mail permissions > Proposed solution: > I'm considering creating group "mail" and going the setgid route, > so that a program which creates files in /var/mail can be simply > setgid mail. > > This is a well understood mail directory protection mechanism > and employs the "principle of least privilege." From a security standpoint, this is a win. If it were only *one* less suid program, it probably wouldn't be worth bothering with, but with the number of MUAs on the average system these days (elm, pine, emacs, mh, xmh, netscape, various X mailers, etc) this is worth doing. Each of these can be changed from suid to sgid as someone is doing a port update. -- Wes Peters | Yes I am a pirate, two hundred years too late Softweyr | The cannons don't thunder, there's nothing to plunder Consulting | I'm an over forty victim of fate... softweyr@xmission.com | Jimmy Buffett From owner-freebsd-security Fri Jun 7 10:28:13 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03988 for security-outgoing; Fri, 7 Jun 1996 10:28:13 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA03980 for ; Fri, 7 Jun 1996 10:28:11 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id KAA01470; Fri, 7 Jun 1996 10:27:22 -0700 (PDT) Message-Id: <199606071727.KAA01470@precipice.shockwave.com> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Fri, 07 Jun 1996 20:19:02 +0400." <199606071619.UAA00541@astral.msk.su> Date: Fri, 07 Jun 1996 10:27:21 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm confused, why do you say adduser must create new user mailbox? Mail.local is already suid root and adduser should deliver a preformatted mail message with mail.local. Paul From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chern >>ov, Black Mage) Subject: Re: FreeBSD's /var/mail permissions > If popper were the only problem, I'd consider chosing a > different directory for this temporary file to be created, such > as /var/tmp. This leads to a new set of problems and I consider > it less secure than maintaining the file in /var/mail as we have > always done. Not popper only is the problem, I remember that procmail and elm use this feature too (but can work without it too). It is common technique to create temporary mailbox in /var/mail and rename it to actual mailbox. This method avoid complex locking during rewriting window. > Proposed solution: > I'm considering creating group "mail" and going the setgid route, > so that a program which creates files in /var/mail can be simply > setgid mail. > > This is a well understood mail directory protection mechanism > and employs the "principle of least privilege." adduser program MUST create new user mailbox in this case to avoid pre-created mailboxes. Now it only send mail wich can be appended to pre-created mailbox. :-( -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Fri Jun 7 12:50:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA15902 for security-outgoing; Fri, 7 Jun 1996 12:50:41 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA15897 for ; Fri, 7 Jun 1996 12:50:39 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id MAA29698 for ; Fri, 7 Jun 1996 12:50:38 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id NAA00227; Fri, 7 Jun 1996 13:48:21 -0600 Date: Fri, 7 Jun 1996 13:48:21 -0600 From: Nate Williams Message-Id: <199606071948.NAA00227@rocky.sri.MT.net> To: Paul Traina Cc: Barnacle Wes , security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: <199606071725.KAA01419@precipice.shockwave.com> References: <199606071542.JAA14520@xmission.xmission.com> <199606071725.KAA01419@precipice.shockwave.com> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Correction: Most MUAs do not need write access to this directory, > so they are not SUID root. They just work on the files. Corretion: Actually, *most* MUA's that I'm aware of need write access to the directory if they plan on doing any sort of mailbox locking, which most decent MUA do. Nate From owner-freebsd-security Fri Jun 7 14:07:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21389 for security-outgoing; Fri, 7 Jun 1996 14:07:31 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA21381 for ; Fri, 7 Jun 1996 14:07:27 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id PAA00612; Fri, 7 Jun 1996 15:07:19 -0600 Date: Fri, 7 Jun 1996 15:07:19 -0600 From: Nate Williams Message-Id: <199606072107.PAA00612@rocky.sri.MT.net> To: Paul Traina Cc: Nate Williams , Barnacle Wes , security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: <199606072105.OAA00533@precipice.shockwave.com> References: <199606071948.NAA00227@rocky.sri.MT.net> <199606072105.OAA00533@precipice.shockwave.com> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Mail locking, to be effective, must be soley performed through the use of > the flock() call on the mail file itself. > > Locking schemes relying on other mechanisms are not effective. Locking schemes relying on flock() are not effective either, so that's why most MUA's I know of use lock files. You'll have to convince *them* that flock() is adequate, although I've yet to be convinced as well. 'flock()' is broken on too many systems to be considered reliable. Nate From owner-freebsd-security Fri Jun 7 14:07:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21414 for security-outgoing; Fri, 7 Jun 1996 14:07:45 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA21408 for ; Fri, 7 Jun 1996 14:07:42 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id OAA00533; Fri, 7 Jun 1996 14:05:23 -0700 (PDT) Message-Id: <199606072105.OAA00533@precipice.shockwave.com> To: Nate Williams cc: Barnacle Wes , security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Fri, 07 Jun 1996 13:48:21 MDT." <199606071948.NAA00227@rocky.sri.MT.net> Date: Fri, 07 Jun 1996 14:05:23 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mail locking, to be effective, must be soley performed through the use of the flock() call on the mail file itself. Locking schemes relying on other mechanisms are not effective. Sorry. From: Nate Williams Subject: Re: FreeBSD's /var/mail permissions > Correction: Most MUAs do not need write access to this directory, > so they are not SUID root. They just work on the files. Corretion: Actually, *most* MUA's that I'm aware of need write access to the directory if they plan on doing any sort of mailbox locking, which most decent MUA do. Nate From owner-freebsd-security Fri Jun 7 14:23:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22691 for security-outgoing; Fri, 7 Jun 1996 14:23:45 -0700 (PDT) Received: from zed.ludd.luth.se (root@zed.ludd.luth.se [130.240.16.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA22678 for ; Fri, 7 Jun 1996 14:23:39 -0700 (PDT) Received: from father.ludd.luth.se (father.ludd.luth.se [130.240.16.18]) by zed.ludd.luth.se (8.7.5/8.7.2) with ESMTP id XAA10435; Fri, 7 Jun 1996 23:23:19 +0200 Received: (pantzer@localhost) by father.ludd.luth.se (8.6.11/8.6.11) id XAA10448; Fri, 7 Jun 1996 23:22:55 +0200 Date: Fri, 7 Jun 1996 23:22:54 +0200 (MET DST) From: Mattias Pantzare To: Paul Traina cc: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= , security@FreeBSD.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: <199606071727.KAA01470@precipice.shockwave.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 > I'm confused, why do you say adduser must create new user mailbox? > Mail.local is already suid root and adduser should deliver a preformatted > mail message with mail.local. Why should adduser send any mail to anybody? Rather silly if you ask me. From owner-freebsd-security Fri Jun 7 14:30:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA23386 for security-outgoing; Fri, 7 Jun 1996 14:30:59 -0700 (PDT) Received: from critter.tfs.com ([140.145.16.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA23371; Fri, 7 Jun 1996 14:30:56 -0700 (PDT) Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id OAA00825; Fri, 7 Jun 1996 14:29:50 -0700 (PDT) To: Paul Traina cc: Nate Williams , Barnacle Wes , security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Fri, 07 Jun 1996 14:05:23 PDT." <199606072105.OAA00533@precipice.shockwave.com> Date: Fri, 07 Jun 1996 14:29:50 -0700 Message-ID: <823.834182990@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199606072105.OAA00533@precipice.shockwave.com>, Paul Traina writes: >Mail locking, to be effective, must be soley performed through the use of >the flock() call on the mail file itself. > >Locking schemes relying on other mechanisms are not effective. say what ? I'd better read up man the manpages for rename(2) to see what changed there... What do you mean when you say "not effective" ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Fri Jun 7 14:42:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24780 for security-outgoing; Fri, 7 Jun 1996 14:42:18 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA24764 for ; Fri, 7 Jun 1996 14:42:10 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id XAA13379; Fri, 7 Jun 1996 23:42:06 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id XAA05614; Fri, 7 Jun 1996 23:41:41 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.4/keltia-uucp-2.8) id VAA18214; Fri, 7 Jun 1996 21:26:42 +0200 (MET DST) From: Ollivier Robert Message-Id: <199606071926.VAA18214@keltia.freenix.fr> Subject: Re: s/key and OTP [was: MD5 Crack code] To: ewb@zns.net (Will Brown) Date: Fri, 7 Jun 1996 21:26:41 +0200 (MET DST) Cc: pst@shockwave.com, freebsd-security@freebsd.org In-Reply-To: <199606071404.KAA02891@selway.i.com> from Will Brown at "Jun 7, 96 10:04:52 am" X-Operating-System: FreeBSD 2.2-CURRENT ctm#2084 X-Mailer: ELM [version 2.4ME+ PL19 (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 It seems that Will Brown said: > IF s/key is approaching "defacto standardization" then that process > should be allowed to continue and OTP should go away. IMHO it is more > important that a standard be established and rolled into the *many* AFAIK S/Key -- the one from Bellcore -- is dead. Some guys in the US Navy have taken over it and now release OPIE (look on ftp.nrl.navy.mil). It is the same as S/Key although there are more features (see below) It conforms to the OTP defined by the IETF and is compatible with S/Key in MD4 mode. 6 May 1996 169.3 Ko /sources/security/passwd/opie-2.21.tar.gz Here is an extract from the README: OPIE Software Distribution, Release 2.21 Important Information ======================================== ===================== Introduction ============ "One-time Passwords In Everything" (OPIE) is a freely distributable software package originally developed at and for the US Naval Research Laboratory (NRL). Recent versions are the result of a cooperative effort between of NRL, several of the original NRL authors, The Inner Net, and many other contributors from the Internet community. OPIE is an implementation of the One-Time Password (OTP) System that is being considered for the Internet standards-track. OPIE provides a one-time password system. The system should be secure against the passive attacks now commonplace on the Internet (see RFC 1704 for more details). The system is vulnerable to active dictionary attacks, though these are not widespread at present and can be detected through proper use of system audit software. OPIE is primarily written for UNIX-like operating systems, but we are working to make applicable portions portable to other operating systems. The OPIE software is derived in part from and is fully interoperable with the Bell Communications Research (Bellcore) S/Key Release 1 software. Because Bellcore claims "S/Key" as a trademark for their software, NRL was forced to use a different name (we picked "OPIE") for this software distribution. OPIE includes the following additions/modifications to the original Bellcore S/Key(tm) Version 1 software: * Just about one-command installation for many common platforms. While we still recommend that you follow instructions and test things by hand, the more adventurous can install OPIE quickly. * A modified BSD FTP daemon that does OPIE. The small and simple BSD ftpd(8) was deliberately chosen over the wuarchive ftpd(8) because we didn't have the time needed to convince ourselves that the wuarchive ftpd(8) didn't have any security holes lurking in its many extra features. * By default, the "su" binary always gives you an OPIE challenge, even on the console. This was a hole for rlogin/telnet sessions in the original S/Key software. * MD5 support. MD5 is now the default algorithm, though MD4 is still supported by changing a parameter in the Makefile. This change was made because MD5 is widely believed to be cryptographically stronger than MD4 (see RFC 1321). * A more portable version of MD4 has been substituted for the original MD4. This should solve many of the endian problems. * Most of the system-dependencies have been moved to a new file "opie_cfg.h". * Configuration options have been moved to the Makefile. * Isolated system dependencies (e.g. BSDisms) with appropriate #ifdefs. * Revised the opiekey(1) program to simultaneously support MD4 and MD5, with the default algorithm being tunable using the MDX symbol in the Makefile. * More operating systems are supported by recent versions of OPIE, but older BSD systems that aren't close to being compliant with the POSIX standard are no longer supported. * Transition mechanisms are optional to prevent potential back doors. * On systems using the /etc/opieaccess transition mechanism, users can choose to require the use of OPIE to login to their accounts when it would otherwise be optional. * Bug fixes * Cosmetic changes * Prompts (optionally) identify specifically what kind of entry (system password, secret pass phrase, or OTP response) is allowed. * Changes to mostly conform with the draft Internet OTP standard. * Optional autoconf support -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #7: Thu Jun 6 20:43:22 MET DST 1996 From owner-freebsd-security Fri Jun 7 14:48:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA25564 for security-outgoing; Fri, 7 Jun 1996 14:48:16 -0700 (PDT) Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA25554 for ; Fri, 7 Jun 1996 14:48:11 -0700 (PDT) Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by kitten.mcs.com (8.7.5/8.6.9) with SMTP id QAA16627; Fri, 7 Jun 1996 16:48:02 -0500 (CDT) Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Fri, 7 Jun 96 16:48 CDT Message-Id: Subject: Re: FreeBSD's /var/mail permissions To: pst@shockwave.com (Paul Traina) Date: Fri, 7 Jun 1996 16:48:01 -0500 (CDT) From: "Karl Denninger, MCSNet" Cc: nate@sri.MT.net, softweyr@xmission.com, security@FreeBSD.org In-Reply-To: <199606072105.OAA00533@precipice.shockwave.com> from "Paul Traina" at Jun 7, 96 02:05:23 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Mail locking, to be effective, must be soley performed through the use of > the flock() call on the mail file itself. > > Locking schemes relying on other mechanisms are not effective. > > Sorry. Mail locking, to be effective, must *work across machines* so that NFS mounts of the mail directory work. flock() cannot be trusted to work in this environment, and in fact doesn't even attempt to work on FreeBSD. Does this mean we should give up on using mail? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | T1 from $600 monthly; speeds to DS-3 available Voice: [+1 312 803-MCS1] | 21 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net/ ISDN - Get it here TODAY! | Home of Chicago's only FULL Clarinet feed! From owner-freebsd-security Fri Jun 7 14:50:50 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA25897 for security-outgoing; Fri, 7 Jun 1996 14:50:50 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA25876 for ; Fri, 7 Jun 1996 14:50:46 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id PAA00803; Fri, 7 Jun 1996 15:50:41 -0600 Date: Fri, 7 Jun 1996 15:50:41 -0600 From: Nate Williams Message-Id: <199606072150.PAA00803@rocky.sri.MT.net> To: "Karl Denninger, MCSNet" Cc: pst@shockwave.com (Paul Traina), security@FreeBSD.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: References: <199606072105.OAA00533@precipice.shockwave.com> Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Karl Denninger writes: > > Mail locking, to be effective, must be soley performed through the use of > > the flock() call on the mail file itself. > > > > Locking schemes relying on other mechanisms are not effective. > > > > Sorry. > > Mail locking, to be effective, must *work across machines* so that NFS > mounts of the mail directory work. > > flock() cannot be trusted to work in this environment, and in fact doesn't > even attempt to work on FreeBSD. > > Does this mean we should give up on using mail? Actually, *nothing* works reliably across NFS locks if you don't have lockd, and since FreeBSD doesn't (yet) have lockd you shouldn't have mailboxes that can be written to by multiple processes on different systems. There are *VERY* few systems (including most of Sun's) that implement reliable NFS file-locking well. Sun attempted it many times and failed. :( Nate From owner-freebsd-security Fri Jun 7 15:35:14 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA29849 for security-outgoing; Fri, 7 Jun 1996 15:35:14 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA29836 for ; Fri, 7 Jun 1996 15:35:11 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id PAA00814; Fri, 7 Jun 1996 15:34:04 -0700 (PDT) Message-Id: <199606072234.PAA00814@precipice.shockwave.com> To: Nate Williams cc: Barnacle Wes , security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Fri, 07 Jun 1996 15:07:19 MDT." <199606072107.PAA00612@rocky.sri.MT.net> Date: Fri, 07 Jun 1996 15:34:04 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Their locking systems are irrelevant if they do not cooperate with mail.local. From: Nate Williams Subject: Re: FreeBSD's /var/mail permissions > Mail locking, to be effective, must be soley performed through the use of > the flock() call on the mail file itself. > > Locking schemes relying on other mechanisms are not effective. Locking schemes relying on flock() are not effective either, so that's why most MUA's I know of use lock files. You'll have to convince *them* that flock() is adequate, although I've yet to be convinced as well. 'flock()' is broken on too many systems to be considered reliable. Nate From owner-freebsd-security Fri Jun 7 15:35:27 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA29903 for security-outgoing; Fri, 7 Jun 1996 15:35:27 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA29890 for ; Fri, 7 Jun 1996 15:35:24 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id QAA01040; Fri, 7 Jun 1996 16:35:15 -0600 Date: Fri, 7 Jun 1996 16:35:15 -0600 From: Nate Williams Message-Id: <199606072235.QAA01040@rocky.sri.MT.net> To: Paul Traina Cc: Nate Williams , Barnacle Wes , security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: <199606072234.PAA00814@precipice.shockwave.com> References: <199606072107.PAA00612@rocky.sri.MT.net> <199606072234.PAA00814@precipice.shockwave.com> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Their locking systems are irrelevant if they do not cooperate with > mail.local. See PHK's recent email. Renaming the file to something else (in /var/mail) is a *real* effective way of making sure you lock the file. :) Nate From owner-freebsd-security Fri Jun 7 15:40:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA00318 for security-outgoing; Fri, 7 Jun 1996 15:40:09 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA00307 for ; Fri, 7 Jun 1996 15:40:05 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id PAA00884; Fri, 7 Jun 1996 15:36:44 -0700 (PDT) Message-Id: <199606072236.PAA00884@precipice.shockwave.com> To: "Karl Denninger, MCSNet" cc: nate@sri.MT.net, softweyr@xmission.com, security@FreeBSD.org Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Fri, 07 Jun 1996 16:48:01 CDT." Date: Fri, 07 Jun 1996 15:36:43 -0700 From: Paul Traina Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Karl, I'm saying that mail.local uses flock(). It does not respect lock files created by other programs. If you want to do something weird because NFS doesn't support locks, be my guest. But if you think it works out of the box, you're wrong. Paul From: "Karl Denninger, MCSNet" Subject: Re: FreeBSD's /var/mail permissions > Mail locking, to be effective, must be soley performed through the use of > the flock() call on the mail file itself. > > Locking schemes relying on other mechanisms are not effective. > > Sorry. Mail locking, to be effective, must *work across machines* so that NFS mounts of the mail directory work. flock() cannot be trusted to work in this environment, and in fact doesn't even attempt to work on FreeBSD. Does this mean we should give up on using mail? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | T1 from $600 monthly; speeds to DS-3 available Voice: [+1 312 803-MCS1] | 21 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.ne >>t/ ISDN - Get it here TODAY! | Home of Chicago's only FULL Clarinet feed! From owner-freebsd-security Fri Jun 7 15:41:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA00400 for security-outgoing; Fri, 7 Jun 1996 15:41:46 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA00395 for ; Fri, 7 Jun 1996 15:41:43 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id PAA00959; Fri, 7 Jun 1996 15:38:41 -0700 (PDT) Message-Id: <199606072238.PAA00959@precipice.shockwave.com> To: Nate Williams cc: Barnacle Wes , security@freebsd.org Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Fri, 07 Jun 1996 16:35:15 MDT." <199606072235.QAA01040@rocky.sri.MT.net> Date: Fri, 07 Jun 1996 15:38:40 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ah, good point. I didn't think someone would actually yank the file out from under mail.local. Cough... hand me dunce cap for assuming all the world was as stupid as elm. Paul From: Nate Williams Subject: Re: FreeBSD's /var/mail permissions > Their locking systems are irrelevant if they do not cooperate with > mail.local. See PHK's recent email. Renaming the file to something else (in /var/mail) is a *real* effective way of making sure you lock the file. :) Nate From owner-freebsd-security Fri Jun 7 15:42:08 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA00439 for security-outgoing; Fri, 7 Jun 1996 15:42:08 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA00429 for ; Fri, 7 Jun 1996 15:42:03 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id PAA01013; Fri, 7 Jun 1996 15:40:17 -0700 (PDT) Message-Id: <199606072240.PAA01013@precipice.shockwave.com> To: Ollivier Robert cc: ewb@zns.net (Will Brown), freebsd-security@freebsd.org Subject: Re: s/key and OTP [was: MD5 Crack code] In-reply-to: Your message of "Fri, 07 Jun 1996 21:26:41 +0200." <199606071926.VAA18214@keltia.freenix.fr> Date: Fri, 07 Jun 1996 15:40:17 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It *is* compatible with S/Key in MD4 mode? If so, then it's reasonable for us to incorporate their sources once it becomes stable. Given the recent change date on the file...stability is a question, no? Paul From: Ollivier Robert Subject: Re: s/key and OTP [was: MD5 Crack code] It seems that Will Brown said: > IF s/key is approaching "defacto standardization" then that process > should be allowed to continue and OTP should go away. IMHO it is more > important that a standard be established and rolled into the *many* AFAIK S/Key -- the one from Bellcore -- is dead. Some guys in the US Navy have taken over it and now release OPIE (look on ftp.nrl.navy.mil). It is the same as S/Key although there are more features (see below) It conforms to the OTP defined by the IETF and is compatible with S/Key in MD4 mode. 6 May 1996 169.3 Ko /sources/security/passwd/opie-2.21.tar.gz Here is an extract from the README: OPIE Software Distribution, Release 2.21 Important Informati >>on ======================================== =================== >>== Introduction ============ "One-time Passwords In Everything" (OPIE) is a freely distributable software package originally developed at and for the US Naval Research Laboratory (NRL). Recent versions are the result of a cooperative effort between of NRL, several of the original NRL authors, The Inner Net, and many other contributors from the Internet community. OPIE is an implementation of the One-Time Password (OTP) System that is being considered for the Internet standards-track. OPIE provides a one-tim >>e password system. The system should be secure against the passive attacks now commonplace on the Internet (see RFC 1704 for more details). The system is vulnerable to active dictionary attacks, though these are not widespread at present and can be detected through proper use of system audit software. OPIE is primarily written for UNIX-like operating systems, but we are working to make applicable portions portable to other operating system >>s. The OPIE software is derived in part from and is fully interoperable with the Bell Communications Research (Bellcore) S/Key Release 1 software. Because Bellcore claims "S/Key" as a trademark for their software, NRL was forced to use a different name (we picked "OPIE") for this software distribution. OPIE includes the following additions/modifications to the original Bellcore S/Key(tm) Version 1 software: * Just about one-command installation for many common platforms. While we still recommend that you follow instructions and test things by hand, the more adventurous can install OPIE quickly. * A modified BSD FTP daemon that does OPIE. The small and simple BSD ftpd(8) was deliberately chosen over the wuarchive ftpd(8) because we didn't have the time needed to convince ourselves that the wuarchive ftpd(8) didn't hav >>e any security holes lurking in its many extra features. * By default, the "su" binary always gives you an OPIE challenge, even on the console. This was a hole for rlogin/telnet sessions in the original S/Key software. * MD5 support. MD5 is now the default algorithm, though MD4 is still supporte >>d by changing a parameter in the Makefile. This change was made because MD5 i >>s widely believed to be cryptographically stronger than MD4 (see RFC 1321). * A more portable version of MD4 has been substituted for the original MD4. This should solve many of the endian problems. * Most of the system-dependencies have been moved to a new file "opie_cfg.h". * Configuration options have been moved to the Makefile. * Isolated system dependencies (e.g. BSDisms) with appropriate #ifdefs. * Revised the opiekey(1) program to simultaneously support MD4 and MD5, with the default algorithm being tunable using the MDX symbol in the Makefile. * More operating systems are supported by recent versions of OPIE, but older BSD systems that aren't close to being compliant with the POSIX standard ar >>e no longer supported. * Transition mechanisms are optional to prevent potential back doors. * On systems using the /etc/opieaccess transition mechanism, users can choose to require the use of OPIE to login to their accounts when it would otherwise be optional. * Bug fixes * Cosmetic changes * Prompts (optionally) identify specifically what kind of entry (system password, secret pass phrase, or OTP response) is allowed. * Changes to mostly conform with the draft Internet OTP standard. * Optional autoconf support -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #7: Thu Jun 6 20:43:22 MET DST 1996 From owner-freebsd-security Fri Jun 7 17:05:40 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA06750 for security-outgoing; Fri, 7 Jun 1996 17:05:40 -0700 (PDT) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA06739 for ; Fri, 7 Jun 1996 17:05:34 -0700 (PDT) Received: (from root@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) id RAA00413; Fri, 7 Jun 1996 17:05:29 -0700 Date: Fri, 7 Jun 1996 17:05:25 -0700 (PDT) From: Steve Reid To: freebsd-security@freebsd.org Subject: MD5 broken In-Reply-To: <199606071926.VAA18214@keltia.freenix.fr> 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, 7 Jun 1996, Ollivier Robert wrote: > Here is an extract from the README: > OPIE Software Distribution, Release 2.21 [snip] > * MD5 support. MD5 is now the default algorithm, though MD4 is still supported > by changing a parameter in the Makefile. This change was made because MD5 is > widely believed to be cryptographically stronger than MD4 (see RFC 1321). Sorry if I'm digging up a dead topic, but is everyone here aware that MD5 has been broken? About a month ago, Hans Dobbertin showed that he could generate MD5 collisions in just 10 hours on a Pentium PC. This is the same guy who presented a cryptanalysis of MD4 at the Fast Software Encryption workshop earlier this year. I'll put the PostScript document on my web server and hope I'm not violating any copyright laws... If you want it, the URL is http://www.edmweb.com/dobbertin.ps I'm not sure if this would affect hashed passwords, where an attacker has a hash but not a plaintext... This would certainly affect systems that uses MD5 hashes to check for tampering, such as PGP signatures and MD5 hashes used to verify binaries. ===================================================================== | Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/) | | Email: steve@edmweb.com Home Page: http://www.edmweb.com/steve/ | | PGP (2048/9F317269) Fingerprint: 11C89D1CD67287E68C09EC52443F8830 | | -- Disclaimer: JMHO, YMMV, TANSTAAFL, IANAL. -- | ===================================================================:) From owner-freebsd-security Fri Jun 7 17:50:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA10721 for security-outgoing; Fri, 7 Jun 1996 17:50:31 -0700 (PDT) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA10714 for ; Fri, 7 Jun 1996 17:50:27 -0700 (PDT) Received: (from softweyr@localhost) by xmission.xmission.com (8.7.5/8.7.5) id SAA15535; Fri, 7 Jun 1996 18:50:13 -0600 (MDT) From: Barnacle Wes Message-Id: <199606080050.SAA15535@xmission.xmission.com> Subject: Re: FreeBSD's /var/mail permissions To: pst@shockwave.com (Paul Traina) Date: Fri, 7 Jun 1996 18:50:12 -0600 (MDT) Cc: security@freebsd.org In-Reply-To: <199606072105.OAA00533@precipice.shockwave.com> from "Paul Traina" at Jun 7, 96 02:05:23 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Mail locking, to be effective, must be soley performed through the use of > the flock() call on the mail file itself. > > Locking schemes relying on other mechanisms are not effective. > > Sorry. Explain that to all of those people writing MUAs out there. Or try to go fix every one of them. If you want to change the semantics of how the mail spool works, you have to consider the effect it will have on all of these (admittedly poortly written) programs. -- Wes Peters | Yes I am a pirate, two hundred years too late Softweyr | The cannons don't thunder, there's nothing to plunder Consulting | I'm an over forty victim of fate... softweyr@xmission.com | Jimmy Buffett From owner-freebsd-security Fri Jun 7 18:24:32 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA14195 for security-outgoing; Fri, 7 Jun 1996 18:24:32 -0700 (PDT) Received: from critter.tfs.com ([140.145.16.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA14184; Fri, 7 Jun 1996 18:24:26 -0700 (PDT) Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id SAA01263; Fri, 7 Jun 1996 18:23:57 -0700 (PDT) To: Steve Reid cc: freebsd-security@freebsd.org Subject: Re: MD5 broken In-reply-to: Your message of "Fri, 07 Jun 1996 17:05:25 PDT." Date: Fri, 07 Jun 1996 18:23:56 -0700 Message-ID: <1261.834197036@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message , Steve >Sorry if I'm digging up a dead topic, but is everyone here aware that MD5 >has been broken? > >About a month ago, Hans Dobbertin showed that he could generate MD5 >collisions in just 10 hours on a Pentium PC. Lets not get unduly worried here. He has not generated "MD5 collissions". He has generated "MD5 >pseudo< collisions". He is using a different initial buffer than the one used in MD5, and argues that he then has exposed a weakness in MD5. He may have. Could be. It's not that interesting. "Hey, if I substitute sugar for sand when I make a window it's much easier to break the glass." You think the insurrance people care ? Until somebody comes up with a way of solving A = MD5(X) for some given value of A then you don't need to worry to much. Poul-Henning -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Fri Jun 7 19:55:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA24721 for security-outgoing; Fri, 7 Jun 1996 19:55:28 -0700 (PDT) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA24712; Fri, 7 Jun 1996 19:55:20 -0700 (PDT) Received: (from root@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) id TAA00574; Fri, 7 Jun 1996 19:55:17 -0700 Date: Fri, 7 Jun 1996 19:55:12 -0700 (PDT) From: Steve Reid To: Poul-Henning Kamp cc: freebsd-security@freebsd.org Subject: Re: MD5 broken (not quite) In-Reply-To: <1261.834197036@critter.tfs.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 Okay, so I've made a fool of myself. MD5 is not broken yet. > >Sorry if I'm digging up a dead topic, but is everyone here aware that > >MD5 has been broken? > >About a month ago, Hans Dobbertin showed that he could generate MD5 > >collisions in just 10 hours on a Pentium PC. > > Lets not get unduly worried here. > He has not generated "MD5 collissions". > He has generated "MD5 >pseudo< collisions". > He is using a different initial buffer than the one used in MD5, and > argues that he then has exposed a weakness in MD5. I admit I'm not a crypto expert (Yes, I should have said that in the first place)... In this paper he specifically uses the term collision, and differentiates between collisions and pseudo-collisions. I see what you're saying, though... Looking more closely at the paper, the initial value he used was 12AC2375 3B341042 5F62B97C 4BA763ED, which is not what the MD5 algorithm normally uses for an IV. So you're right, this won't affect anything yet. This still seems to be a very large step forward, though... Probably about as close to broken as it can be without actually being broken. It would probably be a good idea to switch to something else _now_ rather than waiting for real MD5 to be broken. > Until somebody comes up with a way of solving A = MD5(X) for some given > value of A then you don't need to worry to much. That would definately be the end of MD5, but AFAIK (I'm not a crypto expert) reversing a hash is harder than finding real-world collisions where MD5(X) = MD5(Y), which would also be the end of MD5 in many (but not all) applications. ===================================================================== | Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/) | | Email: steve@edmweb.com Home Page: http://www.edmweb.com/steve/ | | PGP (2048/9F317269) Fingerprint: 11C89D1CD67287E68C09EC52443F8830 | | -- Disclaimer: JMHO, YMMV, TANSTAAFL, IANAL. -- | ===================================================================:) From owner-freebsd-security Fri Jun 7 20:10:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA26788 for security-outgoing; Fri, 7 Jun 1996 20:10:28 -0700 (PDT) Received: from critter.tfs.com ([140.145.16.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA26772; Fri, 7 Jun 1996 20:10:23 -0700 (PDT) Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id UAA01595; Fri, 7 Jun 1996 20:09:55 -0700 (PDT) To: Steve Reid cc: freebsd-security@freebsd.org Subject: Re: MD5 broken (not quite) In-reply-to: Your message of "Fri, 07 Jun 1996 19:55:12 PDT." Date: Fri, 07 Jun 1996 20:09:55 -0700 Message-ID: <1593.834203395@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Until somebody comes up with a way of solving A = MD5(X) for some given >> value of A then you don't need to worry to much. > >That would definately be the end of MD5, but AFAIK (I'm not a crypto >expert) reversing a hash is harder than finding real-world collisions >where MD5(X) = MD5(Y), which would also be the end of MD5 in many (but not >all) applications. If you want to substitute MD5(Y) for A I'm game, for all I care you can substitute sin(y) if you want :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Fri Jun 7 22:12:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA08228 for security-outgoing; Fri, 7 Jun 1996 22:12:21 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA08223 for ; Fri, 7 Jun 1996 22:12:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.7.5/8.6.6) with SMTP id XAA28275; Fri, 7 Jun 1996 23:11:23 -0600 (MDT) Message-Id: <199606080511.XAA28275@rover.village.org> To: Will Brown Subject: Re: MD5 Crack code Cc: angio@aros.net, karpen@sea.campus.luth.se, freebsd-security@FreeBSD.org In-reply-to: Your message of Mon, 03 Jun 1996 18:45:36 EDT Date: Fri, 07 Jun 1996 23:11:23 -0600 From: Warner Losh Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk : - two factors. Exactly how it stays in time-sync with servers I don't : know. Maybe there is more to it... (speak up folks). Yes : unfortunately the target customer seems to be high-end security : freaks (with $$), not ISPs and the ilk (sigh). I recall some discussions around the office about using these. It will know what time your card is at by what number you type in. The server knows all the numbers +- 15 minutes and can use what you claim the number to be to "skew" the delta time on changes. Put more simply, the server knows what the delta between passwords is to much more accuracy than 1 minute. Kinda a clever scheme. Warner From owner-freebsd-security Sat Jun 8 00:50:17 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA28430 for security-outgoing; Sat, 8 Jun 1996 00:50:17 -0700 (PDT) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA28411 for ; Sat, 8 Jun 1996 00:50:14 -0700 (PDT) Received: by sovcom.kiae.su id AA04614 (5.65.kiae-1 ); Sat, 8 Jun 1996 10:46:10 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Sat, 8 Jun 96 10:46:10 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id LAA00996; Sat, 8 Jun 1996 11:39:34 +0400 (MSD) Message-Id: <199606080739.LAA00996@astral.msk.su> Subject: Re: FreeBSD's /var/mail permissions To: pst@shockwave.com (Paul Traina) Date: Sat, 8 Jun 1996 11:39:34 +0400 (MSD) Cc: security@freebsd.org In-Reply-To: <199606071727.KAA01470@precipice.shockwave.com> from "Paul Traina" at "Jun 7, 96 10:27:21 am" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL19 (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 > I'm confused, why do you say adduser must create new user mailbox? > Mail.local is already suid root and adduser should deliver a preformatted > mail message with mail.local. bad guy: create /var/mail/user1 0666 admin: create user1 user1: receive mail from outside world bad guy: read user1 mail -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Sat Jun 8 00:52:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA28923 for security-outgoing; Sat, 8 Jun 1996 00:52:45 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA28907 for ; Sat, 8 Jun 1996 00:52:42 -0700 (PDT) Received: from sovcom.kiae.su (sovcom.kiae.su [144.206.136.1]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id AAA03002 for ; Sat, 8 Jun 1996 00:52:40 -0700 Received: by sovcom.kiae.su id AA04544 (5.65.kiae-1 ); Sat, 8 Jun 1996 10:45:56 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Sat, 8 Jun 96 10:45:55 +0300 Received: (from ache@localhost) by astral.msk.su (8.7.5/8.7.3) id LAA00950; Sat, 8 Jun 1996 11:32:36 +0400 (MSD) Message-Id: <199606080732.LAA00950@astral.msk.su> Subject: Re: FreeBSD's /var/mail permissions To: pantzer@ludd.luth.se (Mattias Pantzare) Date: Sat, 8 Jun 1996 11:32:35 +0400 (MSD) Cc: pst@shockwave.com, security@FreeBSD.org In-Reply-To: from "Mattias Pantzare" at "Jun 7, 96 11:22:54 pm" From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL19 (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 > > I'm confused, why do you say adduser must create new user mailbox? > > Mail.local is already suid root and adduser should deliver a preformatted > > mail message with mail.local. > > Why should adduser send any mail to anybody? Rather silly if you ask me. Because bad guy can pre-create upcoming user mailbox with 666 permissions. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Sat Jun 8 01:36:26 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA10366 for security-outgoing; Sat, 8 Jun 1996 01:36:26 -0700 (PDT) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA10304 for ; Sat, 8 Jun 1996 01:36:11 -0700 (PDT) Received: from palmer.demon.co.uk (localhost [127.0.0.1]) by palmer.demon.co.uk (sendmail/PALMER-1) with ESMTP id JAA04396; Sat, 8 Jun 1996 09:13:51 +0100 (BST) To: "Karl Denninger, MCSNet" cc: pst@shockwave.com (Paul Traina), nate@sri.MT.net, softweyr@xmission.com, security@FreeBSD.ORG From: "Gary Palmer" Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Fri, 07 Jun 1996 16:48:01 CDT." Date: Sat, 08 Jun 1996 09:13:51 +0100 Message-ID: <4393.834221631@palmer.demon.co.uk> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Karl Denninger, MCSNet" wrote in message ID : > Mail locking, to be effective, must *work across machines* so that NFS > mounts of the mail directory work. > flock() cannot be trusted to work in this environment, and in fact doesn't > even attempt to work on FreeBSD. > Does this mean we should give up on using mail? No, it means you should give up on using NFS mounting of /var/mail (or /var/spool/mail, or wherever else your local OS sticks it). NFS is an abombination at the best of times, and NFS locking even more so. THere are far more elegant solutions to the problem of distributing mail to client workstations, namely IMAP and POP. Sure, it means that people who use /usr/bin/mail to read their e-mail will be stumped, but I think that the pro's of using this form of mail distribution far outweigh the cons. (The fact that my favourite mailer, MH supports POP, SPOP, etc, has nothing to do with it :-) Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-security Sat Jun 8 03:29:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA14161 for security-outgoing; Sat, 8 Jun 1996 03:29:34 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA14107; Sat, 8 Jun 1996 03:29:24 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id MAA01837; Sat, 8 Jun 1996 12:29:22 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA28288; Sat, 8 Jun 1996 12:29:16 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id KAA11417; Sat, 8 Jun 1996 10:21:27 +0200 (MET DST) From: J Wunsch Message-Id: <199606080821.KAA11417@uriah.heep.sax.de> Subject: Re: FreeBSD's /var/mail permissions To: pst@shockwave.com (Paul Traina) Date: Sat, 8 Jun 1996 10:21:27 +0200 (MET DST) Cc: security@freebsd.org, core@freebsd.org (FreeBSD core team) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199606071239.FAA19708@precipice.shockwave.com> from Paul Traina at "Jun 7, 96 05:39:22 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (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 As Paul Traina wrote: (No idea whether discussion did already take place, i'm not on the security list. I suggest keeping -core as well.) > Proposed solution: > I'm considering creating group "mail" and going the setgid route, > so that a program which creates files in /var/mail can be simply > setgid mail. > > This is a well understood mail directory protection mechanism > and employs the "principle of least privilege." I don't think so. Unlike SysV, you cannot chown a file to a user of your will except when being root. So IMHO this does already mandate the programs that create mail folders to be setuid root. Given this, there's no sense in using the group `mail' in addition. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-security Sat Jun 8 05:12:37 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA13309 for security-outgoing; Sat, 8 Jun 1996 05:12:37 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA13281 for ; Sat, 8 Jun 1996 05:12:30 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id OAA14015; Sat, 8 Jun 1996 14:12:26 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id OAA00278; Sat, 8 Jun 1996 14:12:13 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.4/keltia-uucp-2.8) id NAA03159; Sat, 8 Jun 1996 13:43:22 +0200 (MET DST) From: Ollivier Robert Message-Id: <199606081143.NAA03159@keltia.freenix.fr> Subject: Re: s/key and OTP [was: MD5 Crack code] To: pst@shockwave.com (Paul Traina) Date: Sat, 8 Jun 1996 13:43:22 +0200 (MET DST) Cc: ewb@zns.net, freebsd-security@freebsd.org In-Reply-To: <199606072240.PAA01013@precipice.shockwave.com> from Paul Traina at "Jun 7, 96 03:40:17 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#2084 X-Mailer: ELM [version 2.4ME+ PL19 (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 It seems that Paul Traina said: > It *is* compatible with S/Key in MD4 mode? If so, then it's reasonable > for us to incorporate their sources once it becomes stable. You can find this in the Makefile.in file: # Which message-digest algorithm do you want to use? # # MD5 is the default and highly recommended because it is stronger. Sites # migrating from Bellcore S/Key v1 might want to use MD4 for compatibility # reasons. Support for MD4 will be removed in a future version of OPIE. MDX=5 #MDX=4 > Given the recent change date on the file...stability is a question, no? Several of the changes were made to sync with the latest OTP specs from IETF. It won't be really stable till the IETF put forth the RFC. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #7: Thu Jun 6 20:43:22 MET DST 1996 From owner-freebsd-security Sat Jun 8 08:05:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27523 for security-outgoing; Sat, 8 Jun 1996 08:05:43 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA27503 for ; Sat, 8 Jun 1996 08:05:40 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id IAA05536; Sat, 8 Jun 1996 08:04:43 -0700 (PDT) Message-Id: <199606081504.IAA05536@precipice.shockwave.com> To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) cc: pantzer@ludd.luth.se (Mattias Pantzare), security@FreeBSD.org Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Sat, 08 Jun 1996 11:32:35 +0400." <199606080732.LAA00950@astral.msk.su> Date: Sat, 08 Jun 1996 08:04:43 -0700 From: Paul Traina Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk But bad guy can't, because /var/mail is 755 From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chern >>ov, Black Mage) Subject: Re: FreeBSD's /var/mail permissions > > I'm confused, why do you say adduser must create new user mailbox? > > Mail.local is already suid root and adduser should deliver a preformatted > > mail message with mail.local. > > Why should adduser send any mail to anybody? Rather silly if you ask me. Because bad guy can pre-create upcoming user mailbox with 666 permissions. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - http://dt.demos.su/~ache : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-security Sat Jun 8 08:07:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27992 for security-outgoing; Sat, 8 Jun 1996 08:07:52 -0700 (PDT) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA27975; Sat, 8 Jun 1996 08:07:48 -0700 (PDT) Received: from shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.5/8.7.3) with ESMTP id IAA05615; Sat, 8 Jun 1996 08:06:48 -0700 (PDT) Message-Id: <199606081506.IAA05615@precipice.shockwave.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: security@freebsd.org, core@freebsd.org (FreeBSD core team) Subject: Re: FreeBSD's /var/mail permissions In-reply-to: Your message of "Sat, 08 Jun 1996 10:21:27 +0200." <199606080821.KAA11417@uriah.heep.sax.de> Date: Sat, 08 Jun 1996 08:06:48 -0700 From: Paul Traina Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Excellent point. :-( From: J Wunsch Subject: Re: FreeBSD's /var/mail permissions As Paul Traina wrote: (No idea whether discussion did already take place, i'm not on the security list. I suggest keeping -core as well.) > Proposed solution: > I'm considering creating group "mail" and going the setgid route, > so that a program which creates files in /var/mail can be simply > setgid mail. > > This is a well understood mail directory protection mechanism > and employs the "principle of least privilege." I don't think so. Unlike SysV, you cannot chown a file to a user of your will except when being root. So IMHO this does already mandate the programs that create mail folders to be setuid root. Given this, there's no sense in using the group `mail' in addition. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-security Sat Jun 8 12:14:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA03464 for security-outgoing; Sat, 8 Jun 1996 12:14:48 -0700 (PDT) Received: from zed.ludd.luth.se (root@zed.ludd.luth.se [130.240.16.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA03459 for ; Sat, 8 Jun 1996 12:14:45 -0700 (PDT) Received: from max.ludd.luth.se (max.ludd.luth.se [130.240.16.52]) by zed.ludd.luth.se (8.7.5/8.7.2) with ESMTP id VAA24325; Sat, 8 Jun 1996 21:14:30 +0200 Received: (pantzer@localhost) by max.ludd.luth.se (8.6.11/8.6.11) id VAA03137; Sat, 8 Jun 1996 21:13:36 +0200 Date: Sat, 8 Jun 1996 21:13:33 +0200 (MET DST) From: Mattias Pantzare To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= cc: pst@shockwave.com, security@FreeBSD.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: <199606080732.LAA00950@astral.msk.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Why should adduser send any mail to anybody? Rather silly if you ask me. > > Because bad guy can pre-create upcoming user mailbox with 666 permissions. Not if the adduser script creates it. To remove the option on sending a mail to the new user fills no function. From owner-freebsd-security Sat Jun 8 16:26:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA05656 for security-outgoing; Sat, 8 Jun 1996 16:26:43 -0700 (PDT) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA05650 for ; Sat, 8 Jun 1996 16:26:41 -0700 (PDT) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA05044; Sat, 8 Jun 1996 17:26:32 -0600 Date: Sat, 8 Jun 1996 17:26:32 -0600 From: Nate Williams Message-Id: <199606082326.RAA05044@rocky.sri.MT.net> To: Mattias Pantzare Cc: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= , pst@shockwave.com, security@FreeBSD.org Subject: Re: FreeBSD's /var/mail permissions In-Reply-To: References: <199606080732.LAA00950@astral.msk.su> Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Why should adduser send any mail to anybody? Rather silly if you ask me. > > > > Because bad guy can pre-create upcoming user mailbox with 666 permissions. > > Not if the adduser script creates it. To remove the option on sending a mail > to the new user fills no function. This assumes that 'adduser' is the only tool used to create passwords, which it isn't by any stretch of the imagination. Closing the hole by "forcing" people to addusers with a tool that doesn't necessary reflect local policy is not a good solution. Nate From owner-freebsd-security Sat Jun 8 22:30:16 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA20081 for security-outgoing; Sat, 8 Jun 1996 22:30:16 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA20070 for ; Sat, 8 Jun 1996 22:30:12 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id BAA09777; Sun, 9 Jun 1996 01:29:17 -0400 (EDT) Date: Sun, 9 Jun 1996 01:29:23 -0400 (EDT) From: Brian Tao To: "Karl Denninger, MCSNet" cc: security@FreeBSD.ORG Subject: Re: FreeBSD's /var/mail permissions 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 Fri, 7 Jun 1996, Karl Denninger, MCSNet wrote: > > Does this mean we should give up on using mail? No, it means you keep mail on a separate machine and manipulate your mailbox through a server like POP3 or IMAP. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't"