Dominic Scheirlinck of VendHQ reports: Many software projects and vendors have implemented support for the “Proxy” request header in their respective CGI implementations and languages by creating the “HTTP_PROXY” environmental variable based on the header value. When this variable is used (in many cases automatically by various HTTP client libraries) any outgoing requests generated in turn from the attackers original request can be redirected to an attacker controlled proxy. This allows attackers to view potentially sensitive information, reply with malformed data, or to hold connections open causing a potential denial of service. The Nginx HTTP server contains support for Fast CGI. If passed a “Proxy” header in the request Fast CGI will automatically populate the HTTP_PROXY environmental variable with whatever user supplied value is present.
Acknowledgments: Name: Scott Geary (VendHQ)
To clarify where the danger lies: - nginx does not itself support CGI, only FastCGI - in the FastCGI scenario, nginx does not start the worker process; only communicates with it over a socket. Thus it cannot set env variables, and can send HTTP_PROXY safely Thus FastCGI processes are not vulnerable directly. See [1]. However, the recommended way to run CGI processes behind nginx at [2] copies the environment indiscriminately, rendering the CGI itself vulnerable. While not part of our supported products, it is likely some customers are using this technique to expose legacy CGI apps behind nginx. [1]: http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html [2]: https://www.nginx.com/resources/wiki/start/topics/examples/simplecgi/
Closing this as NOTABUG, as the script is the affected component it has gotten a CVE, but we don't ship it and we don't appear to use it so closing this. The CVE will be REJECT'ed.