Front page | perl.perl5.porters |
Postings from November 2003
Rick Delaney <rick@bort.ca> 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.
Hugo
Thread Previous
|
Thread Next