Re: SUID shell scripts, questions?

[casper () fwi uva nl (Casper Dik)]

> peter@haywire[5:14pm]/tmp-104> /tmp/suidsh
> /dev/fd/3: e: not found
> uid=433(peter) gid=304(user) euid=0(root) egid=0(root)


As expected.

> #! /bin/sh -p
> IFS="   
> "

> OK. So that works.. IFS can be reset, but what about setting IFS to
> disturb the resetting of IFS itself?
>
> Hmm.  Does this actually work? Or was I just lucky?


No, it does actually work.  IFS based atgument splitting is
done after parameter subsistition, which includes var=value
lists.  So you can set PATH and IFS to safe values.

> Perhaps it's possible that somebody might have done the right thing
> and made IFS assignments themselves immune to the previous IFS
> settings?

All assignments are immune.

> Hmmmm..  Methinks if you have any suid shell scripts on a SVR4 or
> Solaris machine, you'd better make sure that you reset IFS on the very
> first line.

Correct.  Though it can be arguyed that shells should import IFS in the
first place.  Some Bourne shells don't. 

> Also, the LD_* variables wouldn't hurt too, but they should be OK, as
> the loader code ignores them if it's currently running suid.   The
> shell should be immune to them, and probably all the processes spawned
> would be immune to them too, but there might be one that doesn't.

Only processes that settheir uid to the euid are vulnerable to this.
(Which includes programs like sendmail, su, and login which have all
been fixed)

> Are there any _other_ ways of breaking a setuid shell script on a
> SVR4/Solaris system that hasn't been carefully written?

C-shell scripts can always be broken:

        env TERM='`/bin/sh -p < /dev/tty >& /dev/tty`' csh-script

(Works for HOME, PATH and USER as well.)

> If the writer has been careful and makes sure all interesting
> variables have known values, LD_* is reset, PATH is reset, IFS is
> reset on the first line, is there anything else left?

I think you should unset *all* variables, except those that you
know not to be dangerous.

> (Oh, I've seen somewhere, that somebody used: "#! /bin/sh -p -"  Does
> anybody know the significance of the "-"?)

The significance of the - is that it prevents the -i trick.  (which
doesn't work on systems with /dev/fd anyway)

Casper