Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of jorton@redhat.com designates
 209.132.183.28 as permitted sender)
Date: Wed, 23 Nov 2011 14:23:21 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@httpd.apache.org
Subject: [RFC] further proxy/rewrite URL validation security issue
 (CVE-2011-4317)
Message-ID: <20111123142321.GB22547@redhat.com>
Mail-Followup-To: dev@httpd.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-12-10)
Organization: Registered in England and Wales under Company Registration No.
 03798903
  Directors: Michael Cunningham (USA), Mark Hegarty (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

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