Tomcat Undeploy Failure May Allow Remote Users to Access Files
SecurityTracker Alert ID: 1023503|
SecurityTracker URL: http://securitytracker.com/id/1023503
(Links to External Site)
Date: Jan 25 2010
Disclosure of user information|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 5.5.0 - 5.5.28, 6.0.0 - 6.0.20; possibly earlier versions|
A vulnerability was reported in Tomcat. A remote user can access files in certain cases.|
When an undeploy fails, the remaining files will still be deployed by the auto-deployment process. A remote user may be able to access the files.
A remote user can access files that should not have been deployed.|
The vendor has issued a fix (5.5.29 [pending], 6.0.24).|
Patches are also available.
The vendor's advisory is available at:
Vendor URL: tomcat.apache.org/ (Links to External Site)
Access control error|
Linux (Any), UNIX (Any), Windows (Any)|
Source Message Contents
Date: Sun, 24 Jan 2010 16:54:32 -0500|
Subject: [Full-disclosure] [SECURITY] CVE-2009-2901 Apache Tomcat insecure partial deploy after failed undeploy
-----BEGIN PGP SIGNED MESSAGE-----
CVE-2009-2901: Apache Tomcat insecure partial deploy after failed undeploy
The Apache Software Foundation
Tomcat 5.5.0 to 5.5.28
Tomcat 6.0.0 to 6.0.20
The unsupported Tomcat 3.x, 4.x and 5.0.x versions may be also
By default, Tomcat automatically deploys any directories placed in a
host's appBase. This behaviour is controlled by the autoDeploy attribute
of a host which defaults to true. After a failed undeploy, the remaining
files will be deployed as a result of the autodeployment process.
Depending on circumstances, files normally protected by one or more
security constraints may be deployed without those security constraints,
making them accessible without authentication.
6.0.x users should upgrade to 6.0.24 or apply this patch:
5.5.x users should upgrade to 5.5.29 when released or apply this patch:
Note: the patches also address CVE-2009-2693 and CVE-2009-2902.
Alternatively, users of all Tomcat versions may mitigate this issue by
manually ensuring that an undeploy removes all files. If one or more
files cannot be deleted, it may be necessary to stop Tomcat before the
files can be deleted.
This issue was discovered by the Apache Tomcat security team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/