Bug 5261 - tomcat6 security issues CVE-2011-3375, CVE-2011-4858, and CVE-2012-0022
: tomcat6 security issues CVE-2011-3375, CVE-2011-4858, and CVE-2012-0022
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 2
: All Linux
: Normal Severity: normal
: ---
Assigned To: QA Team
:
:
: MGA1TOO has_procedure mga1-32-OK mga2...
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2012-04-06 18:43 CEST by David Walser
Modified: 2012-08-02 20:55 CEST (History)
7 users (show)

See Also:
Source RPM: tomcat6-6.0.32-3.mga1.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2012-04-06 18:43:49 CEST
Ubuntu has issued this advisory on February 13:
http://www.ubuntu.com/usn/usn-1359-1/

Cauldron is also affected.
Comment 1 David Walser 2012-04-06 18:51:36 CEST
Here is a Debian advisory from February 2 for tomcat6 which may be relevant:
http://www.debian.org/security/2012/dsa-2401
Comment 2 David Walser 2012-04-07 18:12:48 CEST
RedHat advisory from December 5 with some of the same CVEs as the Debian one:
https://rhn.redhat.com/errata/RHSA-2011-1780.html
Comment 3 D Morgan 2012-04-18 23:58:51 CEST
pushed in BS
Comment 4 David Walser 2012-04-19 01:08:05 CEST
Thanks D Morgan.  Do you have a list of CVEs/CVE descriptions for what was fixed in the Mageia 1 package you pushed?

Also, note that tomcat7 in Cauldron needs updated or patched as well.
Comment 5 David Walser 2012-04-19 02:56:10 CEST
OK, I found the CVEs.

Advisory:
========================

Updated tomcat6 packages fix security vulnerabilities:

Multiple flaws were found in the way Tomcat handled HTTP DIGEST
authentication. These flaws weakened the Tomcat HTTP DIGEST authentication
implementation, subjecting it to some of the weaknesses of HTTP BASIC
authentication, for example, allowing remote attackers to perform session
replay attacks (CVE-2011-1184, CVE-2011-5062, CVE-2011-5063, CVE-2011-5064).

A flaw was found in the Tomcat MemoryUserDatabase. If a runtime exception
occurred when creating a new user with a JMX client, that user's password
was logged to Tomcat log files. Note: By default, only administrators have
access to such log files (CVE-2011-2204).

A flaw was found in the way Tomcat handled sendfile request attributes when
using the HTTP APR or NIO (Non-Blocking I/O) connector. A malicious web
application running on a Tomcat instance could use this flaw to bypass
security manager restrictions and gain access to files it would otherwise
be unable to access, or possibly terminate the Java Virtual Machine (JVM).
The HTTP blocking IO (BIO) connector, which is not vulnerable to this
issue, is used by default in Red Hat Enterprise Linux 6 (CVE-2011-2526).

It was discovered that Tomcat incorrectly performed certain caching and
recycling operations. A remote attacker could use this flaw to obtain read
access to IP address and HTTP header information in certain cases. This
issue only applied to Ubuntu 11.10 (CVE-2011-3375).

A flaw was found in the way the Coyote (org.apache.coyote.ajp.AjpProcessor)
and APR (org.apache.coyote.ajp.AjpAprProcessor) Tomcat AJP (Apache JServ
Protocol) connectors processed certain POST requests. An attacker could
send a specially-crafted request that would cause the connector to treat
the message body as a new request. This allows arbitrary AJP messages to be
injected, possibly allowing an attacker to bypass a web application's
authentication checks and gain access to information they would otherwise
be unable to access. The JK (org.apache.jk.server.JkCoyoteHandler)
connector is used by default when the APR libraries are not present. The JK
connector is not affected by this flaw (CVE-2011-3190).

It was discovered that Tomcat computed hash values for form parameters
without restricting the ability to trigger hash collisions predictably.
A remote attacker could cause a denial of service by sending many crafted
parameters (CVE-2011-4858).

It was discovered that Tomcat incorrectly handled parameters. A remote
attacker could cause a denial of service by sending requests with a large
number of parameters and values (CVE-2012-0022).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1184
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2204
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2526
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3375
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3190
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4858
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0022
https://rhn.redhat.com/errata/RHSA-2011-1780.html
http://www.ubuntu.com/usn/usn-1359-1/
http://tomcat.apache.org/security-6.html
========================

Updated packages in core/updates_testing:
========================
tomcat6-6.0.35-0.1.mga1.noarch.rpm
tomcat6-admin-webapps-6.0.35-0.1.mga1.noarch.rpm
tomcat6-docs-webapp-6.0.35-0.1.mga1.noarch.rpm
tomcat6-javadoc-6.0.35-0.1.mga1.noarch.rpm
tomcat6-jsp-2.1-api-6.0.35-0.1.mga1.noarch.rpm
tomcat6-lib-6.0.35-0.1.mga1.noarch.rpm
tomcat6-servlet-2.5-api-6.0.35-0.1.mga1.noarch.rpm
tomcat6-el-2.1-api-6.0.35-0.1.mga1.noarch.rpm
tomcat6-webapps-6.0.35-0.1.mga1.noarch.rpm

from tomcat6-6.0.35-0.1.mga1.src.rpm
Comment 6 Dave Hodgins 2012-04-19 04:51:20 CEST
Testing complete on i586 for the srpm
tomcat6-6.0.35-0.1.mga1.src.rpm

Testing using 
http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/sample.war
downloaded to /var/lib/tomcat6/webapps, and
http://localhost:8080/sample/
Comment 7 claire robinson 2012-04-26 18:53:27 CEST
PoC for CVE-2011-4858
http://www.securityfocus.com/bid/51200/exploit
Comment 8 claire robinson 2012-04-26 19:29:05 CEST
x86_64

Before
------
Strange formatting problem with the init, similar to tomcat5.

# service tomcat6 start
# 6:                                                 [  OK  ]


Browsing to HOST:8080/sample/ shows no errors on jsp or snippet pages. Also after configuring the manager and admin roles in /etc/tomcat6/tomcat-users.xml and installing tomcat6-admin-webapps and restarting...

Browsing to HOST:8080/manager/html and logging in as the manager user it displayed the management screens. Stopped the sample application and undeployed it.

Browsing to HOST:8080/host-manager/html and logging in as admin user it displayed the host management screens.

After
-----

manager and host-manager screens work ok.

The sample works but the JSP link in the sample causes an exception. I don't have time right now to check further but this could be similar to the permission problems we had with tomcat5.

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

org.apache.jasper.JasperException: Unable to compile class for JSP
	org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604)
	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

root cause

java.io.FileNotFoundException: /usr/share/tomcat6/work/Catalina/localhost/sample/org/apache/jsp/hello_jsp.java (No such file or directory)
	java.io.FileOutputStream.open(Native Method)
	java.io.FileOutputStream.<init>(FileOutputStream.java:209)
	java.io.FileOutputStream.<init>(FileOutputStream.java:99)
	org.apache.jasper.compiler.Compiler.setupContextWriter(Compiler.java:298)
	org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:230)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
	org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328)
	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

note The full stack trace of the root cause is available in the Apache Tomcat/6.0.35 logs.
Comment 9 D Morgan 2012-05-10 16:39:50 CEST
looking this one
Comment 10 D Morgan 2012-06-26 22:57:08 CEST
please do 


ls -l /usr/share/tomcat6/work/
Comment 11 D Morgan 2012-06-26 23:32:42 CEST
works on cauldron for me now ( i will commit a new spec file in some secs )
Comment 12 D Morgan 2012-06-27 00:13:16 CEST
please test a fix have been pushed in mga1 and 2
Comment 13 D Morgan 2012-06-27 00:52:17 CEST
btw don't forget to stop/start tomcat6 after the update
Comment 14 David Walser 2012-06-27 01:00:44 CEST
I guess the CVEs were already fixed in Mageia 2, it's just these additional issues that were found by QA that have now been fixed there.  We should have a new bug for Mageia 2 for that.  I guess if we can get confirmation from QA that the issue has been resolved it can be filed at that point.  We'll need an advisory for these new fixes (which can also be used as an addendum when the advisory for Mageia 1 is updated).

For the future advisories, here's the packages just built.

Mageia 1:
tomcat6-6.0.35-0.2.mga1.noarch.rpm
tomcat6-admin-webapps-6.0.35-0.2.mga1.noarch.rpm
tomcat6-docs-webapp-6.0.35-0.2.mga1.noarch.rpm
tomcat6-javadoc-6.0.35-0.2.mga1.noarch.rpm
tomcat6-jsp-2.1-api-6.0.35-0.2.mga1.noarch.rpm
tomcat6-lib-6.0.35-0.2.mga1.noarch.rpm
tomcat6-servlet-2.5-api-6.0.35-0.2.mga1.noarch.rpm
tomcat6-el-2.1-api-6.0.35-0.2.mga1.noarch.rpm
tomcat6-webapps-6.0.35-0.2.mga1.noarch.rpm

from tomcat6-6.0.35-0.2.mga1.src.rpm

Mageia 2:
tomcat6-6.0.35-4.1.mga2.noarch.rpm
tomcat6-admin-webapps-6.0.35-4.1.mga2.noarch.rpm
tomcat6-docs-webapp-6.0.35-4.1.mga2.noarch.rpm
tomcat6-javadoc-6.0.35-4.1.mga2.noarch.rpm
tomcat6-jsp-2.1-api-6.0.35-4.1.mga2.noarch.rpm
tomcat6-lib-6.0.35-4.1.mga2.noarch.rpm
tomcat6-servlet-2.5-api-6.0.35-4.1.mga2.noarch.rpm
tomcat6-el-2.1-api-6.0.35-4.1.mga2.noarch.rpm
tomcat6-webapps-6.0.35-4.1.mga2.noarch.rpm

from tomcat6-6.0.35-4.1.mga2.src.rpm
Comment 15 Luan Pham 2012-06-27 16:16:05 CEST
I was install tomcat6-jsp-2.1-api-6.0.35-4.1.mga2.noarch.rpm last night on mageia2 x86_64, now it unable to boot to normal mode.
Comment 16 Dave Hodgins 2012-06-27 21:37:15 CEST
For Mageia 1 i586 ...
Sorry, the following packages cannot be selected:
- tomcat6-6.0.35-0.2.mga1.noarch (due to unsatisfied systemd-units[*])
- tomcat6-admin-webapps-6.0.35-0.2.mga1.noarch
Comment 17 D Morgan 2012-06-28 23:40:58 CEST
(In reply to comment #16)
> For Mageia 1 i586 ...
> Sorry, the following packages cannot be selected:
> - tomcat6-6.0.35-0.2.mga1.noarch (due to unsatisfied systemd-units[*])
> - tomcat6-admin-webapps-6.0.35-0.2.mga1.noarch

interesting, i will check
Comment 18 Dave Hodgins 2012-07-01 22:53:02 CEST
Testing complete on Mageia 2 i586 for the srpm
tomcat6-6.0.35-4.1.mga2.src.rpm

For Mageia 2, according to depcheck on tomcat6,
The following packages will require linking:
java-1.5.0-gcj-1.5.0.0-17.1.24.mga2 (Core Release (distrib1))
Comment 19 David Walser 2012-07-02 22:32:16 CEST
(In reply to comment #16)
> For Mageia 1 i586 ...
> Sorry, the following packages cannot be selected:
> - tomcat6-6.0.35-0.2.mga1.noarch (due to unsatisfied systemd-units[*])
> - tomcat6-admin-webapps-6.0.35-0.2.mga1.noarch

D Morgan has fixed this.

tomcat6-6.0.35-0.3.mga1.noarch.rpm
tomcat6-admin-webapps-6.0.35-0.3.mga1.noarch.rpm
tomcat6-docs-webapp-6.0.35-0.3.mga1.noarch.rpm
tomcat6-el-2.1-api-6.0.35-0.3.mga1.noarch.rpm
tomcat6-javadoc-6.0.35-0.3.mga1.noarch.rpm
tomcat6-jsp-2.1-api-6.0.35-0.3.mga1.noarch.rpm
tomcat6-lib-6.0.35-0.3.mga1.noarch.rpm
tomcat6-servlet-2.5-api-6.0.35-0.3.mga1.noarch.rpm
tomcat6-webapps-6.0.35-0.3.mga1.noarch.rpm

from tomcat6-6.0.35-0.3.mga1.src.rpm

Should this be assigned back to QA now?
Comment 20 David Walser 2012-07-14 01:58:36 CEST
Confirmed by D Morgan on IRC, assigning back to QA.  New split advisory follows:

Advisory (Mageia 1):
========================

Updated tomcat6 packages fix security vulnerabilities:

Multiple flaws were found in the way Tomcat handled HTTP DIGEST
authentication. These flaws weakened the Tomcat HTTP DIGEST authentication
implementation, subjecting it to some of the weaknesses of HTTP BASIC
authentication, for example, allowing remote attackers to perform session
replay attacks (CVE-2011-1184, CVE-2011-5062, CVE-2011-5063, CVE-2011-5064).

A flaw was found in the Tomcat MemoryUserDatabase. If a runtime exception
occurred when creating a new user with a JMX client, that user's password
was logged to Tomcat log files. Note: By default, only administrators have
access to such log files (CVE-2011-2204).

A flaw was found in the way Tomcat handled sendfile request attributes when
using the HTTP APR or NIO (Non-Blocking I/O) connector. A malicious web
application running on a Tomcat instance could use this flaw to bypass
security manager restrictions and gain access to files it would otherwise
be unable to access, or possibly terminate the Java Virtual Machine (JVM).
The HTTP blocking IO (BIO) connector, which is not vulnerable to this
issue, is used by default in Red Hat Enterprise Linux 6 (CVE-2011-2526).

It was discovered that Tomcat incorrectly performed certain caching and
recycling operations. A remote attacker could use this flaw to obtain read
access to IP address and HTTP header information in certain cases. This
issue only applied to Ubuntu 11.10 (CVE-2011-3375).

A flaw was found in the way the Coyote (org.apache.coyote.ajp.AjpProcessor)
and APR (org.apache.coyote.ajp.AjpAprProcessor) Tomcat AJP (Apache JServ
Protocol) connectors processed certain POST requests. An attacker could
send a specially-crafted request that would cause the connector to treat
the message body as a new request. This allows arbitrary AJP messages to be
injected, possibly allowing an attacker to bypass a web application's
authentication checks and gain access to information they would otherwise
be unable to access. The JK (org.apache.jk.server.JkCoyoteHandler)
connector is used by default when the APR libraries are not present. The JK
connector is not affected by this flaw (CVE-2011-3190).

It was discovered that Tomcat computed hash values for form parameters
without restricting the ability to trigger hash collisions predictably.
A remote attacker could cause a denial of service by sending many crafted
parameters (CVE-2011-4858).

It was discovered that Tomcat incorrectly handled parameters. A remote
attacker could cause a denial of service by sending requests with a large
number of parameters and values (CVE-2012-0022).

Additionally, errors caused by incorrect permissions on the
/usr/share/tomcat6/work directory have been fixed.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1184
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2204
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2526
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3375
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3190
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4858
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0022
https://rhn.redhat.com/errata/RHSA-2011-1780.html
http://www.ubuntu.com/usn/usn-1359-1/
http://tomcat.apache.org/security-6.html
========================

Updated packages in core/updates_testing:
========================
tomcat6-6.0.35-0.3.mga1.noarch.rpm
tomcat6-admin-webapps-6.0.35-0.3.mga1.noarch.rpm
tomcat6-docs-webapp-6.0.35-0.3.mga1.noarch.rpm
tomcat6-el-2.1-api-6.0.35-0.3.mga1.noarch.rpm
tomcat6-javadoc-6.0.35-0.3.mga1.noarch.rpm
tomcat6-jsp-2.1-api-6.0.35-0.3.mga1.noarch.rpm
tomcat6-lib-6.0.35-0.3.mga1.noarch.rpm
tomcat6-servlet-2.5-api-6.0.35-0.3.mga1.noarch.rpm
tomcat6-webapps-6.0.35-0.3.mga1.noarch.rpm

from tomcat6-6.0.35-0.3.mga1.src.rpm


Advisory (Mageia 2):
========================

This update fixes errors caused by incorrect permissions on the
/usr/share/tomcat6/work directory.

========================

Updated packages in core/updates_testing:
========================
tomcat6-6.0.35-4.1.mga2.noarch.rpm
tomcat6-admin-webapps-6.0.35-4.1.mga2.noarch.rpm
tomcat6-docs-webapp-6.0.35-4.1.mga2.noarch.rpm
tomcat6-javadoc-6.0.35-4.1.mga2.noarch.rpm
tomcat6-jsp-2.1-api-6.0.35-4.1.mga2.noarch.rpm
tomcat6-lib-6.0.35-4.1.mga2.noarch.rpm
tomcat6-servlet-2.5-api-6.0.35-4.1.mga2.noarch.rpm
tomcat6-el-2.1-api-6.0.35-4.1.mga2.noarch.rpm
tomcat6-webapps-6.0.35-4.1.mga2.noarch.rpm

from tomcat6-6.0.35-4.1.mga2.src.rpm
Comment 21 Dave Hodgins 2012-07-18 01:32:52 CEST
Testing complete on Mageia 1 i586

Testing using the sample and the manager links.
Comment 22 Dave Hodgins 2012-07-18 03:31:05 CEST
Testing complete on Magiea 2 i586.
Comment 23 Dave Hodgins 2012-07-24 03:11:53 CEST
Testing procedure (I'll update the wiki later) ...

urpmi tomcat6-admin-webapps tomcat6-webapps

Edit /etc/tomcat6/tomcat-users.xml
Add/edit the lines
 <role rolename="manager-gui"/>
 <user name="youruser" password="yourpassword" roles="manager-gui" />
right befor the line </tomcat-users> (The last line).

service tomcat6 start

Check out http://127.0.0.1:8080/ including the "Tomcat Manager" using
the user/password from the tomcat-users.xml file and also
http://127.0.0.1:8080/sample
Comment 24 Samuel Verschelde 2012-07-28 16:58:06 CEST
Thanks for the procedure Dave.

Everything seems ok, but I'm wondering why http://127.0.0.1:8080/sample/hello won't say hello. Does it mean that the servlet doesn't work on my setup?
Comment 25 Samuel Verschelde 2012-07-28 16:58:29 CEST
comment #24 is about Mageia 1 64 bits
Comment 26 Dave Hodgins 2012-07-30 21:58:29 CEST
(In reply to comment #24)
> Thanks for the procedure Dave.
> 
> Everything seems ok, but I'm wondering why http://127.0.0.1:8080/sample/hello
> won't say hello. Does it mean that the servlet doesn't work on my setup?

The file /var/lib/tomcat6/webapps/sample/hello referenced from
/var/lib/tomcat6/webapps/sample/index.html does not exist, but this is not
a regression.

I've completed testing on Mageia 2 x86-64, but before I validate the update,
$ depcheck tomcat6  "Core Release (distrib1)" "Core Updates Testing (distrib5)"
----------------------------------------
Running checks for "tomcat6" using media
"Core Release (distrib1)" and "Core Updates Testing (distrib5)".
----------------------------------------
Mageia release 2 (Official) for x86_64
Latest version found in "Core Release (distrib1)" is tomcat6-6.0.35-4.mga2
Latest version found in "Core Updates Testing (distrib5)" is tomcat6-6.0.35-4.1.mga2
----------------------------------------
The following packages will require linking:

java-1.5.0-gcj-1.5.0.0-17.1.24.mga2 (Core 32bit Release (distrib31))
java-1.5.0-gcj-1.5.0.0-17.1.24.mga2 (Core Release (distrib1))
----------------------------------------


Is this intentional?
Comment 27 D Morgan 2012-07-31 13:59:40 CEST
i don't see from where this comes, because i have BuildRequires: java-devel >= 0:1.6.0 and Requires: java >= 0:1.6.0
Comment 28 Dave Hodgins 2012-08-01 02:46:29 CEST
(In reply to comment #27)
> i don't see from where this comes, because i have BuildRequires: java-devel >=
> 0:1.6.0 and Requires: java >= 0:1.6.0

Clearly a bug in the depcheck script, as I don't have the package
installed. Sorry for the noise.

Could someone from the sysadmin team push the srpm
tomcat6-6.0.35-4.1.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core Updates and the srpm
tomcat6-6.0.35-0.3.mga1.src.rpm
from Mageia 1 Core Updates Testing to Core Updates.

Please see Comment 20 for the two different advisories.

https://bugs.mageia.org/show_bug.cgi?id=5261
Comment 29 Samuel Verschelde 2012-08-01 08:50:18 CEST
It's not a bug from depcheck, it's a feature:  when several packages provide something, they are all listed by depcheck, since we can't know what the user will want to install as the added dependency.
But in this case I think it can be safely ignored.
Comment 30 claire robinson 2012-08-01 11:15:58 CEST
$ urpmq --requires-recursive --searchmedia Release tomcat6 | grep gcj

$ urpmq --requires-recursive --searchmedia Testing tomcat6 | grep gcj
java-1.5.0-gcj|java-1.7.0-openjdk|java-1.6.0-openjdk

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