Re: Plan C (was Re: Plan B for fixing 5.8.2 binary API)
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.
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
> >>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?)
Would if be faster if I looked at the mod perl source code? Where should
I start?
> 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)
> >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 :-)]
Nicholas Clark
Reply to: