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 Summary: RewriteOptions MaxRedirects doesn't work for self- looping RewriteRules Product: Apache httpd-1.3 Version: HEAD Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: mod_rewrite AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] 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. Requesting GET /openholidayguide,typ__anf,pid__5924_1050,anz__mb,lid__120,kontinent__Afrika,lan d__Libyen+/+Libysch-Arabische+Dschamahirija,ch__ub.html HTTP/1.0 to that site lets Apache consume cpu and memory in an endless loop, despite the "MaxRedirects" option. After about 10 Minutes of running time, the Apache process already consumed 420 MB of RAM, so this needs quite fast manual response (by killing the process) in order not to take down the server. Using "memfetch", I've grepped a string from a memory dump on such an apache instance: /kunden/homepages/40/d108547339/htdocs/hotelbewertungen/openholidayguide&ch=ub&c h=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch= ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub &ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&ch=ub&c h=ub&ch=ub&ch=ub,typ__anf,pid__5924_1050,anz__mb,lid__120,kontinent__Afrika,land __Libyen+/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija .html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.htm l/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+L ibysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libys ch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-A rabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabi sche+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische +Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dsc hamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschama hirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahiri ja.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.h tml/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/ +Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch -Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Ara bische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabisc he+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+D schamahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dscha mahirija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahi rija.html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija .html/+Libysch-Arabische+Dschamahirija.html/+Libysch-Arabische+Dschamahirija.htm l The amount of "Libysch-Arabische+Daschamahirija.html" within that sample context is certainly much larger than 10, so if I wouldn't kill that instance, Apache would consume memory until the oomkiller strikes. Tracing such an apache in GDB or strace doesn't give that much valuable information: gdb shows that apache spends most of its time in engine.c within the regex parser, strace only shows "brk()"-statements. Tracing such an apache in GDB or strace doesn't give that much valuable information: gdb shows that apache spends most of its time in engine.c within the regex parser, strace only shows "brk()"-statements. I personally see this as a local DoS issue: any .htaccess-capable site owner can take down a server quite easily with such an Rewriterule. With shared hosting, this can have a very severe impact. As the logs only are being written after a request has been fulfilled, strace doesn't give any hints and gdb merely shows that it's "some regex, maybe a Rewriterule", tracking down this issue is quite hard for a "normal" admin. No workarounds exist and it does break a running apache instance, may affect other processes (due to the enormous memory consumption) and imposes a major 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. Regards, Anders -- 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]
