Am 24.11.2011 23:37, schrieb Rainer Jung:
On 23.11.2011 15:23, Joe Orton wrote:
Prutha Parikh from Qualys reported a variant on the CVE-2011-3368 attack
against certain mod_proxy/mod_rewrite configurations. A new CVE name,
CVE-2011-4317, has been assigned to this variant.
The configurations in question are the same as affected by -3368, e.g.:
RewriteRule ^(.*) http://www.example.com$1 [P]
and the equivalent ProxyPassMatch. Request examples are:
GET @localhost::8880 HTTP/1.0\r\n\r\n
GET qualys:@qqq.qq.qualys.com HTTP/1.0\r\n\r\n
These unfortunately do not get trapped in the request parsing trap added
in r1179239, so result in an input to rewrite rule processing which does
not match the URL-path grammar (i.e. does not start with "/").
We could try improve that fix, but I think it would be simpler to change
the translate_name hooks in mod_proxy and mod_rewrite to enforce the
requirement in the "right" place. Other translate_name hooks do this
already.
I propose the patch below. Any comments?
Index: modules/proxy/mod_proxy.c
===================================================================
--- modules/proxy/mod_proxy.c (revision 1179633)
+++ modules/proxy/mod_proxy.c (working copy)
@@ -566,6 +566,13 @@
return OK;
}
+ /* Check that the URI is valid. */
+ if (!r->uri || r->uri[0] != '/') {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ "Invalid URI in request %s", r->the_request);
+ return HTTP_BAD_REQUEST;
+ }
+
/* XXX: since r->uri has been manipulated already we're not really
* compliant with RFC1945 at this point. But this probably isn't
* an issue because this is a hybrid proxy/origin server.
Index: modules/mappers/mod_rewrite.c
===================================================================
--- modules/mappers/mod_rewrite.c (revision 1179633)
+++ modules/mappers/mod_rewrite.c (working copy)
@@ -4266,6 +4266,13 @@
return DECLINED;
}
+ /* Check that the URI is valid. */
+ if (!r->uri || r->uri[0] != '/') {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ "Invalid URI in request %s", r->the_request);
+ return HTTP_BAD_REQUEST;
+ }
+
/*
* add the SCRIPT_URL variable to the env. this is a bit complicated
* due to the fact that apache uses subrequests and internal redirects
Don't know whether that could happen here, but could "OPTIONS *" be a problem?
I think this is a good point. Should be allowed (and prevented by current patch
proposal).
Regards
Rüdiger
