Wonderful, another day, another big bad security hole... or two.
Run your patches!
First up: bash: $ env x='() { :;}; echo OOPS' bash -c /usr/sbin/nologin OOPS This account is currently not available.
http://www.openwall.com/lists/oss-security/2014/09/24/10
claims:
In many common configurations, this vulnerability is exploitable over the network.
I'm trying to guess how? In what instance is some program allowing network vectors to set env vars, especially without sterilization? Or do I not want to know...
Next up, procmail has a formail buffer overflow that may or may not allow arb code exec CVE-2014-3618. Many stock procmail recipes use formail. It's easy to see how this one is remotely exploitable.
I'm trying to guess how? In what instance is some program allowing network vectors to set env vars, especially without sterilization? Or do I not want to know...
My guess would be anything attached to a web server -- CGI, dynamic apps that shell out to stuff like imagemagick, etc. Headers are passed through to the script: HTTP_REFERER, USER_AGENT, and so forth.
Sean
On Thu, Sep 25, 2014 at 6:02 AM, Trevor Cordes trevor@tecnopolis.ca wrote:
Wonderful, another day, another big bad security hole... or two.
Run your patches!
First up: bash: $ env x='() { :;}; echo OOPS' bash -c /usr/sbin/nologin OOPS This account is currently not available.
http://www.openwall.com/lists/oss-security/2014/09/24/10
claims:
In many common configurations, this vulnerability is exploitable over the network.
I'm trying to guess how? In what instance is some program allowing network vectors to set env vars, especially without sterilization? Or do I not want to know...
Next up, procmail has a formail buffer overflow that may or may not allow arb code exec CVE-2014-3618. Many stock procmail recipes use formail. It's easy to see how this one is remotely exploitable. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
Didn't take the script kiddies long to start trying...
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"
The above is on the MUUG web server. Of course, they didn't get anywhere with either of these attempts.
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!
Keeps life interesting, for some, I suppose.
Gilbert
On 25/09/2014 7:23 AM, Sean Walberg wrote:
I'm trying to guess how? In what instance is some program allowing network vectors to set env vars, especially without sterilization? Or do I not want to know...My guess would be anything attached to a web server -- CGI, dynamic apps that shell out to stuff like imagemagick, etc. Headers are passed through to the script: HTTP_REFERER, USER_AGENT, and so forth.
Sean
On Thu, Sep 25, 2014 at 6:02 AM, Trevor Cordes <trevor@tecnopolis.ca mailto:trevor@tecnopolis.ca> wrote:
Wonderful, another day, another big bad security hole... or two. Run your patches! First up: bash: $ env x='() { :;}; echo OOPS' bash -c /usr/sbin/nologin OOPS This account is currently not available. http://www.openwall.com/lists/oss-security/2014/09/24/10 claims: > In many common configurations, this vulnerability is exploitable over > the network. I'm trying to guess how? In what instance is some program allowing network vectors to set env vars, especially without sterilization? Or do I not want to know... Next up, procmail has a formail buffer overflow that may or may not allow arb code exec CVE-2014-3618. Many stock procmail recipes use formail. It's easy to see how this one is remotely exploitable.
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.
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-environmen... 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
On 26/09/2014 2:40 AM, Trevor Cordes wrote:
On 2014-09-25 Gilbert E. Detillieux wrote:
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.
...
Besides CGI which by its nature must pass the ENV, it looks like the number of http-vector cases may be limited.
There's a good overview video from SANS on the subject...
https://www.youtube.com/watch?v=W7GaVyzkCs0
It explains a quick way to find potentially vulnerable scripts, using a Google search...
filetype:sh inurl:cgi-bin site:example.com
... which, of course, is exactly what the script kiddies are now doing (minus the site: tag) to target potential bash scripts.
It also briefly mentions other potentially exploitable vectors, such as ssh running restricted shells/scripts, and DHCP (not easily exploited, but can get you root access).
-
Gilbert E. Detillieux -
Sean Walberg -
Trevor Cordes