Re: Plan C (was Re: Plan B for fixing 5.8.2 binary API)
Nicholas Clark wrote:
On Sat, Oct 18, 2003 at 11:09:24AM -0700, Stas Bekman wrote:
Nicholas Clark wrote:
Something like this? Only with the rough edges smoothed out?
Currently only in blead.
Now merged into maint. If it doesn't work it comes out :-)
[But it does cope with the attack on http://www.cs.rice.edu/~scrosby/hash/
as well as 5.8.1]
Nick, what's your definition of "doesn't work"? This change will affect
run-time only in certain circumstances, which I'd guess no application has
tests for. Won't any application that caches the PERL_HASH value now break
if the rehashing alg tells perl to rehash the key, so the hash entry lookup
will fail? e.g. mod_perl 2.0 caches PERL_HASH value for all perl callback
I believe not, if it comes in through the API in hv.c, because all the
hash lookup and store functions check the flag on that hash - if it's using
custom keys they discard any passed in hash values. This discard may seem
like a slowdown at first sight, but given that it's for the case where
the hash has degraded into a linear search of a linked list, it ought to
be faster. (Certainly it is faster on the attack data from the paper's
website, but so is 5.8.1)
Good. So the first time we pass the precomputed hash value it will discard it.
What happens when the that (now invalid) hash value is passed second time?
Will it still know to discard it?
Are you going to add a test that triggers the run of this new code. If so I'd
like to adopt that test in the mod_perl test suite to verify that everything
is working properly. Chances are close to zero that we will ever have this
problem in mod_perl 2.0, since we only cache the hash values for GV of the
used handlers. Though it's quite possible that someone will write unsafe code
which may generate lots of GVs, making it suspectible to this attack.
GVs it's configured to run, if perl rehashes those values, mod_perl will
break as it no longer will be able to find those GVs.
How does mod perl find those GVs? Via hv.c calls, or by directly scanning
the HV structure?
Every time you configure a handler, e.g.:
it'll fetch My::, My::Project:: and My::Project::handler GVs and cache their
hash values in what Doug called modperl_mgv_t -- a light weight GV, which
stores only a few bits of information (the name, its length and the hash
value). Now during the run time we don't want to do an expensive bare lookup
of My::Project::handler, we already have all the data precalculated, so the
lookup happens much faster. This becomes especially significant if someone has
deeply nested namespaces with long names (e.g.
Also, how does it affect the runtime which relies on the PERL_HASH_SEED env
var to reproduce the exact previous execution? If the rehashing kicks in,
will it always rehash to the same values?
It's using the hash seed to do the rehashing (with the rehashing using
the exact same algorithm as 5.8.1 is using all the time)
Given that both the 5.8.0 and 5.8.1 algorithms are deterministic, I think
that it should be utterly repeatable if the seed is fixed (or as repeatable
as 5.8.0 and 5.8.1 currently are) but I'm only arm waving.
If we had a test that orranges for this attack and cache its HASH_SEED, we
could run a second test that makes sure that the sequence is reproducable with
Also I suppose we need to replace all occurences of PL_hash_seed(_set)?
with the 'PL_new_' prefix in mod_perl 2.0. I guess I'll wait till the dust
settles down. In any case I can't commit the fix since we still have perl's
OK. Yes. If we're going for release than this will get bumped soon.
(and modperl not working is a showstopper, so it's not going to get
released until you're happy)
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:email@example.com http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com