Skip to main content
Support

KB Article #176508

Sentinel 4.0.1 is not vulnerable to CVE-2013-4444

Problem

CVE-2013-4444 vulnerability is for Apache Tomcat 7.x before 7.0.40.  Synchrony Infrastructure 4.6.0 (that Sentinel 4.0.1 comes with) uses Apache Tomcat version 7.0.37.0.

Overview of CVE-2013-4444 vulnerability
  Unrestricted file upload vulnerability in Apache Tomcat 7.x before 7.0.40, in certain situations involving outdated java.io.File code and a custom JMX configuration, allows remote attackers to execute arbitrary code by uploading and accessing a JSP file.

Resolution

R&D has reviewed the vulnerability criteria for CVE-2013-4444 and determined that Sentinel 4.0.1 is not vulnerable.  Referenced the following external source listed on National Vulnerability Database (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4444) website.  Sentinel 4.0.1 meets all the vulnerability criteria, except point e and f (see the excerpt shown below).  Since there is no custom JMX connections in the tomcat delivered by infrastructure, e and f are not applicable.


External Source: BUGTRAQ
Name: 20140910 CVE-2013-4444 Remote Code Execution in Apache Tomcat

In very limited circumstances, it was possible for an attacker to upload a malicious JSP to a Tomcat server and then trigger the execution of that JSP.  While Remote Code Execution would normally be viewed as a critical vulnerability, the circumstances under which this is possible are, in the view of the Tomcat security team, sufficiently limited that this vulnerability is viewed as important.

For this attack to succeed all of the following requirements must be met:
a) Using Oracle Java 1.7.0 update 25 or earlier (or any other Java implementation where java.io.File is vulnerable to null byte injection).
b) A web application must be deployed to a vulnerable version of Tomcat (see previous section).
c) The web application must use the Servlet 3.0 File Upload feature.
d) A file location within a deployed web application must be writeable by the user the Tomcat process is running as. The Tomcat security documentation recommends against this.
e) A custom listener for JMX connections (e.g. the JmxRemoteListener that is not enabled by default) must be configured and be able to load classes from Tomcat's common class loader (i.e. the custom JMX listener must be placed in Tomcat's lib directory)
f) The custom JMX listener must be bound to an address other than localhost for a remote attack (it is bound to localhost by default).  If the custom JMX listener is bound to localhost, a local attack will still be possible.