You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2016/06/22 10:02:59 UTC
[SECURITY][CORRECTION] CVE-2016-3092 Apache Tomcat Denial of Service
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [SECURITY][CORRECTION] CVE-2016-3092 Apache Tomcat Denial of
Service
Posted by Mark Thomas <ma...@apache.org>.
On 30/06/2016 09:20, Kyohei Nakamura wrote:
> 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-69AC95AB9A3F@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".
Use the lowest value you can that doesn't cause your application to break.
Better still, just update the version of Commons FileUpload you are
using so you don't need this work-around.
Mark
>
>
> 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [SECURITY][CORRECTION] CVE-2016-3092 Apache Tomcat Denial of Service
Posted by Kyohei Nakamura <na...@gmail.com>.
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-69AC95AB9A3F@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org