Re: Plan C (was Re: Plan B for fixing 5.8.2 binary API)
Nicholas Clark wrote:
On Sat, Oct 18, 2003 at 12:41:26PM -0700, Stas Bekman wrote:
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?
Yes. A flag is added to the HV saying that an alternative hashing
algorithm is in use, and all supplied keys (internally) have a hash
value computed using this.
meaning that the passed hash value will be always ignored, once the
alternative hashing alg kicks in, until a new HV is created.
The flag is cleared when the HV is cleared
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.
Oops. Yes I meant to. "\0" x 1 to "\0" x 16 is good enough to trigger it.
Hopefully I will have time tomorrow night
Sure, take your time. No hurry on our side ;)
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::handler
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.
MyApache::Project::Subproject1::SubCat2::handler).
What call into the Perl API do you use to do this lookup?
(or are you now doing a lookup into a mod perl structure?)
PERL_HASH()
Would if be faster if I looked at the mod perl source code? Where should
I start?
Sure, you can look at it. The light-weighted GV are implemented in
src/modules/perl/modperl_mgv.c. You can get the latest mod_perl 2 source from
here:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
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.
Given that the default hashing under plan C is the same as 5.8.0
(ie not random) "attacks" are any data that is a pathological case for
5.8.0, and are going to be "attacks" independent of the hash key.
The hash key is now only used for the internal rehashing - effectively
the response to an attack is to enable random hashing for that hash only.
So only the order of the hash attacked would differ based on key, but
with the key fixed for a test it ought to e the same (else there is a bug)
That also means that we are back to a deterministic order of 'keys/each
%hash', right?
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)
It's purely selfish. I'm just trying to save massive embarrassment to
myself if I commit the blooper of an official release that broke mod_perl
[Although I have this feeling that you'd benefit as much, if not more,
from me avoiding this mistake :-)]
I think the best approach would be to get RC1 out of the door asap, but wait
quite a bit with 5.8.2. That way distros will most likely pick 5.8.2-RC1, but
we need more time for this change to be tested. A massive request for testing
may help. Unfortunately most people ignore those requests and start reporting
bugs as soon as a new version is released.
__________________________________________________________________
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
Reply to: