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'
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:
, 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
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
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
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
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
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
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
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
[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
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
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
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
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(
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
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
17 matches
Mail list logo
