Headline
CVE-2016-5386: CERT/CC Vulnerability Note VU#797896
The net/http package in Go through 1.6 does not attempt to address RFC 3875 section 4.1.18 namespace conflicts and therefore does not protect CGI applications from the presence of untrusted client data in the HTTP_PROXY environment variable, which might allow remote attackers to redirect a CGI application’s outbound HTTP traffic to an arbitrary proxy server via a crafted Proxy header in an HTTP request, aka an “httpoxy” issue.
CGI web servers assign Proxy header values from client requests to internal HTTP_PROXY environment variables
Vulnerability Note VU#797896
Original Release Date: 2016-07-18 | Last Revised: 2016-07-19
Overview
Web servers running in a CGI or CGI-like context may assign client request Proxy header values to internal HTTP_PROXY environment variables. This vulnerability can be leveraged to conduct man-in-the-middle (MITM) attacks on internal subrequests or to direct the server to initiate connections to arbitrary hosts.
Description
CWE-807****: Reliance on Untrusted Inputs in a Security Decision, CWE-454****: External Initialization of Trusted Variables or Data Stores
Web servers running in a CGI or CGI-like context may assign client request
Proxy
header values to internal
HTTP_PROXY
environment variables. The vulnerable behavior is the result of a naming convention for meta-variables, defined in RFC 3876, which leads to a name collision: “The HTTP header field name is converted to upper case, has all occurrences of "-" replaced with “_” and has “HTTP_” prepended to give the meta-variable name.”
According to the researchers, a web server is vulnerable if:
- A web server, programming language or framework (and in some limited situations the application itself) sets the environmental variable HTTP_PROXY from the user supplied Proxy header in the web request, or sets a similarly used variable (essentially when the request header turns from harmless data into a potentially harmful environmental variable).
- A web application makes use of HTTP_PROXY or similar variable unsafely (e.g. fails to check the request type) resulting in an attacker controlled proxy being used (essentially when HTTP_PROXY is actually used unsafely).
By sending a specially crafted request to a vulnerable server, a remote, unauthenticated attacker may be able to conduct MITM attacks on internal server subrequests or direct the server to initiate connections to arbitrary hosts. For more information, refer to httpoxy.org.
Impact
A remote, unauthenticated attacker may be able to conduct MITM attacks on internal server subrequests or direct the server to initiate connections to arbitrary hosts.
Solution
Apply an update
Where applicable, affected products and components should be updated to address this vulnerability. Check with vendors for information about patching.
Where patches are unavailable or updating is not an option, consider the following workarounds.
Filter
Proxy
request headers
The researchers and community have identified several filtering strategies that are product-dependent:
Apache/CGI
In this configuration, any language may be vulnerable (the
HTTP_PROXY
env var is “real”). If you are using
mod_headers
, you can unset the "
Proxy
" header with this directive:
RequestHeader unset Proxy
If you are using mod_security, you can use a rule like (vary the action to taste):
SecRuleEngine On
SecRule &REQUEST\_HEADERS:Proxy "@gt 0"
"id:1000005,log,deny,msg:'httpoxy denied'"
Refer to Apache’s response for more information.
HAProxy
httprequest delheader Proxy
lighttpd <= 1.4.40 (reject requests containing “Proxy” header)
Create "/path/to/deny-proxy.lua", read-only to lighttpd, with content:
if (lighty.request\["Proxy"\] == nil) then return 0 else return 403 end
Modify lighttpd.conf to load mod_magnet and run lua code
server.modules += ( "mod\_magnet" )
magnet.attract-raw-url-to = ( “/path/to/deny-proxy.lua” )
lighttpd2 (development) (strip “Proxy” header from request)
Add to lighttpd.conf:
req\_header.remove "Proxy";
Nginx/FastCGI
Use this to block the
Proxy header from being passed on to PHPFPM, PHPPM, etc.
fastcgi\_param HTTP\_PROXY ;
Nginx with proxy_pass
The following setting should work for people who are using “proxy_pass” with nginx:
proxy\_set\_header Proxy ;
Microsoft has provided the following guidance for IIS servers utilizing affected third-party frameworks:
Microsoft IIS Mitigation steps:
Update apphost.config with the following rule:
<system.webServer>
<rewrite>
<rules>
<rule name=3D"Erase HTTP_PROXY" patternSyntax=3D"Wildcard">
<match url=3D"*.*" />
<serverVariables>
<set name=3D"HTTP_PROXY" value=3D />
</serverVariables>
<action type=3D"None" />
</rule>
</rules>
</rewrite>
</system.webServer>
Vendor Information
Filter by content: Additional information available
Sort by:
CVSS Metrics
Group
Score
Vector
Base
5.1
AV:N/AC:H/Au:N/C:P/I:P/A:P
Temporal
4.6
E:POC/RL:ND/RC:C
Environmental
1.1
CDP:ND/TD:L/CR:ND/IR:ND/AR:ND
References****Acknowledgements
Thanks to Dominic Scheirlinck and Scott Geary of Vend for reporting this vulnerability.
This document was written by Joel Land.
Other Information
Related news
Vulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Client programs). Supported versions that are affected are 5.5.56 and earlier and 5.6.36 and earlier. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data as well as unauthorized read access to a subset of MySQL Server accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.0 Base Score 5.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L).