Note: This announcement corrects several errors and omissions in the
Tomcat aspects of the announcement for CVE-2016-3092 from the Apache
Commons project that was recently forwarded to various Apache Tomcat
mailing lists.

For the sake of clarity, the Tomcat specific corrections are as follows:
1. This is a Denial of Service vulnerability, not an Information
Disclosure vulnerability.
2. Apache Tomcat 8.5.x is also affected. The vulnerability exists in
8.5.0 to 8.5.2 and affected users of 8.5.x should upgrade to 8.5.3.
3. Apache Tomcat 6.x and earlier are not affected.
4. Applications that do not use the File Upload feature introduced in
Servlet 3.0 are not vulnerable via Tomcat.

A corrected announcement, for Tomcat only, follows.


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

Reply via email to