Created attachment 34524 [details]
Patch to limit expansion by looping mod_rewrite rules

The following .htaccess will cause a local DOS:

RewriteEngine On
RewriteRule ^(.*)X(.*)$ $1x$2
RewriteRule X - [N]

This sequence of rules causes any moderately long request with path info containing a capital X (e.g. http://www.example.com/the/X/factor/causes/a/server/crash ) to loop repeatedly, appending path info (and thus a new X) to r->filename each iteration.  Each apr_pstrcat allocates a whole new string for the lifetime of the request.

The resulting memory usage is roughly M*N+O*N*(N-1)/2, where M is the size of the filename and O is the size of the path info.  With the default N=32000, even modest values (M=50, O=24) cause disproportionately enormous memory use (about 12GiB) after 32000 iterations.  Larger requests (M=1024, O=768) can easily consume hundreds of gigabytes, typically resulting in swap exhaustion or OOM aborts.  Both outcomes disrupt normal server operations, particularly with threaded MPM's.

As a result, an attacker who can cause an .htaccess file to be placed on the server (either through local access or e.g. through a scripting vulnerability) can subsequently cause disruption at any time by sending a relatively innocuous-appearing request.  (And due to the resulting crash, that request will not even be logged in most setups.)

This is a known issue; to quote a comment in bug 38642, "this bug is deadly in combination with the N-flag."  It can be prevented by the use of the DPI flag, which appears to be the resolution of 38642.

However, users cannot be relied upon to be aware of and use this flag, especially if disrupting server operations is their goal.  It seems undesirable to allow unprivileged users to crash the server process.

To resolve this issue, we have applied the attached patch.  After each RewriteRule, it checks to see if the result exceeds the value set by LimitRequestLine.  If so, it aborts the request.

LimitRequestLine is arguably not the right value here, although it is a decent heuristic default, as it already effectively limits the maximum length of a URL.  It certainly seems more suitable than the 100+GiB URLs being generated in this fashion before applying this patch.