Vulnerability Note VU#797896

CGI web servers assign Proxy header values from client requests to internal HTTP_PROXY environment variables

Original Release date: 18 Jul 2016 | Last revised: 19 Jul 2016

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:

  1. 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).
  2. 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 (Learn More)

VendorStatusDate NotifiedDate Updated
Apache HTTP Server ProjectAffected12 Jul 201618 Jul 2016
Go Programming LanguageAffected-18 Jul 2016
HAProxyAffected-13 Jul 2016
HHVMAffected-18 Jul 2016
lighttpdAffected-19 Jul 2016
Microsoft CorporationAffected12 Jul 201613 Jul 2016
nginxAffected-13 Jul 2016
PythonAffected-18 Jul 2016
The PHP GroupAffected-18 Jul 2016
EfficientIP SASNot Affected12 Jul 201612 Jul 2016
ACCESSUnknown12 Jul 201612 Jul 2016
Alcatel-LucentUnknown12 Jul 201612 Jul 2016
AppleUnknown12 Jul 201612 Jul 2016
Arista Networks, Inc.Unknown12 Jul 201612 Jul 2016
ARRISUnknown12 Jul 201612 Jul 2016
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

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

Credit

Thanks to Dominic Scheirlinck and Scott Geary of Vend for reporting this vulnerability.

This document was written by Joel Land.

Other Information

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.