shotgunefx has asked for the wisdom of the Perl Monks concerning the following question:

I've run into something odd with taint. I've reduced it to a minimal case. If I have an assignment that is a hash or an array reference and it contains more than one set of backticks, $$ suddently becomes tainted within the assignment. Take the code below...


Update: Code moved below

If you comment either backtick out, it passes taint. If you have two variables getting assigned two backticks containing $$, it also works. Why is $$ only tainted when inside hashref and arrayref declarations and after it is used once?

Any ideas?
Update The problem seems to be with any variables whether they were used in a backtick previously or not. 
<code>
#!/usr/bin/perl -T
use strict;
use warnings;
# Original code
$ENV{PATH} = '/usr/bin:/usr/local/bin:/bin';
$ENV{ENV} = '';

my $temp_fails = [ 
                   `mktemp /tmp/temp.$$.XXXXXX`,  
                   `mktemp /tmp/temp2.$$.XXXXXX`,
                  ];

#!/usr/bin/perl -T
use strict;
use warnings;

# This fails as well..
$ENV{PATH} = '/usr/bin:/usr/local/bin:/bin';
$ENV{ENV} = '';

my $untainted = 'foo';
my $also_untainted = 'foobar';
my $temp_fails = [ 
                   `mktemp /tmp/temp.$untainted.XXXXXX`,  
                   `mktemp /tmp/temp.$also_untainted.XXXXXX`,
                 ];

#This is perl, v5.6.1 built for sparc64-linux

# The following works ok
sub do_nothing { @_ };
$ENV{PATH} = '/usr/bin:/usr/local/bin:/bin';
$ENV{ENV} = '';
my $temp_fails = [ 
                   do_nothing(`mktemp /tmp/temp.$untainted.XXXXXX`),  
                   do_nothing(`mktemp /tmp/temp.$also_untainted.XXXXXX
+`),
                 ];

[download]


-Lee

"To be civilized is to deny one's nature."

Replies are listed 'Best First'.
Re: Taint bug with backticks in variable assignments
by duff (Parson) on Nov 19, 2003 at 15:32 UTC

    It has nothing to do with the variables. It's that you're forking twice in the same statement (at least that's my guess). Try these:

    #!/usr/bin/perl -T

use strict;
use warnings;

$ENV{PATH} = '/usr/bin:/usr/local/bin:/bin';
$ENV{ENV} = '';

my ($a,$b) = (`mktemp /tmp/temp.XXXXXX`, `mktemp /tmp/temp.XXXXXX`);
my $temp_fails = [ $a, $b ];
__END__
Insecure dependency in `` while running with -T switch at ./foo line 9
+.

    [download]
    #!/usr/bin/perl -T

use strict;
use warnings;

$ENV{PATH} = '/usr/bin:/usr/local/bin:/bin';
$ENV{ENV} = '';

my $a = `mktemp /tmp/temp.XXXXXX`;
my $b = `mktemp /tmp/temp.XXXXXX`;
my $temp_fails = [ $a, $b ];
__END__

    [download]

    The latter works just fine

    duff
[reply]
[d/l]
[select]
      Not the forking: 
          $ perl -Tlwe '$ENV {PATH} = "/usr/bin:/usr/local/bin:/bin"; 
      fork && fork && `mktemp "/tmp/temp.XXXXXX"` && print "Success"'
    Success

      [download]

      Abigail

[reply]
[d/l]
      Thanks
      I just hit that myself. I started down the variable path thinking it was $$, then trying any variables, then none.
      I still would consider this a bug though..

      -Lee

      "To be civilized is to deny one's nature."
[reply]
        perldoc perlsec
        It would be inefficient for every operator to test every argument for taintedness. Instead, the slightly more efficient and conservative approach is used that if any tainted value has been accessed within the same expression, the whole expression is considered tainted. 
        #!/usr/bin/perl -T
$ENV{PATH} = '/usr/bin:/usr/local/bin:/bin';
$ENV{ENV} = '';
my $good = 'good';
my $bad = `echo bad`;
print($bad); print(`echo $good`); #separate expressions
print($bad), print(`echo $good`); #single list expression

        [download]
[reply]
[d/l]
Re: Taint bug with backticks in variable assignments
by PodMaster (Abbot) on Nov 19, 2003 at 15:08 UTC
    I can kind of explain it, perlvar says
    The process number of the Perl running this script. You should consider this variable read-only, although it will be altered across fork() calls. (Mnemonic: same as shells.)
    When you do, ``, you're doing a fork. If you do it twice in one statement (as in perl -Tle"`dir $$`, `dir $$`"), $$ will be tainted after the first fork.

    update: well, if any variable triggers this then it may very well be a bug. perl -Tle"$a=1;`dir $a`, `dir $a`" Though there is always do ;) perl -Tle"$a=1;`dir $a`, do{`dir $a`}"

    update: yeah, i was reachin' with the fork theory :)(and, btw, i couldn't find a perlbug report on this)

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
[d/l]
[select]
      No, it's not just the fork (which would be weird anyway, as a fork won't change $$ in the parent anyway): 
      #!/usr/bin/perl -T
use strict;
use warnings;

$ENV{PATH} = '/usr/bin:/usr/local/bin:/bin';
$ENV{ENV} = '';

fork || exit;

my $temp_fails = [
                   # `mktemp /tmp/temp.$$.XXXXXX`,
                   `mktemp /tmp/temp2.$$.XXXXXX`,
                  ];

print "Success\n";
 
__END__
Success

      [download]

      Abigail

[reply]
[d/l]
      That would explain $$, but it seems to happen with all variables.. 
      #!/usr/bin/perl -T
use strict;
use warnings;

$ENV{PATH} = '/usr/bin:/usr/local/bin:/bin';
$ENV{ENV} = '';

my $untainted = 'foo';
my $temp_fails = [ 
                   `mktemp /tmp/temp.$untainted.XXXXXX`,  
                   `mktemp /tmp/temp.$untainted.XXXXXX`,
                 ];

      [download]


      -Lee

      "To be civilized is to deny one's nature."
[reply]
[d/l]

Back to Seekers of Perl Wisdom