Re: Tomcat 9 on Debian 12

[Chuck Caldarale]

> On 2025 Mar 10, at 18:06, Jason Bailey  
> wrote:
> 
> I'm running Tomcat 9 on Debian 12 to run Apache Guacamole and am trying
> to get the tomcat-users.xml file to take so that I can manage the
> service from the Tomcat Manager. So far I have not had luck getting the
> login dialog to the manager to accept any xml file I give it.
> 
> First, where should I be putting the tomcat-users.xml file? Is there a
> special place I should be putting this file?


The location of tomcat-users.xml is specified in Tomcat’s server.xml file. On a 
real Tomcat distribution (one downloaded from tomcat.apache.org 
), both server.xml and tomcat-users.xml are located 
in the conf directory, which itself is inside the directory in which you 
installed Tomcat. If you’re using a Debian-provided package, you may have to 
hunt for them, since such packages do not use Tomcat’s standard directory 
layout and may modify the standard settings in the server.xml file.

Note that it’s best to modify the provided tomcat-users.xml file rather than 
trying to generate your own from scratch.


> Second, what is wrong with this config?
> 
> 
> 
> http://tomcat.apache.org/xml";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://tomcat.apache.org/xml
> tomcat-users.xsd"
>   version="1.0">
> 
> 


“admin-gui” is not a role used by the Tomcat manager webapp; why is it here?


> 


The “manager-gui” role is built-in, so you don’t have to specify it in the 
tomcat-users.xml file.


> 


The roles used by any webapp are declared in the app’s WEB-INF/web.xml file; 
there’s no “admin-gui” role for the manager webapp.


> 
> 
> The above isn't what I would call ideal credentials -- it's just
> something to test with, to get going, etc. If any of you have advice for
> getting this working I'd sure appreciate it.


Look in the catalina.out log file to see if you’re getting any errors during 
Tomcat initialization, which is when the tomcat-users.xml file is read. For 
real Tomcat downloads, catalina.out is in Tomcat’s logs directory; for package 
distributions, you’ll have to hunt for it.

  - Chuck

Tomcat 9 on Debian 12

[Jason Bailey]

I'm running Tomcat 9 on Debian 12 to run Apache Guacamole and am trying
to get the tomcat-users.xml file to take so that I can manage the
service from the Tomcat Manager. So far I have not had luck getting the
login dialog to the manager to accept any xml file I give it.

First, where should I be putting the tomcat-users.xml file? Is there a
special place I should be putting this file?

Second, what is wrong with this config?



http://tomcat.apache.org/xml";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://tomcat.apache.org/xml
tomcat-users.xsd"
   version="1.0">

 
 
 



The above isn't what I would call ideal credentials -- it's just
something to test with, to get going, etc. If any of you have advice for
getting this working I'd sure appreciate it.

Thanks


*Confidentiality Notice* This email message may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), you 
are hereby notified that any dissemination, distribution or copying of this 
email message is strictly prohibited. If you have received this email in error, 
please immediately notify the sender and delete this email message from your 
computer.

Has Tomcat 10 dropped support for using log4j2 as its default logger?

[Bruno Melloni]

*TLDR Question*:  Has Tomcat 10 dropped support for using log4j2 as its 
default logger?


Details:

I am wondering because after easily a decade of using log4j with 
Tomcat... it is now virtually impossible to find instructions (_that 
actually work_) for how to configure Tomcat 10 to use *Apache Log4j* as 
its default logger. Since both are Tomcat projects, the only explanation 
I could come up with is that maybe Apache Log4j is considered a dead 
project by Apache even if not announced as so.


And even though I think I figured out a configuration that appears to 
work, when I call shutdown.bat (and in a few other scenarios) I get the 
error:


*class org.apache.logging.log4j.jul.LogManager cannot be cast to class 
java.util.logging.Handler (org.apache.logging.log4j.jul.LogManager is in 
unnamed module of loader 'app'; java.util.logging.Handler is in module 
java.logging of loader 'bootstrap')*


I am using Java 17, Tomcat 10.1.7 and log4j 2.20.0.

Re: Has Tomcat 10 dropped support for using log4j2 as its default logger?

[Piotr P. Karwasz]

Hi Bruno,

On 10.03.2025 18:01, Bruno Melloni wrote:
I am wondering because after easily a decade of using log4j with 
Tomcat... it is now virtually impossible to find instructions (_that 
actually work_) for how to configure Tomcat 10 to use *Apache Log4j* 
as its default logger. Since both are Tomcat projects, the only 
explanation I could come up with is that maybe Apache Log4j is 
considered a dead project by Apache even if not announced as so.


The rumors about Apache Log4j death are greatly exaggerated. The easiest 
way to verify the status of an Apache project is to read the quarterly 
reports of the overseeing PMC[1].


There are two reasons, why Log4j and Tomcat are not more closely integrated:

1. Apache PMCs are very independent and there is no Foundation-wide rule 
that obliges a PMC to prefer dependencies produced by other Apache projects.


2. There are not many user requests to more closely integrate the two 
projects.


[1] https://whimsy.apache.org/board/minutes/Logging_Services.html


If you are looking for instructions on how to replace Tomcat's default 
logging backend with Log4j Core, there is a dedicated section[2] in our 
new Integrating Log4j Core with Jakarta EE Guide[3]


[2] https://logging.apache.org/log4j/2.x/jakarta.html#replace-tomcat

[3] https://logging.apache.org/log4j/2.x/jakarta.html


The above instructions only redirect server logs to Log4j Core, while 
web applications will use whatever logging backend they bundle. If you 
are looking for a tighter integration between server logs and webapp 
logs, I wrote a couple of Log4j Core Plugins and Tomcat Components[4] to 
better integrate the two. Basically what you need to do is:


1. Use a special web application classloader[5] that delegates the 
loading of `org.apache.logging.log4j.*` classes to the parent 
classloader (the standard classloader only delegates the loading of 
`jakarta.*` and `org.apache.tomcat.*` classes to the parent).


2. Use some strategy to distinguish between the logs sent by different 
web applications. There are basically two strategies available:


    * You can split your loggers in logger contexts using an 
appropriate Log4j Core context selector[6]. This way each web 
application can have its own configuration file (but doesn't need to). 
The naming strategy for logging configuration files is inspired by 
Tomcat's context configuration naming convention.


    * You can use a single logger context and use a Log4j Core context 
data provider[7] to enrich each message with the name of the context 
that generated it. This is probably the best strategy if you forward 
your logs to ElasticSearch or similar.


TL;DR: There is a short guide for my extensions at [8].

[4] https://oss.copernik.eu/tomcat/3.x/

[5] https://oss.copernik.eu/tomcat/3.x/components/tomcat-log4j#classloaders

[6] 
https://oss.copernik.eu/tomcat/3.x/components/log4j-tomcat#TomcatContextSelector


[7] 
https://oss.copernik.eu/tomcat/3.x/components/log4j-tomcat#TomcatContextDataProvider


[8] https://oss.copernik.eu/tomcat/3.x/guide

And even though I think I figured out a configuration that appears to 
work, when I call shutdown.bat (and in a few other scenarios) I get 
the error:


*class org.apache.logging.log4j.jul.LogManager cannot be cast to class 
java.util.logging.Handler (org.apache.logging.log4j.jul.LogManager is 
in unnamed module of loader 'app'; java.util.logging.Handler is in 
module java.logging of loader 'bootstrap')*


I am using Java 17, Tomcat 10.1.7 and log4j 2.20.0.


You are probably trying to use `o.a.l.l.jul.LogManager` in the 
`logging.properties` configuration file. To replace the default 
implementation of `java.util.logging.LogManager` you need to add:


LOGGING_MANAGER="org.apache.logging.log4j.jul.LogManager"

to your `setenv.sh` file. See the documentation on Log4j's website[9].


As alternative you can keep the default `o.a.juli.ClassLoaderLogManager` 
and use a single `org.apache.logging.log4j.jul.Log4jBridgeHandler` in 
your `logging.properties` file. This method introduces a considerable 
overhead to logging, so you should also set the `propagateLevels` 
property to `true` to mitigate it. See [10] for more details.


[9] https://logging.apache.org/log4j/2.x/log4j-jul.html#bridge-logmanager

[10] https://logging.apache.org/log4j/2.x/log4j-jul.html#bridge-handler


Piotr


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

[SECURITY] CVE-2025-24813 Potential RCE and/or information disclosure and/or information corruption with partial PUT

[Mark Thomas]

CVE-2025-24813 Potential RCE and/or information disclosure and/or 
information corruption with partial PUT


Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.2
Apache Tomcat 10.1.0-M1 to 10.1.34
Apache Tomcat 9.0.0.M1 to 9.0.98

Description:
The original implementation of partial PUT used a temporary file based 
on the user provided file name and path with the path separator replaced 
by ".".


If all of the following were true, a malicious user was able to view 
security sensitive files and/or inject content into those files:

- writes enabled for the default servlet (disabled by default)
- support for partial PUT (enabled by default)
- a target URL for security sensitive uploads that was a sub-directory
  of a target URL for public uploads
- attacker knowledge of the names of security sensitive files being
  uploaded
- the security sensitive files also being uploaded via partial PUT

If all of the following were true, a malicious user was able to perform 
remote code execution:

- writes enabled for the default servlet (disabled by default)
- support for partial PUT (enabled by default)
- application was using Tomcat's file based session persistence with
  the default storage location
- application included a library that may be leveraged in a
  deserialization attack

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.3 or later
- Upgrade to Apache Tomcat 10.1.35 or later
- Upgrade to Apache Tomcat 9.0.99 or later

Credit:
Information disclosure/corruption: COSCO Shipping Lines DIC
Remote code execution: sw0rd1ight (https://github.com/sw0rd1ight)

History:
2025-03-10 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html

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