DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=40598>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40598 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO ------- Additional Comments From [EMAIL PROTECTED] 2006-09-25 10:40 ------- (In reply to comment #0) > Please note that I've only tested this on the 1.3 series, but this issue > might also apply to 2.0 and 2.2 series of apache. > > In Apache 1.3.28 (a "maintenance release"), the directive > "RewriteOptions" with "MaxRedirects" was introduced to limit local DoS > by looping Rewriterules (multiple rewriterules running in a loop). > However, I've just found that in 1.3.37, this directive won't work on > self-looping RewriteRules: > > Sample from a customer's site: > > RewriteEngine on > RewriteBase /index.php > RewriteRule ^(openholidayguide)(.*)\,(.*)\_\_(.*)\.html$ $1&$3=$4$2.html > [NC,N] > > That ",N" is the thing to take care of. This works as designed as the Option "N" does not cause internal redirects. So MaxRedirects never gets into the game. The documentation for Option "N" states: "Be careful not to create an infinite loop!" Nevertheless I understand that you do not have control over what customers put in their .htaccess file. And that is the core of the problem. Even if MaxRedirects would limit this kind of loop it would not help you as RewriteOptions and thus MaxRedirects can be changed inside of .htaccess. So this would only prevent accidental bad rewriterules not intentional local DoSes. So what you would need would be something like the option MaxLoop which of course would be changeable via .htaccess again. But that would be a new feature. And new features are very very unlikely to be introduced into 1.3. So it makes more sense to propose this as an enhancement for the actual trunk of httpd and hope that it gets backported to 2.0.x. > memory leak, that's why I've tagged this critical. I've first sent this issue > to > [EMAIL PROTECTED] on 9/20/2006 (as it includes a local DoS), but this issue > has been unreplied so far. Given the fact that you sent it 5 days ago, I guess you got no reply as this is not seen as a security issue by the security team, but as a configuration problem. All non security related issues get ignored by [EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
