[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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?)


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: