[SECURITY] CVE-2025-46701 Apache Tomcat - CGI security constraint bypass

2025-05-29 Thread Mark Thomas 

CVE-2025-46701 Apache Tomcat - CGI security constraint bypass

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.6
Apache Tomcat 10.1.0-M1 to 10.1.40
Apache Tomcat 9.0.0.M1 to 9.0.104

Description:
When running on a case insensitive file system with security constraints 
configured for the pathInfo component of a URL that mapped 
to the CGI servlet, it was possible to bypass those security constraints 
with a specially crafted URL.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.7 or later
- Upgrade to Apache Tomcat 10.1.41 or later
- Upgrade to Apache Tomcat 9.0.105 or later

Credit:
The vulnerability was identified by Greg K (https://github.com/gregk4sec)

History:
2025-05-29 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

Re: Adding a CRL to certificate client authentication causes connector to stop responding to all requests having a client certificate.

2025-05-29 Thread My Subs 
Hello Chris,



Were you able to replicate the error on your side?



Best,



Alex



Sent using Zoho Mail








 On Thu, 22 May 2025 08:02:41 -0500 Christopher Schultz 
 wrote ---



Alex, 
 
On 5/21/25 9:01 PM, My Subs wrote: 
> Chris, 
> 
> 
> 
>> Is the client sending just their own cert, or also the chain? 
> It would 
>   be unusual for the client to send a chain, but instead 
> just sends their 
>   own leaf certificate. I'm assuming that both 
> the root and the 
>   intermediate / subordinate cert are both in 
> the trust store. Is that 
>   correct? 
> 
> 
> The client is 
> sending both the leaf and the intermediate certificates (both are in 
> the PKCS12 file imported into Firefox).  That's the only way for the 
> chain of trust to work, because only the root certificate is in the 
> trust store (well, that's how it's supposed to be, as far as I 
> understand).  And it works fine until the CRL comes into play. 
> 
> 
> 
> I also tested adding 
> the subordinate CA's certificate to the trust store.  No change. 
> With no CRL configured, works alright; but when it is configured, I 
> get the same errors.  Revoked client cert is rejected as such, and 
> valid client cert is rejected with SSL_ERROR_UNKNOWN_CA_ALERT. 
> 
> 
> 
> 
>> Can 
> you please try one more thing for me? 
> 
>   > Can 
> you create a self-signed certificate, and use ONLY that self-signed 
>   certificate in your trust store, and have the client send that 
> to the 
>   server? 
> 
>   > It will be easier 
> for me if I just have to deal with a single cert on 
>   either side 
> of the connection rather than set up a whole signing 
>   authority, 
> etc. before I'm able to reproduce it. 
> 
> 
> 
> Done.  Removed root CA certificate from trust store, and left only a 
> self-signed certificate.  The result is exactly the same.  With no 
> CRL checking, it works fine.  Add CRL checking, and I get: "Peer 
> does not recognize and trust the CA that issued your certificate. 
> Error code: SSL_ERROR_UNKNOWN_CA_ALERT" 
 
Perfect. That will make it a lot easier for me to duplicate your setup. 
 
> Guess the finger 
> increasingly points to the CRL checking code. 
 
Agreed, at least in theory. 
 
-chris 
 
>  On Wed, 21 May 2025 16:29:10 -0500 Christopher Schultz 
>  wrote --- 
> 
> 
> 
> Alex, 
> 
> On 5/21/25 1:26 PM, My Subs wrote: 
>> To test this, I set 
>> certificateRevocationListPath to the directory having the CRL file; 
>> changed to certificateVerification="optional"; and 
>> downgraded to HTTP 1.1 (as mentioned, "optional" does not 
>> work with HTTP 2).  The result is that requests without a client 
>> certificate get a 200 OK response. 
> 
> Good. 
> 
>> However, *all* requests having a client certificate (valid or 
>> revoked) are rejected. 
> 
> Okay. 
> 
>> If the client certificate is revoked, it is correctly identified as 
>> such.  Firefox displays message "SSL peer rejected your 
>> certificate as revoked.  Error code: SSL_ERROR_REVOKED_CERT_ALERT". 
> 
> Good! 
> 
>> If the client certificate is not revoked, the connection fails with 
>> Firefox displaying an unexpected message: "Peer does not 
>> recognize and trust the CA that issued your certificate.  Error code: 
>> SSL_ERROR_UNKNOWN_CA_ALERT". 
> 
> Obviously, not good. 
> 
> But I wonder if this is a problem with adding the CRL (which looks like 
> it's working) versus the trust store. But... 
> 
>> But that same issuing CA is perfectly recognized when the 
>> certificateRevocationListPath attribute is removed from the 
>> connector. 
> Yeah, I was afraid you'd say that. 
> 
>> Requests with a non-revoked client certificate get a 200 OK 
>> response, and that certificate is made visible to servlets as a 
>> java.security.cert.X509Certificate object. This holds both for 
>> "optional" and> "required" verification. 
>   > > It's CRL checking what triggers the error. 
>> 
>> I'm 
>> not sure whether the message "No client certificate 
>> CA names sent" means a problem with the trust store.  As you can 
>> see from my connector, caCertificatePath is set to the trust store 
>> directory. It 
>> contains the certificate of the root CA, which signed the certificate 
>> of the subordinate CA.  The client certificates used in the above 
>> test are signed by that subordinate CA.  And as 
>> shown, those are correctly verified when no CRL is configured. 
> 
> Is the client sending just their own cert, or also the chain? It would 
> be unusual for the client to send a chain, but instead just sends their 
> own leaf certificate. I'm assuming that both the root and the 
> intermediate / subordinate cert are both in the trust store. Is that 
> correct? 
> 
>>> If you do not configure the CRL, are any CA certs listed in 
>> this output? 
>> 
>> No.  Message "No client certificate CA names sent" is still there. 
>> The full output is: 
>   > > [snip] 
>   > 
>> --- 
>> 
>> No client certificate CA names sent 
> 
> Okay. 
>

Re: adding new SSL certificate without restarting tomcat

2025-05-29 Thread Mark Thomas 

On 29/05/2025 07:59, Ivano Luberti wrote:
Thanks Chris, yes that's what I tried to explain from the beginning, 
sorry I wasn't clear enough.


To summarize: there is no solution out of the box, I have to develop 
something.


I will look into that.


Just out of interest, what problem are you trying to solve? Depending on 
the problem, there may be other solutions.


Mark



Thanks everyone

Il 28-May-25 14:43, Christopher Schultz ha scritto:

Ivano,

On 5/28/25 4:17 AM, Ivano Luberti wrote:

Thanks for all the responses. I try to be more clear.

My server.xml configuration contains a few SSLHostConfig 
configurations like this






certificateKeystoreFile="/etc/ssl/LetsEncrypt/host domain.it/host 
domain.it.pfx"


certificateKeystorePassword="passwrod"

certificateKeystoreType="PKCS12"

/>





after certificate renewal, reloadin the certificate is no concern.

But if I add (or remove)  a new SSLHostConfig,  tomcat needs to be 
restarted in order to take into account the new configuration.


I would like to know if there is a way to configure tomcat so avoid 
restart.


Even using a different way to configure tomcat outside of server.xml 
using a different certificate format or whatever.


Okay, so you don't mean reconfiguring an existing SSLHostConfig. You 
mean adding a new one (or removing an old one).


You should connect to Tomcat using JMX to see all of the remote- 
management capabilities it has. You are able to use JMX to create 
SSLHostConfig settings on the fly, reconfigure connectors, etc. 
without restarting the JVM.


-chris


Il 28-May-25 09:49, Michael Osipov ha scritto:

On 2025/05/27 20:11:25 Ivano Luberti wrote:

Hi all, is there a way to configure tomcat in order to avoid restart
when I change the list of ssl certificates?

I know and I do it, how to reload existing certificates, but I'm
searching a qay to avoid reloading when I add or remove a certificate.

I'm using Tomcat 9 , but looking for solution also in tomcat 10 or 11.
RTFM:https://tomcat.apache.org/tomcat-11.0-doc/api/org/apache/ 
catalina/security/TLSCertificateReloadListener.html?


Works for me very well.

-
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: adding new SSL certificate without restarting tomcat

2025-05-29 Thread Ivano Luberti 
Thanks Chris, yes that's what I tried to explain from the beginning, 
sorry I wasn't clear enough.


To summarize: there is no solution out of the box, I have to develop 
something.


I will look into that.

Thanks everyone

Il 28-May-25 14:43, Christopher Schultz ha scritto:

Ivano,

On 5/28/25 4:17 AM, Ivano Luberti wrote:

Thanks for all the responses. I try to be more clear.

My server.xml configuration contains a few SSLHostConfig 
configurations like this




ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_CAMELLIA_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_CAMELLIA_128_CBC_SHA"> 



certificateKeystoreFile="/etc/ssl/LetsEncrypt/host domain.it/host 
domain.it.pfx"


certificateKeystorePassword="passwrod"

certificateKeystoreType="PKCS12"

/>





after certificate renewal, reloadin the certificate is no concern.

But if I add (or remove)  a new SSLHostConfig,  tomcat needs to be 
restarted in order to take into account the new configuration.


I would like to know if there is a way to configure tomcat so avoid 
restart.


Even using a different way to configure tomcat outside of server.xml 
using a different certificate format or whatever.


Okay, so you don't mean reconfiguring an existing SSLHostConfig. You 
mean adding a new one (or removing an old one).


You should connect to Tomcat using JMX to see all of the 
remote-management capabilities it has. You are able to use JMX to 
create SSLHostConfig settings on the fly, reconfigure connectors, etc. 
without restarting the JVM.


-chris


Il 28-May-25 09:49, Michael Osipov ha scritto:

On 2025/05/27 20:11:25 Ivano Luberti wrote:

Hi all, is there a way to configure tomcat in order to avoid restart
when I change the list of ssl certificates?

I know and I do it, how to reload existing certificates, but I'm
searching a qay to avoid reloading when I add or remove a certificate.

I'm using Tomcat 9 , but looking for solution also in tomcat 10 or 11.
RTFM:https://tomcat.apache.org/tomcat-11.0-doc/api/org/apache/ 
catalina/security/TLSCertificateReloadListener.html?


Works for me very well.

-
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


--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



Il contenuto di questo messaggio e dei suoi eventuali allegati è 
riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di 
contattare telefonicamente o via e-mail il mittente ai recapiti sopra 
indicati e di cancellare il messaggio e gli eventuali allegati dal Suo 
sistema senza farne copia o diffonderli. Le opinioni espresse sono 
quelle dell'autore e non rappresentano necessariamente quelle della Società.
This message and any attachment are confidential.If you are not the 
intended recipient, please telephone or email the sender and delete this 
message and any attachment from your system. If you are not the intended 
recipient you must not copy this message or attachment or disclose the 
contents to any other person. Any opinions presented are solely those of 
the author and do not necessarily represent those of the Company.


dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/