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
