About whether the described env is safe from CVE 2024-50379 and 56337

[Nguyen Duong]

Hi Tomcat team

I am really sorry to bother you regarding this fix for Tomcat 9.0.98 revolving 
around the following CVEs,
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-50379
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56337

(★) My question is if we install our Tomcat 9.0.97 (or lower version) on 
Windows OS (Case Insensitive), and the default value of DefaultServlet Write 
Enabled is FALSE (Since readonly parameter is not touched)
Then I should not be concerned about the CVE since its first and foremost 
important condition is below right?
> If the default servlet is write enabled (readonly initialisation parameter 
> set to the non-default value of false) for a case insensitive file system
Meaning  with the env described in (★) the CVEs are not a concern, and I do NOT 
have to even set sun.io.useCanonCaches to false on Tomcat9w.exe right?

I am trying to avoid upgrade or restarting my Tomcat.

Best regards,
Nguyen



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

Content type unknown after upgrading Tomcat 10.1.39 => 10.1.40

[Thorsten Heit]

Hi all,

long time Tomcat user, but first time I'm posting, so hi to you all :-)

I'm suffering a strange phenomenon after I upgraded Tomcat on one of our 
virtual machines from 10.1.39 to 10.1.40:


When I open the link to an application being served by Tomcat my browser 
(Firefox) now downloads a file instead of displaying the (generated) 
HTML page. With the network inspector I discovered that the content-type 
in the response is set to "content/unknown;charset=UTF-8". When 
reverting back to 10.1.39 everything works; the content-type in the 
response is (as expected) "text/html;charset=UTF-8".


In the changelog I haven't seen anything regarding this.

The configuration files used to start Tomcat are exactly the same in 
both scenarios, and the application isn't changed.


Can anyone explain what's happening?

Tomcat: 10.1.39 / 40
Java: openjdk-21.0.6
OS: Ubuntu 24.04.2 LTS


Best regards

Thorsten

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

Re: Content type unknown after upgrading Tomcat 10.1.39 => 10.1.40

[Christopher Schultz]

Thorsten,

On 4/16/25 2:35 PM, Thorsten Heit wrote:

long time Tomcat user, but first time I'm posting, so hi to you all :-)

I'm suffering a strange phenomenon after I upgraded Tomcat on one of our 
virtual machines from 10.1.39 to 10.1.40:


When I open the link to an application being served by Tomcat my browser 
(Firefox) now downloads a file instead of displaying the (generated) 
HTML page. With the network inspector I discovered that the content-type 
in the response is set to "content/unknown;charset=UTF-8". When 
reverting back to 10.1.39 everything works; the content-type in the 
response is (as expected) "text/html;charset=UTF-8".


In the changelog I haven't seen anything regarding this.

The configuration files used to start Tomcat are exactly the same in 
both scenarios, and the application isn't changed.


Can anyone explain what's happening?

Tomcat: 10.1.39 / 40
Java: openjdk-21.0.6
OS: Ubuntu 24.04.2 LTS


That definitely sounds odd. Do you have anything on the network between 
the client (browser) and the server (Tomcat)? Specifically, anything 
like a load-balancer, proxy, or similar?


I just want to remove other possible causes before diving into Tomcat 
(but from your description, Tomcat does seem to be the suspicious 
component, here).


-chris


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

Re: Content type unknown after upgrading Tomcat 10.1.39 => 10.1.40

[Thorsten Heit]

Hi Chris,

That definitely sounds odd. Do you have anything on the network between 
the client (browser) and the server (Tomcat)? Specifically, anything 
like a load-balancer, proxy, or similar?


I just want to remove other possible causes before diving into Tomcat 
(but from your description, Tomcat does seem to be the suspicious 
component, here).


No, there's nothing in between me and Tomcat. It's reproducible also by 
directly using curl on the command line:


"curl -v --insecure --noproxy '*' https://.../"; gives me the following 
on 10.1.39 (private data replaced for security):



Note: Using embedded CA bundle (233263 bytes)
Note: Using embedded CA bundle, for proxies (233263 bytes)
  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
 Dload  Upload   Total   SpentLeft 
Speed
  0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0* Host myhost.example.com:8448 was resolved.

* IPv6: 2a02:5a0:f019:1:4448:4350:a9b4:9022
* IPv4: 10.192.141.7
*   Trying [2a02:5a0:f019:1:4448:4350:a9b4:9022]:8448...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [317 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Unknown (8):
{ [41 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [5210 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [520 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: ...
*  start date: May  6 10:01:48 2024 GMT
*  expire date: Dec 26 10:01:48 2048 GMT
*  issuer: ...
*  SSL certificate verify result: self signed certificate in certificate 
chain (19), continuing anyway.
*   Certificate level 0: Public key type ? (4096/128 Bits/secBits), 
signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type ? (4096/128 Bits/secBits), 
signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type ? (4096/128 Bits/secBits), 
signed using sha512WithRSAEncryption
* Connected to myhost.example.com (2a02:5a0:f019:1:4448:4350:a9b4:9022) 
port 8448

* using HTTP/2
* [HTTP/2] [1] OPENED stream for 
https://myhost.example.com:8448/my/servlet/app?version=!!1.22.32-4-g8a3c060!!

* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: myhost.example.com:8448]
* [HTTP/2] [1] [:path: /my/servlet/app?version=!!1.22.32-4-g8a3c060!!]
* [HTTP/2] [1] [user-agent: curl/8.12.1]
* [HTTP/2] [1] [accept: */*]
> GET /my/servlet/app?version=!!1.22.32-4-g8a3c060!! HTTP/2
> Host: myhost.example.com:8448
> User-Agent: curl/8.12.1
> Accept: */*
>
* Request completely sent off
  0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0< HTTP/2 200

< cache-control: max-age=0
< expires: Wed, 16 Apr 2025 16:22:16 GMT
< content-type: text/html;charset=UTF-8
< content-length: 7999
< date: Wed, 16 Apr 2025 16:22:16 GMT
<
{ [7999 bytes data]
100  7999  100  79990 0  31126  0 --:--:-- --:--:-- --:--:-- 
31246

* Connection #0 to host myhost.example.com left intact


With 10.1.40 using exactly the same command the result is the same apart 
from the content-type:


(...)
* Request completely sent off
  0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0< HTTP/2 200

< cache-control: max-age=0
< expires: Wed, 16 Apr 2025 16:19:48 GMT
< content-type: content/unknown;charset=UTF-8
< content-length: 7999
< date: Wed, 16 Apr 2025 16:19:48 GMT
<
{ [7999 bytes data]
100  7999  100  79990 0  32015  0 --:--:-- --:--:-- --:--:-- 
32124



This is what's puzzling me...


BTW, I'm using a system-wide Tomcat installation under /usr/local/share 
and a user installation with its own ./conf directory; basically the 
same what Ubuntu is offering via the packages "tomcat10-common" and 
"tomcat10-user".
This way I can switch the Tomcat version to be used by simply changing 
the CATALINA_HOME variable in the startup script. But I guess this 
shouldn't matter...



Regards

Thorsten

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

Tomcat 11 catalina.policy file removed

[S Abirami]

Hi All,

After upgrading to Tomcat 11, I noticed Catalina.policy file removed from the 
tomcat.
I haven't see any specific documentation regarding it in tomcat release note, 
migration guide etc.

But Gen AI provides the following input, please let me know the following input 
is right/wrong?

The catalina.policy file was removed in Apache Tomcat 11 and later versions 
because the Java SecurityManager, which this file was used to configure, has 
been deprecated and removed in later versions of Java. This change aligns with 
Java's move towards more modern security practices.
Here's a more detailed explanation:

  *   SecurityManager Deprecation:
The Java SecurityManager, which enforced security policies, has been deprecated 
in Java 17 and marked for removal in later versions.

  *   Tomcat 11 Adherence:
Tomcat 11 and later versions align with these Java changes by removing the 
SecurityManager and consequently the catalina.policy file.

  *   Alternative Security Mechanisms:
While the SecurityManager is gone, Tomcat still provides security features 
through other mechanisms like role-based access control and access control 
lists (ACLs).

  *   Security Considerations:
If you are using older versions of Tomcat (prior to 11), you may still need to 
manage the catalina.policy file to control permissions for internal Tomcat 
components and applications, according to 
OpenLogic.

  *   Upgrade Implications:
If you are upgrading to Tomcat 11 or later, you should remove the 
catalina.policy file and review your security configurations to utilize the new 
security mechanisms, as explained in the migration guide.



Regards,
Abirami.S

Re: Tomcat 11 catalina.policy file removed

[Rémy Maucherat]

On Wed, Apr 16, 2025 at 9:14 AM S Abirami
 wrote:
>
> Hi All,
>
> After upgrading to Tomcat 11, I noticed Catalina.policy file removed from the 
> tomcat.
> I haven't see any specific documentation regarding it in tomcat release note, 
> migration guide etc.

The security manager support has been removed in Tomcat 11. As Oracle
reviewed usage of the feature, which added a TON of complexity in the
Java codebase, Tomcat was found to be one of the very few "good" uses
of it out there. This was not sufficient justification to keep it
around, esp since the supposedly good use case had been mostly
replaced with containerization.

Rémy

> But Gen AI provides the following input, please let me know the following 
> input is right/wrong?
>
> The catalina.policy file was removed in Apache Tomcat 11 and later versions 
> because the Java SecurityManager, which this file was used to configure, has 
> been deprecated and removed in later versions of Java. This change aligns 
> with Java's move towards more modern security practices.
> Here's a more detailed explanation:
>
>   *   SecurityManager Deprecation:
> The Java SecurityManager, which enforced security policies, has been 
> deprecated in Java 17 and marked for removal in later versions.
>
>   *   Tomcat 11 Adherence:
> Tomcat 11 and later versions align with these Java changes by removing the 
> SecurityManager and consequently the catalina.policy file.
>
>   *   Alternative Security Mechanisms:
> While the SecurityManager is gone, Tomcat still provides security features 
> through other mechanisms like role-based access control and access control 
> lists (ACLs).
>
>   *   Security Considerations:
> If you are using older versions of Tomcat (prior to 11), you may still need 
> to manage the catalina.policy file to control permissions for internal Tomcat 
> components and applications, according to 
> OpenLogic.
>
>   *   Upgrade Implications:
> If you are upgrading to Tomcat 11 or later, you should remove the 
> catalina.policy file and review your security configurations to utilize the 
> new security mechanisms, as explained in the migration guide.
>
>
>
> Regards,
> Abirami.S

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

Re: About whether the described env is safe from CVE 2024-50379 and 56337

[Mark Thomas]

On 16/04/2025 18:20, Nguyen Duong wrote:

Hi Tomcat team

I am really sorry to bother you regarding this fix for Tomcat 9.0.98 revolving 
around the following CVEs,
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-50379
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56337

(★) My question is if we install our Tomcat 9.0.97 (or lower version) on 
Windows OS (Case Insensitive), and the default value of DefaultServlet Write 
Enabled is FALSE (Since readonly parameter is not touched)
Then I should not be concerned about the CVE since its first and foremost 
important condition is below right?


Correct.


If the default servlet is write enabled (readonly initialisation parameter set 
to the non-default value of false) for a case insensitive file system

Meaning  with the env described in (★) the CVEs are not a concern, and I do NOT 
have to even set sun.io.useCanonCaches to false on Tomcat9w.exe right?


Correct.


I am trying to avoid upgrade or restarting my Tomcat.


Based on the information you have provided, that should not be necessary.

Mark




Best regards,
Nguyen



  
-

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