Bug 756483 (CVE-2011-4317)

Summary: CVE-2011-4317 httpd: uri scheme bypass of the reverse proxy vulnerability CVE-2011-3368 fix
Product: [Other] Security Response Reporter: Tomas Hoger <thoger>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: jbnance, jkaluza, jorton, pahan, pcheung, prc, weli, werner.maes
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=moderate,public=20111123,reported=20111123,source=internet,cvss2=2.6/AV:N/AC:H/Au:N/C:N/I:P/A:N,rhel-4/httpd=notaffected,rhel-5/httpd=notaffected,rhel-6/httpd=affected,jbews-1/httpd=notaffected,fedora-all/httpd=notaffected,certificate_system_7.3/httpd=notaffected,directory_server_8/httpd=notaffected
Fixed In Version: httpd 2.2.22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-14 02:47:58 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 746695, 746696, 746697, 787598, 787599    
Bug Blocks: 736705    

Description Tomas Hoger 2011-11-23 13:17:32 EST
Additional problems were discovered in the httpd fix for CVE-2011-3368 - a reverse proxy bypass flaw - tracked via bug #740045.  Upstream mailing list post identifies following request forms, which are not handled correctly:

 GET @localhost::8880 HTTP/1.0\r\n\r\n
 GET qualys:@qqq.qq.qualys.com HTTP/1.0\r\n\r\n

Reference:
http://thread.gmane.org/gmane.comp.apache.devel/46440
Comment 5 Werner Maes 2011-11-28 09:17:25 EST
Well,
If I try this with a similar setup and post the request forms, I always get an error stating that the request-URI is invalid:

[Mon Nov 28 13:57:34 2011] [error] [client a.b.c.d] invalid request-URI @localhost::8080

Am I doing something wrong :) ? I'm using the latest Redhat httpd rpm.

Kind regards

Werner
Comment 6 Werner Maes 2011-11-29 04:32:00 EST
This works fine:

: httpd-2.2.3 10:24#; fp;echo -e  "GET / HTTP/1.0\r\n" |nc a.b.c.d 80
HTTP/1.1 200 OK

but this command generates the bad request error.

: httpd-2.2.3 10:26#; fp;echo -e  "GET @localhost::80 HTTP/1.0\r\n" |nc a.b.c.d 80
HTTP/1.1 400 Bad Request

 tcpdump -A 'host x and tcp port 80  and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' shows


E..RDE@.>....:
g.:...'.Pd4..........>......
"#..L...GET @localhost::80 HTTP/1.0


E....<@.@..[.:...:
g.P.'....d4......h......
L..."#..HTTP/1.1 400 Bad Request


So my proxy setup does not seem to vulnerable?
Comment 8 Tomas Hoger 2011-12-05 07:06:50 EST
The scheme trick does not work against httpd in Red Hat Enterprise Linux 4 and 5, due to the difference in apr-util's apr_uri_parse() implementation.  Newer apr-util versions include the following change:

  http://svn.apache.org/viewvc?view=revision&revision=594624

to allow URIs as: scheme:rest, where rest does not need to start with "//".  In that case, rest is parsed as path component of the URI, and can possibly start with ':' or '@', which allow redirecting request to a different port on the configured remote host or different remote host as was demonstrated.  Older versions require scheme to be followed by "://" and the part following "://" is parsed as authority (host + optional port and username/password) followed by path.  That code path does not allow paths starting with ':' or '@'.
Comment 9 Tomas Hoger 2012-01-12 04:41:32 EST
(In reply to comment #8)

> Older versions require scheme to be followed by "://" and the part following
> "://" is parsed as authority (host + optional port and username/password)
> followed by path.  That code path does not allow paths starting with
> ':' or '@'.

Let's extend this explanation a bit to make it easier to understand.  The original CVE-2011-3368 fix added following check to reject invalid URIs:

+    if (r->method_number != M_CONNECT 
+        && !r->parsed_uri.scheme 
+        && uri[0] != '/'
+        && !(uri[0] == '*' && uri[1] == '\0')) {

The aim is to reject requests which contain path that does not start with /.  There are exceptions like URI "*" or any URI that contains scheme part.  In recent apr-util, it is easy to provide URI which is parsed by apr_uri_parse() to non-NULL scheme and path not starting with / (scheme: @localhost, path: :8880 and scheme: qualys, path: @qqq.qq.qualys.com).  In older versions, when apr_uri_parse() returns non-NULL scheme, path is always either NULL or starting with /, which is safe.
Comment 10 Tomas Hoger 2012-01-19 05:49:16 EST
Proposed upstream fix:
  http://thread.gmane.org/gmane.comp.apache.devel/47061

originally proposed in the discussion thread linked in comment #0:
  http://thread.gmane.org/gmane.comp.apache.devel/46440/focus=46742
Comment 12 Tomas Hoger 2012-01-26 09:43:55 EST
Fixed in 2.2.x now too, queued for 2.2.22 release:
  http://svn.apache.org/viewvc?view=revision&revision=1235443
Comment 14 Vincent Danen 2012-02-10 11:05:25 EST
Statement:

This issue did not affect the versions of httpd as shipped with Red Hat Enterprise Linux 4 and 5 due to differences in apr-util's apr_uri_parse() implementation.
Comment 15 errata-xmlrpc 2012-02-13 15:34:21 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2012:0128 https://rhn.redhat.com/errata/RHSA-2012-0128.html