Front page | perl.perl5.porters |
Postings from October 1999
Re: [BUG] taint seeps
Thread Previous
From:
M.J.T. Guy
Date:
October 26, 1999 18:09
Subject:
Re: [BUG] taint seeps
Message ID:
E11gHah-0003Ip-00@taurus.cus.cam.ac.uk
Hugo <hv@crypt.compulink.co.uk> wrote
> In <E11g6B4-0007lP-00@taurus.cus.cam.ac.uk>, "M.J.T. Guy" writes:
> :I had always understood this as a feature, because Perl only does
> :a very limited data flow analysis. Specifically, once a tainted
> :value has been encountered within an expression, all subsequent values
^^^^^^^^^^
> :generated in the expression are assumed to be tainted.
>
> If that were the case, I would not expect the order of the key/value
> pairs to affect the result.
I obviously should have emphasised as flagged above. If 'untainted'
comes first, it will be untainted; if it comes second, a previous tainted
value has been seen and it's tainted.
But of course, that's just what happens to happen. Perl doesn't
define the order of evaluation in this case, so you're lucky to see
what you do (or unlucky, or both).
> :And this _is_ documented, even if obliquely, in perlsec:
> :
> : Any variable set
> :to a value derived from tainted data will itself be tainted,
> :even if it is logically impossible for the tainted data
> :to alter the variable.
>
> I think most people would perceive the 'variable' being 'set' here
> as $object2->{untainted}, which is not in any way derived from
> tainted data.
That's what the "logically impossible" bit is trying to say. But it
could be better worded. Perhaps
Within an expression which depends on tainted data, any variable
set may itself be tainted, even if ...
> I wish I had time to look into this more deeply though - it sure don't
> seem right to me.
More complex dataflow analysis is clearly possible, but I very much
doubt that better can be done without excessive run-time costs.
Mike Guy
Thread Previous