How to turn off taint checking in cgi

[Lars Eighner]

How can I turn off taint checking in a perl cgi script?

I mean completely including path checking.

Naturally I would like to do this on a per script basis, but if that
is not possible, is it possible to compile perl (5.8.8) without taint
checking at all?

I am not interested in hearing that I do not want to do this.

I understand I can get around variable taint checking with a do nothing
sed-like replacement, but is it not clear to me how this could be done with
the path.

 

[Paul Lalli]

How can I turn off taint checking in a perl cgi script?

By removing the -T option from the shebang in the script and/or the
perl executable line in your webserver configuration file.

I have now handed you a loaded hand gun and taught you how to point it
at your head. Good luck.

Paul Lalli

 

[anno4000]

How can I turn off taint checking in a perl cgi script?

I mean completely including path checking.

Naturally I would like to do this on a per script basis, but if that
is not possible, is it possible to compile perl (5.8.8) without taint
checking at all?

I am not interested in hearing that I do not want to do this.

I understand I can get around variable taint checking with a do nothing
sed-like replacement, but is it not clear to me how this could be done with
the path.

( $_) = /(.*)/ for $ENV{ PATH};

Anno

 

[Paul Lalli]

PATH is only used if you don't specify the location of the tool you're using -
if you use `ls` instead of `/bin/ls` for instance.

Untrue.

$ perl -Te'system("/bin/ls");'
Insecure $ENV{PATH} while running with -T switch at -e line 1.

Taint checking stops ANY external program from being run until $PATH
is secured, because Perl takes the ultra-paranoid stance that /bin/ls
might call some other program without specifying the full path, and
then that program would be affected by the tainted $PATH.

Paul Lalli

 

[Clenna Lumina]

By removing the -T option from the shebang in the script and/or the
perl executable line in your webserver configuration file.

I don't ever recall seeing anything like that in Apache.

I have now handed you a loaded hand gun and taught you how to point it
at your head. Good luck.

It's amazing how it's always assumed that there isn't a valid reason for
a question like this. The OP may have a perfectly good reason for doing
what he's doing (like, say, debugging in some way), even if we don't
know what it is. Granted, there's nothing wrong with reiterating a
danger where danger potentially exists, but at the same time, it seems
some people act too much like a "parental controls" mechanism, which
only serves to take the focus from the original question itself.

Give warning, by all means, but please try to address the question
itself.

AFAIK, if you are using setuid perl (where tainting is on by default,
iirc), then a common method is using a c wrapper that's suid'ed to the
desired user and executes the script, returning the output.

 

[Peter J. Holzer]

I don't ever recall seeing anything like that in Apache.

Then your CGI scripts are probably not taint checked.

AFAIK there are only two ways to turn taint checking on:

1) Explicitely via the -T flag

2) Implicitely by invoking the perl interpreter with a different ruid
and euid.

I have now handed you a loaded hand gun and taught you how to point it
at your head. Good luck.

[...]
Give warning, by all means, but please try to address the question
itself.

He did, didn't he?

AFAIK, if you are using setuid perl (where tainting is on by default,
iirc), then a common method is using a c wrapper that's suid'ed to the
desired user and executes the script, returning the output.

CGI scripts are generally not invoked with a different ruid and euid, so
this is unlikely to be the reason. However, this can be checked with a
simple script like

#!/usr/bin/perl
use warnings;
use strict;
print "Content-Type: text/plain\n";
print "\n";
print "ruid = $<\n";
print "euid = $>\n";

If this prints the same uid twice, -T flag is left as the only
explanation.

Another question to the OP: Are you really using CGI or are you using
mod_perl? If you use the latter, you share one perl interpreter between
scripts, so the either all have taint checking on or none of them.

hp

 

[Lars Eighner]

I don't ever recall seeing anything like that in Apache.

It's amazing how it's always assumed that there isn't a valid reason for
a question like this. The OP may have a perfectly good reason for doing
what he's doing

Well, as a matter of fact I do. I am putting together tools to use
to build static pages which are then uploaded to a server which is actually
open to the public, unlike my local one. I've got one user. Me.

(like, say, debugging in some way), even if we don't
know what it is. Granted, there's nothing wrong with reiterating a
danger where danger potentially exists, but at the same time, it seems
some people act too much like a "parental controls" mechanism, which
only serves to take the focus from the original question itself.

Give warning, by all means, but please try to address the question
itself.

AFAIK, if you are using setuid perl (where tainting is on by default,
iirc), then a common method is using a c wrapper that's suid'ed to the
desired user and executes the script, returning the output.

Well, apparently it is an apache problem -- or at least I have an
apache problem. I cannot get suexec to work on 2.0.x; and nothing
containing backticks, system, etc. works. Similar things also do not
work in sh scripts (although of course everything runs fine from the
commandline). Perl (when taint is given sneering lip service) and sh
scripts work fine with apache 1.3.xx, but I don't have a php5 module that
works with that. Likewise with versions of apache above 2.0.xx -- no
php handler.

Yes. I have compiled and installed five versions of apache in the last 24
hours, and still cannot get a combination that will do both php5 and
cgi, although each of them will do one or the other.


Look folks, I'd like to sell you my new super secure Server-Scripting
combination. It's called Rock v. 1.0. It is unhackable. It won't
execute malicious code, because it won't execute any code at all.
You can put it on your desk or collocate it -- like on the ground with other
rocks. And you don't have to worry about your data, because it doesn't have
any of your data. It's a Rock. And that seems to be what developers are
trying to create.

Hell, if I ran Windoz, it would be just as useless but at least I could
watch the ripped-off videos on you tube.

 

[anno4000]

Well, apparently it is an apache problem -- or at least I have an
apache problem. I cannot get suexec to work on 2.0.x; and nothing
containing backticks, system, etc. works. Similar things also do not
work in sh scripts (although of course everything runs fine from the
commandline). Perl (when taint is given sneering lip service) and sh
scripts work fine with apache 1.3.xx, but I don't have a php5 module that
works with that. Likewise with versions of apache above 2.0.xx -- no
php handler.

Off topic, and at the risk of belaboring the obvious, have you checked
$PATH in the different runs of apache?

Anno

 

[Clenna Lumina]

Off topic, and at the risk of belaboring the obvious, have you checked
$PATH in the different runs of apache?

Global symbol "$PATH" requires explicit package name at line 1.

Maybe he should check $ENV{PATH} instead

This will give you a nice list:

print join("\n", split /:/, $ENV{PATH}), "\n";