develooper Front page | perl.perl5.porters | Postings from March 2008

Re: Taint (PL_tainting, SvTAINTED_on, SvTAINTED_off, SvTAINT)

Thread Previous | Thread Next
Paul Fenwick
March 13, 2008 09:32
Re: Taint (PL_tainting, SvTAINTED_on, SvTAINTED_off, SvTAINT)
Message ID:
Hash: SHA1

G'day p5p,

I have strong opinions with regards to taint mode; this is your opportunity
to correct them if they're wrong. ;)

Bram wrote (assuming examples running as root):

| #!/usr/bin/perl -l
| print ${^TAINT};
| my $foo = <STDIN>;
| $<=1001;
| print ${^TAINT};
| system "echo $foo"

Jumping exploits Batman!  Taint mode magically turns itself on after you've
fiddled your RUID?  That's closing the gate after the exploited horse has

The whole reason (IMNSHO) why taint needs -T on the shebang line is because
perl *needs* to avoid all the nasty things we could be doing in an untrusted
environment.  For example:

	echo "exec q{/bin/sh};" > /home/h4x0r/lib/
	export PERL5LIB=/home/h4x0r/lib

Having taint enable itself part way through a process means that users may
think that's a _feature_, and be given a false sense of security.  Many of
the common attack vectors (shell environment variables, @INC manipulation,
injection attacks to @ARGV that get run by <>, etc[1]) may have already had
a chance to operate, or are at least sitting in untainted variables waiting
to pounce.

At least with Taint::Runtime you *know* that you're doing something special,
and you have to go to the trouble of pulling down a module from CPAN.
Having taint with a standard perl "wake from slumber" having not done any
taint checking beforehand is a truly awful idea.

| a) Is there a reason why SvTAINTED_on, SvTAINTED_off and SvTAINT check
| if taint mode is enabled and

I assume it's for speed considerations.  If taint mode is off (on the
assumption that it will never turn on), I imagine we save a great many
cycles by skipping the unnecessary work.

At least as of a few years ago, tainted values wouldn't pass cleanly down
through XS generated by swig and potentially other tools[2], so I imagine
that enabling tainted values even when we're not running in taint mode has
the possibility to break things.  Not least a bunch of modules I use
internally and which throw exceptions when handed tainted data (which we
only want to do in taint mode).

| b) wouldn't it make more sense to always set the taint flag and only
| check if taint mode is enabled when 'executing' the commands since it
| can be enabled or disabled while running the code (chaning $<, using
| Taint::Runtime, ...)?

My opinion is that taint should *never* change its state after perl has
started; indeed I'm quite shocked to learn that it can.  IMNSHO this is not
an accident feature, it's a bug.  I'm happy for Taint::Runtime to be an
exception, for reasons given earlier.



[1] For a great many ways to exploit a privileged Perl program when it's not
running with taint mode see the "Perl Security" manual from .  It's a few years old now, so
feedback and corrections welcome.

[2] I liked this behaviour, since it meant that I had to clean values before
passing them down into C.

- --
Paul Fenwick <> |
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681
Version: GnuPG v1.4.5 (MingW32)


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About