Nicholas Clark wrote:
>
> On Sat, Aug 30, 2003 at 10:13:02PM -0400, Benjamin Goldberg wrote:
> > Nicholas Clark wrote:
>
> > > The attacker can craft a bogus CGITempFile object that refers to any
> > > file on the system, and when this object is destroyed it will attempt to
> > > delete that file at whatever privilege level the CGI runs at. And
> > > because that object is getting destroyed inside the deserialise routine
> > > of Storable, this all happens without the user written code getting any
> > > chance to inspect the data. And even Storable can't do anything about
> > > it, because by the time it encounters the repeated hash key, it has
> > > already deserialised this time-bomb. How does it defuse it?
> >
> > The simplest solution *I* can think of, is to have storable copy the
> > taint
> > flag from the input string/stream onto every single string that it
> > produces.
> >
> > Taint checking doesn't solve *all* security problems, of course, but it
> > can catch many of them, and it certainly would catch this one (if $$self
> > were tainted).
>
> I don't believe that it would. A quick test suggests that in perl5
> destructors get to run after a taint violation is detected:
>
> $ perl -Tle 'sub DESTROY {print "We still get to run arbitrary code after taint
> violations"}; bless ($a = []); `cat /etc/motd`'
> Insecure $ENV{PATH} while running with -T switch at -e line 1.
> We still get to run arbitrary code after taint violations
> $
That wasn't what I meant.
The taint violation in your example does *not* correspond to Storable
turning on the taint flag in the strings it produces. At best, it
corresponds to Storable dieing due to a malformed input file, resulting
in destructors being called.
If sub DESTROY tries to unlink a file, and that filename is a tainted
string, then the DESTROY will die.
Currently, Storable *doesn't* turn on the taint flag in the SVPVs that it
produces; because of this, $$self in CGITempFile::DESTORY isn't tainted.
If $$self in CGITempFile::DESTROY *were* tainted, then obviously that
DESTROY would die, and the file wouldn't get unlinked. Thus, we would
avoid that security hole.
> > One defense against following a bomb with malformed data, might be to
> > have Storable save up the SV*s and the names with which to bless them,
> > and only do the blessing *after* the data is fully deserialized, as a
> > last step before returning it to the user. This way, if there's
> > malformed data, no destructors get called. The user still needs to
> > validate the returned data, though, and rebless anything which might
> > result in an evil destructor being called.
> >
> > Another defense is to run deserialization and validation inside of a
> > Safe object. Make sure that if the object fails to validate, it is
> > completely destructed before we exit the Safe compartment.
>
> I think that these could work well.
>
> > For backwards compatibility with perl5, parrot will quite likely support
> > taint checking, safe.pm, and ops.pm.
>
> I don't see why support is needed at core parrot level. I believe that
> the plan is to provide XS-level Perl 5 compatibility via ponie, in which
> case much of this stuff would be up to ponie, not core parrot.
>
> Tainting sounds to me like the sort of things that would be a property on
> a scalar, checked by custom ponie ops, which would be as parrot core as
> python's ops. A brief inspection suggests that ops.pm is entirely a parser
> level thing, so I don't see the need for core parrot support there.
>
> Safe.pm as implemented is an unreliable mess. It's also problematic as
> it describes actions solely in terms of perl 5 ops. I've no idea quite
> how close Arthur, Rafael and the other ponie conspirators think that
> ponie-generated parrot bytecode will be to the perl 5 optree structure,
> but I wouldn't like to place any bets right now. I think that safe
> execution compartments are part of Dan's plan, but I'm not sure if
> anyone yet knows how any of this fits together (even Dan or Arthur)
>
> Nicholas Clark
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
