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. > >