🚀 go-pugleaf

setuid scripts are bad, bad, bad...

The following is from:
Frequently_Asked_Questions_about_Unix_(4_4)_[Monthly_posting]

You can ftp the whole thing (highly recommended) from rtfm.mit.edu if
you don't want to graze.
(/pub/usenet/comp.unix.questions).

Linus Upson
lupson@geom.umn.edu

---------------------------------------------------------------------
    Right, but what about the security risks of setuid shell scripts?

    Well, suppose the script is called `/etc/setuid_script', starting
    with:

	#!/bin/sh
	
    Now let us see what happens if we issue the following commands:

	$ cd /tmp
	$ ln /etc/setuid_script -i
	$ PATH=.
	$ -i

    We know the last command will be rearranged to:

	/bin/sh -i

    But this command will give us an interactive shell, setuid to the
    owner of the script!
    Fortunately this security hole can easily be closed by making the
    first line:

	#!/bin/sh -

    The `-' signals the end of the option list: the next argument `-i'
    will be taken as the name of the file to read commands from, just
    like it should!

    ---------

    There are more serious problems though:

	$ cd /tmp
	$ ln /etc/setuid_script temp
	$ nice -20 temp &
	$ mv my_script temp

    The third command will be rearranged to:

	nice -20 /bin/sh - temp

    As this command runs so slowly, the fourth command might be able to
    replace the original `temp' with `my_script' BEFORE `temp' is opened
    by the shell!
    There are 4 ways to fix this security hole:

	1)  let the OS start setuid scripts in a different, secure way
	    - System V R4 and 4.4BSD use the /dev/fd driver to pass the
	    interpreter a file descriptor for the script

	2)  let the script be interpreted indirectly, through a frontend
	    that makes sure everything is all right before starting the
	    real interpreter - if you use the `indir' program from
	    comp.sources.unix the setuid script will look like this:

		#!/bin/indir -u
		#?/bin/sh /etc/setuid_script

	3)  make a `binary wrapper': a real executable that is setuid and
	    whose only task is to execute the interpreter with the name of
	    the script as an argument

	4)  make a general `setuid script server' that tries to locate the
	    requested `service' in a database of valid scripts and upon
	    success will start the right interpreter with the right
	    arguments.

    ---------

    Now that we have made sure the right file gets interpreted, are there
    any risks left?

    Certainly!  For shell scripts you must not forget to set the PATH
    variable to a safe path explicitly.  Can you figure out why?
    Also there is the IFS variable that might cause trouble if not set
    properly.  Other environment variables might turn out to compromise
    security as well, e.g. SHELL...
    Furthermore you must make sure the commands in the script do not
    allow interactive shell escapes!
    Then there is the umask which may have been set to something
    strange...

    Etcetera.  You should realise that a setuid script `inherits' all the
    bugs and security risks of the commands that it calls!

    All in all we get the impression setuid shell scripts are quite a
    risky business!  You may be better off writing a C program instead!