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.
If a patched version wasn't available for your distribution, it is real easy to add the patches (at least the initial patch) to the source package from your distro. At least that's what I did for all of my customers who are still on RHEL 3 and 4.
If anyone wants the quick rundown on what to do (for RPM based distributions), let me know and I'll post my formula (essentially installing the src.rpm, adding the patches to the SOURCES directory, modifying the .spec file, and running rpmbuild).
Just because something works, doesn't mean it's right. How are you going to prove/test that the scripts really work as they should? After all they supposedly worked fine before Shellshock.
It's not that difficult to test for bashisms (most such scripts fail immediately if run from anything other than bash, often with a syntax error), and honestly, most of the scripts I've encountered in the wild that specific /bin/sh work well with a sh-compatible shell. This is especially true if they target systems that don't ship with bash by default (*BSD).
I think the objective here is that the script authors should request bash when using bash syntax extensions and sh otherwise.
> 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).
If a patched version wasn't available for your distribution, it is real easy to add the patches (at least the initial patch) to the source package from your distro. At least that's what I did for all of my customers who are still on RHEL 3 and 4.
If anyone wants the quick rundown on what to do (for RPM based distributions), let me know and I'll post my formula (essentially installing the src.rpm, adding the patches to the SOURCES directory, modifying the .spec file, and running rpmbuild).