On Fri, Sep 26, 2014 at 4:15 PM, Russell Senior
<[email protected]> wrote:
> DHCP servers can provide shell-processed strings
> apparently, typically run as root to configure a client devices
> network. Some cgi scripts, assuming they fire off a privileged bash,
> would be vulnerable.
It's even a little worse than that, really.
It's not necessary for the strings involved to have been
"shell-processed", only for them to be present in the environment when
bash starts up (it doesn't matter at all what the command to bash was
- bash runs the injected code during its _initialization_ phase (!!!).
Any environment variable name at all - it all depends solely on the
content of _any_ variable.
As you say, obviously every CGI script that might invoke (or god
forbid, run in) bash will exercise the problem (since CGI is entirely
based on putting the contents of request headers into - you guessed
it! - environment variables). And the common Linux dhcp client uses
env vars to do this as well.
Note: there is no shame in those CGI scripts and the DHCP client -
this is a perfectly natural, and often efficient, means of
communication between processes, particularly when one is careful to
control the names of the environment variables. The blame for this
really lies completely with bash's poor code, and really even it's
design - the very idea of being able to transfer executable code via
env vars (which is exactly what bash's _intended_ function-export
feature is) is an incredibly bad idea, security-wise).
As you say, in theory, it's only a serious problem if it's a
privileged shell that's fired. Of course, it depends somewhat what's
meant by "privileged". It's going to run with the same permissions
that your web server run the CGI script as (in most cases, probably
"www-data" or "nobody"), which means it can read (and often, delete!)
all the configuration and content files. For instance, if you run
Wordpress in such a way as to support upgrades from the web interface,
then it can delete all your Wordpress .php files, and will be able to
read the wp-config.php file that contains your read/write mysql
account's username and password. Quite a bit of serious damage can be
done just with that, and it can be triggered as easily as
exec("/bin/true") (on a system where /bin/sh is unpatched bash; PHP's
exec() apparently always invokes shell, making it more like C's
system() and less like Perl's exec()?).
And then of course there's the fact that many rootkits are available,
and that successfully obtaining any shell access at all can often be
all a worm needs to get itself the rest of the way to root. This
vulnerability isn't enough to get there on its own, naturally - but it
can serve to seriously exacerbate any additional issues you may have.
(NOTE: most of what I describe above applies specifically to
CVE-2014-6271, the one that was patched Wednesday, and not to the
further issue described by CVE-2014-7169, which so far has only been
demonstrated to write to files, and does seem to depend on the actual
command fed to bash.)
-mjc
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
