Re: CGI::Application and recent bash security hole
On 26 September 2014 13:45, gvim gvi...@gmail.com wrote:
Updated my bash on CentOS 6.5 this morning so your test fails:
# env x='() { :;}; echo vulnerable' bash -c echo this is a test
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
There's a second vulnerability that escapes the first bug patch.
env X=() { (a)=\\ bash -c '/dev/stdout date'
If this prints the date, you still have a hole where bash can write content
to arbitrary files. ( And this trick somehow makes it write the date to
/dev/stdout. )
--
Kent
*KENTNL* - https://metacpan.org/author/KENTNL
Re: CGI::Application and recent bash security hole
Quoting Kent Fredric kentfred...@gmail.com:
On 26 September 2014 13:45, gvim gvi...@gmail.com wrote:
Updated my bash on CentOS 6.5 this morning so your test fails:
# env x='() { :;}; echo vulnerable' bash -c echo this is a test
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
There's a second vulnerability that escapes the first bug patch.
env X=() { (a)=\\ bash -c '/dev/stdout date'
If this prints the date, you still have a hole where bash can write content
to arbitrary files. ( And this trick somehow makes it write the date to
/dev/stdout. )
New patch released overnight which seems to fix that.
Dave...
Re: CGI::Application and recent bash security hole
Based on the RedHat notice, mod_perl is not known to propagate the bug.
https://access.redhat.com/node/1200223
mod_php, mod_perl, and mod_python do not use environment variables and we
believe they are not affected
Also, with mod_perl you have to whitelist your environment with
PerlPassEnv, before you get anywhere near shelling-out, which I think is
what Bill has demonstrated.
Ash
Message: 8
Date: Thu, 25 Sep 2014 13:33:57 -0700
From: Bill Moseley mose...@hank.org
Subject: Re: CGI::Application and recent bash security hole
To: London.pm Perl M[ou]ngers london.pm@london.pm.org
Message-ID:
cakhn_m4udf9upzxd6166o2wlsw2rxp_9ijc5rk0woa4rfov...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
I did a very quick test today using mod_perl running as my own user.
Maybe you could try something similar.
I'm running on CentOS where it is vulnerable:
$ env x='() { :;}; echo vulnerable' bash -c echo this is a test
vulnerable
this is a test
In my mod_perl script I added:
system( '/bin/bash -c env /home/bill/env.bash' );
system( '/bin/env /home/bill/env.env' );
I also included a print STDERR Dumper \%ENV; in the mod_perl script. I'm
using SetHandler perl-script to build the CGI environment.
Dumping \%ENV I could see all the CGI environment variables in the Apache
log, but env.out and env.bash didn't contain any of the CGI environment
vars.
I also added a header to my request to attempt to use the exploit:
$req-header( Referer = '() { :; }; echo oops /home/bill/oops.txt' );
And that file didn't show up, either.
I'm not quite clear where (or sure that) the environment is getting
scrubbed.
Re: CGI::Application and recent bash security hole
On Thu, Sep 25, 2014 at 05:50:54PM +0100, Dagfinn Ilmari Manns?ker wrote: Remember that Perl's system()¹ , as well as C's system() and popen() invoke /bin/sh, which may or may not be bash (it is on RedHat-like systems, but not on Debian-like systems, for example). ORLY? $ ls -l /bin/bash /bin/sh -rwxr-xr-x1 root root 625228 Dec 19 2004 /bin/bash lrwxrwxrwx1 root root4 Aug 16 2007 /bin/sh - bash On *recent* Debian-ish systems sh isn't bash, but it's foolish to assume that all Debian-ish systems are recent. -- David Cantrell | http://www.cantrell.org.uk/david The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary -- H. L. Mencken
Re: CGI::Application and recent bash security hole
There's a second vulnerability that escapes the first bug patch.
env X=() { (a)=\\ bash -c '/dev/stdout date'
If this prints the date, you still have a hole where bash can write content
to arbitrary files. ( And this trick somehow makes it write the date to
/dev/stdout. )
Kreist, I'm up **it Creek after all :(
gvim
Re: CGI::Application and recent bash security hole
On 26/09/14 10:24, Dave Cross wrote:
env X=() { (a)=\\ bash -c '/dev/stdout date'
But not this:
env X=() { (a)=\\ bash -c 'date'
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
Fri Sep 26 14:11:23 BST 2014
Re: CGI::Application and recent bash security hole
Quoting gvim gvi...@gmail.com:
There's a second vulnerability that escapes the first bug patch.
env X=() { (a)=\\ bash -c '/dev/stdout date'
If this prints the date, you still have a hole where bash can write content
to arbitrary files. ( And this trick somehow makes it write the date to
/dev/stdout. )
Kreist, I'm up **it Creek after all :(
Your distro almost certainly has a second patch already available.
Just update your installed package.
This article seems pretty good:
http://perltricks.com/article/115/2014/9/26/Shellshock-and-Perl
Dave...
Re: CGI::Application and recent bash security hole
On Fri, Sep 26, 2014 at 02:11:49PM +0100, Dirk Koopman wrote:
But not this:
env X=() { (a)=\\ bash -c 'date'
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
Fri Sep 26 14:11:23 BST 2014
Is that not functionally equivalent to
$ env X=foo bar bash -c 'date'
Fri Sep 26 18:31:00 BST 2014
and thus working as designed?
Re: CGI::Application and recent bash security hole
Or you can manually update obsolete systems
http://superuser.com/questions/816787/how-do-i-patch-the-shellshock-vulnerability-on-an-obsolete-ubuntu-system-that-i
Regards,
Anatoliy
On 26 Sep 2014, at 17:11, Dave Cross d...@dave.org.uk wrote:
Quoting gvim gvi...@gmail.com:
There's a second vulnerability that escapes the first bug patch.
env X=() { (a)=\\ bash -c '/dev/stdout date'
If this prints the date, you still have a hole where bash can write content
to arbitrary files. ( And this trick somehow makes it write the date to
/dev/stdout. )
Kreist, I'm up **it Creek after all :(
Your distro almost certainly has a second patch already available. Just
update your installed package.
This article seems pretty good:
http://perltricks.com/article/115/2014/9/26/Shellshock-and-Perl
Dave...
Re: CGI::Application and recent bash security hole
gvim gvi...@gmail.com writes: I built a site several years ago with CGI::Application which runs in cgi, not psgi mode. Is it likely to be vulnerable to the recent bash security hole which I understand revolves around setting ENV variables? gvim -- A disappointingly low fraction of the human race is, at any given time, on fire. - Stig Sandbeck Mathisen
Re: CGI::Application and recent bash security hole
[Sorry for the empty response, I fat-fingered] gvim gvi...@gmail.com writes: I built a site several years ago with CGI::Application which runs in cgi, not psgi mode. Is it likely to be vulnerable to the recent bash security hole which I understand revolves around setting ENV variables? If you ever end up invoking bash you will be vulnerable, since CGI passes the HTTP headers as HTTP_* environment variables. Remember that Perl's system()¹ , as well as C's system() and popen() invoke /bin/sh, which may or may not be bash (it is on RedHat-like systems, but not on Debian-like systems, for example). [1]: If it's passed a single argument which contains shell metacharacters -- - Twitter seems more influential [than blogs] in the 'gets reported in the mainstream press' sense at least. - Matt McLeod - That'd be because the content of a tweet is easier to condense down to a mainstream media article. - Calle Dybedahl
Re: CGI::Application and recent bash security hole
Is your system shell bash? Does your application have any code which shells out to that (system(), ``, qx() etc)? If so, then probably yes. On 25 September 2014 14:52, gvim gvi...@gmail.com wrote: I built a site several years ago with CGI::Application which runs in cgi, not psgi mode. Is it likely to be vulnerable to the recent bash security hole which I understand revolves around setting ENV variables? gvim
Re: CGI::Application and recent bash security hole
I think Perl itself isn't vulnerable to the same problem: env variables aren't automatically evaluated, at least not in general; but, I actually wonder whether the usual Perl variables like PERL5LIB, PERL5OPT, LOGDIR, PERL5DB, PERL5SHELL etc. can't be set and misused through CGI. Also, anything that involves running a shell (open ...| or |..., system, exec with non-trivial single string arguments that Perl doesn't know how to handle directly) will probably be exposing the problem in the used shell (probably bash in sh mode) unless the latter is patched. I don't immediately see any such calls in CGI/Application.pm or CGI/Application/Mailform.pm, but don't rely on that, any number of other modules you're using could be running a shell. Upgrade bash to solve that part. Ch.
Re: CGI::Application and recent bash security hole
2014-09-25 19:36 GMT+01:00, Christian Jaeger chr...@gmail.com: but, I actually wonder whether the usual Perl variables like PERL5LIB, PERL5OPT, LOGDIR, PERL5DB, PERL5SHELL etc. can't be set and misused through CGI. They can't. I was being stupid, this is not a case where users can decide on the variable names (i.e. query parameters are *not* passed as individual env variables). As also Dagfinn has written in his post (which arrived after I wrote mine), it will still a problem with bash though (unless CGI.pm or so deletes or cleans the CGI env variables, I haven't checked that).
Re: CGI::Application and recent bash security hole
I did a very quick test today using mod_perl running as my own user.
Maybe you could try something similar.
I'm running on CentOS where it is vulnerable:
$ env x='() { :;}; echo vulnerable' bash -c echo this is a test
vulnerable
this is a test
In my mod_perl script I added:
system( '/bin/bash -c env /home/bill/env.bash' );
system( '/bin/env /home/bill/env.env' );
I also included a print STDERR Dumper \%ENV; in the mod_perl script. I'm
using SetHandler perl-script to build the CGI environment.
Dumping \%ENV I could see all the CGI environment variables in the Apache
log, but env.out and env.bash didn't contain any of the CGI environment
vars.
I also added a header to my request to attempt to use the exploit:
$req-header( Referer = '() { :; }; echo oops /home/bill/oops.txt' );
And that file didn't show up, either.
I'm not quite clear where (or sure that) the environment is getting
scrubbed.
On Thu, Sep 25, 2014 at 9:59 AM, Sue Spence virtually...@gmail.com wrote:
Is your system shell bash? Does your application have any code which shells
out to that (system(), ``, qx() etc)? If so, then probably yes.
On 25 September 2014 14:52, gvim gvi...@gmail.com wrote:
I built a site several years ago with CGI::Application which runs in cgi,
not psgi mode. Is it likely to be vulnerable to the recent bash security
hole which I understand revolves around setting ENV variables?
gvim
--
Bill Moseley
mose...@hank.org
Re: CGI::Application and recent bash security hole
On 25/09/2014 17:59, Sue Spence wrote: Is your system shell bash? Does your application have any code which shells out to that (system(), ``, qx() etc)? If so, then probably yes. No, I think I'm safe as the application merely takes in form data, scrubs it and enters them it into a database before passing the user to a list of options which, once one is selected, result in a handful of emails being sent out using MIME::Lite::TT and Email::Address. gvim
Re: CGI::Application and recent bash security hole
On 25/09/2014 21:33, Bill Moseley wrote:
I did a very quick test today using mod_perl running as my own user.
Maybe you could try something similar.
I'm running on CentOS where it is vulnerable:
$ env x='() { :;}; echo vulnerable' bash -c echo this is a test
vulnerable
this is a test
Updated my bash on CentOS 6.5 this morning so your test fails:
# env x='() { :;}; echo vulnerable' bash -c echo this is a test
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
gvim
