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 > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
