Bug 756483 (CVE-2011-4317) - CVE-2011-4317 httpd: uri scheme bypass of the reverse proxy vulnerability CVE-2011-3368 fix
Summary: CVE-2011-4317 httpd: uri scheme bypass of the reverse proxy vulnerability CVE...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2011-4317
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 746695 746696 746697 787598 787599
Blocks: 736705
TreeView+ depends on / blocked
 
Reported: 2011-11-23 18:17 UTC by Tomas Hoger
Modified: 2021-09-13 19:41 UTC (History)
9 users (show)

Fixed In Version: httpd 2.2.22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-14 07:47:58 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0128 0 normal SHIPPED_LIVE Moderate: httpd security update 2012-02-14 01:33:00 UTC

Description Tomas Hoger 2011-11-23 18:17:32 UTC
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 14:17:25 UTC
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 09:32:00 UTC
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 12:06:50 UTC
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 09:41:32 UTC
(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 10:49:16 UTC
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 14:43:55 UTC
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 16:05:25 UTC
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 20:34:21 UTC
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


Note You need to log in before you can comment on or make changes to this bug.