Woah. This is getting blown a <i>little</i> out of proportion now. It's a bad bug, but we don't need a bunch of misinformation about it:<p>1. The released patch (and subsequent update for many distributions) fixed the only currently-known remotely exploitable version of the bug. The cases found afterward are a different bug, and so far there's no publicly known way to remotely exploit it. These other bugs were published to demonstrate that there are deeper flaws in bash's parsing of environment variables. If you have updated bash with the most recent fix, the odds are in your favor that you're going to be just fine.<p>2. "Routers, web cameras, SIP gateways, NAS’s" & etc. all need to be running a variant of bash to be exploitable. dash doesn't have this problem. ksh, csh, other shells don't have this problem. ash, used by BusyBox, doesn't have this problem. BSD-based systems don't have this problem (except in rare circumstances).<p>3. DHCP exploitation requires that you have network-start scripts that are run by bash on your system, <i>and</i> you're getting DHCP from a compromised host.<p>4. Yes, ssh hosts are vulnerable -- <i>if</i> you already have ssh access to those hosts and your shell is bash. This bug doesn't give most users a level of access that they don't already have. But, it can mean that if a user is restricted to specific commands for sudo without being prompted for a password, then they can run arbitrary sudo commands, which isn't very nice.<p>5. And yeah, mass-scanning started late last night and the first examples of malware using this as a vector are being seen. As scanning techniques improve -- currently they're pretty rudimentary -- more and more hosts will get compromised.<p>Keep calm and update bash.
The parsing of environment variables to produce functions should be disabled int bash by default, unless a loud and clear command line option is given to request the behavior, like "bash --hit-me-with-environment-variable-stupidity-please".<p>Furthermore, perhaps it should only work on environment variables in a loud an clear namespace like __bash_func_foo="() { whatever }" produces a function called "foo". A variable not in this namespace like TERM or REQUEST_URL is not scanned for this function-defining syntax under any circumstances.<p>Lastly, perhaps the target functions should be in a namespace themselves, making it impossible to pass down a function called "echo" or "ls". For instance only functions with the "if_" prefix ("inheritable function") could be subject to inheritance. Don't like the ugly prefix? Then write your shell application so that every new execution of a script sources all the code it needs from files. Or write your personal scripts so that they use a repository of functions in your ~/.bashrc rather than passing functions down among themselves. Or use local aliases for the ugly prefixed names.
> There is still no working patch.<p>Is this still true? On Ubuntu we got another update today:<p><pre><code> * SECURITY UPDATE: incomplete fix for CVE-2014-6271
- debian/patches/CVE-2014-7169.diff: fix logic in parse.y.
- CVE-2014-7169
-- Marc Deslauriers <marc.deslauriers@ubuntu.com> Thu, 25 Sep 2014 02:06:49 -0400</code></pre>