
Bad news about Shellshock - hkr_mag
http://blog.wallarm.com/post/98420727113/5-very-bad-news-about-shellshock
======
thaumaturgy
Woah. This is getting blown a _little_ out of proportion now. It's a bad bug,
but we don't need a bunch of misinformation about it:

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.

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

3\. DHCP exploitation requires that you have network-start scripts that are
run by bash on your system, _and_ you're getting DHCP from a compromised host.

4\. Yes, ssh hosts are vulnerable -- _if_ 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.

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.

Keep calm and update bash.

------
kazinator
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".

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.

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.

~~~
nhaehnle
Confining the parser to a namespace as in your second paragraph should be a
sufficient solution, because it is already a well-known fact that allowing
completely arbitrary control of the environment to a potential attacker is a
bad idea, and existing software is written to account for that fact by
restricting which environment variables can be set.

In the CGI case, for example, the environment variables in question are
prefixed by HTTP_.

The problem is that any fix for this bug that makes the security crowd
perfectly happy is necessarily going to break compatibility for the (probably
very few) people who actually use this feature.

~~~
kazinator
However, a flaw in some software (failure to properly restrict environment
variables) is amplified by this feature of the shell; it gives an attacker an
instant way to do harm. Whereas without this feature, attackers have to find
some other ways by which environment variable contents can lead to an exploit.
E.g. smuggle a rogue shared library onto the system somehow, then LD_PRELOAD
it or whatever.

------
jewel
> There is still no working patch.

Is this still true? On Ubuntu we got another update today:

    
    
          * 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

~~~
sdrothrock
Wouldn't "incomplete fix" seem to be evidence that it's not a fix?

~~~
CUViper
7169 is the notice that 6271 was incomplete.

