CVE-2013-4444 Remote Code Execution
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
- - Apache Tomcat 7.0.0 to 7.0.39
Description:
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.
Note that requirements b) and c) may be replaced with the following
requirement:
g) A web application is deployed that uses Apache Commons File Upload
1.2.1 or earlier.
In this case a similar vulnerability may exist on any Servlet container,
not just Apache Tomcat.
Mitigation:
This vulnerability may be mitigated by using any one of the following
mitigations:
- - Upgrade to Oracle Java 1.7.0 update 40 or later (or any other Java
implementation where java.io.File is not vulnerable to null byte
injection).
- - Use OS file permissions to prevent the process Tomcat is running as
from writing to any location within a deployed application.
- - Disable any custom JMX listeners
- - Upgrade to Apache Tomcat 7.0.40 or later
Credit:
This issue was identified by Pierre Ernst of the VMware Security
Engineering, Communications & Response group (vSECR) and reported to
the Tomcat security team via the Pivotal security team.
References:
[1] http://tomcat.apache.org/
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
- - Apache Tomcat 7.0.0 to 7.0.39
Description:
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.
Note that requirements b) and c) may be replaced with the following
requirement:
g) A web application is deployed that uses Apache Commons File Upload
1.2.1 or earlier.
In this case a similar vulnerability may exist on any Servlet container,
not just Apache Tomcat.
Mitigation:
This vulnerability may be mitigated by using any one of the following
mitigations:
- - Upgrade to Oracle Java 1.7.0 update 40 or later (or any other Java
implementation where java.io.File is not vulnerable to null byte
injection).
- - Use OS file permissions to prevent the process Tomcat is running as
from writing to any location within a deployed application.
- - Disable any custom JMX listeners
- - Upgrade to Apache Tomcat 7.0.40 or later
Credit:
This issue was identified by Pierre Ernst of the VMware Security
Engineering, Communications & Response group (vSECR) and reported to
the Tomcat security team via the Pivotal security team.
References:
[1] http://tomcat.apache.org/