> -----Original Message----- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Wednesday, September 10, 2014 9:00 AM > To: Tomcat Users List > Cc: Tomcat Developers List; annou...@apache.org; > annou...@tomcat.apache.org; fulldisclos...@seclists.org; > bugt...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
