| Summary: | <www-servers/tomcat-{5.5.32,6.0.32-r1,7.0.8}: Multiple Vulnerabilities (CVE-2010-{1157,2227,4172},CVE-2011-{0013,0534}) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Stefan Behte (RETIRED) <craig> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | henson, java, mike |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://svn.apache.org/viewvc?view=revision&revision=959428 | ||
| Whiteboard: | B3 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 354447 | ||
| Bug Blocks: | 272566, 273662, 322979 | ||
|
Description
Stefan Behte (RETIRED)
2010-07-26 15:34:05 UTC
6.0.28 also fixes this issue: Low: Information disclosure in authentication headers CVE-2010-1157 The WWW-Authenticate HTTP header for BASIC and DIGEST authentication includes a realm name. If a <realm-name> element is specified for the application in web.xml it will be used. However, a <realm-name> is not specified then Tomcat will generate realm name using the code snippet request.getServerName() + ":" + request.getServerPort(). In some circumstances this can expose the local host name or IP address of the machine running Tomcat.This was fixed in revision 936540. 6.0.30 will fix this issue: moderate: Cross-site scripting CVE-2010-4172 The Manager application used the user provided parameters sort and orderBy directly without filtering thereby permitting cross-site scripting. This was fixed in revision 1037779. http://tomcat.apache.org/security-6.html (In reply to comment #1) > > 6.0.30 will fix this issue: > 6.0.30 has been released. http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.30 CVE-2010-4172 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-4172): Multiple cross-site scripting (XSS) vulnerabilities in the Manager application in Apache Tomcat 6.0.12 through 6.0.29 and 7.0.0 through 7.0.4 allow remote attackers to inject arbitrary web script or HTML via the (1) orderBy or (2) sort parameter to sessionsList.jsp, or unspecified input to (3) sessionDetail.jsp or (4) java/org/apache/catalina/manager/JspHelper.java, related to use of untrusted web applications. Tomcat 6.0.32 has been released now that fixes another remote DoS vulnerability. http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.32 *** Bug 354081 has been marked as a duplicate of this bug. *** *** Bug 320963 has been marked as a duplicate of this bug. *** tomcat 5.5.32 is the most recent version in the 5.5 train, any chance of getting an ebuild for that? I understand there's not too much interest in the 5.5 branch, but it's still considered production upstream and there are still webapps which don't work with 6 or 7 :(... Thanks... i bumped tomcat to 6.0.32 and 7.0.8. 5.5.32 fails to apply quite huge patch so it needs more time to bump that one which i do not have atm. (In reply to comment #8) > i bumped tomcat to 6.0.32 and 7.0.8. 5.5.32 fails to apply quite huge patch so > it needs more time to bump that one which i do not have atm. > Great, thank you. Should we stabilize 6.0.32 now? Or would you prefer to wait until 5.5.32 is ready as well? Thanks again. well, i would not wait for 5.5.32 for sure as it might take quite long till someone else or me package it. wrt 6.0.32, there was a change in jdt stuff. in 6.0.29, there was extra build target for building jdt support but it's not in 6.0.32 anymore: "Switch to using the Eclipse compiler JAR directly rather than creating it from the larger JDT download. (markt)" so in other words, there is a risk this change might break something. i guess this is related to compilation of jsp but i am not really sure. it would be best if someone with more experience could test it before it goes stable. Thanks for looking at 5.5.32; I tried to port the patch to 5.5.31 (as attached to bug #272566), but while I got the patch to apply, tomcat then failed to build :(, which left me at a bit of a loss. I don't know if my initial attempt at the patch would be more of a help or hindrance ;), but you could find it on bug #272566. Thanks again... as written in bug #354447, i just committed tomcat-6.0.32-r1. as the reporter wrote, this one fixes the JSP compilation issue. i also used that version for one night while coding and it was working fine so imo it's safe to stabilize it. as for 5.5.32, i will try to ask wltjr who used to be tomcat maintainer if he could have a look at it. he might fix it pretty fast in case he still remembers the reasons for the patch. Thanks, folks. If I understand correctly, we're good to stabilize =www-servers/tomcat-6.0.32-r1. So... Arches, please test and mark stable: =www-servers/tomcat-6.0.32-r1 Target keywords : "amd64 ppc ppc64 x86" ppc/ppc64 stable x86 stable amd64 done Thanks, everyone. From a security perspective, this bug is nearly complete except for possible publication of a GLSA. I have opened bug 354741 to track the stabilization of tomcat 5.5.32. GLSA Vote: Yes. GLSA vote: YES, request filed. 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). |