jwp@sdchema.UUCP (John Pierce) (01/15/85)
In net.unix it has been pointed out that set[ug]id shell scripts can be made, that there are major security problems with them, and a hint as to how to find those problems was given. Conversations with various people indicate that at least one problem with such scripts in 4.xBSD and System V is not really well known. I assume the problem exists in any other UNIX system that honors set[ug]id mode bits for shell scripts, but I do not know that for certain. For those of you who don't know of such a security problem, I will respond to mail from "root" with mail back to "root" that explains the nature of one problem with them. I will also give examples of fixes for the shells that eliminates it (kernel fixes are not really necessary, but may be desirable in some environments). I do not know of a fix for binary-only sites beyond awarness and screaming at your vendor to fix things (or finding someone to give you compiled versions of fixed shells). Mail from individual users will be ignored unless (1) they are listed as site managers in the USENET map information, (2) I know them or someone I trust vouches for them, or (3) they are able to provide *very* convincing reasons as to why they should know about this problem and can't get their local guru to enlighten them. John Pierce, Chemsitry, UC San Diego [ucbvax!]sdcsvax!sdchema!jwp decvax!sdchema!jwp
Ron Natalie <ron@BRL-TGR> (01/17/85)
System V does not honor the setuid bits on shell files. 4.2 Does not honor the setuid bits on shell files. This is because shell files are data, to be input to another program rather than things that get processed by the "exec" system call which is where setuid bits are dealt with. 4.2 does have a mechanism that if the magic number of a file happens to correspond to "#!" the kernel then reads for the rest of the line and uses that as the program to exec. The setuid bits get applied to that program (not necessarily the shell). The standard input gets redirected to the file (the manual is wrong). Any time a setuid program is going to do things like invoking the shell, it is going to have to be careful. Most cases are not a defect in the shell. If you only have a binary license, get rid of setuid files begining with "#!". Carefully redo what they do in a real execed program wathching out for pitfalls. How about a little software design methodology here? Of course, with trully execed (non-#!) programs you have no recourse than to beat on the people you got your UNIX from if they do dumb things in setuid programs. -Ron
guy@rlgvax.UUCP (Guy Harris) (01/17/85)
> 4.2 does have a mechanism that if the magic number of a file happens to > correspond to "#!" the kernel then reads for the rest of the line and > uses that as the program to exec. The setuid bits get applied to that > program (not necessarily the shell). The standard input gets redirected > to the file (the manual is wrong). No, the manual is correct. It says "An interpreter file begins with a line of the form ``#! interpreter''; when an interpreter file is "execve"d, the system "execve"s the specified "interpreter", giving it the name of the originally exec'd file as an argument, shifting over the rest of the original arguments." The following interpreter file: #! /bin/echo when named "putz" and run as "putz foo bar", prints "putz foo bar". The reason this doesn't confuse a shell script (i.e., that the script #! /bin/sh echo '$0 =' "$0" echo "$@" cat >/tmp/stuff (which reads from the terminal, not from the script file, in the "cat" command) when called "futz" and run as "futz foo bar" prints "foo bar" on the second echo line) is that the shell is run as /bin/sh futz foo bar and takes "futz" as the script to run and "foo" and "bar" as the arguments to pass to it. The only code in "kern_exec.c" that does anything with file descriptors is the code that does close-on-exec. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy