kai@uicsrd.csrd.uiuc.edu (07/28/88)
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? Thanks, Patrick Wolfe pwolfe@kai.com kailand!pwolfe
maart@cs.vu.nl (Maarten Litmaath) (07/30/88)
In article <43200021@uicsrd.csrd.uiuc.edu> kai@uicsrd.csrd.uiuc.edu writes:
\
\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?
It has been pointed out before: using any setuid root shell script one can
become root in 10 seconds...
\Are these problems specific to particular versions of UNIX,
Versions with the #! magic number, that's versions which have got setuid
shell scripts at all.
\or particular
\shell types (sh, csh, ksh, perl) or version of those shells?
sh and csh work, ksh (being a superset of sh) too I guess, I don't know about
perl.
Email for more info.
Regards.
--
If you enjoyed the recent heat wave, |Maarten Litmaath @ Free U Amsterdam:
you'll certainly like the ozone gap...|maart@cs.vu.nl, mcvax!botter!maartrwhite@nusdhub.UUCP (Robert C. White Jr.) (08/02/88)
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.
henry@utzoo.uucp (Henry Spencer) (08/02/88)
In article <43200021@uicsrd.csrd.uiuc.edu> kai@uicsrd.csrd.uiuc.edu writes: >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? The basic, underlying, fundamental problem is that the shell -- any shell -- is a complex command interpreter that was not designed with security in mind. (Compare this to the hardware, which is also a somewhat complicated command interpreter but was carefully designed to protect the operating system from user misbehavior.) There are numerous ways to trick shells into doing things that the script-writer did not expect. In general, any one specific security hole can be plugged -- sometimes at a substantial price -- but the shells are simply too big and too complex for anyone to be confident that the last hole has been found. If you want a case in point, here's an oldie: execute the shell script with the IFS environment variable set to something bizarre, and watch the shell break the script up into words in a totally unexpected way that can result in unexpected programs being invoked. This one's not hard to fix -- there is no good reason for the shell to accept IFS from the environment at all, and ours doesn't -- but there are more where that came from. -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu
guy@gorodish.Sun.COM (Guy Harris) (08/03/88)
> > 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): No, that's not what the problem is. The list of things you can do if you already *have* super-user privileges is extremely long, but not really relevant here since the super-user (in systems that have such a notion) had better be trusted (which is why some systems - e.g., proposed secure UNIX systems - don't have the notion of super-user). The problem is that there are ways of using a set-uid shell script to *get* super-user privileges when you're *not* supposed to be able to get them. There has been some discussion of them on the "security" mailing list (no, I don't remember offhand how you get on this list). One of the problems is unique to pre-4.3BSD versions of the C shell, in that you can write your "#! /bin/sh" line in a way that avoids it, regardless of which version of the Bourne (or Korn) shell you have (as far as I know), but you need a feature in the C shell that appears only in 4.3BSD to avoid it. Another problem is specific to systems that use a pre-4.3BSD implementation of "#!". However, another problem is not fixed in any version of UNIX that I know about; it's tricky to fix. It does depend on the particular order in which some things in the system happen, so it's conceivable that it may not occur in some versions of UNIX, but I wouldn't bet on it. There may be a way to fix it. However, that problem didn't occur to me, or to anybody I know, until somebody pointed it out; this indicates that there could, conceivably, be even *more* subtle problems with set-UID shell scripts that nobody has found yet, so I'd be loath to assume that, at any given point, we'd "plugged the last hole".
squires@hpcvlx.HP.COM (Matt Squires) (08/03/88)
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? ^^^^^ > ^^^^^^^ meanwhile... / hpcvlx:comp.unix.wizards / rwhite@nusdhub.UUCP (Robert C. White Jr.) / 12:27 pm Aug 1, 1988 / <As an example, just for nastyness' sake would be (under setuid root or bin <shell, a use executes teh following): ^^^^^ [nasty shell commands deleted...] The issue is giving a user a setuid shell SCRIPT, not a setuid shell! Of course, if you give a user a flippin' root shell, he or she can do anything under the sun! That is what root shells are for! The issue is why are setuid SCRIPTS a security problem. Ideally, a setuid script will run with root (or some other) effective uid, execute the commands in the script file, and exit, leaving the user in his/her original state. Apparently, that is not the case, i.e. there appears to be some way of breaking out of the setuid script, giving the user an effective uid of root (or somebody else). Is this true? How can it be done? Is there a work-around? Enquiring minds want to know! I remember back in the spring of 88 I saw a BSD bug fix that said "setuid/gid scripts are a security problem." and included a patch to the kernal that more or less disabled setuid/gid scripts. Sounds suspicious if you ask me... <There are more [nasty commands], but I think you can get the point. < <Rob. I'm afraid you may have missed the original point, Rob. mcs
rwhite@nusdhub.UUCP (Robert C. White Jr.) (08/04/88)
in article <62472@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) says: > >> > 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): > > No, that's not what the problem is. The list of things you can do if you > already *have* super-user privileges is extremely long, but not really relevant > here since the super-user (in systems that have such a notion) had better be > trusted (which is why some systems - e.g., proposed secure UNIX systems - don't > have the notion of super-user). Read the text please; to whit: "[run these commands] under a setuid root or bin shell, a user executes the following:" [Typos corrected] The poster asked what the danger of a setuid shell was. This is a danger. Because this theoretical shell gives any user the right to execute as root or bin (ethier/or) and therefore the right to "correct" the contents of "ls" thereby setting the entire system up for a fall. This example comes from one peice of comercial code (we have it here) where a single program, setuid root, invokes it's arguments as a child process. If there are no arguments, you get a shell. Ncest pa? The point being that if you setuid a program as broad as the shell you are assuming that everybody who can log in at all is trustworthy; an obvious phalacy. My statement stands un-altered. Rob.
guy@gorodish.Sun.COM (Guy Harris) (08/04/88)
> The poster asked what the danger of a setuid shell was. No, the poster asked what the danger of a setuid shell *script* is: > From: kai@uicsrd.csrd.uiuc.edu > Newsgroups: comp.unix.wizards > Subject: show me > Date: 28 Jul 88 01:53:00 GMT > > 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? I think we all know why a shell that is running setuid, and that is under the control of a potentially-hostile user, is dangerous; this hardly needs explanation - especially not in "comp.unix.wizards". However, what may not be obvious is that, with a system that permits setuid shell *scripts* (not setuid *shells*!) by using the mechanism described below, a hostile user can put the setuid shell that runs the script under their control. Some UNIX systems implement an idea that I believe Dennis Ritchie originally proposed: if an "exec"-family system call is made on a file beginning with the characters "#!", it treats the file as a script to be interpreted. It reads the first line of the file, and checks that it is in the form #! <pathname> or #! <pathname> <additional characters> It then tries to run the file named <pathname>, which must be an executable file (i.e., it cannot in turn begin with "#!). The argument list passed to that program is the argument list from the "exec", with the pathname of the script inserted as the first argument, and with the <additional characters> inserted as the second argument if present. Thus, you can begin a Bourne shell script with #! /bin/sh and give it execute permission; an "exec"-family system call, when given the pathname of that script, will succeed, even though the file isn't a binary program. The program that will actually be executed is "/bin/sh"; the first argument to "/bin/sh" will be the pathname of the script, so if the script is called "foo", and you do execl("foo", "foo", "argument", (char *)NULL); the Bourne shell will be executed with the first argument being "foo" and the second argument being "argument". It will then execute the script "foo" (if it's readable), with the first argument to the script being "argument". The kernel will honor the setuid and setgid bits on such a script. The shell in question will be run setuid or setgid if the script has the setuid or setgid bits set - *regardless of whether the shell itself is setuid or setgid*. "/bin/sh" can have mode "r-xr-xr-x"; it is not setuid, so you have not granted setuid privileges to everybody whose login shell is "/bin/sh", but if the script is setuid, the shell will run setuid when the script is "exec"ed. The problem is that such a script must be "airtight" in order for this to be safe. You must not be able to make the shell running the script do anything other than what the script intends it to do. Unfortunately, there are a variety of ways you *can* fool the shell into doing something other than what the script nominally tells it to do. Again, it's obvious that if you make "/bin/sh" owned by root, with mode "r-sr-xr-x", you render your system totally insecure. That wasn't what was being discussed; if you have setuid shell scripts, you have a security problem even if "/bin/sh" is *NOT* setuid. The naive user may think that setuid shell *scripts* are safe, since "obviously" the only thing the shell will do when using the aforementioned mechanism is whatever the author of the script intended, assuming that the author of the script is sufficiently careful. This is not true; it is tricky to plug some of the security holes caused by using this mechanism, and given that non-obvious holes have appeared before, it's not clear how secure you can be that you've plugged the last such hole.
guy@gorodish.Sun.COM (Guy Harris) (08/05/88)
> Apparently, that is not the case, i.e. there appears to be some way of > breaking out of the setuid script, giving the user an effective uid of > root (or somebody else). > > Is this true? Yes. > How can it be done? Without too much difficulty; it's harder on 4.3BSD with properly-written shell scripts (i.e., ones with #! /bin/sh - or #! /bin/csh -b as the first line - the extra flag blocks one of the holes - and with IFS reset as the first action and PATH reset as the second), but it can still be done. Furthermore, many people are not at all confident that you can guarantee that you have ever caught the "last" security hole. > Is there a work-around? No. > I remember back in the spring of 88 I saw a BSD bug fix that said > "setuid/gid scripts are a security problem." and included a patch > to the kernal that more or less disabled setuid/gid scripts. Sounds > suspicious if you ask me... That fix was posted because of one of the security holes; many people thought that 4.3BSD had closed the last of them, until Randy Smith (then of the NCI Supercomputer Facility) pointed out one that people hadn't thought of....
kai@uicsrd.csrd.uiuc.edu (08/05/88)
I did not want to hear about what can be done once you've got superuser priviledges. I've already got superuser priviledges (being system administrator for three systems). I wanted to hear why I should avoid using setuid shell scripts so that other people don't get to be. Thanks to those who responded with helpful reasons. In the interest of informing system administrators about this very real hazard, here's a summary: 1) C-shell scripts execute the ".cshrc" file of the person executing the script (as opposed to the ".cshrc" file of the user the script is set to) unless the "-f" switch is used (as in "#!/bin/csh -f"). 2) C-shell and Bourne Shell scripts execute the ".login" or ".profile" file belonging to the person executing the script if argv[0] = "-". A simple one line C program can be used to do this. There is NO workaround for this. 3) The wrong commands might be called if the person executing the script modifies the PATH environment variable before calling the script. This can be worked around by setting the PATH in the script. This is an oft seen problem with non-set[gu]id shell script, too, although it usually isn't deliberate. 4) The wrong commands might be called if the person executing the script modifies the IFS environment variable before calling the script. Some system's C and Bourne don't use the IFS passed in the environment, but not all do. If yours does, there is no workaround (if IFS contains the equals sign, IFS=" \t\n" will not reset it, but will instead call the external command IFS). Reason #2 above is enough to convince me that C and Bourne shell scripts aren't worth the hassle. I can't say the same for Perl scripts, since Perl was designed for script usage, not interactive use. Reasons #3 and #4 could cause problems if external commands are called, but can easily be worked around by setting them in each script. Patrick Wolfe (pwolfe@kai.com, kailand!pwolfe) System Manager, Kuck and Associates, Inc. "Don't you wish real life had a ^Z command?"
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (08/05/88)
In article <1570005@hpcvlx.HP.COM> squires@hpcvlx.HP.COM (Matt Squires) writes: |The issue is giving a user a setuid shell SCRIPT, not a setuid shell! Of |course, if you give a user a flippin' root shell, he or she can do anything |under the sun! That is what root shells are for! | |The issue is why are setuid SCRIPTS a security problem. With a setuid shell script, a hacker could get a root shell in 10 seconds. It doesn't matter WHAT is in the shell script. Setuid scripts are basically insecure. There is NO work-around, unless the vendor's software has closed ALL of the holes. You MIGHT consider having a setuid script in a directory where only one group or user can execute it. This only limits the access to the hole. That is, it makes the number of tasks to break in longer. Then you have to make two user ID's are secure instead of one. Not Good. Just to give you a taste of the types of problems with setuid shell scripts, have you considered: 1. People can alias '/bin/cat' in their .cshrc 2. shell scripts import environment variables like PATH 3. Shell scripts, and several programs output to various file descriptors. These can be redirected to other files 4. Temporary files can be modified in the middle of a routine, if access is wrong But these are *Nothing* compared to the real hole. The hole is small, but tough to close. See the summary line. Avoid setuid shell scripts. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
ok@quintus.uucp (Richard A. O'Keefe) (08/06/88)
In article <5030@vdsvax.steinmetz.ge.com> barnett@steinmetz.ge.com (Bruce G. Barnett) writes:
:Just to give you a taste of the types of problems with setuid shell scripts,
:>have you considered:
: 1. People can alias '/bin/cat' in their .cshrc
[and several others]
It is already the case that some systems refuse to run setuid csh scripts
unless they have the -b flag, perhaps they should require -f as well:
#!/bin/csh -fb
so that no .cshrc file will be read. (Of course there is still chroot plus
links to watch out for...)allbery@ncoast.UUCP (Brandon S. Allbery) (08/09/88)
As quoted from <253@quintus.UUCP> by ok@quintus.uucp (Richard A. O'Keefe): +--------------- | It is already the case that some systems refuse to run setuid csh scripts | unless they have the -b flag, perhaps they should require -f as well: | #!/bin/csh -fb | so that no .cshrc file will be read. (Of course there is still chroot plus | links to watch out for...) +--------------- Huh??! Unless your system is *really* broken, you have to be root to do a chroot(). ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc