CVE-2016-0762 Apache Tomcat Realm Timing Attack CVE-2016-5018 Apache Tomcat Security Manager Bypass CVE-2016-6794 Apache Tomcat System Property Disclosure CVE-2016-6796 Apache Tomcat Security Manager Bypass CVE-2016-6797 Apache Tomcat Unrestricted Access to Global Resources Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.0.M9 Apache Tomcat 8.5.0 to 8.5.4 Apache Tomcat 8.0.0.RC1 to 8.0.36 Apache Tomcat 7.0.0 to 7.0.70 Apache Tomcat 6.0.0 to 6.0.45 Earlier, unsupported versions may also be affected. bility harder. Mitigation: Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 9.0.0.M10 or later - Upgrade to Apache Tomcat 8.5.5 or later - Upgrade to Apache Tomcat 8.0.37 or later - Upgrade to Apache Tomcat 7.0.72 or later (Apache Tomcat 7.0.71 has the fix but was not released) - Upgrade to Apache Tomcat 6.0.47 or later (Apache Tomcat 6.0.46 has the fix but was not released)
@ Maintainer(s): Please tell us, - Will you add >=www-servers/tomcat-7.0.72 to tree or is this version EOL? - Can we start stabilization of =www-servers/tomcat-8.0.38 and =www-servers/tomcat-8.5.6?
Adding additional vulnerabilities reported last week: CVE-2016-6817 Apache Tomcat Information Disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.0.M11 Apache Tomcat 8.5.0 to 8.5.6 Earlier versions are not affected. Description The HTTP/2 header parser entered an infinite loop if a header was received that was larger than the available buffer. This made a denial of service attack possible. Mitigation Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 9.0.0.M13 or later (Apache Tomcat 9.0.0.M12 has the fix but was not released) - Upgrade to Apache Tomcat 8.5.8 or later (Apache Tomcat 8.5.7 has the fix but was not released) Credit: This issue was reported as a bug and the security implications identified by the Apache Tomcat Security Team. References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html CVE-2016-8735 Apache Tomcat Remote Code Execution Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.0.M11 Apache Tomcat 8.5.0 to 8.5.6 Apache Tomcat 8.0.0.RC1 to 8.0.38 Apache Tomcat 7.0.0 to 7.0.72 Apache Tomcat 6.0.0 to 6.0.47 Earlier, unsupported versions may also be affected. Description The JmxRemoteLifecycleListener was not updated to take account of Oracle's fix for CVE-2016-3427. Therefore, Tomcat installations using this listener remained vulnerable to a similar remote code execution vulnerability. This issue has been rated as important rather than critical due to the small number of installations using this listener and that it would be highly unusual for the JMX ports to be accessible to an attacker even when the listener is used. Mitigation Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 9.0.0.M13 or later (Apache Tomcat 9.0.0.M12 has the fix but was not released) - Upgrade to Apache Tomcat 8.5.8 or later (Apache Tomcat 8.5.7 has the fix but was not released) - Upgrade to Apache Tomcat 8.0.39 or later - Upgrade to Apache Tomcat 7.0.73 or later - Upgrade to Apache Tomcat 6.0.48 or later Credit: This issue was discovered by Pierre Ernst and reported responsibly to the Apache Tomcat Security Team. References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html [3] http://tomcat.apache.org/security-7.html [4] http://tomcat.apache.org/security-6.html CVE-2016-6816 Apache Tomcat Information Disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.0.M11 Apache Tomcat 8.5.0 to 8.5.6 Apache Tomcat 8.0.0.RC1 to 8.0.38 Apache Tomcat 7.0.0 to 7.0.72 Apache Tomcat 6.0.0 to 6.0.47 Earlier, unsupported versions may also be affected. Description The code that parsed the HTTP request line permitted invalid characters. This could be exploited, in conjunction with a proxy that also permitted the invalid characters but with a different interpretation, to inject data into the HTTP response. By manipulating the HTTP response the attacker could poison a web-cache, perform an XSS attack and/or obtain sensitive information from requests other then their own. Mitigation Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 9.0.0.M13 or later (Apache Tomcat 9.0.0.M12 has the fix but was not released) - Upgrade to Apache Tomcat 8.5.8 or later (Apache Tomcat 8.5.7 has the fix but was not released) - Upgrade to Apache Tomcat 8.0.39 or later - Upgrade to Apache Tomcat 7.0.73 or later - Upgrade to Apache Tomcat 6.0.48 or later Credit: This issue was discovered by Regis Leroy from Makina Corpus. References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html [3] http://tomcat.apache.org/security-7.html [4] http://tomcat.apache.org/security-6.html
i just bumped tomcat to these versions: - 7.0.73 - 8.5.9 - 9.0.0.M15 i think we can start the stabilization process to avoid the affected versions and remove the older affected versions.
@ Arches, please test and mark stable: =www-servers/tomcat-7.0.73 =www-servers/tomcat-8.0.39 (no ppc64) =www-servers/tomcat-8.5.9 (no ppc64)
(In reply to Thomas Deutschmann from comment #4) > @ Arches, > > please test and mark stable: > > =www-servers/tomcat-7.0.73 > =www-servers/tomcat-8.0.39 (no ppc64) > =www-servers/tomcat-8.5.9 (no ppc64) Since www-servers/tomcat:8.5 is not stable, it will not stabilized as part of this bug.
amd64 stable
x86 stable
i cleaned up the old versions so that this is what we are left now with: $ PORTDIR=/usr/src/gentoo.git/ equery meta tomcat * www-servers/tomcat [gentoo] Maintainer: java@gentoo.org (Java) Upstream: None specified Homepage: http://tomcat.apache.org/ Location: /usr/src/gentoo.git/www-servers/tomcat Keywords: 7.0.73:7: amd64 x86 ~amd64-linux ~ppc64 ~x86-freebsd ~x86-linux ~x86-solaris Keywords: 8.0.39:8: amd64 x86 ~amd64-linux ~x86-fbsd ~x86-freebsd ~x86-linux ~x86-solaris Keywords: 8.5.9:8.5: ~amd64 ~amd64-linux ~x86 ~x86-fbsd ~x86-freebsd ~x86-linux ~x86-solaris Keywords: 9.0.0_alpha15:9: ~amd64 ~amd64-linux ~x86 ~x86-fbsd ~x86-freebsd ~x86-linux ~x86-solaris License: Apache-2.0
(In reply to Miroslav Šulc from comment #8) > i cleaned up the old versions so that this is what we are left now with: > > $ PORTDIR=/usr/src/gentoo.git/ equery meta tomcat > * www-servers/tomcat [gentoo] > Maintainer: java@gentoo.org (Java) > Upstream: None specified > Homepage: http://tomcat.apache.org/ > Location: /usr/src/gentoo.git/www-servers/tomcat > Keywords: 7.0.73:7: amd64 x86 ~amd64-linux ~ppc64 ~x86-freebsd ~x86-linux > ~x86-solaris > Keywords: 8.0.39:8: amd64 x86 ~amd64-linux ~x86-fbsd ~x86-freebsd > ~x86-linux ~x86-solaris > Keywords: 8.5.9:8.5: ~amd64 ~amd64-linux ~x86 ~x86-fbsd ~x86-freebsd > ~x86-linux ~x86-solaris > Keywords: 9.0.0_alpha15:9: ~amd64 ~amd64-linux ~x86 ~x86-fbsd > ~x86-freebsd ~x86-linux ~x86-solaris > License: Apache-2.0 Did you intend to drop PPC64 keyword?
(In reply to Aaron Bauman from comment #9) > (In reply to Miroslav Šulc from comment #8) > > i cleaned up the old versions so that this is what we are left now with: > > > > $ PORTDIR=/usr/src/gentoo.git/ equery meta tomcat > > * www-servers/tomcat [gentoo] > > Maintainer: java@gentoo.org (Java) > > Upstream: None specified > > Homepage: http://tomcat.apache.org/ > > Location: /usr/src/gentoo.git/www-servers/tomcat > > Keywords: 7.0.73:7: amd64 x86 ~amd64-linux ~ppc64 ~x86-freebsd ~x86-linux > > ~x86-solaris > > Keywords: 8.0.39:8: amd64 x86 ~amd64-linux ~x86-fbsd ~x86-freebsd > > ~x86-linux ~x86-solaris > > Keywords: 8.5.9:8.5: ~amd64 ~amd64-linux ~x86 ~x86-fbsd ~x86-freebsd > > ~x86-linux ~x86-solaris > > Keywords: 9.0.0_alpha15:9: ~amd64 ~amd64-linux ~x86 ~x86-fbsd > > ~x86-freebsd ~x86-linux ~x86-solaris > > License: Apache-2.0 > > Did you intend to drop PPC64 keyword? yes, that was on purpose as there is no manforce to test and stabilize tomcat on ppc64. i requested that in the past few times but without any result in the last months (years?). it can be re-introduced to tomcat if there is really any use for it.
(In reply to Miroslav Šulc from comment #10) > (In reply to Aaron Bauman from comment #9) > > Did you intend to drop PPC64 keyword? > > yes, that was on purpose as there is no manforce to test and stabilize > tomcat on ppc64. i requested that in the past few times but without any > result in the last months (years?). it can be re-introduced to tomcat if > there is really any use for it. I'm afraid the tree is still slightly broken. https://qa-reports.gentoo.org/output/gentoo-ci/b88d7c818/output.html#dev-java/portletapi
(In reply to James Le Cuirot from comment #11) > (In reply to Miroslav Šulc from comment #10) > > (In reply to Aaron Bauman from comment #9) > > > Did you intend to drop PPC64 keyword? > > > > yes, that was on purpose as there is no manforce to test and stabilize > > tomcat on ppc64. i requested that in the past few times but without any > > result in the last months (years?). it can be re-introduced to tomcat if > > there is really any use for it. > > I'm afraid the tree is still slightly broken. > > https://qa-reports.gentoo.org/output/gentoo-ci/b88d7c818/output.html#dev- > java/portletapi i'm trying to contact ago to discuss with him what would be better, whether dropping ppc64 from portletapi and commons-fileupload (no ebuild that depends on these has ppc64 arch keyword) or we add ppc64 to tomcat-servlet-api:3.0.
