RE: [SECURITY] CVE-2021-42340 Apache Tomcat DoS [EXTERNAL]

[Beard, Shawn]

It has to do with not releasing http websocket connections properly. So its 
both. We just had to upgrade to 9.0.53 on everything because of this.

​
Shawn   Beard• Sr. Systems Engineer
Middleware Engineering
[cid:image852868.png@BE68D2F7.0F762FA2]
3840 109th Street   ,   Urbandale   ,   IA  50322
Phone: +1-515-564-2528
Email:  sbe...@wrberkley.com
Website: https://berkleytechnologyservices.com/
[cid:image544710.jpg@E9DE55D0.0D0A7FFA]
Technology Leadership Unleashing Business Potential


-Original Message-
From: James H. H. Lampert 
Sent: Monday, December 6, 2021 1:29 PM
To: Tomcat Users List 
Subject: Re: [SECURITY] CVE-2021-42340 Apache Tomcat DoS [EXTERNAL]

** CAUTION: External message


On 10/14/21 7:12 AM, Mark Thomas wrote:
> The fix for bug 63362 introduced a memory leak. The object introduced
> to collect metrics for HTTP upgrade connections was not released for
> WebSocket connections once the WebSocket connection was closed. This
> created a memory leak that, over time, could lead to a denial of
> service via an OutOfMemoryError.

Question:

Is this even an issue if the Tomcat is configured to *only* listen on 443, and 
rejects non-HTTPS connections outright?

--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

Re: [SECURITY] CVE-2021-42340 Apache Tomcat DoS

[James H. H. Lampert]

On 10/14/21 7:12 AM, Mark Thomas wrote:
The fix for bug 63362 introduced a memory leak. The object introduced to 
collect metrics for HTTP upgrade connections was not released for 
WebSocket connections once the WebSocket connection was closed. This 
created a memory leak that, over time, could lead to a denial of service 
via an OutOfMemoryError.


Question:

Is this even an issue if the Tomcat is configured to *only* listen on 
443, and rejects non-HTTPS connections outright?


--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RemoveAbandoned Problems

[Phil Steitz]

Sorry again.  Docs are here (at the bottom in the abandoned config section):

https://commons.apache.org/proper/commons-dbcp/configuration.html

On 12/6/21 10:01 AM, Phil Steitz wrote:



On 12/5/21 2:34 PM, Jerry Malcolm wrote:

Phil,

Thanks for the response.  I saw that note in the docs that said the 
removeAbandonedOnMaintenance wouldn't do anything without an evictor 
service.  But removeAbandonedOnBorrow also requires an evictor 
service to run in order remove on borrow?  That's fine. Just a bit 
confusing that on-borrow requires a timed eviction run.  I'll do 
whatever it takes.  Again, just trying to figure it all out.


I am sorry.  My mistake.  I saw the removeAbandonOnMaintenance and not 
the other one.  You are correct that with removeAbandonedOnBorrow on 
you should not need to have the evictor turned on (though it will 
obviously only run on borrow).  The docs could be clearer on this 
(seems some have been moved / deleted), but when 
removeAbandonedOnMaintenance is on, actual removal only happens when 
there are fewer than 2 idle objects available in the pool and 
getNumActive() > getMaxTotal() - 3.


Phil


Jerry

On 12/5/2021 12:19 PM, Phil Steitz wrote:
In order for abandoned connection cleanup to happen, you have to 
have configured a maintenance (aka "evictor") thread to run.  You 
need to set the value of timeBetweenEvictionRunsMillis to a positive 
number.


Phil

On 12/4/21 9:06 PM, Jerry Malcolm wrote:
I had a db connection leak in my code where an error condition 
would throw an exception and bypass the connection cleanup code. I 
found that and fixed it.  But before I found the problem, my 
program was overrunning the max connections and locking out.  It 
would take sometimes 12 hours after a reboot to go from 0 
connections to max. Normal steady state connections should 
currently be under 50.  The ramp over several hours to max was very 
obvious in my numActive log. What I'm confused about is why 
removeAbandoned didn't recover those connections.  Granted, if I 
write my code correctly, removeAbandoned shouldn't be necessary. 
The coding problem is solved now.  But apparently my 
understanding/configuration of removeAbandoned is not correct. I'd 
like to have that figured out in case there's a next time (which 
sadly there probably will be). Basically, with the 
configuration below, I'm not getting any idle connections detected 
and returned.  This is TC 8.5.73. And the leak was happening on a 
basic request/response (no threads involved).  I requested the 
connection, encountered an error, and returned without closing the 
connection. Ideas? Thx.





-
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



-
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: RemoveAbandoned Problems

[Phil Steitz]

On 12/5/21 2:34 PM, Jerry Malcolm wrote:

Phil,

Thanks for the response.  I saw that note in the docs that said the 
removeAbandonedOnMaintenance wouldn't do anything without an evictor 
service.  But removeAbandonedOnBorrow also requires an evictor service 
to run in order remove on borrow?  That's fine. Just a bit confusing 
that on-borrow requires a timed eviction run.  I'll do whatever it 
takes.  Again, just trying to figure it all out.


I am sorry.  My mistake.  I saw the removeAbandonOnMaintenance and not 
the other one.  You are correct that with removeAbandonedOnBorrow on you 
should not need to have the evictor turned on (though it will obviously 
only run on borrow).  The docs could be clearer on this (seems some have 
been moved / deleted), but when removeAbandonedOnMaintenance is on, 
actual removal only happens when there are fewer than 2 idle objects 
available in the pool and getNumActive() > getMaxTotal() - 3.


Phil


Jerry

On 12/5/2021 12:19 PM, Phil Steitz wrote:
In order for abandoned connection cleanup to happen, you have to have 
configured a maintenance (aka "evictor") thread to run.  You need to 
set the value of timeBetweenEvictionRunsMillis to a positive number.


Phil

On 12/4/21 9:06 PM, Jerry Malcolm wrote:
I had a db connection leak in my code where an error condition would 
throw an exception and bypass the connection cleanup code. I found 
that and fixed it.  But before I found the problem, my program was 
overrunning the max connections and locking out.  It would take 
sometimes 12 hours after a reboot to go from 0 connections to max.  
Normal steady state connections should currently be under 50.  The 
ramp over several hours to max was very obvious in my numActive log. 
What I'm confused about is why removeAbandoned didn't recover those 
connections.  Granted, if I write my code correctly, removeAbandoned 
shouldn't be necessary. The coding problem is solved now.  But 
apparently my understanding/configuration of removeAbandoned is not 
correct. I'd like to have that figured out in case there's a next 
time (which sadly there probably will be).  Basically, with the 
configuration below, I'm not getting any idle connections detected 
and returned.  This is TC 8.5.73.  And the leak was happening on a 
basic request/response (no threads involved).  I requested the 
connection, encountered an error, and returned without closing the 
connection.  Ideas? Thx.





-
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



-
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

thread pool count never goes down

[Jonathan Yom-Tov]

hi,

I have a single instance of Tomcat (version 9.0.54) in which the thread
count on a connector thread pool doesn't reduce despite most of the threads
(198/200) being idle. If I understand correctly the default idle time
before a thread is reaped is 60 seconds, but this situation persists for
hours. Any ideas for why this could happen?

Re: Tomcat Service Update throws Application System Error - Error Parsing Command Line

[Konstantin Kolinko]

пн, 6 дек. 2021 г. в 12:28, Ponnusamy, Prabhakar
:
>
> Tomcat User Community,
>
>
>
> I am trying to update the options of tomcat using the //US command line 
> option, but getting this error - Application System Error - Error Parsing 
> Command Line, below is how I was trying to run the commands, but no success. 
> Both in tomcat7 and tomcat9, I am getting the same error, tried with another 
> machine too.
>
>
>
> tomcat9w.exe //US/Passport --Description="test"
> tomcat9w.exe //US/Passport ++Description="test"
>
> [...]
> Please note that ES option works.

https://tomcat.apache.org/tomcat-9.0-doc/windows-service-howto.html

"//US//" is a command for "tomcat9.exe",
but "//ES//" is for tomcat9w.exe. That is why they are listed in
separate tables in documentation.

BTW,
a) if you look into service.bat file lines 212-232, it uses whitespace
instead of a '=' character to separate option and its value.

b) See also original Commons Daemon documentation at
https://commons.apache.org/proper/commons-daemon/procrun.html


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat Service Update throws Application System Error - Error Parsing Command Line

[Ponnusamy, Prabhakar]

Tomcat User Community,

I am trying to update the options of tomcat using the //US command line option, 
but getting this error - Application System Error - Error Parsing Command Line, 
below is how I was trying to run the commands, but no success. Both in tomcat7 
and tomcat9, I am getting the same error, tried with another machine too.

tomcat9w.exe //US/Passport --Description="test"
tomcat9w.exe //US/Passport ++Description="test"

[cid:image001.png@01D7EAB1.5472A730]

I also tried executing this through powershell, there as well no success, so 
any help is appreciated. Neither from Tomcat help page 
https://tomcat.apache.org/findhelp.html nor in Stackoverflow or Google, I could 
see a resolution for this. Please note that ES option works.

PS C:\tomcat\bin> Start-Process tomcat9w.exe -ArgumentList "//US//Passport 
--Description=`"test`""
PS C:\tomcat\bin> Start-Process tomcat9w.exe -ArgumentList "//US//Passport 
--Description='"test'""
PS C:\tomcat\bin> Start-Process tomcat9w.exe -ArgumentList '//US//Passport 
--Description="test"'
PS C:\tomcat\bin> Start-Process tomcat9w.exe -ArgumentList "//US//Passport 
--Description=test"
PS C:\bin> Start-Process tomcat9w.exe -ArgumentList '//US//Passport 
--Description=test'

Regards,
P.Prabhakar

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org