httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: segfaults / core dumps caused by ap_internal_fast_redirect
Date Thu, 23 Apr 2009 19:33:43 GMT

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



View raw message