Mailing List Archive

> I was auditing some Apache::Registry-based scripts for our website
> and was shocked by the lack of input checking (think the worst
> possible: open "|mail $foo"). In an ideal world I would turn
> PerlTaintCheck On immediately and spend a couple weeks fixing
> everything that broke. I do not live in an ideal world. Is there
> a way to turn taint checking on in a per-script basis? The guide
> mentions that -T doesn't work under mod_perl. The best way I could
> think of would be something like
>
> <Files /cgi-bin/please_hack_us.pl>
> PerlTaintCheck On
> </Files>
>
> Is there a better way?

You should send this question to perl5porters mailing list. Let me explain
why:

There is a $^W special variable to turn warnings on and off wherever you
want. There is no equvalent variable for the tainting flag, therefore once
you have started your interpreter with the taint mode On, it stays On for
the rest of the process life, because each process loads the Perl
interpreter only once.

The issue of having a taint flag variable was discussed a lot, and the
concensus was that it should be forced and hardcoded as On in Perl. For
the back compatibility issues and because of some lazy users it wasn't
forced to be that way. Note that it wasn't said in this exact words but
you understand the direction. Of course no one wants to force a thing on
you, beleive me that you want to have this one turned on.

And again, if you feel like you really need this variable, please ask at
the p5p list, but probably read first the archives, so you won't be
unnecessary flamed.

Hope this helps.

_______________________________________________________________________
Stas Bekman mailto:sbekman@iname.com http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.org modperl.sourcegarden.org perlmonth.com perl.org
single o-> + single o-+ = singlesheaven http://www.singlesheaven.com

markw@horvitznewspapers.net (Mark Wagner) wrote:
>I was auditing some Apache::Registry-based scripts for our website
>and was shocked by the lack of input checking (think the worst
>possible: open "|mail $foo"). In an ideal world I would turn
>PerlTaintCheck On immediately and spend a couple weeks fixing
>everything that broke. I do not live in an ideal world. Is there
>a way to turn taint checking on in a per-script basis?

A couple of observations: you can revert these scripts back to regular CGI with
taint-checks turned on (one by one), and then as they get fixed switch them
back to Registry with taintcheck on. Or you could start another server up with
taintcheck on, and see what breaks.


------------------- -------------------
Ken Williams Last Bastion of Euclidity
ken@forum.swarthmore.edu The Math Forum

> I was auditing some Apache::Registry-based scripts for our website
> and was shocked by the lack of input checking (think the worst
> possible: open "|mail $foo"). In an ideal world I would turn
> PerlTaintCheck On immediately and spend a couple weeks fixing
> everything that broke. I do not live in an ideal world. Is there
> a way to turn taint checking on in a per-script basis? The guide
> mentions that -T doesn't work under mod_perl. The best way I could
> think of would be something like
>
> <Files /cgi-bin/please_hack_us.pl>
> PerlTaintCheck On
> </Files>
>
> Is there a better way?

On the second thought, I have a better partial solution for you. Be
careful while using it, since I'm afraid this will not give you a full
protection though.

What you should do is to turn the Taint mode On, make your script
taintness clean. And then turn off the taint mode off (assuming that you
don't change the script afterwards).

Can someone confirm my idea, since I'm not 100% sure that I give a correct
advice. It seems Ok to me, but probably there are subtle checks available
only during the run-time as the perlsec page claims, and it's impossible
to have a secured script without having -T turned on.

Or as Ken has suggested, use a plain mod_cgi for really bad scripts that
cannot work even under PerlRun handler, but make sure you run them on the
light server, to avoid an overhead of loading the Perl interpreter at the
heavy but blazingly fast mod_perl server.

_______________________________________________________________________
Stas Bekman mailto:sbekman@iname.com http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.org modperl.sourcegarden.org perlmonth.com perl.org
single o-> + single o-+ = singlesheaven http://www.singlesheaven.com

I have a third solution that builds on what Ken suggested.

Since many mod_perl installations use mod_proxy front-end anyway, why not
change the mod_proxy mod_rewrite rules to send .tcgi scripts to an apache
backend that runs in taintmode and ones that end in other endings (eg
.cgi) stay on the old server...

Then slowly migrate them by renaming the extensions of your CGIs running
in Apache::Registry.

That way you still get the benefits of Mod_perl... And using the IF blocks
in the config, you can actually have both back-end mod_perl's identicly
configured ...with just one for taintmode on and the other one with
taintmode off.

Later,
Gunther

PS I would not recommend what Stas is saying because the beauty of
taintmode is precisely as he says-- it catches run time stuff...and
frequently it is the unexpected hacking that you are protecting against at
runtime. If you haven't already conceived of input that could crack your
script, then it's likely you won't check this input while you test with
taintmode on.

In other words, testing in taintmode but deploying without merely checks
the determined path of what you thought a user would normally do. But it
doesn't protect against that which one or a few mere mortals (including
myself) not being able to come up with the scenario that 100+ cracker eyes
might see around the world of the Internet.

On Wed, 23 Feb 2000, Stas Bekman wrote:

> > I was auditing some Apache::Registry-based scripts for our website
> > and was shocked by the lack of input checking (think the worst
> > possible: open "|mail $foo"). In an ideal world I would turn
> > PerlTaintCheck On immediately and spend a couple weeks fixing
> > everything that broke. I do not live in an ideal world. Is there
> > a way to turn taint checking on in a per-script basis? The guide
> > mentions that -T doesn't work under mod_perl. The best way I could
> > think of would be something like
> >
> > <Files /cgi-bin/please_hack_us.pl>
> > PerlTaintCheck On
> > </Files>
> >
> > Is there a better way?
>
> On the second thought, I have a better partial solution for you. Be
> careful while using it, since I'm afraid this will not give you a full
> protection though.
>
> What you should do is to turn the Taint mode On, make your script
> taintness clean. And then turn off the taint mode off (assuming that you
> don't change the script afterwards).
>
> Can someone confirm my idea, since I'm not 100% sure that I give a correct
> advice. It seems Ok to me, but probably there are subtle checks available
> only during the run-time as the perlsec page claims, and it's impossible
> to have a secured script without having -T turned on.
>
> Or as Ken has suggested, use a plain mod_cgi for really bad scripts that
> cannot work even under PerlRun handler, but make sure you run them on the
> light server, to avoid an overhead of loading the Perl interpreter at the
> heavy but blazingly fast mod_perl server.
>
> _______________________________________________________________________
> Stas Bekman mailto:sbekman@iname.com http://www.stason.org/stas
> Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
> perl.apache.org modperl.sourcegarden.org perlmonth.com perl.org
> single o-> + single o-+ = singlesheaven http://www.singlesheaven.com
>
>