> -----Ursprüngliche Nachricht----- > Von: Ruediger Pluem > Gesendet: Donnerstag, 23. April 2009 21:34 > An: [email protected] > Betreff: Re: segfaults / core dumps caused by > ap_internal_fast_redirect > > > > On 04/20/2009 06:41 PM, William A. Rowe, Jr. wrote: > > Ruediger Pluem wrote: > >> 3. Fix the current internal consumers of > ap_internal_fast_redirect (mod_dir / > >> mod_negotiation to use the _ex versions and feed them > with the request pool. > > > > If we don't clear the test-redirect pool between attempts, > where does > > that leave us? It sounds like a memory consumption problem > lurking ahead, > > to be followed by claims of DoS vectors against that new > implementation > > of negotiation or dir. > > Good catch. In the case that there are many subrequests to > determine the correct > target this could consume much memory and thus opens a > possible hole for a DoS > attack provided the attacker can influence the number of > subrequests. IMHO > with mod_dir and mod_negotiation this is only possible by > > - setting up a DirectoryIndex with an insane number of files > (mod_dir). > - storing an insane number of variants for mod_negotiate to > choose from (mod_negotiation) > > So both scenarios require access to the server, either to the > documents or to its > configuration (also via .htaccess). > But maybe I missed something. > > So we are somehow in a loose - loose situation: Either this > or the crashes. > The only other approach I can think of is to do the > subrequests with subpools > as we do right now and redo the subrequest that finally gets > chosen again with r->pool. > But this seems horribly inefficient and seems to pervert the > purpose of "fast" internal > redirect.
Any further opinions on this and ideass how to proceed? Regards Rüdiger
