From Secunia: Two vulnerabilities have been reported in Apache Tomcat, which can be exploited by malicious people to cause a DoS (Denial of Service) or potentially disclose sensitive information. 1) An error exists when processing invalid HTTP headers received via the Java AJP connector. This can be exploited to close AJP connections and temporarily block a connector that is a member of a mod_jk load balancing worker. 2) An error in certain authentication classes can be exploited to potentially enumerate existing usernames via specially crafted URL-encoded passwords and brute force attacks. Successful exploitation of this vulnerability requires that form based authentication ("j_security_check") with one of the "MemoryRealm", "DataSourceRealm", or "JDBCRealm" authentication realms is used. The vulnerabilities are reported in versions 4.1.0 through 4.1.39 and 5.5.0 through 5.5.27 and versions 6.0.0 through 6.0.18. -- Additionally from http://tomcat.apache.org/security-5.html: The calendar application in the examples web application contains an XSS flaw due to invalid HTML which renders the XSS filtering protection ineffective. This was fixed in revision 750928. Affects: 5.5.0-5.5.27, 6.0.0-6.0.18
Tomcat 6.0.20 is released. Patches for 5.x are: http://svn.apache.org/viewvc?view=rev&revision=781379 http://svn.apache.org/viewvc?view=rev&revision=781362
another issue was fixed by the information disclosure by the 6.0.20 and 5.5.28 releases: http://www.mail-archive.com/dev@tomcat.apache.org/msg32194.html
I am working on the 6.0.20 ebuild, these patches will be incorporated. -weisso
CVE-2009-0033 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0033): Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, and 6.0.0 through 6.0.18, when the Java AJP connector and mod_jk load balancing are used, allows remote attackers to cause a denial of service (application outage) via a crafted request with invalid headers, related to temporary blocking of connectors that have encountered errors, as demonstrated by an error involving a malformed HTTP Host header. CVE-2009-0580 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0580): Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, and 6.0.0 through 6.0.18, when FORM authentication is used, allows remote attackers to enumerate valid usernames via requests to /j_security_check with malformed URL encoding of passwords, related to improper error checking in the (1) MemoryRealm, (2) DataSourceRealm, and (3) JDBCRealm authentication realms, as demonstrated by a % (percent) value for the j_password parameter. CVE-2009-0783 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0783): Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, and 6.0.0 through 6.0.18 permits web applications to replace an XML parser used for other web applications, which allows local users to read or modify the (1) web.xml, (2) context.xml, or (3) tld files of arbitrary web applications via a crafted application that is loaded earlier than the target application.
CVE-2008-5515 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-5515): Apache Tomcat 4.1.0 through 4.1.39, 5.5.0 through 5.5.27, 6.0.0 through 6.0.18, and possibly earlier versions normalizes the target pathname before filtering the query string when using the RequestDispatcher method, which allows remote attackers to bypass intended access restrictions and conduct directory traversal attacks via .. (dot dot) sequences and the WEB-INF directory in a Request.
Arches please test 6.0.20.
is that a request to test and mark stable?
It is now.
Arches, please test and mark stable: =www-servers/tomcat-6.0.20 Target keywords : "amd64 ppc ppc64 x86"
x86 stable
ppc64 done
ppc done
amd64 done. Java team: Ping wrt 5.x and please remove the vulnerable 6.x versions.
(In reply to comment #13) > amd64 done. > > Java team: Ping wrt 5.x and please remove the vulnerable 6.x versions. > I have removed the 6.0.* version and am currently attempting to contact weisso (tomcat maintainer) to see whether we wish to continue maintaining the 5.5 slot.
(In reply to comment #14) > (In reply to comment #13) > > amd64 done. > > > > Java team: Ping wrt 5.x and please remove the vulnerable 6.x versions. > > > > I have removed the 6.0.* version and am currently attempting to contact weisso > (tomcat maintainer) to see whether we wish to continue maintaining the 5.5 > slot. > Yes, i want to keep 5.5 it is still widely used and fully supported by upstream. They are in the process of bumping 5.5 to fix the security issues.
5.5.28 is available, are you going to bump?
The 5.5 release is up to 5.5.31 now, with a number of fixes over the 5.5.27 currently in portage. Any further thoughts on a rev bump? I tried my hand at a 5.5.31 ebuild myself, but no luck. I ported the main_tomcat_catalina_jasper_build_xml.patch to apply to the new version, the only other change required was getting rid of the examples-cal.patch as it's already fixed in 5.5.31. The compile failed though: BUILD FAILED /var/tmp/portage/www-servers/tomcat-5.5.31/work/apache-tomcat-5.5.31-src/build.xml:49: The following error occurred while executing this line: /var/tmp/portage/www-servers/tomcat-5.5.31/work/apache-tomcat-5.5.31-src/build/build.xml:520: The following error occurred while executing this line: /var/tmp/portage/www-servers/tomcat-5.5.31/work/apache-tomcat-5.5.31-src/build/build.xml:477: The following error occurred while executing this line: /var/tmp/portage/www-servers/tomcat-5.5.31/work/apache-tomcat-5.5.31-src/container/catalina/build.xml:455: Warning: Could not find file /var/tmp/portage/www-servers/tomcat-5.5.31/temp/commons-launcher/bin/LauncherBootstrap.class to copy. I messed with it for a while but my java-fu isn't too high and I didn't figure out what was going on. I could attach the updated patch if anybody wants to look at it. I really didn't want to deploy .27 as is, so I ended up backporting the security fixes for CVE-2008-5515 and CVE-2010-2227 and making a local 27-r5 ebuild instead. The 5.5 release is still considered production by upstream, and there are still apps that require it :(, such as the one I'm deploying. It would be nice to have the current version in portage. Thanks...
Please attach your patch(es), so that others might benefit as well! :)
Created attachment 251387 [details, diff] Patch 1 of 2 to fix CVE-2008-5515 in tomcat 5.5.27
Created attachment 251389 [details, diff] Patch 2 of 2 to fix CVE-2008-5515 in tomcat 5.5.27
Created attachment 251391 [details, diff] Patch to fix CVE-2010-2227 in tomcat 5.5.27
Created attachment 251393 [details] new tomcat 5.5.27 ebuild that applies CVE patches
Created attachment 251395 [details, diff] First run at converting 5.5.27 ebuild patch to apply to 5.5.31
Ok, I attached three patches that fix two of the security issues with tomcat 5.5.27 and a new ebuild that applies them. There are a number of other issues with 5.5.27, I only fixed the major ones applicable to my deployment. It would be much better to upgrade to 5.5.31; I attached my initial run at converting the 5.5.27 ebuild patch to 5.5.31, it applies but tomcat fails to build...
*Ping* to Java herd.
we have 5.5.27-r4 and 6.0.26 stable, so it's probably fixed now.
5.5 should be removed from tree, period. I specifically got involved with Gentoo many years ago to get 5.5 into the tree. Its way past time for it to be removed! 4.x is not in tree, therefore 5.x need not be either. 6.x and 7.x are, and that should be enough. If not, might consider running something other than Gentoo. Not sure when Gentoo became Debian and others. Keeping old stuff around for years, because people do not want to update apps. No app in tree requires 5.5, thus its purpose for remaining? Can go to sunrise or else where, I don't care, just leave developers along, enough security crap with 5.x, etc. If users really want it, let them deal with it all. I have long moved past it, and suggest other do the same ASAP!
Don't hold back, tell us what you really think ;). 4.x is no longer supported upstream, whereas 5.5 is still actively maintained, so that's not really a valid comparison. There's a third-party web app I need to deploy which only supports tomcat 5.5. My entire infrastructure is gentoo based, why would I want to run something else just for that one app? I wouldn't think tomcat is in portage solely as a dependency, any more than Apache is in portage solely to support in-tree webapps. It's an application in its own right, its purpose for remaining is to be available for Gentoo users who want/need to use it. Obviously gentoo is an "interest level support" distribution, if no dev has sufficient interest to maintain something, it stagnates or gets dropped from the tree. If that's what happens in this case, then that's what happens; on the other hand, if someone finds the interest to do a version bump on an actively maintained and used piece of software, that would as always be greatly appreciated. Clearly you've moved on past 5.5, more power to you, I wish the vendor of the web app I need to deploy would do the same; but I'm not sure why you're so vehement about it not being available for others to use.
(In reply to comment #28) > > 4.x is no longer supported upstream, whereas 5.5 is still actively maintained, > so that's not really a valid comparison. Thankfully they dropped 4.x, and I stand corrected there. However 4.x remained supported for quite some time, while not in portage. For a long time there was 5.x and 5.5.x, and then just 5.5.x. Till 6 came along and that got put in tree. I would have looked to removed 5.5 several years ago. > There's a third-party web app I need to deploy which only supports tomcat 5.5. Not sure what to tell you, have you tried to deploy it on 5.5? They should be looking to move on because at some point upstream (tomcat proj) will drop support for 5.5.x. > My entire infrastructure is gentoo based, why would I want to run something > else just for that one app? I wouldn't think tomcat is in portage solely as a > dependency, any more than Apache is in portage solely to support in-tree > webapps. It's an application in its own right, its purpose for remaining is to > be available for Gentoo users who want/need to use it. Point of the dependency aspect is nothing in tree relies on 5.5. Therefore it can be moved to an overlay and reside else where for those that must have it. While not holding back Gentoo itself. > Obviously gentoo is an "interest level support" distribution, if no dev has > sufficient interest to maintain something, it stagnates or gets dropped from > the tree. If that's what happens in this case, then that's what happens; That is what has been going on, no tomcat maintainer since I left. Now I am returning, hoped others would have filled the void. But that has not happened. on the > other hand, if someone finds the interest to do a version bump on an actively > maintained and used piece of software, that would as always be greatly > appreciated. That is what I did before and will be doing again, and will only be supporting 2 versions at best. > Clearly you've moved on past 5.5, more power to you, I wish the > vendor of the web app I need to deploy would do the same; but I'm not sure why > you're so vehement about it not being available for others to use. I moved passed 5.5 when 6.x came out, and now I am on 7.x which is why its in tree. I have no time or interest in messing with anything related to 5.5. That is why I want it gone, and I would have removed it long ago. Its been way to much of a headache to deal with compared to other versions of Tomcat. Not to mention relies on older stuff, and that keeps other crusty stuff in tree. Just keeps to much old stuff around and that is not Gentoo. If it really becomes and issue with users, I might look to punt 6.x as well ;) But really worse case they go to java-overlay, java-junkyard/graveyard or sunrise. Users want it that bad, let them deal with the older stuff, and headaches. I rather spend my time else where, moving forward, not backward or standing still.
(In reply to comment #28) > Obviously gentoo is an "interest level support" distribution, if no dev has > sufficient interest to maintain something, it stagnates or gets dropped from > the tree. Yes, just add user in there. There is nothing stopping users from maintaining tomcat-5.5 and i'm sure that gentoo would be able to facilitate that in some way. Aka, advice, hosting of overlays, etc, etc, etc
I'm sure you'll drop 6.x the day the stupid vendor finally supports it ;). I've already pounded on them on the issue; they actually bundle tomcat 5.5.23 with their product 8-/, so they're not exactly Johnny on the spot on updating <sigh>. I haven't actually tried running the webapp under 6.x, but it is documented as being incompatible and lists particular features that break. I tried porting the patch to 5.5.31 myself, I got it to apply cleanly, but then tomcat doesn't build :(, and I'm not sure exactly why. Maybe I'll take another run at it, but not being a java guy it takes a lot of time to try to come up to speed.
(In reply to comment #31) > I'm sure you'll drop 6.x the day the stupid vendor finally supports it ;). I've > already pounded on them on the issue; they actually bundle tomcat 5.5.23 with > their product 8-/, so they're not exactly Johnny on the spot on updating > <sigh>. I haven't actually tried running the webapp under 6.x, but it is > documented as being incompatible and lists particular features that break. Well the vendor should be looking to support 7.0.x not 6.0.x at this point. But I do not plan to remove 6.0.x till 8.0.x is released. Unless its feasible to do such sooner and/or maintaining 6.0.x becomes cumbersome as maintaining 5.5.x has become. I would suggest doing what you can to get the app running in newer versions. Providing information to the vendor. Look for any work arounds, fixes, etc. > I tried porting the patch to 5.5.31 myself, I got it to apply cleanly, but then > tomcat doesn't build :(, and I'm not sure exactly why. Maybe I'll take another > run at it, but not being a java guy it takes a lot of time to try to come up to > speed. If/when I have time I will take a look. But I have a whole slew of bugs to close for 6.0.x and 7.0.x. Which are more of a priority and concern to me than anything with 5.5.x. Likely end up helping out there, once its out of the tree and in an overlay users can maintain.
tomcat 5.5.x has been removed from the main tree because it's heading its eol in 2012-09-30 and it's unmaintained on our side (all the effort goes to 6.x and 7.x releases). tomcat 5.5.x has been moved to java-overlay for those that still need it.
no affected version in the tree anymore
This issue was resolved and addressed in GLSA 201206-24 at http://security.gentoo.org/glsa/glsa-201206-24.xml by GLSA coordinator Tobias Heinlein (keytoaster).
