Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Trivial
    • Resolution: Fixed
    • Affects Version/s: Trunk
    • Fix Version/s: 16.11.01
    • Component/s: framework
    • Labels:
      None
    • Sprint:
      Bug Crush Event - 21/2/2015

      Description

      Quoting announcement on announce@apache.org and other channels:

      This is the first stable release of the 8.5.x branch. Tomcat 8.x users
      should now use 8.5.x releases in preference to 8.0.x releases.

      Apache Tomcat 8.5.x is intended to replace 8.0.x and includes new
      features pulled forward from the 9.0.x branch. The notable changes since
      8.5.2 include:

      • Ensure error will not be thrown during deployment when scanning jar
        files with no or invalid MANIFEST.MF files.
      • Improvements to memory leak detection and prevention
      • The HTTP Server header is no longer set by default

      Please refer to the change log for the complete list of changes:
      http://tomcat.apache.org/tomcat-8.5-doc/changelog.html

      Downloads:
      http://tomcat.apache.org/download-80.cgi

        Issue Links

          Activity

          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I wonder if we should not also update releases branches, for the sake of consistency, I have no other arguments so far, opinions?

          Show
          jacques.le.roux Jacques Le Roux added a comment - I wonder if we should not also update releases branches, for the sake of consistency, I have no other arguments so far, opinions?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Here is another more pressing reason to update to 8.5.3 (we currently use 8.0.33):

          CVE-2016-3092: Apache Tomcat Denial of Service

          Severity: Moderate

          Vendor:
          The Apache Software Foundation

          Versions Affected:
          Apache Tomcat 9.0.0.M1 to 9.0.0M6
          Apache Tomcat 8.5.0 to 8.5.2
          Apache Tomcat 8.0.0.RC1 to 8.0.35
          Apache Tomcat 7.0.0 to 7.0.69
          Earlier versions are not affected.

          Description:
          CVE-2016-3092 is a denial of service vulnerability that has been
          corrected in the Apache Commons FileUpload component. It occurred when
          the length of the multipart boundary was just below the size of the
          buffer (4096 bytes) used to read the uploaded file. This caused the file
          upload process to take several orders of magnitude longer than if the
          boundary length was the typical tens of bytes.

          Apache Tomcat uses a package renamed copy of Apache Commons FileUpload
          to implement the file upload requirements of the Servlet specification
          and was therefore also vulnerable to the denial of service vulnerability.

          Applications that do not use the File Upload feature introduced in
          Servlet 3.0 are not affected by the Tomcat aspect of this vulnerability.
          If those applications use Apache Commons FileUpload, they may still be
          affected.

          Mitigation:
          Users of affected versions should apply one of the following mitigations

          • Upgrade to Apache Tomcat 9.0.0.M8 or later
            (9.0.0.M7 has the fix but was not released)
          • Upgrade to Apache Tomcat 8.5.3 or later
          • Upgrade to Apache Tomcat 8.0.36 or later
          • Upgrade to Apache Tomcat 7.0.70 or later

          Workaround:
          The issue may be mitigated by limiting the length of the boundary.
          Applications could do this with a custom Filter to reject requests that
          use large boundaries.
          Tomcat provides the maxHttpHeaderSize attribute on the Connector that
          can be used to limit the total HTTP header size. Users should be aware
          that reducing this to 3072 (which should be low enough to protect
          against this DoS) may cause other issues as applications can require
          larger headers than this for correct operation, particularly if the
          application uses relatively large cookie values.

          Credit:
          This issue was identified by the TERASOLUNA Framework Development Team
          at the Software Engineering, Research and Development Headquarters and
          reported to the ASF via JPCERT.

          References:
          http://tomcat.apache.org/security-9.html
          http://tomcat.apache.org/security-8.html
          http://tomcat.apache.org/security-7.html

          Show
          jacques.le.roux Jacques Le Roux added a comment - Here is another more pressing reason to update to 8.5.3 (we currently use 8.0.33): CVE-2016-3092: Apache Tomcat Denial of Service Severity: Moderate Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.0M6 Apache Tomcat 8.5.0 to 8.5.2 Apache Tomcat 8.0.0.RC1 to 8.0.35 Apache Tomcat 7.0.0 to 7.0.69 Earlier versions are not affected. Description: CVE-2016-3092 is a denial of service vulnerability that has been corrected in the Apache Commons FileUpload component. It occurred when the length of the multipart boundary was just below the size of the buffer (4096 bytes) used to read the uploaded file. This caused the file upload process to take several orders of magnitude longer than if the boundary length was the typical tens of bytes. Apache Tomcat uses a package renamed copy of Apache Commons FileUpload to implement the file upload requirements of the Servlet specification and was therefore also vulnerable to the denial of service vulnerability. Applications that do not use the File Upload feature introduced in Servlet 3.0 are not affected by the Tomcat aspect of this vulnerability. If those applications use Apache Commons FileUpload, they may still be affected. Mitigation: Users of affected versions should apply one of the following mitigations Upgrade to Apache Tomcat 9.0.0.M8 or later (9.0.0.M7 has the fix but was not released) Upgrade to Apache Tomcat 8.5.3 or later Upgrade to Apache Tomcat 8.0.36 or later Upgrade to Apache Tomcat 7.0.70 or later Workaround: The issue may be mitigated by limiting the length of the boundary. Applications could do this with a custom Filter to reject requests that use large boundaries. Tomcat provides the maxHttpHeaderSize attribute on the Connector that can be used to limit the total HTTP header size. Users should be aware that reducing this to 3072 (which should be low enough to protect against this DoS) may cause other issues as applications can require larger headers than this for correct operation, particularly if the application uses relatively large cookie values. Credit: This issue was identified by the TERASOLUNA Framework Development Team at the Software Engineering, Research and Development Headquarters and reported to the ASF via JPCERT. References: http://tomcat.apache.org/security-9.html http://tomcat.apache.org/security-8.html http://tomcat.apache.org/security-7.html
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          In case of difficulties we might want to temporary update to 8.0.36

          Show
          jacques.le.roux Jacques Le Roux added a comment - In case of difficulties we might want to temporary update to 8.0.36
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Updating to 8.0.36 with Gradle is a breeze but 8.5.4 needs more work. So I suggest we simply update to 8.0.36.

          BTW I no longer see any reasons to have the jars listed in LICENSE. We might uptade NOTICE as well

          Opinions before I do?

          Show
          jacques.le.roux Jacques Le Roux added a comment - Updating to 8.0.36 with Gradle is a breeze but 8.5.4 needs more work. So I suggest we simply update to 8.0.36. BTW I no longer see any reasons to have the jars listed in LICENSE. We might uptade NOTICE as well Opinions before I do?
          Hide
          jacopoc Jacopo Cappellato added a comment -

          Properly handling LICENSE and NOTICE files is very important and such a relevant change shouldn't be addressed with lazy consensus, especially when the question is posted as an off-topic in a comment in Jira.
          In short: questions about how to manage LICENSE files should be posted to the dev list and discussed there in specific threads.
          By the way, even if we do not distribute the jars, they are still dependencies for our code so I think we have to keep them in the LICENSE file (even if it would be nice to automate the preparation of the LICENSE file). However it is worth doing a research (in ASF documentation and how other ASF projects are doing it) before proposing a change.

          Show
          jacopoc Jacopo Cappellato added a comment - Properly handling LICENSE and NOTICE files is very important and such a relevant change shouldn't be addressed with lazy consensus, especially when the question is posted as an off-topic in a comment in Jira. In short: questions about how to manage LICENSE files should be posted to the dev list and discussed there in specific threads. By the way, even if we do not distribute the jars, they are still dependencies for our code so I think we have to keep them in the LICENSE file (even if it would be nice to automate the preparation of the LICENSE file). However it is worth doing a research (in ASF documentation and how other ASF projects are doing it) before proposing a change.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          OK, so we need to check that before indeed, as a 1st step I can still commit all the changes, including the LICENSE file I mean. And see in a new OFBIZ-7534 sub task if we can remove the jars reference in the LICENSE file

          Show
          jacques.le.roux Jacques Le Roux added a comment - OK, so we need to check that before indeed, as a 1st step I can still commit all the changes, including the LICENSE file I mean. And see in a new OFBIZ-7534 sub task if we can remove the jars reference in the LICENSE file
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Because this security issue was pending for too long, as a 1st step I updated Tomcat to 8.0.36 because I got issues with 8.5.3 when just changing to 8.0.36 in build.gradle files worked.

          I also changed the version number in LICENSE, even if some libs are only downloaded by Gradle as dependencies of the main present in build.gradle, still a WIP...

          I have investigated if we really need to have all the external jar libs in LICENSE even if we don't deliver them in 1st place, but are still used when building, see http://markmail.org/message/emnu6s5wu2yuyith

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Because this security issue was pending for too long, as a 1st step I updated Tomcat to 8.0.36 because I got issues with 8.5.3 when just changing to 8.0.36 in build.gradle files worked. I also changed the version number in LICENSE, even if some libs are only downloaded by Gradle as dependencies of the main present in build.gradle, still a WIP... I have investigated if we really need to have all the external jar libs in LICENSE even if we don't deliver them in 1st place, but are still used when building, see http://markmail.org/message/emnu6s5wu2yuyith
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I close here nothing left to do. We agreed and modidifed the license and notice files. They no longer contains references to Tomcat libs.

          Show
          jacques.le.roux Jacques Le Roux added a comment - I close here nothing left to do. We agreed and modidifed the license and notice files. They no longer contains references to Tomcat libs.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Note that I only updated the trunk (hence the 16.11 branch). Older are still using respectively 8.0.33 for R15/14 and 7.0.68 for R13

          Show
          jacques.le.roux Jacques Le Roux added a comment - Note that I only updated the trunk (hence the 16.11 branch). Older are still using respectively 8.0.33 for R15/14 and 7.0.68 for R13

            People

            • Assignee:
              jacques.le.roux Jacques Le Roux
              Reporter:
              jacques.le.roux Jacques Le Roux
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development

                  Agile