Taint mode and PERL5LIB

K

kj

When running under taint mode (-T switch), $ENV{PERL5LIB} is ignored.
This presents a problem to CGI scripts that want to run in taint
mode but need libraries installed in directories not mentioned in
the default value of @INC [1].

Then again, is running under taint mode really necessary past the
development and testing phase? In other words, is taint mode
anything more than an additional check that the developer can make
prior to releasing the code to make sure that there are no security
gaps in the code, but once the code passes, taint mode can be safely
turned off?

Thanks!

kj

[1] I realize that I could add appropriate "use lib /path/to/my/libs"
lines to the CGI scripts, but at installation time this is a royal
pain, especially if many CGI scripts are involved, since every user
installing this software would have to mung these lines in all its
CGI scripts. At the very least, make would have to do the munging,
which gives me the creeps; I'd prefer to find some other solution.
 
B

Ben Morrow

Quoth kj said:
When running under taint mode (-T switch), $ENV{PERL5LIB} is ignored.
This presents a problem to CGI scripts that want to run in taint
mode but need libraries installed in directories not mentioned in
the default value of @INC [1].

Then again, is running under taint mode really necessary past the
development and testing phase? In other words, is taint mode
anything more than an additional check that the developer can make
prior to releasing the code to make sure that there are no security
gaps in the code, but once the code passes, taint mode can be safely
turned off?
No.

[1] I realize that I could add appropriate "use lib /path/to/my/libs"
lines to the CGI scripts, but at installation time this is a royal
pain, especially if many CGI scripts are involved, since every user
installing this software would have to mung these lines in all its
CGI scripts. At the very least, make would have to do the munging,
which gives me the creeps; I'd prefer to find some other solution.

I am presuming you are looking for a solution you can write into new
scripts, rather than one which will work with existing ones?

At the start of each script, examine $ENV{PERL5LIB}, untaint it, check
that its value looks like a reasonable Perl library dir, etc., split it
on colons and 'use lib'. You can (obviously) put all this in a module,
so you can just say something like

use MyApp::perl5Lib;

at the top of each individual script.

Ben
 
G

Gunnar Strand

Ben said:
Quoth kj said:
When running under taint mode (-T switch), $ENV{PERL5LIB} is ignored.
This presents a problem to CGI scripts that want to run in taint
mode but need libraries installed in directories not mentioned in
the default value of @INC [1].

Then again, is running under taint mode really necessary past the
development and testing phase? In other words, is taint mode
anything more than an additional check that the developer can make
prior to releasing the code to make sure that there are no security
gaps in the code, but once the code passes, taint mode can be safely
turned off?


No.

That is interesting. According to the Perl taint faq i found
(http://gunther.web66.com/FAQS/taintmode.html):

Run-time checking means that you need to test all logical paths of
execution your script might take so that "legal operations" do not
get halted because of taint mode.

I get the impression that if the testing is thorough enough, taint
mode could be turned off for release code. I do *not* argue that
it *should* be turned off, I am just curious to know if there are
situations after testing which could cause taint to fail, for
instance that it would object to the contents of input, despite
untainting?

Kind regards,

/Gunnar
 
B

Ben Morrow

Quoth Gunnar Strand said:
Ben said:
Quoth kj said:
When running under taint mode (-T switch), $ENV{PERL5LIB} is ignored.
This presents a problem to CGI scripts that want to run in taint
mode but need libraries installed in directories not mentioned in
the default value of @INC [1].

Then again, is running under taint mode really necessary past the
development and testing phase? In other words, is taint mode
anything more than an additional check that the developer can make
prior to releasing the code to make sure that there are no security
gaps in the code, but once the code passes, taint mode can be safely
turned off?


No.

That is interesting. According to the Perl taint faq i found
(http://gunther.web66.com/FAQS/taintmode.html):

Run-time checking means that you need to test all logical paths of
execution your script might take so that "legal operations" do not
get halted because of taint mode.

I get the impression that if the testing is thorough enough, taint
mode could be turned off for release code.

In theory, if you were sufficiently confident that you had tested every
code path, you could turn it off with no loss of safety: as you say, if
tainting is never going to fail, there is no need for it.

However, defensive programming practices would recommend assumming that
there *might* be cases you've overlooked (even with coverage testing
tools such as Devel::Cover, you can't necesarily be sure you've tested
all possible sources of tainted data), and leaving tainting on as a
production app that halts with a taint failure, although not acceptable,
is better than one which has a security hole.
I do *not* argue that it *should* be turned off, I am just curious to
know if there are situations after testing which could cause taint to
fail, for instance that it would object to the contents of input,
despite untainting?

No, the only case is where some tainted data arrives from somewhere you
weren't expecting and thus isn't untainted (or checked).

Ben
 
K

kj

Quoth kj said:
When running under taint mode (-T switch), $ENV{PERL5LIB} is ignored.
This presents a problem to CGI scripts that want to run in taint
mode but need libraries installed in directories not mentioned in
the default value of @INC [1].

Then again, is running under taint mode really necessary past the
development and testing phase? In other words, is taint mode
anything more than an additional check that the developer can make
prior to releasing the code to make sure that there are no security
gaps in the code, but once the code passes, taint mode can be safely
turned off?
[1] I realize that I could add appropriate "use lib /path/to/my/libs"
lines to the CGI scripts, but at installation time this is a royal
pain, especially if many CGI scripts are involved, since every user
installing this software would have to mung these lines in all its
CGI scripts. At the very least, make would have to do the munging,
which gives me the creeps; I'd prefer to find some other solution.
I am presuming you are looking for a solution you can write into new
scripts, rather than one which will work with existing ones?
At the start of each script, examine $ENV{PERL5LIB}, untaint it, check
that its value looks like a reasonable Perl library dir, etc., split it
on colons and 'use lib'.

If that's all there is to it, then I don't see why Perl should
disregard PERL5LIB when running under taint mode, instead of just
doing what you say above, and using PERL5LIB as usual if it checks
out.
You can (obviously) put all this in a module,
so you can just say something like
use MyApp::perl5Lib;
at the top of each individual script.

Wouldn't this strategy fail precisely due to the problem it is
trying to solve (how would Perl be able to load MyApp/Perl5Lib.pm
unless it was already in a directory mentioned in the default @INC)?

kj
 
A

Anno Siegel

Gunnar Strand said:
Ben said:
Quoth kj said:
When running under taint mode (-T switch), $ENV{PERL5LIB} is ignored.
This presents a problem to CGI scripts that want to run in taint
mode but need libraries installed in directories not mentioned in
the default value of @INC [1].

Then again, is running under taint mode really necessary past the
development and testing phase? In other words, is taint mode
anything more than an additional check that the developer can make
prior to releasing the code to make sure that there are no security
gaps in the code, but once the code passes, taint mode can be safely
turned off?


No.

That is interesting. According to the Perl taint faq i found
(http://gunther.web66.com/FAQS/taintmode.html):

Run-time checking means that you need to test all logical paths of
execution your script might take so that "legal operations" do not
get halted because of taint mode.

I get the impression that if the testing is thorough enough, taint
mode could be turned off for release code. I do *not* argue that
it *should* be turned off, I am just curious to know if there are
situations after testing which could cause taint to fail, for
instance that it would object to the contents of input, despite
untainting?

Well, for one, there is more than tainted data that may make a taint
test fail. If $ENV{ PATH} points to something that is writable by
anyone but its owner, you can launder the string all day but "system"
and friends will fail in taint mode. That is one test that can only
be done at run time, there are certainly more.

But even if without run time tests, for a complete cover of all cases
you'd have to determine the set of all variables in your program
whose taintedness may matter (including parts of %ENV) and check the
behavior for every combination of tainted/untainted there is.
A look at the long section (in perlsec) that lists which Perl functions
may be taint-sensitive and in which way is discouraging.

So, taint mode must stay on in production, for fundamental and
practical reasons.

Anno
 
J

J Krugman

In said:
Gunnar Strand said:
Ben said:
Quoth kj <[email protected]>:

When running under taint mode (-T switch), $ENV{PERL5LIB} is ignored.
This presents a problem to CGI scripts that want to run in taint
mode but need libraries installed in directories not mentioned in
the default value of @INC [1].

Then again, is running under taint mode really necessary past the
development and testing phase? In other words, is taint mode
anything more than an additional check that the developer can make
prior to releasing the code to make sure that there are no security
gaps in the code, but once the code passes, taint mode can be safely
turned off?


No.

That is interesting. According to the Perl taint faq i found
(http://gunther.web66.com/FAQS/taintmode.html):

Run-time checking means that you need to test all logical paths of
execution your script might take so that "legal operations" do not
get halted because of taint mode.

I get the impression that if the testing is thorough enough, taint
mode could be turned off for release code. I do *not* argue that
it *should* be turned off, I am just curious to know if there are
situations after testing which could cause taint to fail, for
instance that it would object to the contents of input, despite
untainting?
Well, for one, there is more than tainted data that may make a taint
test fail. If $ENV{ PATH} points to something that is writable by
anyone but its owner, you can launder the string all day but "system"
and friends will fail in taint mode. That is one test that can only
be done at run time, there are certainly more.
But even if without run time tests, for a complete cover of all cases
you'd have to determine the set of all variables in your program
whose taintedness may matter (including parts of %ENV) and check the
behavior for every combination of tainted/untainted there is.
A look at the long section (in perlsec) that lists which Perl functions
may be taint-sensitive and in which way is discouraging.
So, taint mode must stay on in production, for fundamental and
practical reasons.

Still it is not clear to me why Perl doesn't offer a builtin function
or a standard module to untaint PERL5LIB. I found an interesting
and not too ancient thread on this at http://tinyurl.com/yr4vs .
There is a module called perl5lib in CPAN that does the job, but
I think it should be part of the distribution. (BTW, is there a
standard channel for requesting adding a feature to future releases
of Perl?)

jill
 
B

Brian McCauley

kj said:
When running under taint mode (-T switch), $ENV{PERL5LIB} is ignored.
This presents a problem to CGI scripts that want to run in taint
mode but need libraries installed in directories not mentioned in
the default value of @INC [1].

If you can configure your web server to ignore the #! line in the CGI
scripts and envoke them via an explicit perl command line then you can
put -I switches in that command line.

If you can't do that see the module "perl5lib" on CPAN.
Then again, is running under taint mode really necessary past the
development and testing phase?

Yes, it is probably wise.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
 
B

Ben Morrow

Quoth J Krugman said:
Still it is not clear to me why Perl doesn't offer a builtin function
or a standard module to untaint PERL5LIB.

Builtin??? Come off it... that's way too specific :). Look at
Scalar::Util: those are things that *failed* to become builtins.

A standard module is a possibility, but the usage would not be high.
Apart from anything else, the conditions under which a given value of
PERL5LIB is safe vary hugely from situation to situation. OTOH it is a
tiny module, and it might make people's lives easier on webhosts who'll
only install the standard distro.
There is a module called perl5lib in CPAN that does the job, but
I think it should be part of the distribution. (BTW, is there a
standard channel for requesting adding a feature to future releases
of Perl?)

(e-mail address removed)

Ben
 
B

Ben Morrow

Quoth kj said:
If that's all there is to it, then I don't see why Perl should
disregard PERL5LIB when running under taint mode, instead of just
doing what you say above, and using PERL5LIB as usual if it checks
out.

*THINK*. How can Perl possibly know what is safe and what isn't? It
depends entirely on the situation. That's the whole point of taint mode:
perl forces you to check things are safe, because it can't check for
you.

Ben
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,994
Messages
2,570,223
Members
46,810
Latest member
Kassie0918

Latest Threads

Top