You don't get a /tmp/foo file (I'm testing pre-patch application) and
the env shows only 8 vars, and nothing passed from httpd external input
(like USER_AGENT).

According to https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ PHP run in mod_php mode is safe but some of the methods of running external commands in PHP aren't if it's in CGI mode.

I just tried something similar on my server, which uses the fpm interface, and the environment isn't passed.

Also tried it in a Rails application and it seemed safe. That said, I've heard reports that people were able to get some older Rails stuff to work: https://twitter.com/patio11/status/515097020273401856

Also, for the curious, there are some stories floating around about people sending the exploit in DHCP options.

Sean

On Fri, Sep 26, 2014 at 2:40 AM, Trevor Cordes <trevor@tecnopolis.ca> wrote:
On 2014-09-25 Gilbert E. Detillieux wrote:
> Didn't take the script kiddies long to start trying...

Ya, good catch Sean for speculating on a vector and thanks Gilbert for
giving us an easy check.  I was thinking only along the lines of
attacking ssh/login. Hadn't thought of http vectors.

> 89.207.135.125 - - [25/Sep/2014:03:22:13 -0500] "GET
> /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 295 "-" "()
> { :;}; /bin/ping -c 1 198.101.206.138"
> 198.20.69.74 - - [25/Sep/2014:13:49:53 -0500] "GET / HTTP/1.1" 301
> 301 "() { :; }; /bin/ping -c 1 104.131.0.69" "() { :; }; /bin/ping -c
> 1 104.131.0.69"

I just checked and the exact same hosts tested my server in the same
way.

> I have another host, with some CGI scripts that have names of the
> form */cgi-bin/*.sh, and those URL's are seeing a lot of attempts
> (all failed as well).  I guess they've got lists of potential target
> URL's to try, and anything ending in ".sh" is going to be
> irresistible!

For sure someone must have compiled existing web-server lists to
rapidly exploit zero-day http vectors.  I'm actually a bit surprised
that a) they did that and b) my measly SMB site is on the list.

I run a lot of PHP, and a few fork out calls to perl, almost always via
bash intermediation.  I tested and mod PHP isn't affected, but I'm
thinking my perl scenario above would be vulnerable, unless PHP is
cleansing the env vars before the bash call.

A quick test reveals that the above scenario is not vulnerable, it
appears PHP is cleaning the env before exec-type calls:

Make a php file in your web doc root (say z.php):
<?
$z=`/bin/perl -e 'foreach (keys %ENV) { print "\$_\t\$ENV{\$_}\n" } '`;
echo "here are the envs:\n$z\n";
?>

644 it and hit it with curl:

curl -X GET -A '() { :; }; /bin/echo foo>/tmp/foo' https://foo.bar/z.php

You don't get a /tmp/foo file (I'm testing pre-patch application) and
the env shows only 8 vars, and nothing passed from httpd external input
(like USER_AGENT).

Phew!

Besides CGI which by its nature must pass the ENV, it looks like the
number of http-vector cases may be limited.
_______________________________________________
Roundtable mailing list
Roundtable@muug.mb.ca
http://www.muug.mb.ca/mailman/listinfo/roundtable



--
Sean Walberg <sean@ertw.com>    http://ertw.com/