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;}