develooper Front page | perl.perl5.porters | Postings from November 2003

Re: [PATCH blead] Re: [perl #24248] taint propagation regression, tests fail to spot this

Thread Previous | Thread Next
Rick Delaney
November 7, 2003 10:28
Re: [PATCH blead] Re: [perl #24248] taint propagation regression, tests fail to spot this
Message ID:
On Fri, Nov 07, 2003 at 04:30:33PM +0000, wrote:
> Rick Delaney <> wrote:
> :While waiting for opinions on my questions I've formed my own opinions.
> [...]
> :Note 2: If we were to add these tests:
> :
> :  test 221, !eval { "x".$TAINT, $notaint =~ /(1)/, kill 0; 1 };
> :  test 222, !eval { "x".$TAINT, $notaint =~ /($notaint)/, kill 0; 1 };
> :  test 223, !eval { "x".$TAINT, $notaint =~ s/(1)/1/, kill 0; 1 };
> :  test 224, !eval { "x".$TAINT, $notaint =~ s/($notaint)/1/, kill 0; 1 };
> :
> :they would all fail after my patch while only 221 and 223 fail before my
> :patch.  This does not mean the patch is wrong; the only reason 222 and
> :224 pass pre-patch is because the regexp is wrongly tainted.  My
> :interpretation of perlsec is NOT that these tests SHOULD all pass (i.e.
> :the kill should bail with an "Insecure dependency") but rather that
> :there is no guarantee that the kill will succeed if it is in a larger
> :expression that contains tainted data, even when the args to kill are
> :untainted.  So the above tests should not be included and the patch
> :below is sufficient, IMO.
> I didn't fully understand that, and it made me worry that something
> like this:
>   $should_taint = ("x".$TAINT, $notaint =~ /($notaint)/)[0];
> would result in an untainted $should_taint, but trying it I find
> that it doesn't.
> Are we talking only about whether complexity of expressions _preceding_
> that pattern match will cause taintedness to propagate into otherwise
> untainted values _following_ the pattern match? If so, I think that is


> fine: tainting safe values in complex expressions is something I believe
> we do only for simplicity of implementation, not because it makes
> anything more secure, and I don't think it should be a problem if we
> reduce the number of situations in which safe values get marked tainted.

That was the conclusion I came to as well.  I brought it up in case
others didn't share my opinion and felt that perlsec guaranteed that
"tainted data anywhere within an expression renders the entire expression 
tainted".  Thanks for sharing your opinion.

Rick Delaney

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