Apache acknowledged another reverse proxy issue (CVE-2011-4317) which was discovered by Apache developer from Red Hat while creating a QualysGuard vulnerability signature for an older problem CVE-2011-3368. Depending on the reverse proxy configuration, the vulnerability could allow access to internal systems from the Internet.
In order to set up Apache HTTPD to run as a reverse proxy, server administrators use specialized modules like mod_proxy and mod_rewrite. Apache developers are working on a fix of a flaw in its web server software that creates a possible mechanism to access internal systems.The zero-day vulnerability only rears its ugly head if reverse proxy rules are configured incorrectly and is far from easy to exploit, but it is nonetheless nasty.
The problem isn't new and a vulnerability that allowed similar attacks was addressed back in October. However, while reviewing the patch for it, Qualys researcher Prutha Parikh realized that it can be bypassed due to a bug in the procedure for URI (Uniform Resource Identifier) scheme stripping. The scheme is the URI part that comes before the colon ":" character, such as http, ftp or file.One relatively common rewrite and proxying rule is "^(.*) https://internal_host$1", which redirects the request to the machine internal_host. However, if this is used and the server receives, for example, a request for "host::port" (with two colons), the "host:" part is stripped and the rest is appended to https://internal_host in order to forward it internally.The problem is that in this case, the remaining part is ":port", therefore transforming the forwarded request into https://internal_host:port, an unintended behavior that can result in the exposure of a protected resource.In order to mitigate the problem server administrators should add a forward slash before $1 in the rewrite rule, the correct form being "^(.*) https://internal_host/$1", Parikh said.
Parikh has published a detailed explanation of the flaw alongside proof of concept code in a post on the Qualys blog here. A possible patch for the vulnerability was suggested by an Apache developer from Red Hat on Wednesday but has yet to be fully tested.