Some flaws take longer—a lot longer—than others to get fixed. The newly named HTTpoxy vulnerability was first discovered back in March 2001 and fixed in the open-source Perl programming language, but it has sat dormant in multiple other languages and applications until July 18.
The HTTPoxy flaw is a misconfiguration vulnerability in the HTTP_PROXY variable that is commonly used by Common Gateway Interface (CGI) environment scripts. The HTTPoxy flaw could potentially enable a remotely exploitable vulnerability on servers, enabling an attacker to run code or redirect traffic. The flaw at its core is a name space conflict between two different uses for a server variable known as HTTP Proxy.
“There is a common system environment variable called “HTTP_PROXY,” which can be used to communicate the HTTP (and sometimes HTTPS) proxy settings for an outgoing HTTP proxy to an application,” Red Hat explains in its advisory on HTTpoxy. “This variable has a completely different purpose and context to that of the HTTP server-script variable.”
Red Hat’s advisory notes that applications, language libraries and scripting modules use the HTTP server script environment variable to help configure a proxy for subsequent outgoing HTTP traffic. The risk is that since the two variables can be confused, an attacker could potentially redirect a server’s outgoing connection to an arbitrary location. The HTTpoxy flaw has a widespread impact, with the open-source PHP, Go, Python and HVVM languages at risk as well as the Apache HTTP and Tomcat servers. As myriad applications rely on those languages and servers, there are multiple updates from application projects as well, including the popular Drupal open-source content-management system, which powers many U.S. government Websites, including Whitehouse.gov.
Christopher Robinson, manager, Red Hat product security program management, explained that the HTTpoxy issue was first identified and fixed in 2001 in a Perl library. Perl is a popular open-source programming language.
“The world of security was quite a bit different back in 2001. It wasn’t common to look at issues as having wide-reaching consequences,” Robinson told eWEEK. “Today, there are a large number of security researchers investigating issues like never before.”
Robinson added that Web apps were also quite different in 2001, and tended to be more monolithic. The idea of doing server-side HTTP requests while fulfilling a client-side request was also not very common. Today, it is a different world with distributed applications and microservices.
“In a worst-case scenario for this issue, an attacker could possibly redirect outgoing HTTP traffic from a CGI script to other servers,” Robinson said. “This could lead to the disclosure of sensitive information contained within both request and response sent between the CGI script and HTTP server.”
That said, Robinson emphasized that on Linux, the majority of Web applications no longer run as CGI scripts, meaning they are not vulnerable to this type of attack.
Greg Knaddison, director of engineering at Card.com and Drupal Security Team member, noted that for most Drupal sites, HTTpoxy is probably only a “corner case” risk.
“The members of Drupal Security Team who worked on this issue were able to think of a few scenarios that would allow a determined attacker to completely take over a site,” Knaddison told eWEEK. “Most of them involved stringing together the HTTPoxy vulnerability in the Guzzle library to achieve a defacement or a Cross-site scripting attack.”
Guzzle is a popular PHP HTTP client that can be used in a Drupal deployment stack. Knaddison added that Drupal core does not use the vulnerable HTTP proxy variable directly; however, Drupal 8 core and several Drupal 7 contributed modules used a version of the Guzzle library that was vulnerable. The Drupal project has now issued an update and guidance on how to further mitigate the limited risk of HTTpoxy.
For users of the popular Apache HTTP Web server, the Apache Software Foundation has issued guidance to help mitigate the risk.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.