Front page | perl.perl5.porters |
Postings from March 2008
-----BEGIN PGP SIGNED MESSAGE-----
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
bolted.
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/strict.pm
export PERL5LIB=/home/h4x0r/lib
/usr/sbin/your_setuid_script.pl
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.
Cheerio,
Paul
[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
http://perltraining.com.au/notes.html . 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 <pjf@perltraining.com.au> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
iD8DBQFH2VcRx5N6j7FHnlURAoTYAJ4oLSKnf0k8ropEV7POutqa5MmaEACfXnL1
n55JJ10KGxTVLK5jvqzh3II=
=EcWW
-----END PGP SIGNATURE-----
Thread Previous
|
Thread Next