From m.keating at shadowcat.co.uk  Mon Sep 22 09:56:06 2014
From: m.keating at shadowcat.co.uk (Mark Keating)
Date: Mon, 22 Sep 2014 09:56:06 +0100
Subject: [ANNOUNCE] London Perl Workshop: Perl and the Arduino
Message-ID: <541FE426.8020702@shadowcat.co.uk>

==Arduino Workshop

It is our pleasure to announce that this year we will be presenting a 
Sponsored Arduino Workshop with part-sponsored equipment. Adrian McEwan 
and Hakim Cassimally will present a 4 hour workshop (split into two 
parts) focussing on the Arduino and Internet of Things.

The workshop will divide into a structured introduction, and a free 
period, where you can play with more electronics or code depending on 
your interests.

First half: Basics of Arduino and Electronics
connecting Arduino, basics of IDE, basics of C++ for Arduino
breadboard basics
wiring up a simple output (LED)
wiring up a simple input (button, potentiometer)
more complicated outputs - RGB LED
connecting to a simple internet app (basic PSGI) to change colour of LED


Second half: Playtime!
Collaborate with other attendees or work by yourself on, for example:
more electronics, wiring up a more complicated input/output from our 
goodie bag
more client code: play with C++ on the Arduino side
more server code: extend the basic PSGI you connected to earlier into a 
full featured Cat/Ox/Mojolicious app
more Perl interfacing: play with Device::Firmata, Device::Arduino::LCD, 
or Device::WebIO

As part of this workshop all attendees will leave with an Arduino Uno, 
Ethernet Shield and various small components. The cost of these 
components is close to ?60 per kit; but thanks to generous sponsorship 
the attendees who sign up to this will only be charged ?25 per person.

To sign up to this you must contact Mark Keating at 
"mailto:m.keating at shadowcat.co.uk" or Claire Jackson 
mailto:c.l.jackson at shadowcat.co.uk and confirm your participation. They 
will give you a link of how to pay. Payment *must* be in advance and 
numbers will be limited to 15 persons. We recommend you sign up early.

More details will be announced.

The speakers have been generously sponsored by the Enlightened Perl 
Organisation.

== Sponsors and Talks

We are still seeking sponsors for this year's event and the Call for 
Papers is open and waiting for you to sign up with your best(est) Perl 
and Internet of Things talks, or other talks as you feel happy to 
submit. There is only a few weeks left to submit those talks.

-mdk

From gvimrc at gmail.com  Thu Sep 25 14:52:26 2014
From: gvimrc at gmail.com (gvim)
Date: Thu, 25 Sep 2014 14:52:26 +0100
Subject: CGI::Application and recent bash security hole
Message-ID: <54241E1A.7010402@gmail.com>

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

From ilmari at ilmari.org  Thu Sep 25 17:45:33 2014
From: ilmari at ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)
Date: Thu, 25 Sep 2014 17:45:33 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <54241E1A.7010402@gmail.com> (gvim's message of "Thu, 25 Sep 2014
	14:52:26 +0100")
References: <54241E1A.7010402@gmail.com>
Message-ID: <d8jppej4pjm.fsf@dalvik.ping.uio.no>

gvim <gvimrc at 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

From ilmari at ilmari.org  Thu Sep 25 17:50:54 2014
From: ilmari at ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)
Date: Thu, 25 Sep 2014 17:50:54 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <54241E1A.7010402@gmail.com> (gvim's message of "Thu, 25 Sep 2014
	14:52:26 +0100")
References: <54241E1A.7010402@gmail.com>
Message-ID: <d8jlhp74pap.fsf@dalvik.ping.uio.no>

[Sorry for the empty response, I fat-fingered]

gvim <gvimrc at 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

From virtuallysue at gmail.com  Thu Sep 25 17:59:46 2014
From: virtuallysue at gmail.com (Sue Spence)
Date: Thu, 25 Sep 2014 17:59:46 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <54241E1A.7010402@gmail.com>
References: <54241E1A.7010402@gmail.com>
Message-ID: <CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>

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 <gvimrc at 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
>

From david at dorward.me.uk  Thu Sep 25 18:20:21 2014
From: david at dorward.me.uk (David Dorward)
Date: Thu, 25 Sep 2014 18:20:21 +0100
Subject: :Application and recent bash security hole
In-Reply-To: <54241E1A.7010402@gmail.com>
References: <54241E1A.7010402@gmail.com>
Message-ID: <8664CD72-B572-4E5F-8A68-624A44E17E00@dorward.me.uk>

On 25 Sep 2014, at 14:52, gvim 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?

 From what I gather, there is a good chance that your HTTP server will 
pass the environment variables through bash before the shebang line 
triggers perl so you could be vulnerable.

Test your installed version of bash with

     env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Look for the word *vulnerable* in the output and upgrade it if it is.

I found [Everything you need to know about the Shellshock Bash bug][1] 
to be interesting reading.

[1]: 
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html



-- 
David Dorward
http://dorward.co.uk/

From chrjae at gmail.com  Thu Sep 25 19:36:54 2014
From: chrjae at gmail.com (Christian Jaeger)
Date: Thu, 25 Sep 2014 19:36:54 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <54241E1A.7010402@gmail.com>
References: <54241E1A.7010402@gmail.com>
Message-ID: <CAEjYwfVW8eUQOqZ2uDgGEQP8asKh3tHhZ3BrhAKgr7FYnvF+mQ@mail.gmail.com>

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.

From chrjae at gmail.com  Thu Sep 25 21:19:29 2014
From: chrjae at gmail.com (Christian Jaeger)
Date: Thu, 25 Sep 2014 21:19:29 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <CAEjYwfVW8eUQOqZ2uDgGEQP8asKh3tHhZ3BrhAKgr7FYnvF+mQ@mail.gmail.com>
References: <54241E1A.7010402@gmail.com>
	<CAEjYwfVW8eUQOqZ2uDgGEQP8asKh3tHhZ3BrhAKgr7FYnvF+mQ@mail.gmail.com>
Message-ID: <CAEjYwfW7O9NoKNvJ=+4AhMMr_1hU44cK9_UYGyWzi5C6WOpeTQ@mail.gmail.com>

2014-09-25 19:36 GMT+01:00, Christian Jaeger <chrjae at 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).

From moseley at hank.org  Thu Sep 25 21:33:57 2014
From: moseley at hank.org (Bill Moseley)
Date: Thu, 25 Sep 2014 13:33:57 -0700
Subject: CGI::Application and recent bash security hole
In-Reply-To: <CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>
References: <54241E1A.7010402@gmail.com>
	<CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>
Message-ID: <CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg@mail.gmail.com>

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 <virtuallysue at 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 <gvimrc at 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
moseley at hank.org

From gvimrc at gmail.com  Fri Sep 26 02:41:13 2014
From: gvimrc at gmail.com (gvim)
Date: Fri, 26 Sep 2014 02:41:13 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>
References: <54241E1A.7010402@gmail.com>
	<CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>
Message-ID: <5424C439.4080803@gmail.com>

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

From gvimrc at gmail.com  Fri Sep 26 02:45:21 2014
From: gvimrc at gmail.com (gvim)
Date: Fri, 26 Sep 2014 02:45:21 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg@mail.gmail.com>
References: <54241E1A.7010402@gmail.com>	<CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>
	<CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg@mail.gmail.com>
Message-ID: <5424C531.3040206@gmail.com>

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

From kentfredric at gmail.com  Fri Sep 26 07:28:33 2014
From: kentfredric at gmail.com (Kent Fredric)
Date: Fri, 26 Sep 2014 18:28:33 +1200
Subject: CGI::Application and recent bash security hole
In-Reply-To: <5424C531.3040206@gmail.com>
References: <54241E1A.7010402@gmail.com>
	<CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>
	<CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg@mail.gmail.com>
	<5424C531.3040206@gmail.com>
Message-ID: <CAATnKFAFF7_i3ZyGUy6aY57-DgRnYF5aqd27=U7Fxc0R448DwQ@mail.gmail.com>

On 26 September 2014 13:45, gvim <gvimrc at 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

From dave at dave.org.uk  Fri Sep 26 10:24:09 2014
From: dave at dave.org.uk (Dave Cross)
Date: Fri, 26 Sep 2014 09:24:09 +0000
Subject: CGI::Application and recent bash security hole
In-Reply-To: <CAATnKFAFF7_i3ZyGUy6aY57-DgRnYF5aqd27=U7Fxc0R448DwQ@mail.gmail.com>
References: <54241E1A.7010402@gmail.com>
	<CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>
	<CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg@mail.gmail.com>
	<5424C531.3040206@gmail.com>
	<CAATnKFAFF7_i3ZyGUy6aY57-DgRnYF5aqd27=U7Fxc0R448DwQ@mail.gmail.com>
Message-ID: <20140926092409.Horde.46Rqqk2EqnungqUB2g5VvA1@webmail.mag-sol.com>

Quoting Kent Fredric <kentfredric at gmail.com>:

> On 26 September 2014 13:45, gvim <gvimrc at 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...



From ash+perl at best-scarper.co.uk  Fri Sep 26 11:56:24 2014
From: ash+perl at best-scarper.co.uk (Ashley Hindmarsh)
Date: Fri, 26 Sep 2014 11:56:24 +0100
Subject: CGI::Application and recent bash security hole
Message-ID: <CACB3aYX_jSxsxEaGxV7fwVOSfdDLEmiKt4p8DZuq4RjmOi9rsQ@mail.gmail.com>

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 <moseley at hank.org>
> Subject: Re: CGI::Application and recent bash security hole
> To: "London.pm Perl M[ou]ngers" <london.pm at london.pm.org>
> Message-ID:
>         <
> CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg at 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.
>
>

From david at cantrell.org.uk  Fri Sep 26 12:06:10 2014
From: david at cantrell.org.uk (David Cantrell)
Date: Fri, 26 Sep 2014 12:06:10 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <d8jlhp74pap.fsf@dalvik.ping.uio.no>
References: <54241E1A.7010402@gmail.com> <d8jlhp74pap.fsf@dalvik.ping.uio.no>
Message-ID: <20140926110609.GA1128@bytemark.barnyard.co.uk>

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-x    1 root     root       625228 Dec 19  2004 /bin/bash
lrwxrwxrwx    1 root     root            4 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

From gvimrc at gmail.com  Fri Sep 26 13:06:01 2014
From: gvimrc at gmail.com (gvim)
Date: Fri, 26 Sep 2014 13:06:01 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <CAATnKFAFF7_i3ZyGUy6aY57-DgRnYF5aqd27=U7Fxc0R448DwQ@mail.gmail.com>
References: <54241E1A.7010402@gmail.com>	<CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>	<CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg@mail.gmail.com>	<5424C531.3040206@gmail.com>
	<CAATnKFAFF7_i3ZyGUy6aY57-DgRnYF5aqd27=U7Fxc0R448DwQ@mail.gmail.com>
Message-ID: <542556A9.2050309@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 :(

gvim


From djk at tobit.co.uk  Fri Sep 26 14:11:49 2014
From: djk at tobit.co.uk (Dirk Koopman)
Date: Fri, 26 Sep 2014 14:11:49 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <20140926092409.Horde.46Rqqk2EqnungqUB2g5VvA1@webmail.mag-sol.com>
References: <54241E1A.7010402@gmail.com>	<CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>	<CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg@mail.gmail.com>	<5424C531.3040206@gmail.com>	<CAATnKFAFF7_i3ZyGUy6aY57-DgRnYF5aqd27=U7Fxc0R448DwQ@mail.gmail.com>
	<20140926092409.Horde.46Rqqk2EqnungqUB2g5VvA1@webmail.mag-sol.com>
Message-ID: <54256615.8040103@tobit.co.uk>

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



From dave at dave.org.uk  Fri Sep 26 16:11:10 2014
From: dave at dave.org.uk (Dave Cross)
Date: Fri, 26 Sep 2014 15:11:10 +0000
Subject: CGI::Application and recent bash security hole
In-Reply-To: <542556A9.2050309@gmail.com>
References: <54241E1A.7010402@gmail.com>
	<CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>
	<CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg@mail.gmail.com>
	<5424C531.3040206@gmail.com>
	<CAATnKFAFF7_i3ZyGUy6aY57-DgRnYF5aqd27=U7Fxc0R448DwQ@mail.gmail.com>
	<542556A9.2050309@gmail.com>
Message-ID: <20140926151110.Horde.VpR2B_e93dn-KHkc1MaNPw1@webmail.mag-sol.com>

Quoting gvim <gvimrc at 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...


From roger at firedrake.org  Fri Sep 26 18:32:20 2014
From: roger at firedrake.org (Roger Bell_West)
Date: Fri, 26 Sep 2014 18:32:20 +0100
Subject: CGI::Application and recent bash security hole
In-Reply-To: <54256615.8040103@tobit.co.uk>
References: <54241E1A.7010402@gmail.com>
	<CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>
	<CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg@mail.gmail.com>
	<5424C531.3040206@gmail.com>
	<CAATnKFAFF7_i3ZyGUy6aY57-DgRnYF5aqd27=U7Fxc0R448DwQ@mail.gmail.com>
	<20140926092409.Horde.46Rqqk2EqnungqUB2g5VvA1@webmail.mag-sol.com>
	<54256615.8040103@tobit.co.uk>
Message-ID: <20140926173220.GA29680@firedrake.org>

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?

From tolid-london.pm at tolid.eu.org  Fri Sep 26 19:30:41 2014
From: tolid-london.pm at tolid.eu.org (Anatoliy Dmytriyev)
Date: Fri, 26 Sep 2014 20:30:41 +0200
Subject: CGI::Application and recent bash security hole
In-Reply-To: <20140926151110.Horde.VpR2B_e93dn-KHkc1MaNPw1@webmail.mag-sol.com>
References: <54241E1A.7010402@gmail.com>
	<CAB12hvGx5=UM80yxBkXuV5qva9jmET5hfZ9BfrD9PPjcAQwtFg@mail.gmail.com>
	<CAKhN_m4UDF9uPzxD6166o2wLSw2RxP_9iJC5Rk0WoA4RFovcfg@mail.gmail.com>
	<5424C531.3040206@gmail.com>
	<CAATnKFAFF7_i3ZyGUy6aY57-DgRnYF5aqd27=U7Fxc0R448DwQ@mail.gmail.com>
	<542556A9.2050309@gmail.com>
	<20140926151110.Horde.VpR2B_e93dn-KHkc1MaNPw1@webmail.mag-sol.com>
Message-ID: <FC139B6F-3E37-4BBB-A779-3A193691A9DB@tolid.eu.org>

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 <dave at dave.org.uk> wrote:

> Quoting gvim <gvimrc at 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...