Setuid Shell Scripts -- Read The Whole Story Now!

[Maarten Litmaath]

Consider a setuid root shell script written in Bourne shell command language
and called `/bin/powerful'.
The first line of the script will be:

#! /bin/sh

If it doesn't begin with such a line, it's no use to chmod it to 6755 or
whatever, because in that case it's just a shell script of the `old' kind:
the Bourne shell receives an exec format error when trying to execute it, and
decides it must be a shell script, so it forks a subshell with the script name
as argument, to indicate from which file the commands are to be read.
Shell scripts of the `new' kind are treated as follows: the kernel discovers
the magic number `#!' and tries to execute the command interpreter pointed out,
which may be followed in the script by 1 argument.
Before the exec of the interpreter the uid and gid fields somewhere in the user
structure of the process are filled in.
Setuid script scheme (kernel manipulations faked by C routines):

	execl("/bin/powerful", "powerful", (char *) 0);

	  |
	  V

	setuid(0);
	setgid(0);      /* possibly */
	execl("/bin/sh", "sh", "/bin/powerful", (char *) 0);

Now, what if the name of the very shell script were e.g. "-i"? Wouldn't that
give a nice exec?

	execl("/bin/sh", "sh", "-i", (char *) 0);

So link the script to a file named "-i", and voila!
Yes, one needs write permission somewhere on the same device, if one's
operating system doesn't support symbolic links.

What about the csh command interpreter? Well, Sun Unix provides us with a csh
which has a NEW option: "-b"! Its goal is to avoid just the thing described
above: the mnemonic for `b' is `break'; this option prevents following
arguments of an exec of /bin/csh from being interpreted as options...
The csh refuses to run a setuid shell script unless the option is present...
Scheme:

#! /bin/csh -b

	execl("-i", "unimportant", (char *) 0);

	  |
	  V

	setuid(0);
	setgid(0);
	execl("/bin/csh", "csh", "-b", "-i", (char *) 0);

And indeed the contents of the file "-i" are executed!
However, there's still another bug hidden, albeit not for long!
What if I could `get between' the setuid()/setgid() and the open() of the
command file by the command interpreter?
In that case I could unlink() my link to the setuid shell script, and quickly
link() some other shell script into its place, couldn't I?
Right.
Yet another source of trouble for /bin/sh setuid scripts is the reputed IFS
shell variable. Of course there's also the PATH variable, which might cause
trouble. However, one can circumvent those 2 jokers easily.
A solution to the link()/unlink() problems would be the specification of the
full path of the script in the script itself:

	#! /bin/sh /etc/setuid_script
	shift		# remove the `extra' argument

Some objections:
1)
	currently the total length of shell + argument mustn't exceed 32 chars
	(easily fixed);
2)
	Sun's csh is expecting a `-b' flag as the first argument, instead of
	the full path (easily fixed);
3)
	the interpreter gets an extra argument;
4)
	the difficulty of maintaining setuid shell scripts increases - if one
	moves a script, one shouldn't forget to edit it... - editing in turn
	could turn off the setuid bits, so one shouldn't forget to chmod(1)
	the file `back'... - conceptually the solution above isn't `elegant'.
-- 
fcntl(fd, F_SETFL, FNDELAY):          |Maarten Litmaath @ VU Amsterdam:
      let's go weepin' in the corner! |maart at cs.vu.nl, mcvax!botter!maart