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
$
> 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
