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.caThread Previous