5 ms·

On my Debian/Ubuntu systems (that weren't in production and that I was free to play with), I had a lot of luck pointing /bin/bash at /bin/dash and making a sepa

On my Debian/Ubuntu systems (that weren't in production and that I was free to play with), I had a lot of luck pointing /bin/bash at /bin/dash and making a separate /bin/bash-really. The default scripts weren't using /bin/bash at all. Of the third-party scripts that did call /bin/bash, most of them were just lazily using /bin/bash when they could have used /bin/sh just as well. (A few that were actually using some bash-ism that it took me 5 minutes to fix, and only 1 was left that was using some very very weird bash syntax that I couldn't understand.) 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.

Zancarius 12y ago
> 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).
- derekp7 12y ago
  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).
  - danielweber 12y ago
    Because for some people it's edifying to learn just how necessary bash is on their systems.
    - ciupicri 12y ago
      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.
      - Zancarius 12y ago
        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.
  - Zancarius 12y ago
nodata 12y ago
You cannot be serious. Just in case there is a bug in bash? What if there's a bug in sh?
- masklinn 12y ago
  > 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.
  - nodata 12y ago
    Or I do none of that, and patch. Same as when Apache has a bug, or when Java does.

Zancarius 12y ago

> 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).

derekp7 12y ago
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).
- danielweber 12y ago
  Because for some people it's edifying to learn just how necessary bash is on their systems.
  - ciupicri 12y ago
    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.
    - Zancarius 12y ago
      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.
- Zancarius 12y ago

nodata 12y ago

You cannot be serious. Just in case there is a bug in bash? What if there's a bug in sh?

masklinn 12y ago
> 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.
- nodata 12y ago
  Or I do none of that, and patch. Same as when Apache has a bug, or when Java does.