9.4. Shell Scripting Languages (sh and csh Derivatives)

I strongly recommend against using standard command shell scripting languages (such as csh, sh, and bash) for setuid/setgid secure code. Some systems (such as Linux) completely disable them, so you're creating an unnecessary portability problem. On some old systems they are fundamentally insecure due to a race condition (as discussed in Section 3.1.3). Even for other systems, they're not really a good idea. Standard command shells are still notorious for being affected by nonobvious inputs - generally because command shells were designed to try to do things ``automatically'' for an interactive user, not to defend against a determined attacker. For example, ``hidden'' environment variables (e.g., the ENV or BASH_ENV variable) can affect how they operate or even execute arbitrary user-defined code before the script can even execute. Even things like filenames of the executable or directory contents can affect things. For example, on many Bourne shell implementations, doing the following will grant root access (thanks to NCSA for describing this exploit):

 % ln -s /usr/bin/setuid-shell /tmp/-x
 % cd /tmp
 % -x

Some systems may have closed this hole, but the point still stands: most command shells aren't intended for writing secure setuid/setgid programs. For programming purposes, avoid creating setuid shell scripts, even on those systems that permit them. Instead, write a small program in another language to clean up the environment, then have it call other executables (some of which might be shell scripts).

If you still insist on using shell scripting languages, at least put the script in a directory where it cannot be moved or changed. Set PATH and IFS to known values very early in your script.