tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Vulnerability from PCI scan
Date Wed, 02 Nov 2016 15:05:56 GMT
Hash: SHA256


On 11/1/16 6:05 PM, Carl K. wrote:
> On 11/1/2016 5:25 PM, Christopher Schultz wrote: Carl,
> On 11/1/16 5:11 PM, Carl K. wrote:
>>>> Control Scan has returned this as a vulnerability in Tomcat 
>>>> 8.0.38:
>>>> Vulnerable version of Apache Tomcat: 8.0.38
>>>> Risk: High (3) Port: 443/tcp Protocol: tcp Threat ID: 
>>>> web_dev_tomcatver
>>>> Details: 404 Error Page Cross Site Scripting Vulnerability 
>>>> 12/21/09 Apache Tomcat is prone to a cross-site scripting 
>>>> vulnerability because it fails to properly sanitize
>>>> user-supplied input. An attacker may leverage this issue to
>>>> execute arbitrary script code in the browser of an
>>>> unsuspecting user in the context of the affected site. Apache
>>>> Tomcat mitigates HTTP_PROXY environment variable "httpoxy"
>>>> issue
>>>> I have read everything I can find and it still doesn't make 
>>>> sense... can someone help to point me in the correct
>>>> direction?
>>>> I am further puzzled because this is the first time this has
>>>> come up and we run Tomcat for years... note that the date is
>>>> listed as 12-21-2009.
> Technically, this is not a vulnerability in Tomcat (or any 
> reverse-proxy, such as httpd) but it does represent a failure to 
> protect stupid command-line utilities from making bad decisions
> about trusting environment variables.
> Long story short, if using the CGI Servlet, any headers coming
> from the request are set as HTTP_* environment variables on a
> script that is executed as a CGI script. Notably, python, Perl, and
> PHP (and others) use an environment variable called HTTP_PROXY to
> indicate the presence of a forward-proxy to be used for outgoing
> HTTP connections. Thus, setting a "Proxy" header in an HTTP request
> to Tomcat will result in a CGI script seeing that value in the
> HTTP_PROXY environment variable. This could present a problem in
> your environment, but is possible to mitigate in a number of
> different ways.
> I have no idea where your scanner got the date 2009-12-21. Perhaps 
> they took the recently-disclosed CVE (CVE-2016-5388 -- note the
> year on that CVE identifier) and made a best-guess of when the
> product was first vulnerable. The first beta version of Tomcat 7
> wasn't available until 2010, so perhaps they were considering
> Tomcat 6 as well. But Tomcat 6's history goes back well before
> that. Honestly, I think they may have picked that date out of the
> air.
> At any rate, you are safe if any of the following are true:
> 1. You don't use the CGI servlet 2. You don't use any scripts that
> use HTTP_PROXY in this manner (this is a weak criteria, since you
> may not KNOW if you are using such scripts) 3. You don't allow
> outgoing HTTP requests from your application servers, and no error
> messages produces by those scripts would leak any information like
> URLs, etc. 4. If you have a reverse-proxy (e.g. httpd) and
> explicitly remove any "proxy" headers from incoming HTTP requests
> Mitigation is possible through a variety of means. If you aren't 
> vulnerable, this scan is likely to complain merely because of the 
> version number of Tomcat and the fact that this CVE hasn't
> officially been closed, yet.
>> That is about where I had gotten to.
>> I really appreciate your quick and thorough response.

I dug a bit, and it seems that this was fixed in Tomcat 8.0.38, as per
the changelog[1]. Search for CVE-2016-5388 (or httpoxy) and you'll see
it's in there. So your scanning is either incorrect or you have
explicitly whitelisted the "PROXY" header for your CGIs. I suspect you
ave no CGIs and the scanner is just dumping a list of things that
*might* be vulnerabilities.

- -chris
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message