[RndTbl] bash + procmail vulnerabilities

Sean Walberg sean at ertw.com
Fri Sep 26 07:31:40 CDT 2014


>
> 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 at 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 at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable
>



-- 
Sean Walberg <sean at ertw.com>    http://ertw.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20140926/3b657433/attachment.html>


More information about the Roundtable mailing list