Bug 740045 - (CVE-2011-3368) CVE-2011-3368 httpd: reverse web proxy vulnerability
CVE-2011-3368 httpd: reverse web proxy vulnerability
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20111005,repor...
: Security
Depends On: 743659 743901 743902 743903 743904 746695 746696 746697 785070
Blocks: 736705
  Show dependency treegraph
 
Reported: 2011-09-20 15:13 EDT by Vincent Danen
Modified: 2016-02-15 08:52 EST (History)
11 users (show)

See Also:
Fixed In Version: httpd 2.2.22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-07 15:34:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2011-09-20 15:13:37 EDT
RMDG partner and independent security consultancy, "Context Information 
Security" has made CPNI Response aware of a security vulnerability which 
could potentially allow an attacker to gain full internal access to a 
network from the internet.

The technique exploits insecurely configured reverse web proxies to gain 
access to internal/DMZ systems.

This attack is based on an Apache web server which is using "mod_rewrite" 
to proxy web requests internally. Other proxies may suffer from this 
issue.

The vulnerability occurs if the Apache configuration file is configured 
like this:

                RewriteRule ^(.*) http://internalserver:80$1 [P]

As opposed to:

                RewriteRule ^(.*) http://internalserver:80/$1 [P]


It is important for readers to review their reverse proxy configurations 
to ensure that the rewrite rules are securely configured and cannot be 
abused in such a way that they can be used to compromise internal systems.
Comment 1 Tomas Hoger 2011-09-26 07:54:29 EDT
Part of the problem is that httpd documentation was giving a bad example, that is probably going to get corrected in future upstream releases:

  http://httpd.apache.org/docs/2.2/rewrite/flags.html#flag_p
  RewriteRule (.*)\.(jpg|gif|png) http://images.example.com$1.$2 [P]
Comment 2 Vincent Danen 2011-10-05 12:10:49 EDT
This flaw is now public, and has been fixed in svn:

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

The full upstream advisory is as follows (noted because it contains mitigation information):

Apache HTTP Server Security Advisory
====================================

Title:       mod_proxy reverse proxy exposure

CVE:         CVE-2011-3368
Date:        20111005
Product:     Apache HTTP Server
Versions:    httpd 1.3 all versions, httpd 2.x all versions

Description:
============

An exposure was reported affecting the use of Apache HTTP Server in
reverse proxy mode.  We would like to thank Context Information
Security Ltd for reporting this issue to us.

When using the RewriteRule or ProxyPassMatch directives to configure a
reverse proxy using a pattern match, it is possible to inadvertently
expose internal servers to remote users who send carefully crafted
requests.  The server did not validate that the input to the pattern
match was a valid path string, so a pattern could expand to an
unintended target URL.

For future releases of the Apache HTTP Server, the software will
validate the request URI, correcting this specific vulnerability.  The
documentation has been updated to reflect the more general risks with
pattern matching in a reverse proxy configuration.

Details:
========
A configuration like one of the following examples:

  RewriteRule (.*)\.(jpg|gif|png)    http://images.example.com$1.$2 [P]
  ProxyPassMatch (.*)\.(jpg|gif|png) http://images.example.com$1.$2

could result in an exposure of internal servers.  A request of the form:

  GET @other.example.com/something.png HTTP/1.1

would get translated to a target of:

  http://images.example.com@other.example.com/something.png

This will cause the proxy to connect to the hostname
"other.example.com", as the "images.example.com@" segment would be
treated as user credentials when parsing the URL.  This would allow a
remote attacker the ability to proxy to hosts other than those
expected, which could be a security exposure in some circumstances.

The request-URI string in this example,
"@other.example.com/something.png", is not valid according to the HTTP
specification, since it neither an absolute URI
("http://example.com/path") nor an absolute path ("/path").  For
future releases, the server has been patched to reject such requests,
instead returning a "400 Bad Request" error.

Actions:
========

Apache HTTPD users should examine their configuration files to determine
if they have used an insecure configuration for reverse proxying.
Affected users can update their configuration, or apply the patch from:

   http://www.apache.org/dist/httpd/patches/apply_to_2.2.21/

For example, the above RewriteRule could be changed to:

  RewriteRule /(.*)\.(jpg|gif|png)    http://images.example.com/$1.$2 [P]

to ensure the pattern only matches against paths with a leading "/".
Comment 3 Vincent Danen 2011-10-05 12:12:39 EDT
Created httpd tracking bugs for this issue

Affects: fedora-all [bug 743653]
Comment 6 Tomas Hoger 2011-10-06 05:21:49 EDT
(In reply to comment #1)
> Part of the problem is that httpd documentation was giving a bad example, that
> is probably going to get corrected in future upstream releases:
> 
>   http://httpd.apache.org/docs/2.2/rewrite/flags.html#flag_p
>   RewriteRule (.*)\.(jpg|gif|png) http://images.example.com$1.$2 [P]

The example was changed to:
  RewriteRule /(.*)\.(jpg|gif|png) http://images.example.com/$1.$2 [P]

via:
  http://svn.apache.org/viewvc?view=revision&revision=1179283
Comment 9 Tomas Hoger 2011-10-07 11:05:31 EDT
External References:

http://www.contextis.com/research/blog/reverseproxybypass/
Comment 10 Tomas Hoger 2011-10-11 09:40:42 EDT
Acknowledgement:

Red Hat would like to thank Context Information Security for reporting this issue.
Comment 14 errata-xmlrpc 2011-10-20 12:56:36 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 4

Via RHSA-2011:1392 https://rhn.redhat.com/errata/RHSA-2011-1392.html
Comment 15 errata-xmlrpc 2011-10-20 12:57:04 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:1391 https://rhn.redhat.com/errata/RHSA-2011-1391.html
Comment 20 Vincent Danen 2011-11-15 15:31:34 EST
The upstream fix for this issue is here:

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

However that fix is insufficient as it does not handle HTTP 0.9 style requests (as noted via https://bugzilla.novell.com/show_bug.cgi?id=722545#c15).

The additional fix to handle HTTP 0.9 requests is here:

http://svn.apache.org/viewvc?view=revision&revision=1188745
Comment 21 Vincent Danen 2011-11-15 15:32:47 EST
Sorry, I didn't realize we had already filed a bug for the incomplete fix (bug #752080).
Comment 22 errata-xmlrpc 2012-05-07 14:48:37 EDT
This issue has been addressed in following products:

  JBoss Enterprise Web Server 1.0.2

Via RHSA-2012:0543 https://rhn.redhat.com/errata/RHSA-2012-0543.html
Comment 23 errata-xmlrpc 2012-05-07 15:02:58 EDT
This issue has been addressed in following products:

  JBEWS 1.0 for RHEL 5
  JBEWS 1.0 for RHEL 6

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

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