- Oct 23, 2012
- 12,527
HTTPoxy is the name of a 15-year-old vulnerability that has plagued several code libraries that make HTTP requests, and has most recently been found to affect CGI-based applications written in PHP, Python, and Go.
Dominic Scheirlinck, a developer for Vend, discovered the bug this past February, when he started the process of disclosing this issue and having it fixed with various server vendors.
Today, he has released the public details of this vulnerability, with all the technical details and mitigation procedures explained on its website, along with advisories from US CERT, Apache, Red Hat, Nginx, Drupal, CloudFlare, and Akamai.
The actual problem goes back to March 2001, when Randal L. Schwartz discovered that the libwww-perl module incorrectly handled HTTP_PROXY headers. The same issue was later discovered and fixed in curl (April 2001), Ruby (July 2012), Nginx (November 2013), and now in PHP, Python, and Go scripts running in CGI environments.
HTTPoxy leads to Man-in-the-Middle attacks
The issue is that CGI-based environments that receive incoming HTTP requests containing a "Proxy" header dump the header's content in the HTTP_PROXY environment variable without any sanitization.
Dominic Scheirlinck, a developer for Vend, discovered the bug this past February, when he started the process of disclosing this issue and having it fixed with various server vendors.
Today, he has released the public details of this vulnerability, with all the technical details and mitigation procedures explained on its website, along with advisories from US CERT, Apache, Red Hat, Nginx, Drupal, CloudFlare, and Akamai.
The actual problem goes back to March 2001, when Randal L. Schwartz discovered that the libwww-perl module incorrectly handled HTTP_PROXY headers. The same issue was later discovered and fixed in curl (April 2001), Ruby (July 2012), Nginx (November 2013), and now in PHP, Python, and Go scripts running in CGI environments.
HTTPoxy leads to Man-in-the-Middle attacks
The issue is that CGI-based environments that receive incoming HTTP requests containing a "Proxy" header dump the header's content in the HTTP_PROXY environment variable without any sanitization.
This same HTTP_PROXY variable is used in many applications to automatically configure the local outgoing proxy client. When the user makes a subsequent HTTP request, it will be using the locally configured proxy to reach the request's destination.
An attacker can utilize this vulnerability to poison servers and force a vulnerable CGI application to use a malicious proxy for its outgoing HTTP requests, carrying out MitM attacks.
"This vulnerability affects applications that use 'classic' CGI execution models, and could lead to API token disclosure of the services that your application may talk to," explains Joe Seggiola of CloudFlare.
Mitigation is easy and should not be delayed
Scheirlinck, who provides an explanation for non-technical users on Medium, says that mitigating this vulnerability is easy.
"You should try to do your mitigation as early and as far upstream as you can," he explains. "Do it 'at the edge,' where HTTP requests first enter your system. That way, you can fix lots of vulnerable software at once."
Scheirlinck also recommends stripping the Proxy header altogether. "Everything behind a reverse proxy or application firewall that strips the Proxy header is safe!" he says.
There are many applications and open source projects that are vulnerable to HTTPoxy when in CGI mode. Today, the Drupal project has issued an update to the 8.x branch specifically to mitigate this type of attack in the Guzzle PHP library that Drupal uses to make HTTP requests from within the CMS.
Webmasters should not wait for updates in open source projects and take the necessary steps to mitigate the issue themselves.
The CVE identifiers for the HTTPoxy vulnerabilities are CVE-2016-5385 (PHP); CVE-2016-5386 (Go); CVE-2016-5387 (Apache HTTP Server); CVE-2016-5388 (Apache Tomcat); CVE-2016-1000109 (HHVM); and CVE-2016-1000110 (Python).
On Reddit, Scheirlinck has mentioned that the HTTPS_PROXY environment variable is not affected by this issue.