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 callbackI 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.: PerlResponseHandler My::Project::handlerit'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. MyApache::Project::Subproject1::SubCat2::handler).
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 that HASH_SEED.
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 SUBVERSION==1 :(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)
Thanks ;0) __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com