Re: Http2UpgradeHandler error

[Andrei Ivanov]

On Wed, Jun 22, 2016 at 10:42 PM, Mark Thomas  wrote:
> 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

[James Wiley]

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

[Mark Thomas]

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

[Mark Thomas]

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

[James Wiley]

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

[Lentes, Bernd]

- 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

[Lentes, Bernd]

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

[Mark Thomas]

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

[Mark Thomas]

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

[Mark Thomas]

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

[Markus Näher]

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

[Chinoy Gupta]

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 List 
Subject: 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

[Mark Thomas]

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