Jim Beard wrote,
> I believe the security concern comes from the fact the a
>shell script executes a shell, so if the script is setuid to root, you
>have a shell running as root during the scripts execution. If at
>anytime during the execution the user was able to gain direct access to
>the shell, they would essentially have root access to the machine.
Actually, that's a problem with ALL setuid programs, not just shell
scripts. The cure for it is careful coding, with the maximum possible
paranoia.
The problem with setuid scripts is deeper, and no amount of careful
scripting can cure it. Unlike a binary executable, a script has to be
opened TWICE--once by the kernel, to check the file type and figure out
what shell to use, and once by the shell, in order to actually read in
the script and start executing the commands therein. This is a classic
example of a race condition: Once the kernel has done the first open, the
race is on to see who (the shell or the attacker) can get to the script
first.
Consider the following scenario:
ln -s setuid_script linkname
linkname&
ln -fs evil_script linkname
If the attacker can get the timing just right, so that "ln -fs" operation
happens after the kernel has opened linkname but before the shell opens
it, then the shell will execute evil_script with setuid_script's permissions.
Some UNIXes have extra code in the kernel to try to make setuid scripts
safe with clever tricks to avoid the double open. But even then setuid
shell scripts aren't entirely safe: The shell's command parsing is
controlled by an environment variable ("IFS") which it can inherit from
its parent. There are all sorts of nasty tricks an attacker can play by
using IFS to subvert the command parsing before the script has a chance to
set IFS to a safe value.
Linux takes a simpler approach to the problem by ignoring the setuid bit
on scripts. The double-open race condition is still there, but attackers
can't exploit it to gain permissions they don't deserve.
- Neil Parker
_______________________________________________
EUGLUG mailing list
[email protected]
http://www.euglug.org/mailman/listinfo/euglug
