Ubuntu has issued this advisory on February 13: http://www.ubuntu.com/usn/usn-1359-1/ Cauldron is also affected.
Blocks: (none) => 5046
CC: (none) => dmorganec
Here is a Debian advisory from February 2 for tomcat6 which may be relevant: http://www.debian.org/security/2012/dsa-2401
RedHat advisory from December 5 with some of the same CVEs as the Debian one: https://rhn.redhat.com/errata/RHSA-2011-1780.html
pushed in BS
Assignee: bugsquad => qa-bugs
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.
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
Blocks: 5046 => (none)
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/
CC: (none) => davidwhodgins
PoC for CVE-2011-4858 http://www.securityfocus.com/bid/51200/exploit
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.
CC: (none) => qa-bugsHardware: i586 => AllAssignee: qa-bugs => dmorganec
looking this one
please do ls -l /usr/share/tomcat6/work/
works on cauldron for me now ( i will commit a new spec file in some secs )
please test a fix have been pushed in mga1 and 2
btw don't forget to stop/start tomcat6 after the update
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
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.
CC: (none) => pham182b
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
(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
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))
Whiteboard: (none) => mga2-32-OK
(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?
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
Assignee: dmorganec => qa-bugs
Testing complete on Mageia 1 i586 Testing using the sample and the manager links.
Testing complete on Magiea 2 i586.
Whiteboard: mga2-32-OK => mga1-32-OK mga2-32-OK
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
CC: (none) => stormiWhiteboard: mga1-32-OK mga2-32-OK => has_procedure mga1-32-OK mga2-32-OK
Version: 1 => 2Whiteboard: has_procedure mga1-32-OK mga2-32-OK => MGA1TOO has_procedure mga1-32-OK mga2-32-OK
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?
Whiteboard: MGA1TOO has_procedure mga1-32-OK mga2-32-OK => MGA1TOO has_procedure mga1-32-OK mga2-32-OK MGA1-64-OK?
comment #24 is about Mageia 1 64 bits
(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?
Whiteboard: MGA1TOO has_procedure mga1-32-OK mga2-32-OK MGA1-64-OK? => MGA1TOO has_procedure mga1-32-OK mga2-32-OK MGA1-64-OK
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
(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
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsWhiteboard: MGA1TOO has_procedure mga1-32-OK mga2-32-OK MGA1-64-OK => MGA1TOO has_procedure mga1-32-OK mga2-32-OK MGA1-64-OK MGA2-64-OK
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.
$ 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
Update pushed: Mageia 1: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0189 Mageia 2: https://wiki.mageia.org/en/Support/Advisories/MGAA-2012-0144
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED