Bug 13442 - tomcat (tomcat7) and tomcat6 new security issues CVE-2014-0075, CVE-2014-0096, CVE-2014-0099, CVE-2014-0119
Summary: tomcat (tomcat7) and tomcat6 new security issues CVE-2014-0075, CVE-2014-0096...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 4
Hardware: i586 Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/603529/
Whiteboard: MGA3TOO has_procedure MGA3-32-OK mga3...
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2014-05-27 22:36 CEST by David Walser
Modified: 2014-06-25 22:38 CEST (History)
6 users (show)

See Also:
Source RPM: tomcat-7.0.52-1.mga4.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2014-05-27 22:36:58 CEST
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:
David Walser 2014-05-27 22:37:05 CEST

Whiteboard: (none) => MGA4TOO, MGA3TOO

Comment 1 David Walser 2014-05-27 22:40:59 CEST
I imagine we'll also want to sync the last few commits from Fedora:
http://pkgs.fedoraproject.org/cgit/tomcat.git/log/
Comment 2 David Walser 2014-05-27 22:42:11 CEST
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

Comment 3 David Walser 2014-06-04 21:55:46 CEST
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.
Comment 4 David Walser 2014-06-12 19:01:34 CEST
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
Comment 5 David Walser 2014-06-12 19:21:46 CEST
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) => dmorganec
Version: Cauldron => 4
Assignee: dmorganec => qa-bugs
Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO

Comment 6 David Walser 2014-06-17 17:50:46 CEST
Testing procedure:
https://bugs.mageia.org/show_bug.cgi?id=8307#c17

Whiteboard: MGA3TOO => MGA3TOO has_procedure

Comment 7 David Walser 2014-06-17 17:51:34 CEST
Tested successfully tomcat on Mageia 4 and tomcat6 and tomcat on Mageia 3 using Claire's testing procedure.  Tested on i586 VMWare VMs.
Comment 8 David Walser 2014-06-17 17:58:17 CEST
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

Comment 9 claire robinson 2014-06-19 10:30:08 CEST
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

Comment 10 claire robinson 2014-06-19 11:04:50 CEST
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

Comment 11 Rémi Verschelde 2014-06-19 19:15:58 CEST
Validating update. Advisory has been uploaded.

Please push tomcat6 and tomcat to 3 core/updates and tomcat to 4 core/updates.

Keywords: (none) => validated_update
Whiteboard: 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 advisory
CC: (none) => remi, sysadmin-bugs

Comment 12 Thomas Backlund 2014-06-19 22:39:45 CEST
Update pushed:
http://advisories.mageia.org/MGASA-2014-0268.html

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED

Comment 13 Dan Fandrich 2014-06-21 19:48:38 CEST
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 => REOPENED
CC: (none) => dan
Resolution: FIXED => (none)

Comment 14 David Walser 2014-06-21 19:51:55 CEST
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 => RESOLVED
Resolution: (none) => FIXED

Comment 15 Pascal Terjan 2014-06-21 20:12:53 CEST
(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

Comment 16 David Walser 2014-06-21 20:24:01 CEST
(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.
Comment 17 Pascal Terjan 2014-06-21 20:33:43 CEST
(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.
Comment 18 Dan Fandrich 2014-06-21 20:37:40 CEST
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.
Comment 19 David Walser 2014-06-21 20:41:44 CEST
(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.
Comment 20 David Walser 2014-06-21 20:43:48 CEST
(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.
Comment 21 Pascal Terjan 2014-06-21 21:04:19 CEST
(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.
Comment 22 Thomas Backlund 2014-06-21 21:09:49 CEST
(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
Comment 23 David Walser 2014-06-21 21:17:01 CEST
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.
Comment 24 Thomas Backlund 2014-06-21 21:19:43 CEST
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...
Comment 25 Dan Fandrich 2014-06-22 00:26:42 CEST
I've created bug #13571 as requested.
David Walser 2014-06-25 22:38:59 CEST

URL: (none) => http://lwn.net/Vulnerabilities/603529/


Note You need to log in before you can comment on or make changes to this bug.