[PLUG] cross-platform bash vulnerability widespread

Tim tim-pdxlug at sentinelchicken.org
Fri Sep 26 15:23:43 UTC 2014


This vulnerability in bash is particularly nasty because even if you
only ever call /bin/sh in a script or via system(3), popen(3) and
friends, then you are likely still vulnerable because /bin/sh is a
symlink to bash on many linux systems.  And as Micah pointed out, the
bugs aren't all fixed yet, even if you apply the initial patch.


For years I have ditched bash as my /bin/sh since bash is large and
slow.  It uses 5x as much memory as alternatives such as dash.  Bash
is good as a user interface, but not as a scripting tool, and all of
those scripts in /etc that run at boot time go a whole lot faster if
you use a simpler alternative.  As it so happens, changing to something
like dash will also vastly reduce the attack surface related to this
vulnerability.

To change your default /bin/sh to dash on Debian-based systems 
(e.g. Ubuntu), all you need to do is:
  sudo apt-get install dash

And then say "yes" to the prompt when it asks about /bin/sh.  I
recommend this for everyone on these platforms, in addition to
patching their bash as new fixes come out.  I can't say whether or not
a similar change on other Linux platforms is as painless as it is on
Debian, but it might be worth a try.

tim


PS- Once again, you really do need to patch even with this mitigation.
The maintainers of dhclient, in their infinite wisdom, decided that
simple shell scripts must rely on bash non-standard features for the
most menial of tasks, so if you don't patch, you're still vulnerable
to malicious DHCP servers.



On Thu, Sep 25, 2014 at 11:53:58AM -0700, Micah Cowan wrote:
> <snipped historical discussion of bash bug>
> 
> None of yesterday's fixes are complete (but still use yesterday's patch
> anyway in the meantime, as it's better than nothing).
> 
> bash is STILL vulnerable everywhere, as tracked by this (newer) CVE:
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
> 
> I'm not currently aware of a patch for the revised issue as of yet. Some
> folks I know (my employer, for instance) are responding by completely
> disabling function exports completely, which does the job:
> 
> 
> https://github.com/akamai/bash/commit/7caac6ee41f645fc21b6e5eddc820151f6e6c43c
> 
> Note that (as I discovered) the patch above will successfully apply
> INCORRECTLY to some older versions of bash, unless you also specify --fuzz
> 1 (fuzz 2, the default, lets it apply). In one version of bash
> (4.2.something) I patched, the results were BUILDABLE, but completely
> wrong. Eyeball it after patching to make sure it only excludes the body of
> a single if statement.
> 
> Example of the still-existing exploit:
> 
>   $ env X='() { (a)=>\' sh -c "echo date"; cat echo
> 
> (if the file "echo" exists afterwards, it's vulnerable)
> 
> Again, as of this time, there is NO released patch for this one yet.
> 
> -mjc
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug



More information about the PLUG mailing list