Vulnerability on Apache Tomcat Default Files

[FANG YAP]

Hello Apache Tomcat,

I have an issue on the subject mentioned as the vulnerability scan flagged
out.

Plugin: 12085
Plugin Text: Apache Tomcat Default Files
Protocol: TCP
Port: 8080

Apache Tomcat 8.5.55 (x64-bit machines)

In my app folder (located in the webapp folder) I already had the necessary
error pages. Also indicated the error jsp file in the app's web.xml. How to
know what should be shown when they(user) enter the wrong site for tomcat?

Should it be showing this page below or it should show my custom error page
set in app's web.xml?
HTTP 404 No Found
The webpage cannot be found..
Most likely causes:...
- There might be a typing error in the address
- If you clicked on a link, it may be out of date

What you can try:
.

Rgs,
Fang

Re: Reloading JNDI

[Phil Steitz]

On 7/24/20 10:46 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I have a JNDI  which is a JDBC DataSource. It is set to
singleton="true" via defaults (not explicitly set).

The JDBC Connections in this DataSource pool (using dbcp2 as provided
by Tomcat) have TLS configuration including client certificates,
trusted server certificates, etc.

I'd like to be able to "bounce" the DataSource so that each Connection
is re-established in order to pick-up any new TLS configuration --
specifically, reloading the key store and trust store for the connection
.

What's the best way to do that?


Do you want the connections that are checked out to clients to be 
force-closed, so they will get exceptions when they try to use them, or 
are you OK waiting until they get returned to the pool?


If you are OK being kind to clients, there is an enhancement request 
pending for DBCP (https://issues.apache.org/jira/browse/DBCP-559) 
 that might do what you 
want.  I  have not tested this, but I suspect that BDS closed followed 
by "open" (new method proposed, to be JMX-exposed) would cause idle 
connections to be closed immediately, checked out to be closed when they 
come back and new ones to be created in a new pool created by the open 
request.


If you really need to kill them all immediately, that would (as Mark 
said) require an invalidateAll or somesuch method added to commons pool, 
then exposed by DBCP as maybe closeAll.


Phil



It looks like Tomcat will automatically register a JMX bean for the
DataSource under
/Catalina:DataSource/[host]/[webapp]/javax.sql.DataSource/[dataSourceNam
e].
That JMX Bean has a "close" method that can be called. Calling "close"
seems to kill the DataSource, but a webapp reload can resurrect it.

There is also an "evict" method which takes zero arguments; that
appears to call the DBCP2 eviction process which removes "old" pool
members, not all.

I wasn't able to find anything else via the JMX method.

The class of the DataSource coming back from the JNDI lookup is
org.apache.tomcat.dbcp.dbcp2.BasicDataSource. It looks like I might be
able to downcast the object and call some other methods to stop /
restart it, but that seems fragile.

BasicDataSource.getConnectionPool is protected, but could be
forced-open via reflection without a SecurityManager (yuck). Then
GenericObjectPool.clear() could be called, but that only affects idle
connections in the pool and you can't be sue you've evicted all of them.

Any suggestions, other than reloading the context? I'm looking for a
zero-downtime solution.

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8bHoUACgkQHPApP6U8
pFgfqhAAol3JNOn/PIBZ0jD53N/jfIYjycF9NhHZ3EK7wMrB/clAl6rOVvR72C0E
ljt7Q2zx69+tTezd6yOqx5KejCU6oF9bVBR1NDdwAf1QPG50m+B35k6S2Aj6o3Ge
+5RNMS2OVDYHKi5nIxS5N1y8LtVcWBbo1LQN+QTjV6e5nEztg+fLct+HtDhwNYIv
KwRDiDeztR/ulxKrDEHpuJzUHmIa+c+hD6teYLLPtEcOD11fXXO/VTtO3ZL37qCn
JhEjb5ysoqHuIUH82CjzBghsEliZPczue5u7eaGhccnXR9y9WMM59yIf2jd3AH2L
2RVtw1/txdo3YmUGLJUi5IFQkQ8C8d13dSKT7I/KqO9NFywkiIPp7kimHmLdxvK5
vGJYFvZ6GV22oHWT0OaytaqbL1v4lf58k3frtt3bLRV7+2l78XUmsGsVksBr+3E+
7S0nFw7Cc7vvDJP0euvHlZEEoK+EsnTtDLd7EoFLU6Mct2U58NT1nmp5Aepnia8/
oKSAd1SaHiPCZeqHadQl8N4dyTuRKtwbH1Hlv9+o7hnyISLcwf5Nx9PHjgVn9BEZ
aOqpC5C0JxpGLXKDt4wTwjiIXdGo8c2T7pSV/pP82GnMhWAyHvGV1DPNHTvdoEKW
Y4Z/azWfNdKPbKxHcOgu3Lfx2oDFpDn40Yx5SK823ERn/hNUTG4=
=KgAg
-END PGP SIGNATURE-

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

Tomcat 9 Catalina Logging issue

[Campbell, Lance]

Apache Tomcat Version 9.0.37

I just upgraded to this version.  When I start tomcat sometimes it generates a 
“logs/catalina.out” file and other times it does not.  What is going on? Is 
anyone else having this issue?

I always get a catalina.2020-08-03.log .  However, it is lacking all of my 
startup info that is in the catalina.out file.

Any help on identifying this issue would be most appreciated.

Thanks,


LANCE CAMPBELL
Software Architect

Web Services
Public Affairs
Contact the Webtools Team
217.333.0382
la...@illinois.edu


[/var/folders/wp/1f6l7hw95y718z976kgnl5f9kr5rtc/T/com.microsoft.Outlook/WebArchiveCopyPasteTempFiles/signature_logo.png]

Under the Illinois Freedom of Information Act any written communication to or 
from university employees regarding university business is a public record and 
may be subject to public disclosure.

Re: Reloading JNDI

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/2/20 11:55, Mark Thomas wrote:
> On July 24, 2020 5:46:45 PM UTC, Christopher Schultz
 wrote:
> All,
>
> I have a JNDI  which is a JDBC DataSource. It is set to
> singleton="true" via defaults (not explicitly set).
>
> The JDBC Connections in this DataSource pool (using dbcp2 as
> provided by Tomcat) have TLS configuration including client
> certificates, trusted server certificates, etc.
>
> I'd like to be able to "bounce" the DataSource so that each
> Connection is re-established in order to pick-up any new TLS
> configuration -- specifically, reloading the key store and trust
> store for the connection .
>
> What's the best way to do that?
>
> It looks like Tomcat will automatically register a JMX bean for
> the DataSource under
> /Catalina:DataSource/[host]/[webapp]/javax.sql.DataSource/[dataSourceN
am
>
>
e].
> That JMX Bean has a "close" method that can be called. Calling
> "close" seems to kill the DataSource, but a webapp reload can
> resurrect it.
>
> There is also an "evict" method which takes zero arguments; that
> appears to call the DBCP2 eviction process which removes "old"
> pool members, not all.
>
> I wasn't able to find anything else via the JMX method.
>
> The class of the DataSource coming back from the JNDI lookup is
> org.apache.tomcat.dbcp.dbcp2.BasicDataSource. It looks like I might
> be able to downcast the object and call some other methods to stop
> / restart it, but that seems fragile.
>
> BasicDataSource.getConnectionPool is protected, but could be
> forced-open via reflection without a SecurityManager (yuck). Then
> GenericObjectPool.clear() could be called, but that only affects
> idle connections in the pool and you can't be sue you've evicted
> all of them.
>
> Any suggestions, other than reloading the context? I'm looking for
> a zero-downtime solution.
>
> Thanks, -chris
>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> Short of code changes, I think you have identified all the
> solutions I can think of.> If you want to be able to force a
> refresh of all the objects in the pool then you'd have to start
> with code changes to Commons Pool.
Okay. If I can come up with some suggestions, it that something you
could look at getting into upstream? We can modify our own copy of
course (have we diverged significantly at this point? Or was that
pre-dbcp-2.x?) but upstream is better IMO if possible.

> Could you do something with the validation query? Something that
> queried some database provided env var that told you if the
> current cert was being used? That would require a round trip though
> which would be slow.
Yeah, that might be slow. I'm also not sure what my options are for
querying the current client certificate being used.

> How about simply dropping all the connections at the database
> server side? The next validation query fails and picks up a new
> connection. Assuming you updated the files on the client side I
> think you would pick up the new config.

That sounds wonderfully hacky, but what I really need to do is have
the pool reconfigure the driver with a "new" connection URL. The URL
of course won't have changed, but presumably re-initing the pool will
cause everything to be re-read, including (my goal) the keystore.

Now, maybe I'm putting too much faith in the DriverManager and/or JDBC
driver. It's possible that I will have to literally change the URL in
some trivial way so that the DM/driver doesn't just say "oh, I have
one of those already!" and return the existing objects.

Certainly further testing of those components is warranted before
proceeding any further with the connection pool. It might all be
wasted effort.

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8oPB0ACgkQHPApP6U8
pFibNw/+MwUGt+aohxG6jQOup3TKCTC5B6aXEO6VByJq/9DOETlngiFXJGE+lctA
H3Ma+Kr+VpOvEzXxtxEDcvZlTwLy3dGWsiXeR0EDDZEoSwxDDg6LmRwWAfdT1OBo
dRc904x9N2njA302LpPLiS7auNxO0njzkCcS/J3q2GqnwMRBFPJlPWQryxwkw5HX
Ro3FtJf6Y8YbOLH7JuetQtAa7Czqs6MY8YlvqJP03hkboyX3hUQ3AwcY+XOJ7KQR
OAUdtQFqc6b3QoNtahXmv3LsQYH6me/Nc1yzCHh0hDJ22SKCDzEUN9hEyOLu3LrF
+W6Wgop7Bx75WroDWbf4aJ4fEWGzOOJn8VMN3xDJeANO0O1e/W1u4ftFOP6lEuZJ
UNvDswdj1JmcbhxKWzgkkz0IAUnnY0h49tSpYD+zkwi1wgf3yGhQY05gadhqXfH1
lN9mL7spHJrNnmmDUphoszDCkn0ZxmXU8xTl14vXHsl04FNbmJegzq99nlr1x7Z7
H3ZOVJzb3wBXK3ctKJGsJ8eJ6eIQBn5rFtd+fMqoI+2mamkvXjy7GRtnm8wAwECP
noTwHb69IW0KZtriXFSsfi3l2pBT3WtNYHZjJapeNy1uW11YnKlLOzb5ZUrtYi7N
UHSfpLP4Lk7olcoq/7yF91tIfY27FwTew2CYTCef6uL2SeZPyAk=
=DMvU
-END PGP SIGNATURE-

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