From owner-freebsd-security Tue Dec 28 1: 7:49 1999 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 A5A7F150BA for ; Tue, 28 Dec 1999 01:07:42 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA06285; Tue, 28 Dec 1999 10:07:33 +0100 (CET) (envelope-from des@flood.ping.uio.no) To: Warner Losh Cc: Fernando Schapachnik , freebsd-security@FreeBSD.ORG Subject: Re: OpenSSH vulnerable to protocol flaw? References: <199912161207.JAA22894@ns1.via-net-works.net.ar> <199912162104.OAA74270@harmony.village.org> From: Dag-Erling Smorgrav Date: 28 Dec 1999 10:07:33 +0100 In-Reply-To: Warner Losh's message of "Thu, 16 Dec 1999 14:04:35 -0700" Message-ID: Lines: 42 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 Warner Losh writes: > OpenSSH implements the ssh1 protocol, which is vulnerable to insertion > attacks like the one described in bugtraq. I don't think they have > changed the protocol at all, but I'm sure someone will tell me if I'm > wrong. Random quotes from the advisory: Note that the new revision for the SSH protocol, proposed and published as Internet Drafts [2],[3],[4] [5] makes use of cryptographycally strong message authentication codes for integrity checks that wont fail to these attacks. [...] [2] "SSH Protocol Architecture", draft-ietf-secsh-architecture-01.txt.gz T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997 [3] "SSH Connection Protocol", draft-ietf-secsh-connect-03.txt.gz T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997 [4] "SSH Authentication Protocol", draft-ietf-secsh-userauth-03.txt.gz T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997 [5] "SSH Transport Layer Protocol",draft-ietf-secsh-transport-03.txt.gz T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997 (drafts expired on May 7th, 1998) [...] In the meantime, upgrade to version 1.2.25 of SSH, which fixes the problem. The SSH 1.2.25 distribution can be obtained from: DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 28 3:46:42 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 1D1C714ED6; Tue, 28 Dec 1999 03:46:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 09D761CD814; Tue, 28 Dec 1999 03:46:41 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 28 Dec 1999 03:46:40 -0800 (PST) From: Kris Kennaway To: Dag-Erling Smorgrav Cc: Warner Losh , Fernando Schapachnik , freebsd-security@FreeBSD.ORG Subject: Re: OpenSSH vulnerable to protocol flaw? 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 28 Dec 1999, Dag-Erling Smorgrav wrote: > Note that the new revision for the SSH protocol, proposed and > published as Internet Drafts [2],[3],[4] [5] makes use of > cryptographycally strong message authentication codes for > integrity checks that wont fail to these attacks. Correct me if I'm wrong, but these describe the SSH v2 protocol, which is implemented in ssh 2.x, not sh 1.x (and hence openssh 1.x). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 28 6:56: 0 1999 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 E68B015484 for ; Tue, 28 Dec 1999 06:55:54 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id JAA46246; Tue, 28 Dec 1999 09:55:49 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 28 Dec 1999 09:55:49 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Kurt D. Zeilenga" Cc: freebsd-security@freebsd.org Subject: Re: bjorb vs sslproxy vs stunnel In-Reply-To: <3.0.5.32.19991224135854.00948d70@localhost> 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 Don't have any experience with bjorb or stunnel, but I do remember finding that sslproxy doesn't correctly reap fork()'d zombie children, resulting in large numbers of zombies on a production machine. This was a couple of months ago, so it may have been fixed since then, but it wasn't very entertaining. You might also consider SSH for tunneling if you allow users to have accounts on your machine (i.e., SSH requires them to log in before providing tunneling services) -- this is a common arrangement with CVS where they will need to authenticate anyway. I hope to give stunnel a try shortly in the hopes that it is better than sslproxy :-). On Fri, 24 Dec 1999, Kurt D. Zeilenga wrote: > I am looking at using an SSL proxy to provide > privacy protection for a variety of services > including CVS. There are at least three differnet > packages available in the ports collection that > provide SSL tunneling services. > > Does anyone know of or have a decent, up-to-date > comparative review of these packages? > > TIA, Kurt > > ---- > Kurt D. Zeilenga > Net Boolean Incorporated > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, 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 Dec 28 8:25:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from cantor.boolean.net (cantor.boolean.net [209.133.111.73]) by hub.freebsd.org (Postfix) with ESMTP id EA43714ED9 for ; Tue, 28 Dec 1999 08:25:40 -0800 (PST) (envelope-from kurt@boolean.net) Received: from boolean.net (localhost [127.0.0.1]) by cantor.boolean.net (8.9.3/8.9.3) with ESMTP id QAA09008; Tue, 28 Dec 1999 16:25:36 GMT (envelope-from kurt@boolean.net) Message-ID: <3868E4A9.2290E82@boolean.net> Date: Tue, 28 Dec 1999 08:26:17 -0800 From: "Kurt D. Zeilenga" Organization: Net Boolean X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-GB,en-US,en,de-DE,de MIME-Version: 1.0 To: Robert Watson Cc: freebsd-security@freebsd.org Subject: Re: bjorb vs sslproxy vs stunnel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson wrote: > Don't have any experience with bjorb or stunnel, but I do remember finding > that sslproxy doesn't correctly reap fork()'d zombie children, resulting > in large numbers of zombies on a production machine. This was a couple of > months ago, so it may have been fixed since then, but it wasn't very > entertaining. You might also consider SSH for tunneling if you allow > users to have accounts on your machine (i.e., SSH requires them to log in > before providing tunneling services) -- this is a common arrangement with > CVS where they will need to authenticate anyway. We don't allow logins to the system providing the CVS master repository. > I hope to give stunnel a > try shortly in the hopes that it is better than sslproxy :-). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 28 11: 9: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from anarcat.dyndns.org (phobos.IRO.UMontreal.CA [132.204.20.20]) by hub.freebsd.org (Postfix) with ESMTP id E646C154CA for ; Tue, 28 Dec 1999 11:08:52 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id 953EB1B66; Tue, 28 Dec 1999 14:07:39 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14441.2683.366094.187063@anarcat.dyndns.org> Date: Tue, 28 Dec 1999 14:07:39 -0500 (EST) To: freebsd-security@freebsd.org Subject: Mounting / Read-Only X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: beaupran@iro.umontreal.ca Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I am currently in the process of enforcing a policy of / and /usr being mounted read-only. I would like to know if other people have tried this policy and/or the modifications that have been needed. Right now, I have been forced to turn off "UPDATE_MOTD" (duh!). There is also the following lines in /etc/rc # Whack the pty perms back into shape. chflags 0 /dev/tty[pqrsPQRS]* chmod 666 /dev/tty[pqrsPQRS]* chown root:wheel /dev/tty[pqrsPQRS]* that give annoying warnings (read-only filesystem). A good idea would be to change it to: # Whack the pty perms back into shape. chflags 0 /dev/tty[pqrsPQRS]* 2> /dev/null chmod 666 /dev/tty[pqrsPQRS]* 2> /dev/null chown root:wheel /dev/tty[pqrsPQRS]* 2> /dev/null since it does not produce any output normally either. I was also wondering... If we can modify the status (RW/RO) of a mounted filesystem (/ included) with mount -u, why bother? :)) What is the purpose of mounting a filesystem ReadOnly, since it can be disabled? Does it serve the same function as the schg flag? I think the securelevel does not change this behavior, right? Anyways, any personal experiences or advices are welcome. Thanks The AnarCat -- Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir Lofofora ------- end of forwarded message ------- -- Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir Lofofora To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 28 11: 9: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from anarcat.dyndns.org (phobos.IRO.UMontreal.CA [132.204.20.20]) by hub.freebsd.org (Postfix) with ESMTP id 7E193154AA for ; Tue, 28 Dec 1999 11:08:53 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id 796301A63; Tue, 28 Dec 1999 14:06:30 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14441.2614.114877.349074@anarcat.dyndns.org> Date: Tue, 28 Dec 1999 14:06:30 -0500 (EST) To: freebsd-security@freebsd.org Subject: ports/15577: Amanda 2.3.0 runtar program allow any user to run tar as root X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: Spidey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. I don't know if any of you took a look at this PR I made, but I think it would be a good idea. I would like to have your advice on the modifications I am suggesting. Also, it would be urgent to mark the port either as broken or commit the fix, as, right now, anyone who installs the amanda 2.3 package from the ports or the packages is very likely to get *wacked* by its local users. Should I have posted this earlier to the list? I thought someone would have noticed the PR... Thanks. The AnarCat -- Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir Lofofora To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 28 11:19:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from beach.silcom.com (beach.silcom.com [199.201.128.19]) by hub.freebsd.org (Postfix) with ESMTP id 8330114F0C for ; Tue, 28 Dec 1999 11:19:50 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Received: from smarter.than.nu (pm1-38.vpop1.avtel.net [207.71.237.88]) by beach.silcom.com (Postfix) with ESMTP id 5E5F21454CA; Tue, 28 Dec 1999 11:19:43 -0800 (PST) Date: Tue, 28 Dec 1999 11:19:42 -0800 (PST) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu To: Spidey Cc: freebsd-security@FreeBSD.ORG Subject: Re: Mounting / Read-Only In-Reply-To: <14441.2683.366094.187063@anarcat.dyndns.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, 28 Dec 1999, Spidey wrote: > I was also wondering... If we can modify the status (RW/RO) of a > mounted filesystem (/ included) with mount -u, why bother? :)) > > What is the purpose of mounting a filesystem ReadOnly, since it can be > disabled? Does it serve the same function as the schg flag? I think > the securelevel does not change this behavior, right? Mounting a filesystem read-only is not a security measure. It gains you nothing if root is compromised. -- Brian Buchanan brian@CSUA.Berkeley.EDU -------------------------------------------------------------------------- FreeBSD - The Power to Serve! http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 28 11:31:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id CF11714D68 for ; Tue, 28 Dec 1999 11:31:09 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA70952; Tue, 28 Dec 1999 11:30:35 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912281930.LAA70952@gndrsh.dnsmgr.net> Subject: Re: Mounting / Read-Only In-Reply-To: from "Brian W. Buchanan" at "Dec 28, 1999 11:19:42 am" To: brian@CSUA.Berkeley.EDU (Brian W. Buchanan) Date: Tue, 28 Dec 1999 11:30:34 -0800 (PST) Cc: beaupran@iro.umontreal.ca (Spidey), freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > On Tue, 28 Dec 1999, Spidey wrote: > > > I was also wondering... If we can modify the status (RW/RO) of a > > mounted filesystem (/ included) with mount -u, why bother? :)) > > > > What is the purpose of mounting a filesystem ReadOnly, since it can be > > disabled? Does it serve the same function as the schg flag? I think > > the securelevel does not change this behavior, right? > > Mounting a filesystem read-only is not a security measure. I disagree, mounting a filesystem read-only _is_ a security measure, it can prevent certain attacks that may not have compromised root, but say they did manage to compromise something that would allow them to write a file in /usr/bin, if /usr/bin/ is read-only the are SOL, if it is r/w they be having root in a few minutes... > It gains you > nothing if root is compromised. But it gains you a lot if it defeats them from getting root. From someone who almost always runs /usr RO.... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 28 12: 1:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from beach.silcom.com (beach.silcom.com [199.201.128.19]) by hub.freebsd.org (Postfix) with ESMTP id D239214F3F for ; Tue, 28 Dec 1999 12:01:31 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Received: from smarter.than.nu (pm1-38.vpop1.avtel.net [207.71.237.88]) by beach.silcom.com (Postfix) with ESMTP id 6BF6A145720; Tue, 28 Dec 1999 12:00:58 -0800 (PST) Date: Tue, 28 Dec 1999 12:00:57 -0800 (PST) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu To: "Rodney W. Grimes" Cc: Spidey , freebsd-security@FreeBSD.ORG Subject: Re: Mounting / Read-Only In-Reply-To: <199912281930.LAA70952@gndrsh.dnsmgr.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 Tue, 28 Dec 1999, Rodney W. Grimes wrote: > > On Tue, 28 Dec 1999, Spidey wrote: > > > > > I was also wondering... If we can modify the status (RW/RO) of a > > > mounted filesystem (/ included) with mount -u, why bother? :)) > > > > > > What is the purpose of mounting a filesystem ReadOnly, since it can be > > > disabled? Does it serve the same function as the schg flag? I think > > > the securelevel does not change this behavior, right? > > > > Mounting a filesystem read-only is not a security measure. > I disagree, mounting a filesystem read-only _is_ a security measure, it > can prevent certain attacks that may not have compromised root, but > say they did manage to compromise something that would allow them to > write a file in /usr/bin, if /usr/bin/ is read-only the are SOL, if > it is r/w they be having root in a few minutes... Not really. If anyone other than root can write to /bin, /usr/bin, or any other directory containing binaries root might run, then your permissions are set up incorrectly. > ls -la /usr/bin |head total 14697 drwxr-xr-x 2 root wheel 6656 Dec 17 22:06 . drwxr-xr-x 20 root wheel 512 Dec 2 10:05 .. -r-xr-xr-x 3 root wheel 68076 Dec 2 02:46 CC -r-xr-xr-x 2 root wheel 64876 Dec 2 02:50 Mail -r-xr-xr-x 1 root wheel 99254 Dec 2 02:48 a2p -r-xr-xr-x 1 root wheel 36992 Dec 2 02:46 addftinfo -r-xr-xr-x 14 root wheel 50928 Dec 2 02:50 addr2line -r-xr-xr-x 1 root wheel 5184 Dec 2 02:50 apply -r-xr-xr-x 2 root wheel 2245 Dec 2 02:46 apropos All binaries have write permissions turned off, root owns all binaries, and only root can write to the directory. The only thing read-only mounting the filesystem protects you from is someone who's found a hole that lets him write arbitrary data as root at an arbitrary point on the filesystem, and by that point I'd be willing to bet that you've already lost, since he can probably nail /etc/swpd.db, /etc/rc, or any number of other things. schg flags and securelevels are your friends when it comes to protecting binaries and configuration data. Protecting the password file is a bit trickier... I guess there is no substitute for a thorough code review. -- Brian Buchanan brian@CSUA.Berkeley.EDU -------------------------------------------------------------------------- FreeBSD - The Power to Serve! http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 28 15:38:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 83F561551A for ; Tue, 28 Dec 1999 15:38:39 -0800 (PST) (envelope-from sprice@hiwaay.net) Received: from localhost (sprice@localhost) by mail.HiWAAY.net (8.9.3/8.9.0) with ESMTP id RAA24206; Tue, 28 Dec 1999 17:38:37 -0600 (CST) Date: Tue, 28 Dec 1999 17:38:36 -0600 (CST) From: Steve Price To: Spidey Cc: freebsd-security@FreeBSD.ORG Subject: Re: ports/15577: Amanda 2.3.0 runtar program allow any user to run tar as root In-Reply-To: <14441.2614.114877.349074@anarcat.dyndns.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, 28 Dec 1999, Spidey wrote: # Hi. # # I don't know if any of you took a look at this PR I made, but I think # it would be a good idea. # # I would like to have your advice on the modifications I am # suggesting. # # Also, it would be urgent to mark the port either as broken or commit # the fix, as, right now, anyone who installs the amanda 2.3 package # from the ports or the packages is very likely to get *wacked* by its # local users. # # Should I have posted this earlier to the list? I thought someone would # have noticed the PR... I noticed the problem report. The 'patch' needs help, but I've almost got something that I think accomplishes the spirit of the PR at least. Look for it to get committed, later tonight. -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 29 6:31:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from faui01.informatik.uni-erlangen.de (faui01.informatik.uni-erlangen.de [131.188.2.1]) by hub.freebsd.org (Postfix) with ESMTP id 74A1C14BEA for ; Wed, 29 Dec 1999 06:31:50 -0800 (PST) (envelope-from msfriedl@faui01.informatik.uni-erlangen.de) Received: (from msfriedl@localhost) by faui01.informatik.uni-erlangen.de (8.8.8/8.1.16-FAU) id PAA26014; Wed, 29 Dec 1999 15:31:46 +0100 (MET) Date: Wed, 29 Dec 1999 15:31:46 +0100 From: Markus Friedl To: freebsd-security@FreeBSD.ORG Cc: Warner Losh , Fernando Schapachnik Subject: Re: OpenSSH vulnerable to protocol flaw? Message-ID: <19991229153146.A25953@faui01.informatik.uni-erlangen.de> References: <199912161207.JAA22894@ns1.via-net-works.net.ar> <199912162104.OAA74270@harmony.village Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from owner-freebsd-security on Fri, Dec 28, 2007 at 12:07:49AM +0000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OpenSSH implements the SSH1 protocol. The mentioned flaw can only be fixed by breaking the protocol. I have an experimental patch that replaces CRC with hmac-sha1 among other things. send mail to markus@openssh.COM if you want to review/test/comment/crytoanalyze the patches. -markus On Fri, Dec 28, 2007 at 12:07:49AM +0000, owner-freebsd-security wrote: > Warner Losh writes: > > OpenSSH implements the ssh1 protocol, which is vulnerable to insertion > > attacks like the one described in bugtraq. I don't think they have > > changed the protocol at all, but I'm sure someone will tell me if I'm > > wrong. > > Random quotes from the advisory: > > Note that the new revision for the SSH protocol, proposed and > published as Internet Drafts [2],[3],[4] [5] makes use of > cryptographycally strong message authentication codes for > integrity checks that wont fail to these attacks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 29 6:40:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 7114114DAD for ; Wed, 29 Dec 1999 06:40:15 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 123KGt-0003Hf-00 for freebsd-security@freebsd.org; Wed, 29 Dec 1999 06:40:15 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-security@freebsd.org Subject: identd Message-Id: Date: Wed, 29 Dec 1999 06:40:15 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org are these yet another form of attack, or is there a buglet i should be chasing? inetd[221]: /usr/local/sbin/identd[12109]: exit status 0xb inetd[221]: /usr/local/sbin/identd[72509]: exit status 0xb randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 30 3:38:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from eltex.ru (ELTEX-2-SPIIRAS.nw.ru [195.19.204.46]) by hub.freebsd.org (Postfix) with ESMTP id D79AA14F7A for ; Thu, 30 Dec 1999 03:38:29 -0800 (PST) (envelope-from ark@eltex.ru) Received: from yaksha.eltex.ru (root@yaksha.eltex.ru [195.19.198.2]) by eltex.ru (8.9.3/8.9.3) with SMTP id OAA14145 for ; Thu, 30 Dec 1999 14:38:17 +0300 (MSK) Received: by yaksha.eltex.ru (ssmtp TIS-0.5alpha, 19 Oct 1998); Thu, 30 Dec 1999 14:35:46 +0300 Received: from undisclosed-intranet-sender id xma010141; Thu, 30 Dec 99 14:35:41 +0300 Date: Thu, 30 Dec 1999 14:35:26 +0300 From: -=ArkanoiD=- Message-Id: <199912301135.OAA12144@paranoid.eltex.spb.ru> To: freebsd-security@freebsd.org Subject: http://www.intes.odessa.ua/vxe Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Linux only for now, but not a bad idea.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 30 8:40:48 1999 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 C5A1E15162 for ; Thu, 30 Dec 1999 08:40:45 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA66905; Thu, 30 Dec 1999 11:40:28 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 30 Dec 1999 11:40:28 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: -=ArkanoiD=- Cc: freebsd-security@freebsd.org Subject: Re: http://www.intes.odessa.ua/vxe In-Reply-To: <199912301135.OAA12144@paranoid.eltex.spb.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 Have you looked at the TIS Labs Wrappers toolkit? It allows you to specify custom policies for processes based on syscall masks and argument management. It's been a while since I've looked at this work, but my understanding is you can specify general policies to manage processes, quite effectively. Also, the jail() environment provides far more extensive (almost) virtual machine protection for chroot() processes, and is available in -CURRENT. Shortly, capability and ACL extensions will be available providing similar fine-grained access control support on FreeBSD, allowing you to eliminate concentrations of privileges (such as uid 0 having no extra privileges). Syscall mask mechanisms such as the one you pointed us to can work, but are in some sense a hack -- given the vast number of ways to potentially attack such a mechanism, you'd have to be very careful. Robert Watson On Thu, 30 Dec 1999, -=ArkanoiD=- wrote: > > Linux only for now, but not a bad idea.. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, 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 Thu Dec 30 8:57: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from bekool.com (ns2.netquick.net [216.48.34.2]) by hub.freebsd.org (Postfix) with ESMTP id C70EE15356 for ; Thu, 30 Dec 1999 08:56:21 -0800 (PST) (envelope-from trouble@netquick.net) Received: from bastille.netquick.net ([216.48.32.159] helo=netquick.net ident=root) by bekool.com with esmtp (Exim 3.03 #1) id 123jLh-000Ibp-00 for freebsd-security@FreeBSD.ORG; Thu, 30 Dec 1999 12:26:53 -0500 Message-ID: <386B9258.893C7483@netquick.net> Date: Thu, 30 Dec 1999 12:11:52 -0500 From: TrouBle Reply-To: trouble@netquick.net Organization: Hacked Furbies X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-security@FreeBSD.ORG Subject: IDS recommendations References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What would you all recommend for IDS systems that run under FreeBSD ??? -- ...and that is how we know the Earth to be banana-shaped. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 30 9:50:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id BB36F14D01; Thu, 30 Dec 1999 09:50:25 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id MAA86720; Thu, 30 Dec 1999 12:55:07 -0500 (EST) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199912301755.MAA86720@cc942873-a.ewndsr1.nj.home.com> Subject: Re: OpenSSL does not build under 2.2.8S? In-Reply-To: <99122711212502.10246@tux.axian.com> from Terry Griffin at "Dec 27, 1999 11:13:48 am" To: terryg@axian.com (Terry Griffin) Date: Thu, 30 Dec 1999 12:55:07 -0500 (EST) Cc: freebsd-questions@FreeBSD.ORG (FreeBSD Questions), freebsd-security@FreeBSD.ORG Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM946576507-86499-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM946576507-86499-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Terry Griffin wrote, > Christ, > > Some time ago on the freebsd-questions mailing list you wrote: > > Between the RSAref2 overflow issue and all of the chatter about > > [snip] > > ld: invalid command option `--whole-archive' > > [snip] > > I was having the same problem but was disappointed to find that you're question > had gone unanswered in the list. I've since found the solution. Edit the > makefile to replace the --whole-archive switch with the -Bforcearchive switch, > and simply delete all use of the --no-whole-archive switch. > > I built and installed OpenSSL with this change and then was able to build > OpenSSH. Thanks, Terry. That small pointer was what I needed. OpenSSL appears to have built cleanly for me with your suggested change of --whole-archive to -Bforcearchive. I am forwarding this response to -questions and -security so your response finds its way into the mail archives. To make it even easier for people having trouble, I have attached a patch below. Drop the patch (or this entire mail) into /usr/ports/security/openssl/patches and name it 'patch-za' (or any unused name that comes after the other patches), and you should be able to 'make' from the port directory without tampering with any Makefiles. Thanks again for the response. -- Crist J. Clark cjclark@home.com --ELM946576507-86499-0_ Content-Type: text/plain; charset=US-ASCII Content-Disposition: attachment; filename=patch-za Content-Description: patch-za Content-Transfer-Encoding: 7bit --- Makefile.org.orig Thu Dec 30 12:19:31 1999 +++ Makefile.org Thu Dec 30 12:19:36 1999 @@ -196,7 +196,7 @@ ${MAKE} CC='${CC}' PLATFORM='${PLATFORM}' CFLAG='-fPIC ${CFLAG}' SDIRS='${SDIRS}' INSTALLTOP='${INSTALLTOP}' PEX_LIBS='${PEX_LIBS}' EX_LIBS='${EX_LIBS}' BN_ASM='${BN_ASM}' DES_ENC='${DES_ENC}' BF_ENC='${BF_ENC}' CAST_ENC='${CAST_ENC}' RC4_ENC='${RC4_ENC}' RC5_ENC='${RC5_ENC}' SHA1_ASM_OBJ='${SHA1_ASM_OBJ}' MD5_ASM_OBJ='${MD5_ASM_OBJ}' RMD160_ASM_OBJ='${RMD160_ASM_OBJ}' AR='${AR}' DIRS=$$i clean all || exit 1; \ ( set -x; ${CC} -shared -o lib$$i.so.${SHLIBVER} \ -Wl,-S,-soname=lib$$i.so.${SHLIBVER} \ - -Wl,--whole-archive lib$$i.a ) || exit 1; \ + -Wl,-Bforcearchive lib$$i.a ) || exit 1; \ rm -f lib$$i.a; (cd $$i ; ${MAKE} clean) || exit 1 ;\ done; @set -x; \ --ELM946576507-86499-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 30 10:52:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 75A6014D98 for ; Thu, 30 Dec 1999 10:52:13 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA48411 for ; Thu, 30 Dec 1999 11:52:11 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA11820 for ; Thu, 30 Dec 1999 11:52:11 -0700 (MST) Message-Id: <199912301852.LAA11820@harmony.village.org> To: freebsd-security@freebsd.org Subject: Niels Provos: CVS: cvs.openbsd.org: src Date: Thu, 30 Dec 1999 11:52:11 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This just went into OpenBSD and looks way cool. :-) Anybody with lots of spare time wanna port it :-) Warner ------- Forwarded Message Date: Thu, 30 Dec 1999 11:21:56 -0700 (MST) From: Niels Provos Message-Id: <199912301821.LAA18904@cvs.openbsd.org> To: source-changes@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT: /cvs Module name: src Changes by: provos@cvs.openbsd.org 1999/12/30 11:21:56 Modified files: sys/uvm : uvm_meter.c uvm_pdaemon.c uvm_swap.c sys/vm : vm_page.h vm_param.h sys/conf : files Added files: sys/uvm : uvm_swap_encrypt.c uvm_swap_encrypt.h Log message: swap encryption for UVM, option UVM_SWAP_ENCRYPT. needs to be enabled via sysctl. Pages are encrypted with the Blowfish encryption algorithm, the key is initialized randomly on first swap out, ensuring that entropy has accumulated in the kernel randomness pool. Eventually, swap encryption will be decided on a process by process basis, e.g. a process that reads from a cryptographic filesystem will enable swap encrypt for its pages. okay art@ and deraadt@. ------- 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 Thu Dec 30 11:18:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 42A051538C for ; Thu, 30 Dec 1999 11:18:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA76495; Thu, 30 Dec 1999 11:18:49 -0800 (PST) (envelope-from dillon) Date: Thu, 30 Dec 1999 11:18:49 -0800 (PST) From: Matthew Dillon Message-Id: <199912301918.LAA76495@apollo.backplane.com> To: Warner Losh Cc: freebsd-security@FreeBSD.ORG Subject: Re: Niels Provos: CVS: cvs.openbsd.org: src References: <199912301852.LAA11820@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :This just went into OpenBSD and looks way cool. :-) Anybody with lots :of spare time wanna port it :-) : :Warner Hmm. Looks VERY interesting, though I shudder at the overhead. It would not be too hard to do w/ FreeBSD but in order to avoid low-memory deadlocks we would have to encrypt the page in-place and then free it after the pageout (or de-encrypt it in place after the pageout to retain the page). The tie-ins are trivial. We could add a flags field to the swblock structure and then simply tie-in to swstrategy(). I would like to see a general cryptographic VFS layer - instead of having a specific cryptfs we instead should have a VFS layer that we can stack on any filesystem and enable with a mount option, kinda like how union mounts work now except easier since we need only overlay the VOP_READ/WRITE/GETPAGES/PUTPAGES functions. Imagine: mount -o crypt=KEY /dev/sd0d /mnt -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 30 12:53: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from 1Cust218.tnt1.tco2.da.uu.net (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 237AF152C6; Thu, 30 Dec 1999 12:53:00 -0800 (PST) (envelope-from green@FreeBSD.org) Date: Thu, 30 Dec 1999 15:52:57 -0500 (EST) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Randy Bush Cc: freebsd-security@freebsd.org Subject: Re: identd 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 Wed, 29 Dec 1999, Randy Bush wrote: > are these yet another form of attack, or is there a buglet i should be > chasing? > > inetd[221]: /usr/local/sbin/identd[12109]: exit status 0xb > inetd[221]: /usr/local/sbin/identd[72509]: exit status 0xb Try giving us some information first. For example, what _is_ that binary? What version of whatever it is is it? What's the inetd line you have in effect for it? etc. > > randy > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 30 21:40:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 749B014CB2 for ; Thu, 30 Dec 1999 21:40:06 -0800 (PST) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id XAA51399; Thu, 30 Dec 1999 23:40:01 -0600 (CST) From: Joe Greco Message-Id: <199912310540.XAA51399@aurora.sol.net> Subject: Re: Mounting / Read-Only To: freebsd@gndrsh.dnsmgr.net Date: Thu, 30 Dec 1999 23:40:00 -0600 (CST) Cc: freebsd-security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] 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 "Brian W. Buchanan" writes: > On Tue, 28 Dec 1999, Rodney W. Grimes wrote: > > > On Tue, 28 Dec 1999, Spidey wrote: > > > > I was also wondering... If we can modify the status (RW/RO) of a > > > > mounted filesystem (/ included) with mount -u, why bother? :)) > > > > > > > > What is the purpose of mounting a filesystem ReadOnly, since it can be > > > > disabled? Does it serve the same function as the schg flag? I think > > > > the securelevel does not change this behavior, right? > > > > > > Mounting a filesystem read-only is not a security measure. > > I disagree, mounting a filesystem read-only _is_ a security measure, it > > can prevent certain attacks that may not have compromised root, but > > say they did manage to compromise something that would allow them to > > write a file in /usr/bin, if /usr/bin/ is read-only the are SOL, if > > it is r/w they be having root in a few minutes... > > Not really. If anyone other than root can write to /bin, /usr/bin, or any > other directory containing binaries root might run, then your permissions > are set up incorrectly. And if I manage to clobber a file using ill-gained root privilege, then I win. Would you like to know how many security issues I've tracked back to files getting clobbered via some root privilege hole? _Most_ of them. > > ls -la /usr/bin |head > total 14697 > drwxr-xr-x 2 root wheel 6656 Dec 17 22:06 . > drwxr-xr-x 20 root wheel 512 Dec 2 10:05 .. > -r-xr-xr-x 3 root wheel 68076 Dec 2 02:46 CC > -r-xr-xr-x 2 root wheel 64876 Dec 2 02:50 Mail > -r-xr-xr-x 1 root wheel 99254 Dec 2 02:48 a2p > -r-xr-xr-x 1 root wheel 36992 Dec 2 02:46 addftinfo > -r-xr-xr-x 14 root wheel 50928 Dec 2 02:50 addr2line > -r-xr-xr-x 1 root wheel 5184 Dec 2 02:50 apply > -r-xr-xr-x 2 root wheel 2245 Dec 2 02:46 apropos > > All binaries have write permissions turned off, root owns all binaries, > and only root can write to the directory. The only thing read-only > mounting the filesystem protects you from is someone who's found a hole > that lets him write arbitrary data as root at an arbitrary point on the > filesystem, and by that point I'd be willing to bet that you've already > lost, since he can probably nail /etc/swpd.db, /etc/rc, or any number of > other things. We were originally discussing / read-only, which kinda exempts things in /etc from being vulnerable. > schg flags and securelevels are your friends when it comes > to protecting binaries and configuration data. Protecting the password > file is a bit trickier... I guess there is no substitute for a thorough > code review. Protecting the password file isn't tricky, if you don't need it to change very often. :-) I schg very large portions of a system by default, on the basis that I really don't want it to change unless I go dink with the machine on the console. This is not mutually incompatible with ro mounts, however. ro mounts may be an option for a filesystem where you normally want the entire thing to be frozen, but you may wish to make changes while in multiuser mode (something you can't do with schg). schg has much finer-grained control over individual files, but is hell if you really need to change a file on a running system without rebooting. Both will protect you from overwrite-via- root-privilege-hole exploits. ro won't protect you if they actually gain a root shell. A well-implemented schg strategy will make life hell for an intruder, possibly at the risk of making life difficult for the admin. And using both together provides additional layers of frustration for any would-be hacker. If you want to talk paranoia and layers of frustration, this shell server I'm on: Diskless boots off of a NFS server that is protected up the wazoo, Mounts its filesystems RO, The NFS server exports its filesystems RO, and the underlying filesystems are mounted RO, and the files are _still_ schg protected. I do not have many fears of people overwriting my binaries, but running tripwire periodically is still smart. I resisted the temptation of wiring the RO jumper on the hard drive to a switch on the panel. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 30 23:37:16 1999 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 2BF3914DBF for ; Thu, 30 Dec 1999 23:37:15 -0800 (PST) (envelope-from jwyatt@rwsystems.net) Received: from bsdie.rwsystems.net([209.197.223.2]) (935 bytes) by bsdie.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Fri, 31 Dec 1999 01:33:51 -0600 (CST) (Smail-3.2.0.106 1999-Mar-31 #1 built 1999-Aug-7) Date: Fri, 31 Dec 1999 01:33:51 -0600 (CST) From: James Wyatt To: TrouBle Cc: freebsd-security@FreeBSD.ORG Subject: Re: IDS recommendations In-Reply-To: <386B9258.893C7483@netquick.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 We're using snort from the ports/packages with some rule tuning. It leaves a bit to be desired in companies with several subnets to watch for, but is a good start and tool in a toolbox. - Jy@ On Thu, 30 Dec 1999, TrouBle wrote: > What would you all recommend for IDS systems that run under FreeBSD ??? > -- > ...and that is how we know the Earth to be banana-shaped. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 31 15:41:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6770115648 for ; Fri, 31 Dec 1999 15:41:33 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA52234; Fri, 31 Dec 1999 16:41:31 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA18868; Fri, 31 Dec 1999 16:41:31 -0700 (MST) Message-Id: <199912312341.QAA18868@harmony.village.org> To: Robert Watson Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) Cc: Chris England , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Dec 1999 09:18:00 EST." References: Date: Fri, 31 Dec 1999 16:41:31 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Robert Watson writes: : So, I'm sorry, could you be specific here: was this problem reported to : security-officer@freebsd.org, or reported via a send-pr, or not reported : to us? Reported to a swamped security officer. : Would it be feasible for someone to go disable setuid bits in all the : games/ tree? :-) Why was xsoldier setuid? High scores. We'll be bringing on someone to the security officer team after the first of the year to help us keep up with ports. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message