You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@apache.org by Mark Thomas <ma...@apache.org> on 2014/09/10 16:00:24 UTC
[SECURITY] CVE-2013-4444 Remote Code Execution in Apache Tomcat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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/security-7.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJUEFl4AAoJEBDAHFovYFnnR3cQAL034ZrbUeBcJ4zotNp5+ea2
llNatC3MUlg/vZ2qG8Qo4xxbdS4F53cpu90fFhKm+dFzIiRhZeHROYDv6Lu1biSu
Nvq0YXV6KVJ9Js4G6HFilhy3vownvn/hMAjzmPojSYjWO5slXNfFvAlwyRrGt0Cp
t5rUh4QNavhgO4m0HXJJLg+PNlSKsnGdra+0gWmq8YKtKotgu24SbPq/p3HP7TuJ
nnMjx4A6r2LcoghL/nFAPp2ZwgBCtm67osObJ1uMxYhZ2I/3MztFYpSKvfVONuUK
rL265wmrKLvvDdozd/Aw2d2poXdSO/oWeuhKbbzYOxpUT6iRzf+BkPUR99e6Rqso
lOfLoAYuzYfK4rW/ooxVNKnHMhs+0BVfNZoclKCDSvz+a9dIVS5XD6KcyJQ3uv12
ujyTGaGhLuS/ciAVS372Dx8H0/mfd5nZCkYL6NDyzSWSmb5eG4XxqrLi77yByvAT
ulSAyg1UWk8sRgQ4AY3belH3jDiN1rHSWJAaB+WVwszQdCe4iXgDyB1u4ES22oAN
Ymrg5l7tLQ8/9LyMvlQ0tE4f+OYE6kki6e4JMc2cMqPL/rcjiUnLWZ7YUyx92RM1
LRt9QhMd1h3Uwle7a7LxqJCGf/rIPwRmrjTYYWt43np1Adx7y2RuZOTDjEY98sN3
oCLjuSCalVcBX9hGaJ7n
=98BB
-----END PGP SIGNATURE-----
Re: [SECURITY] CVE-2013-4444 Remote Code Execution in Apache Tomcat
Posted by David kerber <dc...@verizon.net>.
On 9/10/2014 11:10 AM, Jeffrey Janner wrote:
>> -----Original Message-----
>> From: Mark Thomas [mailto:markt@apache.org]
>> Sent: Wednesday, September 10, 2014 9:00 AM
>> To: Tomcat Users List
>> Cc: Tomcat Developers List; announce@apache.org;
>> announce@tomcat.apache.org; fulldisclosure@seclists.org;
>> bugtraq@securityfocus.com
>> Subject: [SECURITY] CVE-2013-4444 Remote Code Execution in Apache
>> Tomcat
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> 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.
>
> How does one avoid this if deploying war files? By definition, doesn't the exploded directory need to be writable by the Tomcat process?
> The only way I can think of is to not explode the war file, but that is a performance hit.
>
>> 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.
>>
>
> Are these two an AND case?
That's what he said: "For this attack to succeed all of the following
requirements must be met:"
> If using the JmxRemoteListener, wouldn't one normally deploy it in Tomcat/lib?
>
> Finally, if you've taken care of a) & b), is this sufficient to mitigate the problem, even if any/all of c) thru g) apply?
>
>> 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/security-7.html
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQIcBAEBAgAGBQJUEFl4AAoJEBDAHFovYFnnR3cQAL034ZrbUeBcJ4zotNp5+ea
>> 2
>> llNatC3MUlg/vZ2qG8Qo4xxbdS4F53cpu90fFhKm+dFzIiRhZeHROYDv6Lu1biSu
>> Nvq0YXV6KVJ9Js4G6HFilhy3vownvn/hMAjzmPojSYjWO5slXNfFvAlwyRrGt0C
>> p
>> t5rUh4QNavhgO4m0HXJJLg+PNlSKsnGdra+0gWmq8YKtKotgu24SbPq/p3HP7T
>> uJ
>> nnMjx4A6r2LcoghL/nFAPp2ZwgBCtm67osObJ1uMxYhZ2I/3MztFYpSKvfVONu
>> UK
>> rL265wmrKLvvDdozd/Aw2d2poXdSO/oWeuhKbbzYOxpUT6iRzf+BkPUR99e6R
>> qso
>> lOfLoAYuzYfK4rW/ooxVNKnHMhs+0BVfNZoclKCDSvz+a9dIVS5XD6KcyJQ3uv1
>> 2
>> ujyTGaGhLuS/ciAVS372Dx8H0/mfd5nZCkYL6NDyzSWSmb5eG4XxqrLi77yByvA
>> T
>> ulSAyg1UWk8sRgQ4AY3belH3jDiN1rHSWJAaB+WVwszQdCe4iXgDyB1u4ES22
>> oAN
>> Ymrg5l7tLQ8/9LyMvlQ0tE4f+OYE6kki6e4JMc2cMqPL/rcjiUnLWZ7YUyx92RM1
>> LRt9QhMd1h3Uwle7a7LxqJCGf/rIPwRmrjTYYWt43np1Adx7y2RuZOTDjEY98sN
>> 3
>> oCLjuSCalVcBX9hGaJ7n
>> =98BB
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY] CVE-2013-4444 Remote Code Execution in Apache Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 10/09/2014 16:10, Jeffrey Janner wrote:
>> -----Original Message-----
>> From: Mark Thomas [mailto:markt@apache.org]
>> Sent: Wednesday, September 10, 2014 9:00 AM
>> To: Tomcat Users List
>> Cc: Tomcat Developers List; announce@apache.org;
>> announce@tomcat.apache.org; fulldisclosure@seclists.org;
>> bugtraq@securityfocus.com
>> Subject: [SECURITY] CVE-2013-4444 Remote Code Execution in Apache
>> Tomcat
>>
> 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.
>
>> How does one avoid this if deploying war files? By definition, doesn't the exploded directory need to be writable by the Tomcat process?
>> The only way I can think of is to not explode the war file, but that is a performance hit.
Don't deploy WAR files, deploy an exploded directory. You create the
exploded web app with the appropriate permissions (root rw, tomcat r)
and then move it into place (and move the old one out of the way at the
same time).
The general recommendation (see the security guide) is that the Tomcat
process should not have write access apart from temp and work.
> 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.
>
>
>> Are these two an AND case?
All 6 are an AND case. i.e. if you don't meet any one of the
requirements you are safe (this is the main reason this is rated as
important rather than critical).
>> If using the JmxRemoteListener, wouldn't one normally deploy it in Tomcat/lib?
Yes, you would although in theory you might be able to install it
elsewhere on the class path - I haven't tried.
>> Finally, if you've taken care of a) & b), is this sufficient to mitigate the problem, even if any/all of c) thru g) apply?
Again, you have to meet all of a) through f) or all of a) plus d)
through g) to be vulnerable.
Mark
>
> 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/security-7.html
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [SECURITY] CVE-2013-4444 Remote Code Execution in Apache Tomcat
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> Sent: Wednesday, September 10, 2014 9:00 AM
> To: Tomcat Users List
> Cc: Tomcat Developers List; announce@apache.org;
> announce@tomcat.apache.org; fulldisclosure@seclists.org;
> bugtraq@securityfocus.com
> Subject: [SECURITY] CVE-2013-4444 Remote Code Execution in Apache
> Tomcat
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
How does one avoid this if deploying war files? By definition, doesn't the exploded directory need to be writable by the Tomcat process?
The only way I can think of is to not explode the war file, but that is a performance hit.
> 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.
>
Are these two an AND case?
If using the JmxRemoteListener, wouldn't one normally deploy it in Tomcat/lib?
Finally, if you've taken care of a) & b), is this sufficient to mitigate the problem, even if any/all of c) thru g) apply?
> 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/security-7.html
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBAgAGBQJUEFl4AAoJEBDAHFovYFnnR3cQAL034ZrbUeBcJ4zotNp5+ea
> 2
> llNatC3MUlg/vZ2qG8Qo4xxbdS4F53cpu90fFhKm+dFzIiRhZeHROYDv6Lu1biSu
> Nvq0YXV6KVJ9Js4G6HFilhy3vownvn/hMAjzmPojSYjWO5slXNfFvAlwyRrGt0C
> p
> t5rUh4QNavhgO4m0HXJJLg+PNlSKsnGdra+0gWmq8YKtKotgu24SbPq/p3HP7T
> uJ
> nnMjx4A6r2LcoghL/nFAPp2ZwgBCtm67osObJ1uMxYhZ2I/3MztFYpSKvfVONu
> UK
> rL265wmrKLvvDdozd/Aw2d2poXdSO/oWeuhKbbzYOxpUT6iRzf+BkPUR99e6R
> qso
> lOfLoAYuzYfK4rW/ooxVNKnHMhs+0BVfNZoclKCDSvz+a9dIVS5XD6KcyJQ3uv1
> 2
> ujyTGaGhLuS/ciAVS372Dx8H0/mfd5nZCkYL6NDyzSWSmb5eG4XxqrLi77yByvA
> T
> ulSAyg1UWk8sRgQ4AY3belH3jDiN1rHSWJAaB+WVwszQdCe4iXgDyB1u4ES22
> oAN
> Ymrg5l7tLQ8/9LyMvlQ0tE4f+OYE6kki6e4JMc2cMqPL/rcjiUnLWZ7YUyx92RM1
> LRt9QhMd1h3Uwle7a7LxqJCGf/rIPwRmrjTYYWt43np1Adx7y2RuZOTDjEY98sN
> 3
> oCLjuSCalVcBX9hGaJ7n
> =98BB
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org