“Shellshock”
dwheeler.com
dwheeler.com
Redhat apparently uses /bin/bash almost universally. That would be a nightmare to try to fix under pressure.
One lesson I've learned (and I didn't always follow it) is to write POSIX-compatible scripts whenever possible and point them at /bin/sh, which is allowed to point to any POSIX-compatible shell. If we get word that, say, a /bin/dash or /bin/ksh attack is coming, you can at least switch your default "runtime" to another shell.
I don't understand why more people did not accept this as a viable solution (with the exception of systems that are replete with bashisms). I had a curious discussion on the Arch general mailing list with someone who seemed to 1) have his head in the sand regarding the severity of this exploit, 2) believed bash's POSIX-compliant mode when invoked as /bin/sh was sufficient for nearly all use cases, and 3) was content with the first patch that came out as having resolved the problem even though it became obvious fairly early on that the patch wasn't sufficient but made unreasonable demands for more and more evidence to the contrary.
(Admittedly: The other side of the coin is that Arch has several scripts that rely heavily on bashisms, so I guess I can at least partially understand where he was coming from--but they all correctly use /bin/bash. The other argument I observed, that adding a dependency on dash somehow inflates the default install too much, seems absurd when dash is about 1/7th the size of bash.)
My solution so far has been to follow the advice you share (more or less) where possible: Replace the /bin/sh symlink to point to /bin/dash and fix those things that need fixing, patching bash in the process. It works well. For everything else, I really rather wish they'd stick as closely to bare POSIX-compatibility for system scripts (I'm guilty of using bash extensions, too, so it would seem hypocritical to point fingers).
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).
I think the objective here is that the script authors should request bash when using bash syntax extensions and sh otherwise.
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).
Mostly because it's a pain in the ass, I've tried doing it and not only do you have to be careful to stick to POSIX, you also have to avoid shell and binary extensions (e.g. `echo -e` would print `-e` with a POSIX echo, it won't with GNU echo or most shell builtins). Even testing it multiple posix-compatible and userland environments, you never really know whether your script actually is cross-platform.
It'd be nice to have an environment (shell and binaries) which implements only POSIX and warns/errors when triggering common extensions.
Not that I'm aware, if you find it I'm interested.
I think that's true for most software, though. Presumption is no replacement for testing...
Just in case there is a bug in bash? What if there's a bug in sh?
As he says, you swap your system shell to an other POSIX-compatible shell. You were using bash? Switch to dash, or zsh, or ksh.
1. http://www.dwheeler.com/sloccount/ 2. http://www.dwheeler.com/trusting-trust/
He is the co-inventor of "Burrows–Wheeler transform", which is a key component in any modern genomics analysis pipeline, used in bzip2 (the "b" stands for BWT), etc.