Tomcat 7.0.54 has been released on May 22, fixing one security issue. Tomcat 7.0.53 also fixed three other security issues. All four of these issues have been made public today: http://tomcat.apache.org/security-7.html Mageia 3 and Mageia 4 are also affected. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
I imagine we'll also want to sync the last few commits from Fedora: http://pkgs.fedoraproject.org/cgit/tomcat.git/log/
In Mageia 3, these issues also affect tomcat6 and were fixed in 6.0.41: http://tomcat.apache.org/security-6.html
Summary: tomcat (tomcat7) new security issues CVE-2014-0075, CVE-2014-0096, CVE-2014-0099, CVE-2014-0119 => tomcat (tomcat7) and tomcat6 new security issues CVE-2014-0075, CVE-2014-0096, CVE-2014-0099, CVE-2014-0119
I've synced the latest SPEC changes from Fedora into mga3/mga4/cauldron SVN. I tried building 7.0.54 locally, but unfortunately it does not build. On Mageia 3, building 6.0.41 locally was successful, so I've checked that into Mageia 3 SVN.
Tomcat 7.0.54 apparently only builds with Java 8. Upstream doesn't seem to care. I found a patch on an upstream bug that fixes this: https://issues.apache.org/bugzilla/show_bug.cgi?id=56373
Updated packages uploaded for Mageia 3, Mageia 4, and Cauldron. Advisory: ======================== Updated tomcat and tomcat6 packages fix security vulnerabilities: Integer overflow in the parseChunkHeader function in java/org/apache/coyote/http11/filters/ChunkedInputFilter.java in Apache Tomcat before 6.0.40 and 7.x before 7.0.53 allows remote attackers to cause a denial of service (resource consumption) via a malformed chunk size in chunked transfer coding of a request during the streaming of data (CVE-2014-0075). java/org/apache/catalina/servlets/DefaultServlet.java in the default servlet in Apache Tomcat before 6.0.40 and 7.x before 7.0.53 does not properly restrict XSLT stylesheets, which allows remote attackers to bypass security-manager restrictions and read arbitrary files via a crafted web application that provides an XML external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue (CVE-2014-0096). Integer overflow in java/org/apache/tomcat/util/buf/Ascii.java in Apache Tomcat before 6.0.40 and 7.x before 7.0.53, when operated behind a reverse proxy, allows remote attackers to conduct HTTP request smuggling attacks via a crafted Content-Length HTTP header (CVE-2014-0099). Apache Tomcat before 6.0.40 and 7.x before 7.0.54 does not properly constrain the class loader that accesses the XML parser used with an XSLT stylesheet, which allows remote attackers to read arbitrary files via a crafted web application that provides an XML external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue, or read files associated with different web applications on a single Tomcat instance via a crafted web application (CVE-2014-0119). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0075 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0096 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0099 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0119 http://tomcat.apache.org/security-6.html http://tomcat.apache.org/security-7.html ======================== Updated packages in core/updates_testing: ======================== tomcat6-6.0.41-1.mga3 tomcat6-admin-webapps-6.0.41-1.mga3 tomcat6-docs-webapp-6.0.41-1.mga3 tomcat6-javadoc-6.0.41-1.mga3 tomcat6-systemv-6.0.41-1.mga3 tomcat6-jsp-2.1-api-6.0.41-1.mga3 tomcat6-lib-6.0.41-1.mga3 tomcat6-servlet-2.5-api-6.0.41-1.mga3 tomcat6-el-2.1-api-6.0.41-1.mga3 tomcat6-webapps-6.0.41-1.mga3 tomcat-7.0.54-1.mga3 tomcat-admin-webapps-7.0.54-1.mga3 tomcat-docs-webapp-7.0.54-1.mga3 tomcat-javadoc-7.0.54-1.mga3 tomcat-jsvc-7.0.54-1.mga3 tomcat-jsp-2.2-api-7.0.54-1.mga3 tomcat-log4j-7.0.54-1.mga3 tomcat-lib-7.0.54-1.mga3 tomcat-servlet-3.0-api-7.0.54-1.mga3 tomcat-el-2.2-api-7.0.54-1.mga3 tomcat-webapps-7.0.54-1.mga3 tomcat-7.0.54-1.mga4 tomcat-admin-webapps-7.0.54-1.mga4 tomcat-docs-webapp-7.0.54-1.mga4 tomcat-javadoc-7.0.54-1.mga4 tomcat-jsvc-7.0.54-1.mga4 tomcat-jsp-2.2-api-7.0.54-1.mga4 tomcat-log4j-7.0.54-1.mga4 tomcat-lib-7.0.54-1.mga4 tomcat-servlet-3.0-api-7.0.54-1.mga4 tomcat-el-2.2-api-7.0.54-1.mga4 tomcat-webapps-7.0.54-1.mga4 from SRPMS: tomcat6-6.0.41-1.mga3.src.rpm tomcat-7.0.54-1.mga3.src.rpm tomcat-7.0.54-1.mga4.src.rpm
CC: (none) => dmorganecVersion: Cauldron => 4Assignee: dmorganec => qa-bugsWhiteboard: MGA4TOO, MGA3TOO => MGA3TOO
Testing procedure: https://bugs.mageia.org/show_bug.cgi?id=8307#c17
Whiteboard: MGA3TOO => MGA3TOO has_procedure
Tested successfully tomcat on Mageia 4 and tomcat6 and tomcat on Mageia 3 using Claire's testing procedure. Tested on i586 VMWare VMs.
Claire gave me the OK to add the whiteboard marker. Adding now.
Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure MGA3-32-OK MGA4-32-OK
Testing complete mga4 64
Whiteboard: MGA3TOO has_procedure MGA3-32-OK MGA4-32-OK => MGA3TOO has_procedure MGA3-32-OK MGA4-32-OK mga4-64-ok
Testing complete mga3 64
Whiteboard: MGA3TOO has_procedure MGA3-32-OK MGA4-32-OK mga4-64-ok => MGA3TOO has_procedure MGA3-32-OK mga3-64-ok MGA4-32-OK mga4-64-ok
Validating update. Advisory has been uploaded. Please push tomcat6 and tomcat to 3 core/updates and tomcat to 4 core/updates.
Keywords: (none) => validated_updateWhiteboard: MGA3TOO has_procedure MGA3-32-OK mga3-64-ok MGA4-32-OK mga4-64-ok => MGA3TOO has_procedure MGA3-32-OK mga3-64-ok MGA4-32-OK mga4-64-ok advisoryCC: (none) => remi, sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGASA-2014-0268.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
Trying to upgrade my mga3 x86 box gives the following: The following packages have to be removed for others to be upgraded: eclipse-platform-4.2.1-8.mga3.i586 (due to unsatisfied glassfish-jsp-api >= 2.2.1, due to unsatisfied glassfish-jsp >= 2.2.5) freemind-0.9.0-4.mga3.noarch (due to missing groovy) glassfish-jsp-2.2.6-2.mga3.noarch (due to missing mvn(javax.el:javax.el-api)) glassfish-jsp-api-2.2.1-3.mga3.noarch (due to missing mvn(javax.el:javax.el-api)) groovy-1.8.7-2.mga3.noarch (due to missing jansi) hawtjni-1.6-1.mga3.noarch (due to missing xbean) jansi-1.6-2.mga3.noarch (due to missing hawtjni, due to missing jansi-native) jansi-native-1.4-1.mga3.i586 (due to missing hawtjni) xbean-3.11.1-2.mga3.noarch (due to missing eclipse-rcp) (y/N) y To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Updates") tomcat-el-2.2-api 7.0.54 1.mga3 noarch tomcat-jsp-2.2-api 7.0.54 1.mga3 noarch tomcat-servlet-3.0-api 7.0.54 1.mga3 noarch tomcat6-servlet-2.5-api 6.0.41 1.mga3 noarch 61MB of disk space will be freed. 482KB of packages will be retrieved. Oddly, glassfish-jsp-2.2.6-2.mga3.noarch requires an unversioned mvn(javax.el:javax.el-api) but tomcat-el-2.2-api provides four versions of that dependency, so I'm not quite sure what's up.
Status: RESOLVED => REOPENEDCC: (none) => danResolution: FIXED => (none)
The security issues are fixed, so please open a new report for this. Unfortunately, there's probably not a whole lot we can do. We just sync our java stuff from Fedora. Would this issue affect them? They only have 7.0.54 in Rawhide currently, they haven't fixed the latest security issues in stable releases yet.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
(In reply to David Walser from comment #14) > The security issues are fixed, so please open a new report for this. Not really as the updates can't be installed for many users of it. (In reply to Dan Fandrich from comment #13) > Oddly, glassfish-jsp-2.2.6-2.mga3.noarch requires an unversioned > mvn(javax.el:javax.el-api) but tomcat-el-2.2-api provides four versions of > that dependency, so I'm not quite sure what's up. Hmm I don't see such provides: $ rpm -qp --provides 3/i586/media/core/updates/tomcat-el-2.2-api-7.0.54-1.mga3.noarch.rpm el_1_0_api = 0:7.0.54-1.mga3 el_api = 2.2 tomcat-el-2.2-api = 0:7.0.54-1.mga3 osgi(javax.el) = 2.2.0 mvn(org.apache.tomcat:tomcat-el-api) = 7.0.54 mvn(org.eclipse.jetty.orbit:javax.el) = 7.0.54 Possibly related: http://pkgs.fedoraproject.org/cgit/glassfish-el-api.git/commit/?id=12a53d450a54a48a9f4b57db06851e2e71e63ef8
CC: (none) => pterjan
(In reply to Pascal Terjan from comment #15) > (In reply to David Walser from comment #14) > > The security issues are fixed, so please open a new report for this. > > Not really as the updates can't be installed for many users of it. It can, you just have to uninstall those other packages or force it for now, but for tomcat itself, it installs perfectly fine. > (In reply to Dan Fandrich from comment #13) > > Oddly, glassfish-jsp-2.2.6-2.mga3.noarch requires an unversioned > > mvn(javax.el:javax.el-api) but tomcat-el-2.2-api provides four versions of > > that dependency, so I'm not quite sure what's up. > > Hmm I don't see such provides: > > $ rpm -qp --provides > 3/i586/media/core/updates/tomcat-el-2.2-api-7.0.54-1.mga3.noarch.rpm > el_1_0_api = 0:7.0.54-1.mga3 > el_api = 2.2 > tomcat-el-2.2-api = 0:7.0.54-1.mga3 > osgi(javax.el) = 2.2.0 > mvn(org.apache.tomcat:tomcat-el-api) = 7.0.54 > mvn(org.eclipse.jetty.orbit:javax.el) = 7.0.54 > > Possibly related: > http://pkgs.fedoraproject.org/cgit/glassfish-el-api.git/commit/ > ?id=12a53d450a54a48a9f4b57db06851e2e71e63ef8 So the dep problem may not even be in tomcat itself anyway.
(In reply to David Walser from comment #16) > (In reply to Pascal Terjan from comment #15) > > (In reply to David Walser from comment #14) > > > The security issues are fixed, so please open a new report for this. > > > > Not really as the updates can't be installed for many users of it. > > It can, you just have to uninstall those other packages or force it for now, > but for tomcat itself, it installs perfectly fine. But what's the use of tomcat on your server if you can't run your application anymore due to other commonly used java stuff being removed? > > (In reply to Dan Fandrich from comment #13) > > > Oddly, glassfish-jsp-2.2.6-2.mga3.noarch requires an unversioned > > > mvn(javax.el:javax.el-api) but tomcat-el-2.2-api provides four versions of > > > that dependency, so I'm not quite sure what's up. > > > > Hmm I don't see such provides: > > > > $ rpm -qp --provides > > 3/i586/media/core/updates/tomcat-el-2.2-api-7.0.54-1.mga3.noarch.rpm > > el_1_0_api = 0:7.0.54-1.mga3 > > el_api = 2.2 > > tomcat-el-2.2-api = 0:7.0.54-1.mga3 > > osgi(javax.el) = 2.2.0 > > mvn(org.apache.tomcat:tomcat-el-api) = 7.0.54 > > mvn(org.eclipse.jetty.orbit:javax.el) = 7.0.54 > > > > Possibly related: > > http://pkgs.fedoraproject.org/cgit/glassfish-el-api.git/commit/ > > ?id=12a53d450a54a48a9f4b57db06851e2e71e63ef8 > > So the dep problem may not even be in tomcat itself anyway. I understand it as tomcat used to have the el implementation but there is now a new implementation (glassfish-el) and Fedora decided to drop the provide so that people don't end up with both: http://pkgs.fedoraproject.org/cgit/tomcat.git/commit/tomcat.spec?id=7290014b82f31331b44e6483eeaeabf47e14536e Unfortunatly we don't have the other one, so we should probably revert that commit.
This is a pretty clear regression, so IMHO it is related to this security release bug. I was looking at the wrong version when I checked dependencies. tomcat-el-2.2-api-7.0.52-1.mga3 provides it, but tomcat-el-2.2-api-7.0.54-1.mga3 does not.
(In reply to Pascal Terjan from comment #17) > (In reply to David Walser from comment #16) > > It can, you just have to uninstall those other packages or force it for now, > > but for tomcat itself, it installs perfectly fine. > > But what's the use of tomcat on your server if you can't run your > application anymore due to other commonly used java stuff being removed? I won't pretend to know enough about tomcat to answer that, but what application are you talking about? The list of packages looks like a bunch of Java libraries. I guess if you had Eclipse installed, that'd get removed because of losing eclipse-platform, but first of all Eclipse is not a web application, and second of all, I don't know why that package requires some glassfish thing. If you download Eclipse from upstream, all it requires is a jre. That sounds like a packaging problem (outside of tomcat). > > > (In reply to Dan Fandrich from comment #13) > > > > Oddly, glassfish-jsp-2.2.6-2.mga3.noarch requires an unversioned > > > > mvn(javax.el:javax.el-api) but tomcat-el-2.2-api provides four versions of > > > > that dependency, so I'm not quite sure what's up. > > > > > > Hmm I don't see such provides: > > > > > > $ rpm -qp --provides > > > 3/i586/media/core/updates/tomcat-el-2.2-api-7.0.54-1.mga3.noarch.rpm > > > el_1_0_api = 0:7.0.54-1.mga3 > > > el_api = 2.2 > > > tomcat-el-2.2-api = 0:7.0.54-1.mga3 > > > osgi(javax.el) = 2.2.0 > > > mvn(org.apache.tomcat:tomcat-el-api) = 7.0.54 > > > mvn(org.eclipse.jetty.orbit:javax.el) = 7.0.54 > > > > > > Possibly related: > > > http://pkgs.fedoraproject.org/cgit/glassfish-el-api.git/commit/ > > > ?id=12a53d450a54a48a9f4b57db06851e2e71e63ef8 > > > > So the dep problem may not even be in tomcat itself anyway. > > I understand it as tomcat used to have the el implementation but there is > now a new implementation (glassfish-el) and Fedora decided to drop the > provide so that people don't end up with both: > > http://pkgs.fedoraproject.org/cgit/tomcat.git/commit/tomcat. > spec?id=7290014b82f31331b44e6483eeaeabf47e14536e > > Unfortunatly we don't have the other one, so we should probably revert that > commit. Thanks. We can try it.
(In reply to Dan Fandrich from comment #18) > This is a pretty clear regression, so IMHO it is related to this security > release bug. Please file a new bug. Pascal had some ideas, so we can try to fix the regression.
(In reply to David Walser from comment #19) > (In reply to Pascal Terjan from comment #17) > > (In reply to David Walser from comment #16) > > > It can, you just have to uninstall those other packages or force it for now, > > > but for tomcat itself, it installs perfectly fine. > > > > But what's the use of tomcat on your server if you can't run your > > application anymore due to other commonly used java stuff being removed? > > I won't pretend to know enough about tomcat to answer that, but what > application are you talking about? Well, tomcat is intended to run your java server applications. It's like saying that apache-php can be installed so this is fine even if some php-* commonly used need to be uninstalled (let's say php-mysql). Most sysadmins would have to refuse the update or their website would break. > The list of packages looks like a bunch > of Java libraries. I guess if you had Eclipse installed, that'd get removed > because of losing eclipse-platform, but first of all Eclipse is not a web > application, and second of all, I don't know why that package requires some > glassfish thing. If you download Eclipse from upstream, all it requires is > a jre. That sounds like a packaging problem (outside of tomcat). eclipse-platform is a set of frameworks to use in your applications and is not related to using eclipse. tomcat-el no longer provides the el api it implements, so is a bit useless as things requiring el through maven will not know it's installed.
(In reply to Pascal Terjan from comment #17) > http://pkgs.fedoraproject.org/cgit/tomcat.git/commit/tomcat. > spec?id=7290014b82f31331b44e6483eeaeabf47e14536e > > Unfortunatly we don't have the other one, so we should probably revert that > commit. Well, we sort of have: $ urpmq -i glassfish-el Name : glassfish-el Version : 2.2 Release : 2.mga3 Group : Development/Java Size : 157537 Architecture: noarch Source RPM : glassfish-el-2.2-2.mga3.src.rpm Build Host: ecosse.mageia.org $ urpmq --provides glassfish-el glassfish-el[== 2.2-2.mga3] osgi(org.glassfish.web.el-impl)[== 2.2.0] mvn(org.glassfish.web:el)[== 2.2] mvn(javax.el:el-api)[== 2.2] mvn(org.glassfish.web:el-impl)[== 2.2] So it only does miss the: PROVIDES mvn(javax.el:*javax*.el-api) but doing a change like this is not nice in a stable relases... And reading this: http://svnweb.mageia.org/packages?view=revision&revision=633154 I also see this: - Don't provide maven javax.jsp:jsp-api and javax.servlet.jsp:javax.servlet.jsp-api (rhbz#1076949) wich also is somewhat questionable for us in a stable release
Well maybe we should drop tomcat and not support it in future stable releases if we don't have any packagers who understand it enough and are responsive enough to actually take care of these updates.
yeah, just to make it clear... you David is doing a great job of trying to manage security updates whereas the maintainers does not care (or exist), so I'm not really blaming him for trying to track fedora ... it's just a fact that stuff like this can happend sometimes...
I've created bug #13571 as requested.
URL: (none) => http://lwn.net/Vulnerabilities/603529/