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

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

Thread Previous
From:
Rick Delaney
Date:
October 24, 2003 20:42
Subject:
Re: [perl #24248] taint propagation regression, tests fail to spot this
Message ID:
20031024234122.D2233@biff.bort.ca
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About