> I don't understand why people would go through the trouble of re-pointing /bin/bash to something else (along with auditing their scripts), vs. just updating bash to the patched version. Patches for the most serious of the vulnerabilities were available on day 1, and by day 2 or 3 we had Red Hat's patches (putting exported variables in their own name space) which should mitigate all possible variant vulnerabilities.
I think you misunderstood/misread my comment. Please re-read it: You'll notice that I'm advocating pointing /bin/sh to something else. This is what Debian and Ubuntu both do (/bin/sh is a symlink to dash). I'm not advocating molesting /bin/bash in any way, shape, or form. It is my opinion (and opinions can be wrong) that /bin/sh should be explicitly understood to be a minimal POSIX-compliant shell. If a script wants /bin/bash, it should specifically ask for such. Curiously, using something other than bash for the /bin/sh symlink sidelines some of the attack surface (APR if it hasn't been changed from its default configuration, some syscalls, etc.).
So, two other things remain that I feel warrant pointing /bin/sh elsewhere:
1) We're assuming the last 3 or so patches have corrected all of the low-hanging fruit in bash. The fact the initial shellshock vulnerability went undiscovered for so long until it was audited should be worrisome.
2) Not all systems (most, but not all) may have bash installed by default. Targeting a minimum POSIX-compliant shell mostly guarantees a script will work on these systems (OpenBSD, FreeBSD, most nearly all Linux flavors). If you need anything more complicated, ask for bash specifically or do something else (Python, Perl, etc are usually installed on most systems these days, save for embedded platforms).
I think you misunderstood/misread my comment. Please re-read it: You'll notice that I'm advocating pointing /bin/sh to something else. This is what Debian and Ubuntu both do (/bin/sh is a symlink to dash). I'm not advocating molesting /bin/bash in any way, shape, or form. It is my opinion (and opinions can be wrong) that /bin/sh should be explicitly understood to be a minimal POSIX-compliant shell. If a script wants /bin/bash, it should specifically ask for such. Curiously, using something other than bash for the /bin/sh symlink sidelines some of the attack surface (APR if it hasn't been changed from its default configuration, some syscalls, etc.).
So, two other things remain that I feel warrant pointing /bin/sh elsewhere:
1) We're assuming the last 3 or so patches have corrected all of the low-hanging fruit in bash. The fact the initial shellshock vulnerability went undiscovered for so long until it was audited should be worrisome.
2) Not all systems (most, but not all) may have bash installed by default. Targeting a minimum POSIX-compliant shell mostly guarantees a script will work on these systems (OpenBSD, FreeBSD, most nearly all Linux flavors). If you need anything more complicated, ask for bash specifically or do something else (Python, Perl, etc are usually installed on most systems these days, save for embedded platforms).