Front page | perl.perl5.porters |
Postings from October 2003
On Wed, Oct 22, 2003 at 12:49:07AM -0400, Rick Delaney wrote:
> On Sun, Oct 19, 2003 at 02:44:20PM -0000, Nicholas Clark wrote:
> >
> > I consider this to be critical because we have
> >
> > 1: A regression from 5.8.0 to 5.8.1
> > 2: Our regression tests completely fail to spot this
> > 3: Taint propagation seems to be broken in fairly fundamental ways.
>
> Yes, indeed.
[snip]
> It appears that any expression more complicated than a simple scalar
> variable is wrongly propagating its taint into the regexp. I don't know
> if it's intended that a tainted regexp should taint $1 without
> 'use re "taint"' (I think that's reasonable) but that's another issue.
I've poked through the source a bit with a ten-foot pole and started
writing regression tests (TODO) for all the bugs I'm finding there but
there's a class of bugs I'm not sure are bugs at all. perlsec says:
sub is_tainted {
return ! eval { eval("#" . substr(join("", @_), 0, 0)); 1 };
}
This function makes use of the fact that the presence of tainted data
anywhere within an expression renders the entire expression tainted. 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.
What that really means is that if PL_tainted is set by some operation in
an expression then other parts may act as if tainted. What it doesn't
say is that some operators may cavalierly call TAINT_NOT, rendering
the expression untainted in some cases. Or that in some cases
PL_tainted will not be set. So for example:
$0, kill 0; # kill succeeds (PL_tainted never set)
"".$0, kill 0; # dies: Insecure dependency in kill
"".$0, /1/, kill 0; # kill succeeds (pp_match calls TAINT_NOT)
"".$0, $a = 1, kill 0; # kill succeeds (pp_sassign calls TAINT_NOT)
My question is, "Is this behaviour acceptable?" Should operators reset
PL_tainted so that in examples like this the kill always bails? There
is no security risk here that I can see but maybe it's important to
adhere to the semantic of "the presence of tainted data anywhere within
an expression renders the entire expression tainted".
--
Rick Delaney
rick@bort.ca
Thread Previous