Re: Http2UpgradeHandler error
On Wed, Jun 22, 2016 at 10:42 PM, Mark Thomaswrote: > On 21/06/2016 17:36, Mark Thomas wrote: >> On 21/06/2016 14:52, Mark Thomas wrote: >>> On 21/06/2016 14:43, Andrei Ivanov wrote: >> >> >> 21-Jun-2016 13:38:41.122 FINE [https-openssl-apr-8443-exec-6] org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.fillReadBuffer An APR general error was returned by the SSL read operation on APR/native socket [1,852,286,144] with wrapper [org.apache.tomcat.util.net. AprEndpoint$AprSocketWrapper@1dfa0278:1852286144]. It will be treated as EAGAIN and the socket returned to the poller. 21-Jun-2016 13:38:41.125 SEVERE [https-openssl-apr-8443-exec-6] org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading request, ignored java.lang.IllegalStateException >>> >>> Bingo! >>> >>> That proves the theory. Thanks for testing it so quickly. I should be >>> able to put together a fix for this fairly quickly. I'll update this >>> thread when I have the fix ready to test. If you're able to build Tomcat >>> 8.5.x locally by then, great. If not, I can always provide a snapshot >>> build for you to test with. >> >> This is going to take a little longer than I thought. I need to dig >> deeper into the tc-native / OpenSSL code. > > Progress has been made. > > I think the root cause was a bug in tc-native (fixed for 1.2.8) that had > an incomplete work-around applied in Tomcat. I've fixed this in > tc-native 1.2.x. An update to tc-native 1.2.8 (when released) should be > sufficient to fix this. If I upload a snapshot build of the 1.2.8-dev > .dll somewhere would you be able to test it? Do you need 32-bit or 64-bit? Yes, I can test. 64-bit please. Thank you :-) > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL problems with Tomcat 7.0.69
Mark, Thanks for the hint! I added the following line to my connector and it did the trick! ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256" Cheers, James On 6/22/16, 9:55 AM, "Mark Thomas"wrote: On 22/06/2016 16:47, James Wiley wrote: > Hi Tomcat Users, > > Has anyone run into any issues supporting SSL using the JSSE Connector when > upgrading from 7.0.68 to 7.0.69? > > I help maintain a web application that uses tomcat7. A recent upgrade from > 7.0.68 to 7.0.69 has caused the tomcat7 instance to throw an “Error during > SSL Handshake” with the Apache proxy server. The tomcat instance is running > in AWS using a Amazon Linux image (very similar to CentOS) using JDK 1.7. > Also, it is proxied by an Apache HTTP server, version 2.2.31. > > I’ve gone through the SSL documentation a nd updated the settings without any luck. This instance is configured to use the JSSE Connector. The following configuration settings work fine under 7.0.68, but break under 7.0.69: > > protocol="org.apache.coyote.http11.Http11Protocol" >SSLEnabled="true" >maxThreads="150" >scheme="https" secure="true" >clientAuth="false" sslProtocol="TLS" > sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" >keystoreFile="" >keystorePass="" /> I suspect the more restricted cipher list is the root cause. You can use the Manager app or JMX to see which ciphers are enabled for a connector. Compare the results for 7.0.68 and 7.0.69 along with what httpd supports and adjust accordingly. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http2UpgradeHandler error
On 21/06/2016 17:36, Mark Thomas wrote: > On 21/06/2016 14:52, Mark Thomas wrote: >> On 21/06/2016 14:43, Andrei Ivanov wrote: > > > >>> 21-Jun-2016 13:38:41.122 FINE [https-openssl-apr-8443-exec-6] >>> org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.fillReadBuffer >>> An APR general error was returned by the SSL read operation on >>> APR/native socket [1,852,286,144] with wrapper >>> [org.apache.tomcat.util.net. >>> AprEndpoint$AprSocketWrapper@1dfa0278:1852286144]. It will be treated >>> as EAGAIN and the socket returned to the poller. >>> 21-Jun-2016 13:38:41.125 SEVERE [https-openssl-apr-8443-exec-6] >>> org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error >>> reading request, ignored >>> java.lang.IllegalStateException >> >> Bingo! >> >> That proves the theory. Thanks for testing it so quickly. I should be >> able to put together a fix for this fairly quickly. I'll update this >> thread when I have the fix ready to test. If you're able to build Tomcat >> 8.5.x locally by then, great. If not, I can always provide a snapshot >> build for you to test with. > > This is going to take a little longer than I thought. I need to dig > deeper into the tc-native / OpenSSL code. Progress has been made. I think the root cause was a bug in tc-native (fixed for 1.2.8) that had an incomplete work-around applied in Tomcat. I've fixed this in tc-native 1.2.x. An update to tc-native 1.2.8 (when released) should be sufficient to fix this. If I upload a snapshot build of the 1.2.8-dev .dll somewhere would you be able to test it? Do you need 32-bit or 64-bit? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL problems with Tomcat 7.0.69
On 22/06/2016 16:47, James Wiley wrote: > Hi Tomcat Users, > > Has anyone run into any issues supporting SSL using the JSSE Connector when > upgrading from 7.0.68 to 7.0.69? > > I help maintain a web application that uses tomcat7. A recent upgrade from > 7.0.68 to 7.0.69 has caused the tomcat7 instance to throw an “Error during > SSL Handshake” with the Apache proxy server. The tomcat instance is running > in AWS using a Amazon Linux image (very similar to CentOS) using JDK 1.7. > Also, it is proxied by an Apache HTTP server, version 2.2.31. > > I’ve gone through the SSL documentation and updated the settings without any > luck. This instance is configured to use the JSSE Connector. The following > configuration settings work fine under 7.0.68, but break under 7.0.69: > > protocol="org.apache.coyote.http11.Http11Protocol" >SSLEnabled="true" >maxThreads="150" >scheme="https" secure="true" >clientAuth="false" sslProtocol="TLS" > sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" >keystoreFile="" >keystorePass="" /> I suspect the more restricted cipher list is the root cause. You can use the Manager app or JMX to see which ciphers are enabled for a connector. Compare the results for 7.0.68 and 7.0.69 along with what httpd supports and adjust accordingly. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL problems with Tomcat 7.0.69
Hi Tomcat Users, Has anyone run into any issues supporting SSL using the JSSE Connector when upgrading from 7.0.68 to 7.0.69? I help maintain a web application that uses tomcat7. A recent upgrade from 7.0.68 to 7.0.69 has caused the tomcat7 instance to throw an “Error during SSL Handshake” with the Apache proxy server. The tomcat instance is running in AWS using a Amazon Linux image (very similar to CentOS) using JDK 1.7. Also, it is proxied by an Apache HTTP server, version 2.2.31. I’ve gone through the SSL documentation and updated the settings without any luck. This instance is configured to use the JSSE Connector. The following configuration settings work fine under 7.0.68, but break under 7.0.69: Thanks, James
Re: error during startup after applying changes from CVE-2016-3092
- On Jun 22, 2016, at 1:52 PM, Bernd Lentes bernd.len...@helmholtz-muenchen.de wrote: > Hi, > > i changed maxHttpHeaderSize in server.xml following the recommendation in > CVE-2016-3092. > I changed it to 2048 bytes. > >connectionTimeout="2" > redirectPort="8443" maxHttpHeaderSize="2048" /> > >
error during startup after applying changes from CVE-2016-3092
Hi, i changed maxHttpHeaderSize in server.xml following the recommendation in CVE-2016-3092. I changed it to 2048 bytes.
Re: Webapp with underscore in it's name leads to failed session-cookies
On 22/06/2016 11:29, Mark Thomas wrote: > On 22/06/2016 09:28, Markus Näher wrote: >> In the web console of firefox, I could see that the session cookie was >> set with the path /jsf%5ftest, while other cookies (set by myfaces) were >> correctly set with the path /jsf_test. >> It looks like firefox treats /jsf_test and /jsf%5ftest as different >> pathes and therefore does not send the session cookie with the next >> request, while chromium ignores the difference. > > I see a similar issue if I rename the examples web application to > "exa_mples". It shouldn't take me too long to figure out where things > are going wrong. Tomcat is correctly setting the path for the session cookie as "/exa_mples" > I'll keep that in mind once I figure out the root cause. It may impact > how we fix this. The problem is that FireFox, by default, encodes all URIs and doesn't take account of the encoding when matching URIs to cookie paths. Failing to account for encoding looks like a FireFox bug to me. A possible work-around is to disable the automatic encoding of URLs that FireFox provides by setting network.standard-url.encode-utf8 to false under about:config. >> Unfortunately, my real-world productive project has an underscore in >> it's name too, but as many users have bookmarked it, I can't just rename >> it. >> >> Is this a bug in tomcat ? > > At this point I'd say it is likely but until I dig into this to figure > out exactly what the root cause is, I can't be sure. No, it is a FireFox bug. And a long standing one at that. https://bugzilla.mozilla.org/show_bug.cgi?id=665851 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Webapp with underscore in it's name leads to failed session-cookies
On 22/06/2016 09:28, Markus Näher wrote: > Hi, > > I'm working on a JSF (myfaces) project that runs on Tomcat. First I > thought it was a myfaces issue, but they told me that the container is > responsible for the session cookie, so now I'm here :-) That is correct. To a point. There are some things the application can do to control the session cookie so the problem may lie elsewhere but, with the information provided to date, you look to be asking in the right place. > I've created a minimal JSF test project and I called it jsf_test. When I > open the tomcat manager (web) and the webapp's welcome page in the > browser, I can see that every reload of the webapp page increases the > session count. If you have a test case it is generally a good idea to put it somewhere where the members of the mailing list can access it. > In the web console of firefox, I could see that the session cookie was > set with the path /jsf%5ftest, while other cookies (set by myfaces) were > correctly set with the path /jsf_test. > It looks like firefox treats /jsf_test and /jsf%5ftest as different > pathes and therefore does not send the session cookie with the next > request, while chromium ignores the difference. I see a similar issue if I rename the examples web application to "exa_mples". It shouldn't take me too long to figure out where things are going wrong. > I also noticed that the issue does not occur on every deployment / > tomcat restart. It looks like the webapp name is stored internally > during initialization, and depending on little timing variations (race > condition ?), it is either initialized to the escaped or the unescaped > value. Tomcat manager always displays the unescaped name. That is very strange. Web application initialisation is single threaded (per webapp) so a race condition is unlikely. > Among my teammates, some are always affected, some occasionally, and > some never. That suggests something triggered by the environment. No idea what it could be at this point though. > After renaming the webapp to "jsftest", the session count increments > were gone. > The issue also occurs with a minus in the name, like "jsf-test". I'll keep that in mind once I figure out the root cause. It may impact how we fix this. > Unfortunately, my real-world productive project has an underscore in > it's name too, but as many users have bookmarked it, I can't just rename > it. > > Is this a bug in tomcat ? At this point I'd say it is likely but until I dig into this to figure out exactly what the root cause is, I can't be sure. > Environment: > OS: Linux / Windows > Tomcat version: 8.0.36 > JDK: Oracle JDK 1.8.0_92 > Within the team, we're using different minor verions, but I've tested > with the newest ones. Thanks for providing the version info. Not everyone does and it can often be very helpful. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Webapp with underscore in it's name leads to failed session-cookies
Hi, I'm working on a JSF (myfaces) project that runs on Tomcat. First I thought it was a myfaces issue, but they told me that the container is responsible for the session cookie, so now I'm here :-) I've created a minimal JSF test project and I called it jsf_test. When I open the tomcat manager (web) and the webapp's welcome page in the browser, I can see that every reload of the webapp page increases the session count. In the web console of firefox, I could see that the session cookie was set with the path /jsf%5ftest, while other cookies (set by myfaces) were correctly set with the path /jsf_test. It looks like firefox treats /jsf_test and /jsf%5ftest as different pathes and therefore does not send the session cookie with the next request, while chromium ignores the difference. I also noticed that the issue does not occur on every deployment / tomcat restart. It looks like the webapp name is stored internally during initialization, and depending on little timing variations (race condition ?), it is either initialized to the escaped or the unescaped value. Tomcat manager always displays the unescaped name. Among my teammates, some are always affected, some occasionally, and some never. After renaming the webapp to "jsftest", the session count increments were gone. The issue also occurs with a minus in the name, like "jsf-test". Unfortunately, my real-world productive project has an underscore in it's name too, but as many users have bookmarked it, I can't just rename it. Is this a bug in tomcat ? Environment: OS: Linux / Windows Tomcat version: 8.0.36 JDK: Oracle JDK 1.8.0_92 Within the team, we're using different minor verions, but I've tested with the newest ones. Regards, Markus Näher - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability
Thanks for the info Mark. Regards, Chinoy -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, June 22, 2016 11:43 AM To: Tomcat Users ListSubject: Re: CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability On 22/06/2016 05:51, Chinoy Gupta wrote: > What about 8.5.x branch? Is that also affected. Yes. 8.5.0 to 8.5.2 are affected. > And I am not able to see this update on Tomcat security page. Any reasons for > that? Oversight. I'll get it added later today unless someone beats me to it. I'll also send out a corrected, Tomcat specific announcement for this rather than the forwarded one from Apache Commons below which has a number of errors in the Tomcat version information: - 8.5.x is not listed (8.5.0 to 8.5.2 are affected) - 6.0.x is listed as affected when it is not - 5.5.x and earlier are listed as may be affected when they are not Mark > > Regards, > Chinoy > > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Tuesday, June 21, 2016 3:23 PM > To: users@tomcat.apache.org; d...@tomcat.apache.org; > annou...@tomcat.apache.org; annou...@apache.org; > secur...@tomcat.apache.org > Subject: Fwd: CVE-2016-3092: Apache Commons Fileupload information > disclosure vulnerability > > > Original Message > From: Jochen Wiedmann > Sent: 21 June 2016 10:18:15 BST > To: priv...@commons.apache.org, "secur...@apache.org" > , Tomcat Security List > , annou...@apache.org, Apache Commons > Developers List > Subject: CVE-2016-3092: Apache Commons Fileupload information > disclosure vulnerability > > CVE-2016-3092: Apache Commons Fileupload information disclosure > vulnerability > > Severity: Moderate > > Vendor: > The Apache Software Foundation > > Versions Affected: > Apache Commons Fileupload 1.3 to 1.3.1 Apache Commons Fileupload 1.2 > to 1.2.2 The unsupported Apache Commons Fileupload 1.0.x, and 1.1.x > may also be affected. > Apache Tomcat 9.x to 9.0.0M6 > Apache Tomcat 8.x to 8.0.35 > Apache Tomcat 7.x to 7.0.69 > Apache Tomcat 6.x > Unsupported versions of Apache Tomcat, like 5.x may also be affected. > Apache Struts 2.5.x, and previous versions, which are distributing Commons > FileUpload 1.3.1, or earlier versions. > > Description: > A malicious client can send file upload requests that cause the HTTP server > using the Apache Commons Fileupload library to become unresponsive, > preventing the server from servicing other requests. > > This flaw is not exploitable beyond causing the code to loop expending CPU > resources. > > > Mitigation: > All users of Apache Commons Fileupload should upgrade to 1.3.2. > All users of Apache Tomcat should upgrade to 9.0.0M8, 8.0.36, or 7.0.70, > respectively. > All users of Apache Struts should replace the copy of Commons FileUpload > (which is distributed as part of Struts) with the fixed version 1.3.2. > > Workaround: > > System administrators should restrict the permitted maximum size of HTTP > request header values (For example, Apache Httpd provides a > LimitRequestFieldSize directive, and Apache Tomcat provides a > maxHttpHeaderSize attribute in their respective configuration files). A > maximum header value size of 2048 bytes would block all dangerous request. > > Example: > File upload requests contain a so-called boundary in the Content-Type header: > > Content-Type: multipart/mixed; > boundary=gc0p4Jq0M2Yt08jU534c0p > > The boundary may be chosen by the request sender. In the case of previous > versions of Apache Commons Fileupload the boundary becomes dangerous, if its > size is close to 4096 bytes. > > Credit: > TERASOLUNA Framework Development Team at the Software Engineering, Research > and Development Headquarter, for detecting this flaw, and reporting it to the > JPCERT/CC, Taki Uchiyama (JPCERT/CC Vulnerability Handling Team) reported > this problem to us. > > References: > https://commons.apache.org/proper/commons-fileupload/security.html > > > > Note: Apache Tomcat 6.x and earlier are NOT affected. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability
On 22/06/2016 05:51, Chinoy Gupta wrote: > What about 8.5.x branch? Is that also affected. Yes. 8.5.0 to 8.5.2 are affected. > And I am not able to see this update on Tomcat security page. Any reasons for > that? Oversight. I'll get it added later today unless someone beats me to it. I'll also send out a corrected, Tomcat specific announcement for this rather than the forwarded one from Apache Commons below which has a number of errors in the Tomcat version information: - 8.5.x is not listed (8.5.0 to 8.5.2 are affected) - 6.0.x is listed as affected when it is not - 5.5.x and earlier are listed as may be affected when they are not Mark > > Regards, > Chinoy > > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Tuesday, June 21, 2016 3:23 PM > To: users@tomcat.apache.org; d...@tomcat.apache.org; > annou...@tomcat.apache.org; annou...@apache.org; secur...@tomcat.apache.org > Subject: Fwd: CVE-2016-3092: Apache Commons Fileupload information disclosure > vulnerability > > > Original Message > From: Jochen Wiedmann> Sent: 21 June 2016 10:18:15 BST > To: priv...@commons.apache.org, "secur...@apache.org" , > Tomcat Security List , annou...@apache.org, > Apache Commons Developers List > Subject: CVE-2016-3092: Apache Commons Fileupload information disclosure > vulnerability > > CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability > > Severity: Moderate > > Vendor: > The Apache Software Foundation > > Versions Affected: > Apache Commons Fileupload 1.3 to 1.3.1 > Apache Commons Fileupload 1.2 to 1.2.2 > The unsupported Apache Commons Fileupload 1.0.x, and 1.1.x may also be > affected. > Apache Tomcat 9.x to 9.0.0M6 > Apache Tomcat 8.x to 8.0.35 > Apache Tomcat 7.x to 7.0.69 > Apache Tomcat 6.x > Unsupported versions of Apache Tomcat, like 5.x may also be affected. > Apache Struts 2.5.x, and previous versions, which are distributing Commons > FileUpload 1.3.1, or earlier versions. > > Description: > A malicious client can send file upload requests that cause the HTTP server > using the Apache Commons Fileupload library to become unresponsive, > preventing the server from servicing other requests. > > This flaw is not exploitable beyond causing the code to loop expending CPU > resources. > > > Mitigation: > All users of Apache Commons Fileupload should upgrade to 1.3.2. > All users of Apache Tomcat should upgrade to 9.0.0M8, 8.0.36, or 7.0.70, > respectively. > All users of Apache Struts should replace the copy of Commons FileUpload > (which is distributed as part of Struts) with the fixed version 1.3.2. > > Workaround: > > System administrators should restrict the permitted maximum size of HTTP > request header values (For example, Apache Httpd provides a > LimitRequestFieldSize directive, and Apache Tomcat provides a > maxHttpHeaderSize attribute in their respective configuration files). A > maximum header value size of 2048 bytes would block all dangerous request. > > Example: > File upload requests contain a so-called boundary in the Content-Type header: > > Content-Type: multipart/mixed; > boundary=gc0p4Jq0M2Yt08jU534c0p > > The boundary may be chosen by the request sender. In the case of previous > versions of Apache Commons Fileupload the boundary becomes dangerous, if its > size is close to 4096 bytes. > > Credit: > TERASOLUNA Framework Development Team at the Software Engineering, Research > and Development Headquarter, for detecting this flaw, and reporting it to the > JPCERT/CC, Taki Uchiyama (JPCERT/CC Vulnerability Handling Team) reported > this problem to us. > > References: > https://commons.apache.org/proper/commons-fileupload/security.html > > > > Note: Apache Tomcat 6.x and earlier are NOT affected. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org