A 15-year-old security flaw has once again reared its head, causing a rush by developers to patch the issue.
As noted by The Register, the httpoxy security flaw impacts a range of server software, including PHP, Go, Apache HTTP server, Apache TomCat, PHP-engine HHVM, and Python.
The security flaws affect applications which are running in CGI or similar environments and have been caused by a simple namespace conflict. In CGI, RFC 3875 puts the HTTP Proxy header from a request into environmental variables including HTTP_PROXY -- which can be used to configure outgoing proxies.
This, in turn, causes a security weakness which can be exploited by remote attackers to execute code remotely. All it takes is outgoing HTTP requests to be proxied, directed to a malicious server and then for the web application to be forced to use a malicious proxy.
The Vend security team which discovered the problem and organized public disclosure, led by Dominic Scheirlinck, says that the Proxy header should be immediately blocked by developers to prevent their web domains becoming compromised. However, httpoxy is only effective for server-side web applications -- and so if no code is being deployed, no action needs to be taken.
"We suspect there may be more CVEs coming for httpoxy, as less common software is checked over," the team says.
The set of vulnerabilities have been assigned different CVE numbers depending on the affected software. The CVE assignments are CVE-2016-5385 (PHP), CVE-2016-5386 (Go), CVE-2016-5387 (Apache HTTP), CVE-2016-5388 (Apache TomCat), CVE-2016-1000109 (HHVM), and CVE-2016-1000110 (Python).
The bug was first spotted over 15 years ago by various researchers in different software applications, but it is only now that an instance of the security flaw being exploited in the wild has been discovered.
"Consider the fact that LWP, curl and Ruby teams all noticed at some point over the last 15 years, yet thousands of applications remain vulnerable today," the group noted. "We can only think that's because their finding wasn't loudly and urgently transmitted to everyone else using CGI. So, we think this calls for a slightly "louder" fix."