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