Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: show me
Message-ID: <62472@sun.uucp>
Date: 2 Aug 88 18:16:10 GMT
References: <43200021@uicsrd.csrd.uiuc.edu> <1123@nusdhub.UUCP>
Sender: news@sun.uucp
Lines: 32

> > 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".