From owner-freebsd-security Sun Aug 3 07:06:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA25318 for security-outgoing; Sun, 3 Aug 1997 07:06:30 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA25313 for ; Sun, 3 Aug 1997 07:06:27 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id KAA04700 for ; Sun, 3 Aug 1997 10:05:46 GMT Date: Sun, 3 Aug 1997 10:05:45 +0000 (GMT) From: "Jonathan A. Zdziarski" To: security@freebsd.org Subject: setuid shutdown? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just realized that my version of freebsd 2.2.2 installs with a set-uid-root shutdown command allowing anybody who wants to to shutdown or reboot the server. Obviously I removed the bits, and got rid of the problem, but you might all want to check that. I currently have sudo installed, and am able to unsuid quite a few other programs and run them under sudo (which logs nicely what my employees are doing too). Also: I noticed that 2.2.2 installs /usr/bin/perl (4) and a setuid root version of it as well (found this out when I noticed that adduser and rmuser are perl and not c). If I'm not mistaken 4 has some major security problems with setuid perl, no? ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Sun Aug 3 07:33:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA26325 for security-outgoing; Sun, 3 Aug 1997 07:33:42 -0700 (PDT) Received: from grunt.vl.kharkov.ua (news@grunt.vl.kharkov.ua [193.124.76.209]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26320 for ; Sun, 3 Aug 1997 07:33:35 -0700 (PDT) Received: (from news@localhost) by grunt.vl.kharkov.ua (8.8.6/8.8.6) id SAA26084 for dev.null; Sun, 3 Aug 1997 18:39:12 +0300 (EEST) To: freebsd-security@freebsd.org Subject: Re: setuid shutdown? Date: 3 Aug 1997 18:39:10 +0300 Message-ID: <5s28mu$pev$1@grunt.vl.kharkov.ua> X-Newsreader: TIN [UNIX 1.3 unoff BETA 970709; i386 FreeBSD 2.2.2-RELEASE] X-Via: News-To-Mail v1.0 From: Vladimir Litovka Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! Jonathan A. Zdziarski wrote: > I just realized that my version of freebsd 2.2.2 installs with a > set-uid-root shutdown command allowing anybody who wants to to shutdown or > reboot the server. Why anybody? /sbin/shutdown installed as: -r-sr-x--- root operator shutdown So only users, that is in 'operator' group allowed to start this program. This is enought security, I think. Sinc, Doka ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~NewsGate~ (c) Vladimir Litovka From owner-freebsd-security Sun Aug 3 07:35:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA26551 for security-outgoing; Sun, 3 Aug 1997 07:35:20 -0700 (PDT) Received: from shell.monmouth.com (root@shell.monmouth.com [205.164.220.9]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26544 for ; Sun, 3 Aug 1997 07:35:18 -0700 (PDT) Received: from i4got.lakewood.com (fh-ppp23.monmouth.com [205.164.221.55]) by shell.monmouth.com (8.8.5/8.7.3) with ESMTP id KAA25973; Sun, 3 Aug 1997 10:32:47 -0400 (EDT) Received: (from pechter@localhost) by i4got.lakewood.com id KAA02364 (8.8.5/IDA-1.6); Sun, 3 Aug 1997 10:35:02 -0400 (EDT) From: Bill Pechter Message-ID: <199708031435.KAA02364@i4got.lakewood.com> Subject: Re: setuid shutdown? In-Reply-To: from "Jonathan A. Zdziarski" at "Aug 3, 97 10:05:45 am" To: jonz@netrail.net (Jonathan A. Zdziarski) Date: Sun, 3 Aug 1997 10:35:02 -0400 (EDT) Cc: freebsd-security@freebsd.org Reply-to: pechter@lakewood.com X-Phone-Number: 908-389-3592 X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I just realized that my version of freebsd 2.2.2 installs with a > set-uid-root shutdown command allowing anybody who wants to to shutdown or > reboot the server. Obviously I removed the bits, and got rid of the > problem, but you might all want to check that. I currently have sudo > installed, and am able to unsuid quite a few other programs and run them > under sudo (which logs nicely what my employees are doing too). > -r-sr-x--- 1 root operator 151552 Jun 10 13:59 /sbin/shutdown According to the permissions only root and members of the operator group can do shutdown with this version of shutdown (2.2.2-RELEASE) Bill ------------------------------------------------------------------------------ Bill Pechter | 17 Meredith Drive Tinton Falls, NJ 07724 | 908-389-3592 pechter@lakewood.com | Save computing history, give an old geek old hardware. This msg brought to you by the letters PDP and the number 11. From owner-freebsd-security Sun Aug 3 07:39:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA26877 for security-outgoing; Sun, 3 Aug 1997 07:39:40 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26869 for ; Sun, 3 Aug 1997 07:39:37 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id AAA14256; Mon, 4 Aug 1997 00:09:30 +0930 (CST) From: Michael Smith Message-Id: <199708031439.AAA14256@genesis.atrad.adelaide.edu.au> Subject: Re: setuid shutdown? In-Reply-To: from "Jonathan A. Zdziarski" at "Aug 3, 97 10:05:45 am" To: jonz@netrail.net (Jonathan A. Zdziarski) Date: Mon, 4 Aug 1997 00:09:30 +0930 (CST) Cc: security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jonathan A. Zdziarski stands accused of saying: > I just realized that my version of freebsd 2.2.2 installs with a > set-uid-root shutdown command allowing anybody who wants to to shutdown or > reboot the server. silver:~>ls -l `which shutdown` -r-sr-x--- 1 root operator 135168 Jun 7 18:37 /sbin/shutdown This is consistent with what 'operator' means in my book. 8) > Also: I noticed that 2.2.2 installs /usr/bin/perl (4) and a setuid root > version of it as well (found this out when I noticed that adduser and > rmuser are perl and not c). If I'm not mistaken 4 has some major security > problems with setuid perl, no? Correct. If you are running a production system you should have read all of the advisories released since 2.2.2, and preferably be tracking -stable on a support system, or installing the rolling 2.2-stable snapshots post-advisory. At this stage, there is not a security-update-patch mechanism more advanced that this. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Sun Aug 3 07:52:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA27323 for security-outgoing; Sun, 3 Aug 1997 07:52:16 -0700 (PDT) Received: from firewall.ftf.dk (root@[129.142.64.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA27318 for ; Sun, 3 Aug 1997 07:52:12 -0700 (PDT) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id RAA12863; Sun, 3 Aug 1997 17:17:15 +0200 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id QAA08144; Sun, 3 Aug 1997 16:52:31 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.5/8.8.5/prosa-1.1) id QAA20437; Sun, 3 Aug 1997 16:51:16 +0200 (CEST) Message-ID: <19970803165116.24551@deepo.prosa.dk> Date: Sun, 3 Aug 1997 16:51:16 +0200 From: Philippe Regnauld To: "Jonathan A. Zdziarski" Cc: freebsd-security@freebsd.org Subject: Re: setuid shutdown? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: Main Body X-Mailer: Mutt 0.69 In-Reply-To: ; from Jonathan A. Zdziarski on Sun, Aug 03, 1997 at 10:05:45AM +0000 X-Operating-System: FreeBSD 2.2.1-RELEASE i386 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jonathan A. Zdziarski writes: > > Also: I noticed that 2.2.2 installs /usr/bin/perl (4) and a setuid root > version of it as well (found this out when I noticed that adduser and > rmuser are perl and not c). If I'm not mistaken 4 has some major security > problems with setuid perl, no? Fixed in FreeBSD 2.2.1, IIRC -- check the list archives. -- -- Phil -[ Philippe Regnauld / Systems Administrator / regnauld@prosa.dk ]- -[ Location.: +55.4N +11.3E PGP Key: finger regnauld@hotel.prosa.dk ]- From owner-freebsd-security Sun Aug 3 08:21:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA28351 for security-outgoing; Sun, 3 Aug 1997 08:21:14 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28345 for ; Sun, 3 Aug 1997 08:21:11 -0700 (PDT) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id KAA15784; Sun, 3 Aug 1997 10:21:10 -0500 (CDT) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.5/8.8.2) id KAA26646; Sun, 3 Aug 1997 10:21:09 -0500 (CDT) Message-ID: <19970803102109.40387@Jupiter.Mcs.Net> Date: Sun, 3 Aug 1997 10:21:09 -0500 From: Karl Denninger To: Marc Slemko Cc: freebsd-security@FreeBSD.ORG Subject: Re: Vulnerability in 4.4BSD rfork() implementation References: <199708030102.UAA20008@enteract.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: ; from Marc Slemko on Sat, Aug 02, 1997 at 09:53:52PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The patch does not build on -CURRENT; the make process returns a complaint for the DISPATCH macro. The kernel patch *is* effective. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal On Sat, Aug 02, 1997 at 09:53:52PM -0600, Marc Slemko wrote: > On Sat, 2 Aug 1997, Thomas H. Ptacek wrote: > > > ---------------------------------------------------------------------------- > > > > OpenBSD Security Advisory > > > > August 2, 1997 > > > > Vulnerability in rfork() System Call > > > > ---------------------------------------------------------------------------- > > > > SYNOPSIS > > > > A vulnerability in certain 4.4BSD kernels allows processes to gain > > access to restricted resources by manipulating the file descriptor > > tables of SUID and SGID executables. Applications of this vulnerability > > will allow users to gain root access. > > > > ---------------------------------------------------------------------------- > > > > AFFECTED SYSTEMS > > > > It is believed that all 4.4BSD operating systems implementing the > > rfork() system call are currently vulnerable to this problem. These > > operating systems include OpenBSD 2.1 and FreeBSD 3.0. The OpenBSD > > project has resolved this problem in OpenBSD-current. > > Since this wasn't entirely clear on some of the FreeBSD aspects, a few > comments... > > First, this is a real hole. Earlier today it took me only a few minutes > to make a program to add another uid 0 to your passwd file to give you > root access. With the skeleton code posted in this advisory, it is even > easier. > > Secondly, FreeBSD 2.2 (probably any version of 2.2-current starting > around 1996/02/23) and 3.0 are both vulnerable. 2.1 and earlier are not. > > Third, I would recommend the use of the loadable module included in the > advisory to close the hole temporarily until there is a FreeBSD advisory > or patch. While the supplied patch for kern_exec looks fine, using the > module is easier and saves you having to do things twice when an official > patch comes out. Few things (very few...) use rfork() so it shouldn't > hurt much. > > To use the loadable module, unarchive the shell archive included in the > origial post, type "make", then do something like: > > modload -e disable_rfork disable_rfork.o > > as root. You should get a kernel message that the rfork() call is > disabled. You should probably make it load at boot to prevent someone > from deliberately crashing the system to remove the protection. > From owner-freebsd-security Sun Aug 3 08:39:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA28961 for security-outgoing; Sun, 3 Aug 1997 08:39:42 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28955 for ; Sun, 3 Aug 1997 08:39:39 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id LAA09248; Sun, 3 Aug 1997 11:38:55 GMT Date: Sun, 3 Aug 1997 11:38:55 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Bill Pechter cc: freebsd-security@freebsd.org Subject: Re: setuid shutdown? In-Reply-To: <199708031435.KAA02364@i4got.lakewood.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hmm mine was globably executable ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- On Sun, 3 Aug 1997, Bill Pechter wrote: :> I just realized that my version of freebsd 2.2.2 installs with a :> set-uid-root shutdown command allowing anybody who wants to to shutdown or :> reboot the server. Obviously I removed the bits, and got rid of the :> problem, but you might all want to check that. I currently have sudo :> installed, and am able to unsuid quite a few other programs and run them :> under sudo (which logs nicely what my employees are doing too). :> : :-r-sr-x--- 1 root operator 151552 Jun 10 13:59 /sbin/shutdown : :According to the permissions only root and members of the operator :group can do shutdown with this version of shutdown (2.2.2-RELEASE) : :Bill :------------------------------------------------------------------------------ : Bill Pechter | 17 Meredith Drive Tinton Falls, NJ 07724 | 908-389-3592 : pechter@lakewood.com | Save computing history, give an old geek old hardware. : This msg brought to you by the letters PDP and the number 11. : From owner-freebsd-security Sun Aug 3 09:53:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA02135 for security-outgoing; Sun, 3 Aug 1997 09:53:49 -0700 (PDT) Received: from grunt.vl.kharkov.ua (news@grunt.vl.kharkov.ua [193.124.76.209]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA02123 for ; Sun, 3 Aug 1997 09:53:29 -0700 (PDT) From: doka@vl.kharkov.ua Received: (from news@localhost) by grunt.vl.kharkov.ua (8.8.6/8.8.6) id UAA27012 for dev.null; Sun, 3 Aug 1997 20:58:34 +0300 (EEST) To: freebsd-security@freebsd.org Subject: CERT advisories - where? Date: 3 Aug 1997 20:58:33 +0300 Message-ID: <5s2gs9$qbv$1@grunt.vl.kharkov.ua> X-Newsreader: TIN [UNIX 1.3 unoff BETA 970709; i386 FreeBSD 2.2.2-RELEASE] X-Via: News-To-Mail v1.0 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! Where I can subscribe on security advisores - from CERT, OpenBSD, etc. As I know, not only CERT send this, but many firms (IBM, for example). Does anybody knows such servers? Thanks in advance. Sinc, Doka ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~NewsGate~ (c) Vladimir Litovka From owner-freebsd-security Sun Aug 3 11:13:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA06030 for security-outgoing; Sun, 3 Aug 1997 11:13:02 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA06021 for ; Sun, 3 Aug 1997 11:13:00 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id OAA16795; Sun, 3 Aug 1997 14:12:00 GMT Date: Sun, 3 Aug 1997 14:12:00 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Vladimir Litovka cc: freebsd-security@FreeBSD.ORG Subject: Re: setuid shutdown? In-Reply-To: <5s28mu$pev$1@grunt.vl.kharkov.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yah that's enough, I was concerned b/c mine was executable by everybody. ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- On 3 Aug 1997, Vladimir Litovka wrote: :Hello! : :Jonathan A. Zdziarski wrote: : :> I just realized that my version of freebsd 2.2.2 installs with a :> set-uid-root shutdown command allowing anybody who wants to to shutdown or :> reboot the server. : :Why anybody? /sbin/shutdown installed as: : -r-sr-x--- root operator shutdown : :So only users, that is in 'operator' group allowed to start this program. :This is enought security, I think. : :Sinc, Doka : :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : ~NewsGate~ (c) Vladimir Litovka : From owner-freebsd-security Sun Aug 3 11:21:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA06639 for security-outgoing; Sun, 3 Aug 1997 11:21:45 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA06622 for ; Sun, 3 Aug 1997 11:21:39 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id LAA18374 for security@freebsd.org; Sun, 3 Aug 1997 11:21:38 -0700 Date: Sun, 3 Aug 1997 11:21:38 -0700 From: Sean Eric Fagan Message-Id: <199708031821.LAA18374@kithrup.com> To: security@freebsd.org Subject: Proposed alternate patch for the rfork vulnerability Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I haven't looked at the rfork code extensively... I should. However, something similar to the following should be done for every shared resource that might be inhereted across a fork. (However, what are those? Looking at /sys/sys/unistd.h, it doesn't look like we actually implement anything other than shared VM [which is hosed across an exec anyway], no wait on child [which isn't relevent to this], and the fd table copying and zeroing... and that's what comes into play across an exec... So maybe this is all that should be necessary.) I haven't extensively tested this; I ran the included program, and I am currently up multiuser with my patched kernel. *** kern_exec.c.~1~ Sat Nov 9 02:42:28 1996 --- kern_exec.c Sun Aug 3 11:14:06 1997 *************** *** 325,330 **** --- 325,338 ---- vrele(ndp->ni_vp); FREE(ndp->ni_cnd.cn_pnbuf, M_NAMEI); + if (p->p_fd->fd_refcnt > 1) { + struct filedesc *tmp; + + tmp = fdcopy(p); + fdfree(p); + p->p_fd = tmp; + } + return (0); exec_fail_dealloc: From owner-freebsd-security Sun Aug 3 12:03:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA09375 for security-outgoing; Sun, 3 Aug 1997 12:03:25 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA09368 for ; Sun, 3 Aug 1997 12:03:20 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id MAA02954; Sun, 3 Aug 1997 12:02:51 -0700 (PDT) To: "Jonathan A. Zdziarski" cc: security@FreeBSD.ORG Subject: Re: setuid shutdown? In-reply-to: Your message of "Sun, 03 Aug 1997 10:05:45 -0000." Date: Sun, 03 Aug 1997 12:02:51 -0700 Message-ID: <2950.870634971@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I just realized that my version of freebsd 2.2.2 installs with a > set-uid-root shutdown command allowing anybody who wants to to shutdown or > reboot the server. Obviously I removed the bits, and got rid of the Uh, no, that's not correct. Shutdown's permissions, as installed in 2.2.2, are: -r-sr-x--- 1 root operator 139264 Jul 15 02:08 /sbin/shutdown Joe User *cannot* shut the system down because Joe user can't even execute the damn thing. Did you actually CHECK this before you sent this bug report in? :-) > Also: I noticed that 2.2.2 installs /usr/bin/perl (4) and a setuid root > version of it as well (found this out when I noticed that adduser and > rmuser are perl and not c). If I'm not mistaken 4 has some major security > problems with setuid perl, no? You need to read the CERT advisories - a patch for this has existed for ages now. Jordan From owner-freebsd-security Sun Aug 3 12:13:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA10063 for security-outgoing; Sun, 3 Aug 1997 12:13:55 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10058 for ; Sun, 3 Aug 1997 12:13:52 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id PAA19881; Sun, 3 Aug 1997 15:13:06 GMT Date: Sun, 3 Aug 1997 15:13:06 +0000 (GMT) From: "Jonathan A. Zdziarski" To: "Jordan K. Hubbard" cc: security@FreeBSD.ORG Subject: Re: setuid shutdown? In-Reply-To: <2950.870634971@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yes I did check it out before reporting it I'm not an idiot. Perhaps it was set that way by somebody else before I took over the position, either way I noticed they were all globally executable. I'm glad that it's not the default of the installation. ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- On Sun, 3 Aug 1997, Jordan K. Hubbard wrote: :> I just realized that my version of freebsd 2.2.2 installs with a :> set-uid-root shutdown command allowing anybody who wants to to shutdown or :> reboot the server. Obviously I removed the bits, and got rid of the : :Uh, no, that's not correct. Shutdown's permissions, as installed in :2.2.2, are: : :-r-sr-x--- 1 root operator 139264 Jul 15 02:08 /sbin/shutdown : :Joe User *cannot* shut the system down because Joe user can't even :execute the damn thing. : :Did you actually CHECK this before you sent this bug report in? :-) : :> Also: I noticed that 2.2.2 installs /usr/bin/perl (4) and a setuid root :> version of it as well (found this out when I noticed that adduser and :> rmuser are perl and not c). If I'm not mistaken 4 has some major security :> problems with setuid perl, no? : :You need to read the CERT advisories - a patch for this has existed for :ages now. : : Jordan : From owner-freebsd-security Sun Aug 3 16:22:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA25533 for security-outgoing; Sun, 3 Aug 1997 16:22:32 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA25526 for ; Sun, 3 Aug 1997 16:22:25 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id JAA29291; Mon, 4 Aug 1997 09:26:03 +1000 (EST) Date: Mon, 4 Aug 1997 09:26:02 +1000 (EST) From: "Daniel O'Callaghan" To: doka@vl.kharkov.ua cc: freebsd-security@FreeBSD.ORG Subject: Re: CERT advisories - where? In-Reply-To: <5s2gs9$qbv$1@grunt.vl.kharkov.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 3 Aug 1997 doka@vl.kharkov.ua wrote: > Where I can subscribe on security advisores - from CERT, OpenBSD, etc. > As I know, not only CERT send this, but many firms (IBM, for example). > Does anybody knows such servers? Thanks in advance. Subscribe to BUGTRAQ - listserv@netspace.org. CERT, FreeBSD, AusCERT, OpenBSD, NetBSD and other advisories are sent there, plus discussion and exploits. Danny From owner-freebsd-security Sun Aug 3 16:50:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA26797 for security-outgoing; Sun, 3 Aug 1997 16:50:26 -0700 (PDT) Received: from counterintelligence.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA26789 for ; Sun, 3 Aug 1997 16:50:22 -0700 (PDT) Received: from localhost (jamil@localhost) by counterintelligence.ml.org (8.8.6/8.8.5) with SMTP id QAA00399 for ; Sun, 3 Aug 1997 16:49:54 -0700 (PDT) Date: Sun, 3 Aug 1997 16:49:52 -0700 (PDT) From: "Jamil J. Weatherbee" To: freebsd-security@freebsd.org Subject: Firewalling / DNS problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk this is in freebsd-stable RELENG I found the following problem on two different freebsd machine connected to the internet on one interface (the ip address ill call 111.222.333.444) i use the particualr machine as a tftp server (udp) for some diskless booting workstations (on its ethernet interface 192.168.1.1) it also has a ppp interface 111.222.333.444. Now realizing that tftp does not authenticate its clients i thought it would be nice to put up a firewall rule on this machine to block tftp request from the outside to the ppp interface (i want to allow them only to the ethernet interface on my lan) since it is possible to have some sensitive info in my /tftpboot directory that is world readable, and i dont want the whole world looking at it. i did a: (on a firewall="open" type setup in rc.conf) ipfw add 1100 deny udp from any to 111.222.333.444/32 tftp and verified that i could access with tftp from the inside but not the outside --- everything worked fine until... a couple of days later i notice that the was large amounts of mail sitting in the mail queue with name lookup defferred errors on it. So i tried doing host -d on a couple of those hosts and notice that many of the hosts this doesn't work for (many timeouts on the local nameserver 127.0.0.1) also the tally for drops on 111.222.333.444 port 69 (udp) is rather high -- after removing this entry all the mail is cleared from the queue but reenabling it causes the problem again (in other words i have verified it --- also on another unrelated machine). The question is why are outside sending udp packets to port 69 during name lookups. The following machines cause this: host -d rs0.internic.net host -d hotmail.com host -d best.com these didn't: host -d freebsd.org host -d cdrom.com i cant think of anymore, please help. From owner-freebsd-security Mon Aug 4 00:02:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA18508 for security-outgoing; Mon, 4 Aug 1997 00:02:04 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA18500 for ; Mon, 4 Aug 1997 00:02:00 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id QAA08668; Mon, 4 Aug 1997 16:51:41 +1000 Date: Mon, 4 Aug 1997 16:51:41 +1000 From: Bruce Evans Message-Id: <199708040651.QAA08668@godzilla.zeta.org.au> To: security@freebsd.org, sef@Kithrup.COM Subject: Re: Proposed alternate patch for the rfork vulnerability Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I haven't looked at the rfork code extensively... I should. However, >something similar to the following should be done for every shared resource >that might be inhereted across a fork. (However, what are those? Looking at I think exec should just fail if it can't honour setuid'ness. For ptrace it is OK to turn off the trace bit and succeed, since tracing is unlikely to be essential to the operation of the new process image, but ignoring the setuid bit or changing the resources may affect operation. Bruce From owner-freebsd-security Mon Aug 4 09:26:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA08705 for security-outgoing; Mon, 4 Aug 1997 09:26:10 -0700 (PDT) Received: from enteract.com (enteract.com [206.54.252.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA08700 for ; Mon, 4 Aug 1997 09:26:03 -0700 (PDT) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id LAA21165; Mon, 4 Aug 1997 11:25:46 -0500 (CDT) From: "Thomas H. Ptacek" Message-Id: <199708041625.LAA21165@enteract.com> Subject: Re: Proposed alternate patch for the rfork vulnerability To: bde@zeta.org.au (Bruce Evans) Date: Mon, 4 Aug 1997 11:25:46 -0500 (CDT) Cc: security@FreeBSD.ORG, sef@Kithrup.COM Reply-To: tqbf@enteract.com In-Reply-To: <199708040651.QAA08668@godzilla.zeta.org.au> from "Bruce Evans" at Aug 4, 97 04:51:41 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I think exec should just fail if it can't honour setuid'ness. For ptrace Why? What does this win? ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?" From owner-freebsd-security Mon Aug 4 09:43:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA09605 for security-outgoing; Mon, 4 Aug 1997 09:43:20 -0700 (PDT) Received: from enteract.com (enteract.com [206.54.252.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA09600 for ; Mon, 4 Aug 1997 09:43:17 -0700 (PDT) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id LAA24267; Mon, 4 Aug 1997 11:43:09 -0500 (CDT) From: "Thomas H. Ptacek" Message-Id: <199708041643.LAA24267@enteract.com> Subject: Re: Vulnerability in 4.4BSD rfork() implementation To: marcs@znep.com (Marc Slemko) Date: Mon, 4 Aug 1997 11:43:08 -0500 (CDT) Cc: freebsd-security@FreeBSD.ORG Reply-To: tqbf@enteract.com In-Reply-To: from "Marc Slemko" at Aug 2, 97 09:53:52 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > root access. With the skeleton code posted in this advisory, it is even > easier. Sorry about that. > Secondly, FreeBSD 2.2 (probably any version of 2.2-current starting > around 1996/02/23) and 3.0 are both vulnerable. 2.1 and earlier are not. Sorry about that. > Third, I would recommend the use of the loadable module included in the > advisory to close the hole temporarily until there is a FreeBSD advisory You've mentioned the only real problem with this: if the module is unloaded or the system reboots and it isn't replaced, you've lost root. If you want to finalize this change on your system, replace the function pointer "rfork" in kern/init_sysent.c with "nosys" and recompile. Also, many of my systems don't run with LKM support; however, my module doesn't actually "load" anything, it just takes advantage of the bootstrap function to get at kernel memory. If you want to chop rfork() out of your system without using an LKM, I've included a short C program here to do that through /dev/kmem; you can use it instead if you feel like living dangerously. To compile, do "cc -g -o disable_rfork disable_rfork.c -lkvm". -- cut here -- #include #include #include #include #include #include #include #include #include #include #include #include #define PATH_KVM "/dev/kmem" #define RFORK_SYSCALL 251 #define SYSCALL_TABLE_NAME "_sysent" #define BAD_SYSTEM_CALL_HANDLER "_nosys" #define SYSENT_VECTOR "_aout_sysvec" int main() { int sycall; int fd, i; kvm_t *kt; struct nlist name[4]; struct sysent *sp; struct sysentvec *sv; sycall = RFORK_SYSCALL; fd = open(PATH_KVM, O_RDWR); if(fd < 0) { perror("kmem open failure"); exit(errno); } kt = kvm_open(NULL, NULL, NULL, O_RDONLY, "kvm open"); if(!kt) exit(errno); name[0].n_un.n_name = SYSCALL_TABLE_NAME; name[1].n_un.n_name = BAD_SYSTEM_CALL_HANDLER; name[2].n_un.n_name = SYSENT_VECTOR; name[3].n_un.n_name = NULL; if((i = kvm_nlist(kt, name)) < 0) { fprintf(stderr, "unable to locate data (%d): %s\n", i, strerror(errno)); exit(errno); } if(lseek(fd, name[2].n_value, SEEK_SET) < 0) { perror("lseek"); exit(errno); } sv = malloc(sizeof(*sv)); if(!sv) { fprintf(stderr, "malloc failure\n"); exit(-1); } if(read(fd, (u_char *) sv, sizeof(struct sysentvec)) < sizeof(struct sysentvec)) { perror("syscall vector read"); exit(errno); } if(sycall > (sv->sv_size - 1) || sv < 0) { fprintf(stderr, "System call out of bounds! (%d)\n", sv->sv_size); exit(-1); } if(lseek(fd, name[0].n_value + (sycall * sizeof(struct sysent)), SEEK_SET) < 0) { perror("seek"); exit(errno); } sp = malloc(sizeof(struct sysent)); if(!sp) { fprintf(stderr, "malloc failure\n"); exit(errno); } if(read(fd, (u_char *) sp, sizeof(*sp)) < sizeof(*sp)) { perror("read sysent"); exit(errno); } if(lseek(fd, name[0].n_value + (sycall * sizeof(struct sysent)), SEEK_SET) < 0) { perror("seek"); exit(errno); } sp->sy_call = (int (*)()) name[1].n_value; if((i = write(fd, (u_char *) sp, sizeof(*sp))) < sizeof(*sp)) { perror("write"); if(i) { fprintf(stderr, "Some data written; now" " would be a good time to" " shut down gracefully\n"); exit(-1); } } exit(0); } From owner-freebsd-security Mon Aug 4 10:01:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA10909 for security-outgoing; Mon, 4 Aug 1997 10:01:05 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA10897 for ; Mon, 4 Aug 1997 10:01:01 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id CAA02664; Tue, 5 Aug 1997 02:58:51 +1000 Date: Tue, 5 Aug 1997 02:58:51 +1000 From: Bruce Evans Message-Id: <199708041658.CAA02664@godzilla.zeta.org.au> To: bde@zeta.org.au, tqbf@enteract.com Subject: Re: Proposed alternate patch for the rfork vulnerability Cc: security@FreeBSD.ORG, sef@Kithrup.COM Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I think exec should just fail if it can't honour setuid'ness. For ptrace > >Why? What does this win? Conformance with the rfork man page: ! RFFDG If set, the invoker's file descriptor table (see intro(2) ! ) is copied; otherwise the two processes share a single ! table. !... ! File descriptors in a shared file descriptor table are kept open until ! either they are explicitly closed or all processes sharing the table ex- ! it. It doesn't say that exec turns off the sharing. Bruce From owner-freebsd-security Mon Aug 4 10:04:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA11286 for security-outgoing; Mon, 4 Aug 1997 10:04:06 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA11275 for ; Mon, 4 Aug 1997 10:04:00 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id KAA16417; Mon, 4 Aug 1997 10:03:55 -0700 Date: Mon, 4 Aug 1997 10:03:55 -0700 From: Sean Eric Fagan Message-Id: <199708041703.KAA16417@kithrup.com> To: bde@zeta.org.au, tqbf@enteract.com Subject: Re: Proposed alternate patch for the rfork vulnerability Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm sorry, Bruce, but having the file descriptor sharing break on exec is the ONLY way to have it make sense, let alone be secure. Note that exit closes file descriptors. So I guess exit should close all file descriptors for all processes, huh? From owner-freebsd-security Mon Aug 4 10:37:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA14664 for security-outgoing; Mon, 4 Aug 1997 10:37:35 -0700 (PDT) Received: from enteract.com (enteract.com [206.54.252.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA14647 for ; Mon, 4 Aug 1997 10:37:30 -0700 (PDT) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id MAA01264; Mon, 4 Aug 1997 12:22:09 -0500 (CDT) From: "Thomas H. Ptacek" Message-Id: <199708041722.MAA01264@enteract.com> Subject: Re: Proposed alternate patch for the rfork vulnerability To: bde@zeta.org.au (Bruce Evans) Date: Mon, 4 Aug 1997 12:22:07 -0500 (CDT) Cc: bde@zeta.org.au, tqbf@enteract.com, security@FreeBSD.ORG, sef@Kithrup.COM Reply-To: tqbf@enteract.com In-Reply-To: <199708041658.CAA02664@godzilla.zeta.org.au> from "Bruce Evans" at Aug 5, 97 02:58:51 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >> I think exec should just fail if it can't honour setuid'ness. For ptrace > >Why? What does this win? > Conformance with the rfork man page: > It doesn't say that exec turns off the sharing. exeve() doesn't "turn off the sharing". Execution of an SUID program in a process that shares a file descriptor table causes the SUID bit not to be honored; this is a semantic with precedent (NOSUID, ptrace). ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?" From owner-freebsd-security Mon Aug 4 10:41:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA14945 for security-outgoing; Mon, 4 Aug 1997 10:41:23 -0700 (PDT) Received: from enteract.com (enteract.com [206.54.252.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA14940 for ; Mon, 4 Aug 1997 10:41:20 -0700 (PDT) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id MAA04433; Mon, 4 Aug 1997 12:41:10 -0500 (CDT) From: "Thomas H. Ptacek" Message-Id: <199708041741.MAA04433@enteract.com> Subject: Re: Proposed alternate patch for the rfork vulnerability To: sef@Kithrup.COM (Sean Eric Fagan) Date: Mon, 4 Aug 1997 12:41:09 -0500 (CDT) Cc: bde@zeta.org.au, tqbf@enteract.com, security@FreeBSD.ORG Reply-To: tqbf@enteract.com In-Reply-To: <199708041703.KAA16417@kithrup.com> from "Sean Eric Fagan" at Aug 4, 97 10:03:55 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm sorry, Bruce, but having the file descriptor sharing break on > exec is the ONLY way to have it make sense, let alone be secure. The problem is specifically an issue with an interaction between the rfork() resource sharing semantics and the SUID bit. The problem is equally well solved by ignoring the SUID bit. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?" From owner-freebsd-security Mon Aug 4 10:56:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA15865 for security-outgoing; Mon, 4 Aug 1997 10:56:04 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA15853 for ; Mon, 4 Aug 1997 10:56:01 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id DAA05901; Tue, 5 Aug 1997 03:53:05 +1000 Date: Tue, 5 Aug 1997 03:53:05 +1000 From: Bruce Evans Message-Id: <199708041753.DAA05901@godzilla.zeta.org.au> To: bde@zeta.org.au, tqbf@enteract.com Subject: Re: Proposed alternate patch for the rfork vulnerability Cc: security@FreeBSD.ORG, sef@Kithrup.COM Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >exeve() doesn't "turn off the sharing". Execution of an SUID program in a >process that shares a file descriptor table causes the SUID bit not to be >honored; this is a semantic with precedent (NOSUID, ptrace). I would argue that ptrace is broken (but has to stay that way for historical reasons). It isn't very useful to lose control on exec - if you want that then you can detach before exec. Losing the shared descriptor table on exec is also useless. If the table is shared then you probably want it to continue to be shared. This only causes security problems in the setuid case. Bruce From owner-freebsd-security Mon Aug 4 11:00:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA16124 for security-outgoing; Mon, 4 Aug 1997 11:00:57 -0700 (PDT) Received: from enteract.com (enteract.com [206.54.252.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA16113 for ; Mon, 4 Aug 1997 11:00:53 -0700 (PDT) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id NAA07897; Mon, 4 Aug 1997 13:00:35 -0500 (CDT) From: "Thomas H. Ptacek" Message-Id: <199708041800.NAA07897@enteract.com> Subject: Re: Proposed alternate patch for the rfork vulnerability To: bde@zeta.org.au (Bruce Evans) Date: Mon, 4 Aug 1997 13:00:27 -0500 (CDT) Cc: bde@zeta.org.au, tqbf@enteract.com, security@FreeBSD.ORG, sef@Kithrup.COM Reply-To: tqbf@enteract.com In-Reply-To: <199708041753.DAA05901@godzilla.zeta.org.au> from "Bruce Evans" at Aug 5, 97 03:53:05 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Losing the shared descriptor table on exec is also useless. If the > table is shared then you probably want it to continue to be shared. > This only causes security problems in the setuid case. We're on the same side. The issue has already been resolved; the exact same type of problem (relations between processes that allow one to manipulate the other) was addressed with ptrace(). The solution was to ignore SUID and maintain the ptrace flag, while allowing the execve() to succeed. I don't see why FreeBSD has (apparently) decided to address this issue in a different manner, especially because they are now using an rfork() implementation that is incompatible with OpenBSD's. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?" From owner-freebsd-security Mon Aug 4 11:12:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA16952 for security-outgoing; Mon, 4 Aug 1997 11:12:38 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA16944 for ; Mon, 4 Aug 1997 11:12:34 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id LAA21777 for security@freebsd.org; Mon, 4 Aug 1997 11:12:30 -0700 Date: Mon, 4 Aug 1997 11:12:30 -0700 From: Sean Eric Fagan Message-Id: <199708041812.LAA21777@kithrup.com> To: security@freebsd.org Subject: My last words on teh subject Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Period. Get it? Do not reply to this, do not offer me your opinion. Having any resources shared across an exec is bad. It is a completely different address space. Historically, no resources have been shared. Not even environment space, which is arguably more useful than a shared file descriptor space. rfork() exists for two reasons, semi-related. One is to offer a faster way to create a process, by making the process creation more lightweight. The other is to offer support for threads; to do this, resources need to be shared. The latter is a change in the unix model, but one that has done before, and will undoubtedly be done again. One use for the latter is to have sh, make, init, etc., use rfork() instead of fork(). Make it multi-threaded, that is, instead of what it is now. This could result in some interesting performance gains. But by having the SUIDness turned off, this breaks. How useful is a /bin/sh that can't run passwd? You end up with non-traditional behavour -- the exec() succeeds, but the program is not what it expects to be. So it goes and creates some files, or writes some data. And, lo, the parent now has access to any file descriptors it creates! Including sockets. Perhaps there was a password embedded in the program, or a key. Perhaps it just tried to rely on some security thorugh obscurity. Who knows, and it's not all that relevent. The rfork fd table sharing across exec is not, primarily, a security issue. It is a unix API issue. As it was, it was *broken*. Period. The fact that this only showed up because of the SUID issue is irrelevent; when I first read the description, my first thought was, "this is broken." I don't care if OpenBSD got it wrong. OpenBSD is not the model I base my life on. If I did, I would be breaking into systems all over the world because someone annoyed me. Sean. From owner-freebsd-security Mon Aug 4 11:35:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA19134 for security-outgoing; Mon, 4 Aug 1997 11:35:44 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA19128 for ; Mon, 4 Aug 1997 11:35:41 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id EAA08942; Tue, 5 Aug 1997 04:33:39 +1000 Date: Tue, 5 Aug 1997 04:33:39 +1000 From: Bruce Evans Message-Id: <199708041833.EAA08942@godzilla.zeta.org.au> To: sef@Kithrup.COM, tqbf@enteract.com Subject: Re: Proposed alternate patch for the rfork vulnerability Cc: bde@zeta.org.au, security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I'm sorry, Bruce, but having the file descriptor sharing break on >> exec is the ONLY way to have it make sense, let alone be secure. It makes just as much sense to have completely shared file descriptors after exec as before exec. The exec'ed process may not expect them, but it won't even notice if the other process doesn't do much with them - the other process should at least be able to fstat them. >The problem is specifically an issue with an interaction between the >rfork() resource sharing semantics and the SUID bit. The problem is >equally well solved by ignoring the SUID bit. No, that may give unexpected behaviour. There was actually a problem with the the non-SUID case - I got a panic in fstat() the first time I tried it (execing /usr/bin/vi). This is with yesterday's FreeBSD- current kernel. Not allowing the sharing across exec should fix the panic of course. Bruce From owner-freebsd-security Mon Aug 4 11:41:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA19383 for security-outgoing; Mon, 4 Aug 1997 11:41:31 -0700 (PDT) Received: from horst.bfd.com (horst.bfd.com [204.160.242.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA19378 for ; Mon, 4 Aug 1997 11:41:28 -0700 (PDT) Received: from harlie.bfd.com (bastion.bfd.com [204.160.242.14]) by horst.bfd.com (8.8.5/8.7.3) with SMTP id LAA04081; Mon, 4 Aug 1997 11:41:13 -0700 (PDT) Date: Mon, 4 Aug 1997 11:41:13 -0700 (PDT) From: "Eric J. Schwertfeger" To: "Thomas H. Ptacek" cc: security@FreeBSD.ORG Subject: Re: Proposed alternate patch for the rfork vulnerability In-Reply-To: <199708041741.MAA04433@enteract.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 4 Aug 1997, Thomas H. Ptacek wrote: > > I'm sorry, Bruce, but having the file descriptor sharing break on > > exec is the ONLY way to have it make sense, let alone be secure. > > The problem is specifically an issue with an interaction between the > rfork() resource sharing semantics and the SUID bit. The problem is > equally well solved by ignoring the SUID bit. I'm not sure I agree. Imagine troubleshooting a problem where if a command is typed in on the command line it works fine, but when your fancy shell tries to execute the same command, it fails because the SUID isn't honored, and the SUID program is too stupid to say "I'm not working because I don't have adequate permission to open my config file" but rather says "can't find config file." Sloppy programming, yes, but all too common in the college-student quick-hack programs (not that all college students can only write hacks, or only college students write hacks). Now, if there's at least an error message spit out, this shouldn't be an issue. Then again, if the calling program doesn't say why the rfork() failed (doesn't check error conditions, etc) then you're back in the same boat. From owner-freebsd-security Mon Aug 4 11:50:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA19903 for security-outgoing; Mon, 4 Aug 1997 11:50:44 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA19897 for ; Mon, 4 Aug 1997 11:50:41 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id EAA10329; Tue, 5 Aug 1997 04:49:53 +1000 Date: Tue, 5 Aug 1997 04:49:53 +1000 From: Bruce Evans Message-Id: <199708041849.EAA10329@godzilla.zeta.org.au> To: bde@zeta.org.au, sef@Kithrup.COM, tqbf@enteract.com Subject: Re: Proposed alternate patch for the rfork vulnerability Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Note that exit closes file descriptors. So I guess exit should close >all file descriptors for all processes, huh? Only completely shared ones :-). My test program had its stderr closed when the (non-execed) child process exited. All descriptors get closed. Cooperating processes with completely shared descriptors need to handle this somehow if one of them exits and others want to keep running. Exec doesn't really affect the problem - processes can still cooperate after exec. Bruce From owner-freebsd-security Mon Aug 4 11:55:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA20195 for security-outgoing; Mon, 4 Aug 1997 11:55:31 -0700 (PDT) Received: from ishiboo.com (user9141@bleep.ishiboo.com [206.64.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA20190 for ; Mon, 4 Aug 1997 11:55:29 -0700 (PDT) From: nirva@ishiboo.com Received: (qmail 9134 invoked by uid 1000); 4 Aug 1997 19:57:06 -0000 Message-ID: <19970804195706.9133.qmail@ishiboo.com> Subject: Re: Proposed alternate patch for the rfork vulnerability In-Reply-To: <199708041703.KAA16417@kithrup.com> from Sean Eric Fagan at "Aug 4, 97 10:03:55 am" To: sef@kithrup.com (Sean Eric Fagan) Date: Mon, 4 Aug 1997 14:57:06 -0500 (EST) Cc: bde@zeta.org.au, tqbf@enteract.com, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sean Eric Fagan stands accused of saying: > I'm sorry, Bruce, but having the file descriptor sharing break on > exec is the ONLY way to have it make sense, let alone be secure. > Breaking file descriptor sharing is breaking the established sematics of rfork(). Note that when exec()ing an suid/sgid program while being ptrace()ed, the suid/sgid bit is dropped, not the functionality of ptrace(). kern_exec.c: /* * * Disable setuid/setgid if the filesystem prohibits it or if * * the process is being traced. * */ if ((vp->v_mount->mnt_flag & MNT_NOSUID) || (p->p_flag & P_TRACED)) attr->va_mode &= ~(VSUID | VSGID); If you choose to break FD sharing, you are not following what seems to be an established method of removing premissions where security is concerned. The fact that you remove the sharing will do much damage to non-premission extending programs without gaining any advantage. If you were to just remove the premission extensions, then you would be following convention of the ptrace() issue, as well as only changing functionality when security is a concern. If you choose to copy FDs on exec, you might as well stay consistent and turn off ptrace and anything else that might be accessed by more than one process. --------------------------------------------------------------------------- Danny Dulai Feet. Pumice. Lotion. http://www.ishiboo.com/~nirva/ nirva@ishiboo.com --------------------------------------------------------------------------- From owner-freebsd-security Mon Aug 4 12:27:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA21862 for security-outgoing; Mon, 4 Aug 1997 12:27:39 -0700 (PDT) Received: from onyx.atipa.com (ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA21854 for ; Mon, 4 Aug 1997 12:27:35 -0700 (PDT) Received: (qmail-queue invoked by uid 1018); 4 Aug 1997 19:25:57 -0000 Date: Mon, 4 Aug 1997 13:25:57 -0600 (MDT) From: FreeBSD Mailing List X-Sender: freebsd@dot.ishiboo.com To: "Jonathan A. Zdziarski" cc: ports@freebsd.org, security@freebsd.org Subject: Re: SetUID In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Johnathan, As far as I know, shell scripts can not bet setuid root. You would need to setuid root all the binaries evoked from the shell, which is not a great idea. You could instead write a setuid "wrapper" of some sort that runs a shell script (or set of scripts), using c, c++, etc. Kevin On Mon, 4 Aug 1997, Jonathan A. Zdziarski wrote: > Not sure if this is the right forum for this but... > > I recently, in an attempt to make my FreeBSD a litle more system Vish > like I'm used to, create a set of /sbin/init.d scripts to start and stop > services, and wired this and rc3.d into /etc/rc. It works fine, but then > I took it a step further, and made the noc-executable, and noc-setuid root > so that anybody in the noc could restart them without having to be in sudo > for it. For some odd reason (and this may just be a FreeBSD thing that > I'm not used to), I get the error that the script doesn't have permission > to kill the current running process (most which are running as root) even > though it's setuid (I've tried setuid and setgid as well). Now I'm used > to setuid programs running AS root - having basically superuser abilities, > but that appears to be different here. Could someone explain to me how to > set up a setuid program that acts like its a real setuid program (su) to > do something like this? > > > ------------------------------------------------------------------------- > Jonathan A. Zdziarski NetRail Incorporated > Server Engineering Manager 230 Peachtree St. Suite 500 > jonz@netrail.net Atlanta, GA 30303 > http://www.netrail.net (888) - NETRAIL > ------------------------------------------------------------------------- > > From owner-freebsd-security Mon Aug 4 12:34:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA22165 for security-outgoing; Mon, 4 Aug 1997 12:34:10 -0700 (PDT) Received: from onyx.atipa.com (user9577@ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA22160 for ; Mon, 4 Aug 1997 12:34:05 -0700 (PDT) Received: (qmail-queue invoked by uid 1018); 4 Aug 1997 19:36:27 -0000 Date: Mon, 4 Aug 1997 13:36:27 -0600 (MDT) From: FreeBSD Mailing List X-Sender: freebsd@dot.ishiboo.com To: "Jonathan A. Zdziarski" , ports@freebsd.org, security@freebsd.org Subject: Re: SetUID In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 4 Aug 1997, FreeBSD Mailing List wrote: > > Johnathan, > > As far as I know, shell scripts can not bet setuid root. You would need > to setuid root all the binaries evoked from the shell, which is not a > great idea. > > You could instead write a setuid "wrapper" of some sort that runs a > shell script (or set of scripts), using c, c++, etc. > > Kevin Here is a simple "wrapper": -- cut here (wrapper.c) -- #include main() { execl("/etc/rc.WHATEVER","WHATEVER",NULL); } -- end-- The resulting binary can be setuid root and restricted to your appropriate /etc/group. Kevin From owner-freebsd-security Mon Aug 4 13:05:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA23773 for security-outgoing; Mon, 4 Aug 1997 13:05:22 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA23765; Mon, 4 Aug 1997 13:05:16 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id QAA09735; Mon, 4 Aug 1997 16:04:29 GMT Date: Mon, 4 Aug 1997 16:04:29 +0000 (GMT) From: "Jonathan A. Zdziarski" To: FreeBSD Mailing List cc: ports@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: SetUID In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ah that explains it. Thanx ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- On Mon, 4 Aug 1997, FreeBSD Mailing List wrote: : :Johnathan, : :As far as I know, shell scripts can not bet setuid root. You would need :to setuid root all the binaries evoked from the shell, which is not a :great idea. : :You could instead write a setuid "wrapper" of some sort that runs a :shell script (or set of scripts), using c, c++, etc. : :Kevin : :On Mon, 4 Aug 1997, Jonathan A. Zdziarski wrote: : :> Not sure if this is the right forum for this but... :> :> I recently, in an attempt to make my FreeBSD a litle more system Vish :> like I'm used to, create a set of /sbin/init.d scripts to start and stop :> services, and wired this and rc3.d into /etc/rc. It works fine, but then :> I took it a step further, and made the noc-executable, and noc-setuid root :> so that anybody in the noc could restart them without having to be in sudo :> for it. For some odd reason (and this may just be a FreeBSD thing that :> I'm not used to), I get the error that the script doesn't have permission :> to kill the current running process (most which are running as root) even :> though it's setuid (I've tried setuid and setgid as well). Now I'm used :> to setuid programs running AS root - having basically superuser abilities, :> but that appears to be different here. Could someone explain to me how to :> set up a setuid program that acts like its a real setuid program (su) to :> do something like this? :> :> :> ------------------------------------------------------------------------- :> Jonathan A. Zdziarski NetRail Incorporated :> Server Engineering Manager 230 Peachtree St. Suite 500 :> jonz@netrail.net Atlanta, GA 30303 :> http://www.netrail.net (888) - NETRAIL :> ------------------------------------------------------------------------- :> :> : From owner-freebsd-security Mon Aug 4 13:12:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA24347 for security-outgoing; Mon, 4 Aug 1997 13:12:42 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA24342 for ; Mon, 4 Aug 1997 13:12:40 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id NAA14244; Mon, 4 Aug 1997 13:14:31 -0700 (PDT) Message-Id: <199708042014.NAA14244@implode.root.com> To: Sean Eric Fagan cc: security@FreeBSD.ORG Subject: Re: My last words on teh subject In-reply-to: Your message of "Mon, 04 Aug 1997 11:12:30 PDT." <199708041812.LAA21777@kithrup.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 04 Aug 1997 13:14:31 -0700 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Period. Get it? Do not reply to this, do not offer me your opinion. Well, I'm going to anyway. :-) Obviously I agree with Sean or I wouldn't have chosen his fix over the one put forward by tqbf. It really comes down to just a few issues: 1) The process address space and context can't be shared across an exec; it should be obvious why this is the case. It is entirely consistent for the file descriptor table sharing to be severed, too, especially when one considers the primary purpose of rfork(). 2) Files are normally closed on exec; thus doing an exec in a child would normally close all files in the parent and all other processes in a thread. This means that without special coding in both the parent and the child, exec is escentially useless after an rfork(). This is simply broken and makes rfork() much less useful in typical situations. 3) Dropping setuid/setgid will almost certainly cause a target image that is specifically set this way to break badly. We do this with ptrace() only because of a probably wrong assumption that ptrace() of such a process is still useful. Further, while this fixes the security problem, it ignores the bigger picture of fd table sharing across an exec being generally unuseful and broken from an API perspective. 4) Failing to do the exec with EPERM is very inconsistent with expected behavior of exec, and few applications, if any, are going to handle this well. I originally thought that dropping setuid/setgid in the case of a shared fd table was the right approach, until I realized #2 and then considered #3 and #1. Further, Sean's points about the intended usage of rfork() further point to only one viable (to my mind) solution: copy the file descriptor table, thus severing the sharing while keeping the files themselves open. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Mon Aug 4 13:37:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA25536 for security-outgoing; Mon, 4 Aug 1997 13:37:41 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25526; Mon, 4 Aug 1997 13:37:38 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id OAA16879; Mon, 4 Aug 1997 14:37:26 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id OAA28905; Mon, 4 Aug 1997 14:35:02 -0600 (MDT) Date: Mon, 4 Aug 1997 14:35:01 -0600 (MDT) From: Marc Slemko To: FreeBSD Mailing List cc: "Jonathan A. Zdziarski" , ports@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: SetUID In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You could. If you did, however, you would be silly. The wrapper you give allows anyone who can run it to do anything they want as the uid it is setuid to. On Mon, 4 Aug 1997, FreeBSD Mailing List wrote: > > > On Mon, 4 Aug 1997, FreeBSD Mailing List wrote: > > > > > Johnathan, > > > > As far as I know, shell scripts can not bet setuid root. You would need > > to setuid root all the binaries evoked from the shell, which is not a > > great idea. > > > > You could instead write a setuid "wrapper" of some sort that runs a > > shell script (or set of scripts), using c, c++, etc. > > > > Kevin > > Here is a simple "wrapper": > > -- cut here (wrapper.c) -- > > #include > main() > { > execl("/etc/rc.WHATEVER","WHATEVER",NULL); > } > > -- end-- > > The resulting binary can be setuid root and restricted to your > appropriate /etc/group. > > Kevin > From owner-freebsd-security Mon Aug 4 13:37:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA25571 for security-outgoing; Mon, 4 Aug 1997 13:37:47 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25551 for ; Mon, 4 Aug 1997 13:37:42 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id OAA16885 for security@FreeBSD.ORG; Mon, 4 Aug 1997 14:37:41 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id OAA28914 for ; Mon, 4 Aug 1997 14:36:54 -0600 (MDT) Date: Mon, 4 Aug 1997 14:36:54 -0600 (MDT) From: Marc Slemko To: security@FreeBSD.ORG Subject: Re: Proposed alternate patch for the rfork vulnerability In-Reply-To: <19970804195706.9133.qmail@ishiboo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 4 Aug 1997 nirva@ishiboo.com wrote: > Sean Eric Fagan stands accused of saying: > > I'm sorry, Bruce, but having the file descriptor sharing break on > > exec is the ONLY way to have it make sense, let alone be secure. > > > > Breaking file descriptor sharing is breaking the established sematics > of rfork(). I'm not sure I like breaking sharing on execs either. An alternative I haven't seen mentioned is simply haveing exec() fail if it tries to exec a setuid program when descriptors are being shared. If someone isn't checking the return from exec, that is their problem. From owner-freebsd-security Mon Aug 4 14:05:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA27654 for security-outgoing; Mon, 4 Aug 1997 14:05:57 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27648; Mon, 4 Aug 1997 14:05:55 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id PAA18420; Mon, 4 Aug 1997 15:05:45 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id PAA29175; Mon, 4 Aug 1997 15:07:36 -0600 (MDT) Date: Mon, 4 Aug 1997 15:07:36 -0600 (MDT) From: Marc Slemko To: Atipa cc: "Jonathan A. Zdziarski" , ports@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: SetUID In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 4 Aug 1997, Atipa wrote: > > > On Mon, 4 Aug 1997, Marc Slemko wrote: > > > You could. If you did, however, you would be silly. > > > > The wrapper you give allows anyone who can run it to do anything they want > > as the uid it is setuid to. > > If you allow the shell script to be modified, yes. Otherwise, I can not > see how they could use the wrapper to execute anything but the script > hard coded therein. Am I being naive? > > Set the permissions to 750, chown root. > And make sure the shell script is non world or group writable. > > What's the vulnerablility? You are being very naive. You can do an awful lot with environment variables. What would happen if you set ENV before running your wrapper? /bin/sh would see it and execute whatever is in the file it points to. What if you set one of a couple of LD_* environment variables? The loader would see them and use whatever they point to. Net result: people who can run it can do whatever they want as the user it is setuid to. Not passing in the external environment is a good first step to making it secure. > > Kevin > > > > > -- cut here (wrapper.c) -- > > > > > > #include > > > main() > > > { > > > execl("/etc/rc.WHATEVER","WHATEVER",NULL); > > > } > > > > > > -- end-- > From owner-freebsd-security Mon Aug 4 14:06:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA27774 for security-outgoing; Mon, 4 Aug 1997 14:06:45 -0700 (PDT) Received: from onyx.atipa.com (user11604@ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA27760 for ; Mon, 4 Aug 1997 14:06:41 -0700 (PDT) Received: (qmail-queue invoked by uid 1018); 4 Aug 1997 21:01:31 -0000 Date: Mon, 4 Aug 1997 15:01:31 -0600 (MDT) From: Atipa X-Sender: freebsd@dot.ishiboo.com To: Marc Slemko cc: "Jonathan A. Zdziarski" , ports@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: SetUID In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 4 Aug 1997, Marc Slemko wrote: > You could. If you did, however, you would be silly. > > The wrapper you give allows anyone who can run it to do anything they want > as the uid it is setuid to. If you allow the shell script to be modified, yes. Otherwise, I can not see how they could use the wrapper to execute anything but the script hard coded therein. Am I being naive? Set the permissions to 750, chown root. And make sure the shell script is non world or group writable. What's the vulnerablility? Kevin > > > -- cut here (wrapper.c) -- > > > > #include > > main() > > { > > execl("/etc/rc.WHATEVER","WHATEVER",NULL); > > } > > > > -- end-- From owner-freebsd-security Mon Aug 4 14:52:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA00192 for security-outgoing; Mon, 4 Aug 1997 14:52:23 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA00172; Mon, 4 Aug 1997 14:52:18 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA20267; Mon, 4 Aug 1997 23:52:10 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id XAA13283; Mon, 4 Aug 1997 23:50:33 +0200 (MET DST) Message-ID: <19970804235032.NS48816@uriah.heep.sax.de> Date: Mon, 4 Aug 1997 23:50:32 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: marcs@znep.com (Marc Slemko) Cc: freebsd@atipa.com (Atipa), jonz@netrail.net (Jonathan A. Zdziarski), ports@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: SetUID References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Marc Slemko on Aug 4, 1997 15:07:36 -0600 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Marc Slemko wrote: > You are being very naive. You can do an awful lot with environment > variables. What would happen if you set ENV before running your wrapper? > /bin/sh would see it and execute whatever is in the file it points to. No longer. $ENV should only be evaluated for interactive shells. Recent versions of FreeBSD's /bin/sh handle it this way (but probably not the version of the guy who's been asking here). > What if you set one of a couple of LD_* environment variables? The loader > would see them and use whatever they point to. But that's a right point, indeed. The loader will ignore these variables for the wrapper, but not for the called executables. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-security Mon Aug 4 23:14:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA22487 for security-outgoing; Mon, 4 Aug 1997 23:14:04 -0700 (PDT) Received: from anugpo.anu.edu.au (anugpo.anu.edu.au [150.203.2.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA22467; Mon, 4 Aug 1997 23:13:56 -0700 (PDT) Received: from bohm.anu.edu.au (root@bohm.anu.edu.au [150.203.21.88]) by anugpo.anu.edu.au (8.8.5/8.8.5) with SMTP id QAA19317; Tue, 5 Aug 1997 16:12:43 +1000 (EST) Received: from totoro by bohm.anu.edu.au (SMI-8.6/SMI-SVR4) id QAA04032; Tue, 5 Aug 1997 16:12:34 +1000 Message-Id: <3.0.32.19970805161419.00a65b08@student.anu.edu.au> X-Sender: s3080696@student.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 05 Aug 1997 16:14:28 +1000 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), marcs@znep.com (Marc Slemko) From: James Seng Subject: Re: SetUID Cc: freebsd@atipa.com (Atipa), jonz@netrail.net (Jonathan A. Zdziarski), ports@FreeBSD.ORG, security@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 23:50 4/08/97 +0200, J Wunsch wrote: >As Marc Slemko wrote: > >> You are being very naive. You can do an awful lot with environment >> variables. What would happen if you set ENV before running your wrapper? >> /bin/sh would see it and execute whatever is in the file it points to. > >No longer. $ENV should only be evaluated for interactive shells. >Recent versions of FreeBSD's /bin/sh handle it this way (but probably >not the version of the guy who's been asking here). > >> What if you set one of a couple of LD_* environment variables? The loader >> would see them and use whatever they point to. > >But that's a right point, indeed. The loader will ignore these >variables for the wrapper, but not for the called executables. In other words, the shell script #!/bin/sh would not be suspetible to ENV parsing problem but the wrapper will. The easilest (and oldest) exploited would probably be using IFS on the posted wrapper program *8) Look at wrapper which comes with sendmail if you really want something which is more secure. -James Seng From owner-freebsd-security Mon Aug 4 23:44:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA24153 for security-outgoing; Mon, 4 Aug 1997 23:44:39 -0700 (PDT) Received: from radford.i-plus.net (root@Radford.i-Plus.net [206.99.237.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA24141 for ; Mon, 4 Aug 1997 23:44:35 -0700 (PDT) Received: from totally.fuckin.nutty.net (insane@totally.nutty.net [206.99.237.44]) by radford.i-plus.net (8.8.6/8.8.5) with SMTP id CAA19412 for ; Tue, 5 Aug 1997 02:42:59 -0400 (EDT) Message-Id: <199708050642.CAA19412@radford.i-plus.net> X-Mailer: Microsoft Outlook Express 4.71.0544.0 From: "Troy Settle" To: Subject: Re: SetUID Date: Tue, 5 Aug 1997 02:47:35 -0400 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.0544.0 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ok, this SetUID thread has brought a question to mind. I'm the sysadmin for a small ISP, and have created a perl script for user management. The script is basically a menu with options to create/delete/di sable/enable accounts and change passwords. I've got safeguards in place that will only allow user accounts to be modified. In my script, I'm using: - hacked up code from /usr/bin/adduser to create accounts - a call to /usr/sbin/pw to disable and delete accounts - a call to /usr/bin/passwd to change user passwords and re-enable accounts My staff is allowed to run this script using the sudo utility, and all seems to work well. The script itself is owned by root, and has 0500 for permissions, and is using /usr/local/bin/perl (perl 5.003) as the interpreter. Is this safe? Is there anything I should watch out for? Any comments/suggestions are welcome. I'm willing to share my script if anyone is willing to suffer through poor coding :^) Troy Settle Network Administrator, iPlus Internet Services http://www.i-Plus.net From owner-freebsd-security Tue Aug 5 00:21:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA26366 for security-outgoing; Tue, 5 Aug 1997 00:21:54 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA26341; Tue, 5 Aug 1997 00:21:45 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA27475; Tue, 5 Aug 1997 09:21:37 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA16325; Tue, 5 Aug 1997 09:16:33 +0200 (MET DST) Message-ID: <19970805091633.IM60027@uriah.heep.sax.de> Date: Tue, 5 Aug 1997 09:16:33 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: jseng@pobox.org.sg (James Seng) Cc: marcs@znep.com (Marc Slemko), freebsd@atipa.com (Atipa), jonz@netrail.net (Jonathan A. Zdziarski), ports@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: SetUID References: <3.0.32.19970805161419.00a65b08@student.anu.edu.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <3.0.32.19970805161419.00a65b08@student.anu.edu.au>; from James Seng on Aug 5, 1997 16:14:28 +1000 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As James Seng wrote: > In other words, the shell script #!/bin/sh would not be suspetible to ENV > parsing problem but the wrapper will. The easilest (and oldest) exploited > would probably be using IFS on the posted wrapper program *8) No. Our shell doesn't import IFS. > Look at wrapper which comes with sendmail if you really want something > which is more secure. This advise is still valid, of course. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-security Tue Aug 5 02:18:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA02114 for security-outgoing; Tue, 5 Aug 1997 02:18:00 -0700 (PDT) Received: from foo.primenet.com (ip193.sjc.primenet.com [206.165.96.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA02105 for ; Tue, 5 Aug 1997 02:17:57 -0700 (PDT) Received: (from bkogawa@localhost) by foo.primenet.com (8.8.6/8.6.12) id CAA14803; Tue, 5 Aug 1997 02:22:41 -0700 (PDT) Date: Tue, 5 Aug 1997 02:22:41 -0700 (PDT) Message-Id: <199708050922.CAA14803@foo.primenet.com> To: rewt@i-Plus.net Subject: Re: SetUID Newsgroups: localhost.freebsd.security References: <> <199708050642.CAA19412@radford.i-plus.net> From: "Bryan K. Ogawa" Cc: X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In localhost.freebsd.security you write: >Ok, this SetUID thread has brought a question to mind. >I'm the sysadmin for a small ISP, and have created a perl script for user >management. The script is basically a menu with options to create/delete/di >sable/enable accounts and change passwords. I've got safeguards in place >that will only allow user accounts to be modified. >In my script, I'm using: >- hacked up code from /usr/bin/adduser to create accounts >- a call to /usr/sbin/pw to disable and delete accounts >- a call to /usr/bin/passwd to change user passwords and re-enable >accounts Depending on how you call the above, they may or may not show info (say, the account's password) in the ps listings. Another thing you can do if you don't trust the staff (or the security of the staff's accounts) is to run perl in taint mode (-t , I believe). Then, perl will become paranoid and refuse to do a lot of things which may potentially be unsafe. >My staff is allowed to run this script using the sudo utility, and all >seems to work well. The script itself is owned by root, and has 0500 for >permissions, and is using /usr/local/bin/perl (perl 5.003) as the >interpreter. >Is this safe? Is there anything I should watch out for? >Any comments/suggestions are welcome. I'm willing to share my script if >anyone is willing to suffer through poor coding :^) >Troy Settle >Network Administrator, iPlus Internet Services >http://www.i-Plus.net -- bryan k ogawa http://www.primenet.com/~bkogawa/ From owner-freebsd-security Tue Aug 5 02:51:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA03700 for security-outgoing; Tue, 5 Aug 1997 02:51:20 -0700 (PDT) Received: from kongur.cs.ucdavis.edu (kongur.cs.ucdavis.edu [128.120.56.192]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA03695; Tue, 5 Aug 1997 02:51:18 -0700 (PDT) Received: from dragon.nuxi.com (carina55.wco.com [209.21.28.55]) by kongur.cs.ucdavis.edu (8.8.5/8.8.5) with ESMTP id CAA16815; Tue, 5 Aug 1997 02:50:09 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.5/8.7.3) id JAA29356; Tue, 5 Aug 1997 09:50:00 GMT Message-ID: <19970805025000.01050@dragon.nuxi.com> Date: Tue, 5 Aug 1997 02:50:00 -0700 From: "David O'Brien" To: FreeBSD Mailing List Cc: "Jonathan A. Zdziarski" , ports@freebsd.org, security@freebsd.org Subject: Re: SetUID Reply-To: obrien@NUXI.COM References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: ; from FreeBSD Mailing List on Mon, Aug 04, 1997 at 01:36:27PM -0600 X-Warning: Mutt Bites! X-Operating-System: FreeBSD 2.2-STABLE Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > You could instead write a setuid "wrapper" of some sort that runs a > > shell script (or set of scripts), using c, c++, etc. > > Here is a simple "wrapper": > > -- cut here (wrapper.c) -- > > #include > main() > { > execl("/etc/rc.WHATEVER","WHATEVER",NULL); > } Still too dangerous. The environment isn't cleansed. Please try the super port (ports/security/super) which is a wrapper program like this, but does some cleansing and can use control lists. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) From owner-freebsd-security Tue Aug 5 05:43:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA10757 for security-outgoing; Tue, 5 Aug 1997 05:43:16 -0700 (PDT) Received: from tiga.worldaccess.nl (tiga.worldaccess.nl [194.178.56.6]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA10744 for ; Tue, 5 Aug 1997 05:43:09 -0700 (PDT) Received: from anarchismf (sld3-4.worldaccess.nl [194.178.85.51]) by tiga.worldaccess.nl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14833 for ; Tue, 5 Aug 1997 12:42:53 GMT Message-Id: <199708051242.MAA14833@tiga.worldaccess.nl> From: "F.J.J. van Heusden" To: Subject: unsubscribe Date: Tue, 5 Aug 1997 14:36:38 +0200 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-security Wed Aug 6 04:11:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA16359 for security-outgoing; Wed, 6 Aug 1997 04:11:36 -0700 (PDT) Received: from grunt.vl.kharkov.ua (grunt.vl.kharkov.ua [193.124.76.209]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA16339 for ; Wed, 6 Aug 1997 04:11:05 -0700 (PDT) From: doka@vl.kharkov.ua Received: (from news@localhost) by grunt.vl.kharkov.ua (8.8.6/8.8.6) id NAA08322 for dev.null; Wed, 6 Aug 1997 13:10:37 +0300 (EEST) To: freebsd-security@freebsd.org Subject: identd working? Date: 6 Aug 1997 13:10:31 +0300 Message-ID: <5s9iin$83t$1@grunt.vl.kharkov.ua> X-Newsreader: TIN [UNIX 1.3 unoff BETA 970709; i386 FreeBSD 2.2.2-RELEASE] X-Via: News-To-Mail v1.0 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! On my system (FreeBSD 2.2.2) don't work identd (pident-2.2.4) I have such line in inetd.conf: ident stream tcp wait root /usr/local/sbin/identd identd -w -t120 but when connecting to remote side, there is no identification. When I try to connect to this service, it write, that 'connection refused'. No changes in behavior when I removed 2nd identd in string above. This 'feature' present not only on my host, but on hosts around me. Any ideas? /usr/local/sbin/identd owned by root.bin and has 755 mode. Sinc, Doka ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~NewsGate~ (c) Vladimir Litovka From owner-freebsd-security Wed Aug 6 12:58:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA15902 for security-outgoing; Wed, 6 Aug 1997 12:58:19 -0700 (PDT) Received: from grunt.vl.kharkov.ua (grunt.vl.kharkov.ua [193.124.76.209]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA15880 for ; Wed, 6 Aug 1997 12:57:52 -0700 (PDT) Received: (from news@localhost) by grunt.vl.kharkov.ua (8.8.6/8.8.6) id WAA22261 for dev.null; Wed, 6 Aug 1997 22:56:08 +0300 (EEST) To: freebsd-security@freebsd.org Subject: SUMMARY: identd working? Date: 6 Aug 1997 19:56:07 GMT Message-ID: <5saksn$ln5$1@grunt.vl.kharkov.ua> X-Newsreader: TIN [version 1.2 PL2] X-Via: News-To-Mail v1.0 From: doka@dragon.opera.kharkov.ua (Vladimir Litovka) Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! On Wed, 6 Aug 1997, Hoss Firooznia wrote: > > On my system (FreeBSD 2.2.2) don't work identd (pident-2.2.4) I have such > > line in inetd.conf: > > > > ident stream tcp wait root /usr/local/sbin/identd identd -w -t120 > > > > but when connecting to remote side, there is no identification. > > It's possible (but probably unlikely) that your system has been broken > into and your copy of identd has been replaced with a "trojan horse" > program that allows attackers back into your system. I don't think such, because I recently rebuild pident package, and problem is still. This feature happens only with some versions of inetd. For example, inetd, that is in FreeBSD package, work normally. So, this isn't a problem of pidentd, but IMHO problem of inetd. > Below I've included a recent CERT advisory that explains the problem. > Good luck, and I hope this is just a harmless problem with identd and > not something more serious. Thank you. I _think_ that there isn't hacker's wars :-) Vladimir Litovka , UNIX System Administrator Check my resume at http://pasha.tnp.com/~doka ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~NewsGate~ (c) Vladimir Litovka From owner-freebsd-security Wed Aug 6 17:25:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA00414 for security-outgoing; Wed, 6 Aug 1997 17:25:41 -0700 (PDT) Received: from yoss.canweb.net (root@yoss.canweb.net [207.139.235.8]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA00409 for ; Wed, 6 Aug 1997 17:25:38 -0700 (PDT) Received: from localhost (yossman@localhost) by yoss.canweb.net (8.8.5/8.8.5) with SMTP id UAA24654; Wed, 6 Aug 1997 20:18:18 -0400 (EDT) Date: Wed, 6 Aug 1997 20:18:18 -0400 (EDT) From: yossman To: doka@vl.kharkov.ua cc: freebsd-security@FreeBSD.ORG Subject: Re: identd working? In-Reply-To: <5s9iin$83t$1@grunt.vl.kharkov.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk you may have to play with the first part in /etc/inetd.conf, 'ident'. /etc/services: ----- auth 113/tcp ident tap #Authentication Service auth 113/udp ident tap #Authentication Service ----- /etc/inetd.conf: ----- auth stream tcp wait root /usr/local/sbin/identd identd -w -t120 -l ----- note the listing in /etc/services is different than the default identd 'example' listing in /etc/inetd.conf. yossman On 6 Aug 1997 doka@vl.kharkov.ua wrote: > Hello! > > On my system (FreeBSD 2.2.2) don't work identd (pident-2.2.4) I have such > line in inetd.conf: > > ident stream tcp wait root /usr/local/sbin/identd identd -w -t120 > > but when connecting to remote side, there is no identification. When I try > to connect to this service, it write, that 'connection refused'. No changes > in behavior when I removed 2nd identd in string above. This 'feature' > present not only on my host, but on hosts around me. Any ideas? > > /usr/local/sbin/identd owned by root.bin and has 755 mode. > > Sinc, Doka > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~NewsGate~ (c) Vladimir Litovka > ----------------------------------------------------------------------- Yossarian Holmberg (yossman) yossman@yossman.org System Administrator, National Online http://www.yossman.org/ my statements are my own, not my employer's -- i do not speak for them. '... and if i die, before i learn to speak .. can money pay for all the days i've lived awake but half asleep?' -- Primitive Radio Gods, "Standing Outside a Broken Phone Booth With Money In My Hand" From owner-freebsd-security Thu Aug 7 09:19:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA15349 for security-outgoing; Thu, 7 Aug 1997 09:19:20 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA15336 for ; Thu, 7 Aug 1997 09:19:15 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wwVGa-000652-00; Thu, 7 Aug 1997 10:18:24 -0600 To: yossman Subject: Re: identd working? Cc: doka@vl.kharkov.ua, freebsd-security@freebsd.org In-reply-to: Your message of "Wed, 06 Aug 1997 20:18:18 EDT." References: Date: Thu, 07 Aug 1997 10:18:24 -0600 From: Warner Losh Message-Id: Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Have you rebooted your system, or otherwise restarted inetd? If so, then what does netstat -an tell you about things listening on port 113? Warner From owner-freebsd-security Thu Aug 7 10:21:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA18220 for security-outgoing; Thu, 7 Aug 1997 10:21:23 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA18214 for ; Thu, 7 Aug 1997 10:21:18 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id NAA09262; Thu, 7 Aug 1997 13:19:40 GMT Date: Thu, 7 Aug 1997 13:19:40 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Warner Losh cc: yossman , doka@vl.kharkov.ua, freebsd-security@FreeBSD.ORG Subject: Re: identd working? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk If that doesnt report anything try making 'lsof' and seeing if '113' is being held onto by any processes - i had this problem with ytalk working, for some reason a tcsh process was holding onto the talk port ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- On Thu, 7 Aug 1997, Warner Losh wrote: :Have you rebooted your system, or otherwise restarted inetd? : :If so, then what does netstat -an tell you about things listening on :port 113? : :Warner : From owner-freebsd-security Fri Aug 8 12:50:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08474 for security-outgoing; Fri, 8 Aug 1997 12:50:13 -0700 (PDT) Received: from nak.myhouse.com (nak.myhouse.com [209.70.45.162]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA08466 for ; Fri, 8 Aug 1997 12:50:10 -0700 (PDT) Received: (qmail 14161 invoked by uid 1000); 8 Aug 1997 19:50:07 -0000 Date: Fri, 8 Aug 1997 15:50:07 -0400 (EDT) From: zoonie To: isp@freebsd.org, security@freebsd.org Subject: SKIP & freebsd 2.2.2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk has anybody gotten SKIP to work with freebsd 2.2.X? i downloaded the source from the SKIP site a few months ago but couldn't test it because according to one of the readme files it would not compile under 2.2.X. since i was kinda busy with other stuff i never took the time to see if i could do it myself. thanks.... From owner-freebsd-security Sat Aug 9 06:47:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA24185 for security-outgoing; Sat, 9 Aug 1997 06:47:03 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA24178; Sat, 9 Aug 1997 06:46:59 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id JAA21770; Sat, 9 Aug 1997 09:46:21 GMT Date: Sat, 9 Aug 1997 09:46:21 +0000 (GMT) From: "Jonathan A. Zdziarski" To: zoonie cc: isp@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: SKIP & freebsd 2.2.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk what is skip? If it's something I'd be interested in using I'll hack it to work ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- On Fri, 8 Aug 1997, zoonie wrote: :has anybody gotten SKIP to work with freebsd 2.2.X? i downloaded the :source from the SKIP site a few months ago but couldn't test it because :according to one of the readme files it would not compile under 2.2.X. :since i was kinda busy with other stuff i never took the time to see if i :could do it myself. thanks.... : From owner-freebsd-security Sat Aug 9 07:45:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA26260 for security-outgoing; Sat, 9 Aug 1997 07:45:17 -0700 (PDT) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26237; Sat, 9 Aug 1997 07:45:10 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with ESMTP id KAA09283; Sat, 9 Aug 1997 10:45:03 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPAN/970608) with ESMTP id KAA28886; Sat, 9 Aug 1997 10:45:03 -0400 (EDT) To: "Jonathan A. Zdziarski" cc: zoonie , isp@FreeBSD.ORG, security@FreeBSD.ORG From: "Gary Palmer" Subject: Re: SKIP & freebsd 2.2.2 In-reply-to: Your message of "Sat, 09 Aug 1997 09:46:21 -0000." Date: Sat, 09 Aug 1997 10:45:03 -0400 Message-ID: <28884.871137903@orion.webspan.net> Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Jonathan A. Zdziarski" wrote in message ID : > what is skip? If it's something I'd be interested in using I'll hack it > to work http://skip.incog.com/ It's basically a reduced but freely redistributable implimentation (if you live in the US or Canada) of part of SMIs SunScreen encrypted tunnel product. I've got a version that compiles and will be sending it out for testing to someone this week. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-security Sat Aug 9 08:33:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA28409 for security-outgoing; Sat, 9 Aug 1997 08:33:20 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28403; Sat, 9 Aug 1997 08:33:11 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id LAA00625; Sat, 9 Aug 1997 11:36:53 -0400 (EDT) Date: Sat, 9 Aug 1997 11:36:52 -0400 (EDT) From: Bernie Doehner X-Sender: bad@uhf.wdc.net To: Gary Palmer cc: "Jonathan A. Zdziarski" , zoonie , isp@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: SKIP & freebsd 2.2.2 In-Reply-To: <28884.871137903@orion.webspan.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > It's basically a reduced but freely redistributable implimentation (if > you live in the US or Canada) of part of SMIs SunScreen encrypted > tunnel product. I've got a version that compiles and will be sending > it out for testing to someone this week. > I didn't see anything in the docs suggesting that it is only for tunneling. Yes, we'd be interested in hearing about your compilation attempts on skip. Can you please send us a unified diff reflecting the changes you had to make. Thanks. Bernie