maart@cs.vu.nl (Maarten Litmaath) (11/15/88)
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@cs.vu.nl, mcvax!botter!maart
guy@auspex.UUCP (Guy Harris) (11/17/88)
>What about the csh command interpreter? Well, Sun Unix provides us with a csh >which has a NEW option: "-b"! Credit where credit is due; Berkeley provides that in 4.3BSD, Sun just picked it up. >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... An early 4.3 alpha or beta Bourne shell had this, but I think they realized that the "-" (yes, just "-") option already handled this in the Bourne shell - just use #! /bin/sh - rather than #! /bin/sh However, the other problems discussed still exist, so, as you state, you have to do more than that....