Hi, I have a question about the maxHttpHeaderSize.
In this announcement, the recommended value is 3072 bytes. However, in the announcement from the Apache Commons project, the recommended value is 2048 bytes. http://mail-archives.apache.org/mod_mbox/www-announce/201606.mbox/%3c45a20804-abff-4fed-a297-69ac95ab9...@apache.org%3E If an application uses the Apache Commons FileUpload (not use the Tomcat File Upload feature), which one should I use? "3072" or "2048". 2016-06-22 19:02 GMT+09:00 Mark Thomas <ma...@apache.org>: > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
