[jira] [Commented] (OFBIZ-7348) Upgrade Tomcat to 8.5.3

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15345109#comment-15345109 ]

Jacques Le Roux commented on OFBIZ-7348:
----------------------------------------

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

{quote}
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
{quote}

> Upgrade Tomcat to 8.5.3
> -----------------------
>
>                 Key: OFBIZ-7348
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-7348
>             Project: OFBiz
>          Issue Type: Task
>          Components: framework
>    Affects Versions: Trunk
>            Reporter: Jacques Le Roux
>            Priority: Trivial
>             Fix For: Upcoming Branch
>
>
> Quoting announcement on [hidden email] and other channels:
> {quote}
> 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
> {quote}

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)