You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2022/04/29 18:41:42 UTC
Tomcat mitigations for CVE-2022-21449
All,
CVE-2022-21449 is a bug in the JDK which allows a malicious signer using
ECDSA to forge a signature which an affected (buggy) verifier fails to
detect.
I used deliberate language above instead of "client" and "server"
because in many csases, the server is performing verification as well
(e.g. of a client's TLS certificate in a mutually-authenticated TLS
handshake).
This affects JDK versions from 15 - 18. Notably, Java 15 and 16 are EOL
and won't be getting any updates. This Isn't Good.
This wasn't as popular in the press as "log4shell" nor does it have as
exciting or sensational a name given to it, but it's still a pretty big
problem.
Tomcat is, of course, transiently affected by this bug under the
following conditions (all of which must be true, I believe):
1. The underlying JVM is affected
2. A Connector is defined with uses mutual TLS
3. The client's key is ECDSA
If all of the above are true, then anyone can impersonate any client to
the server. An attacker may need to find a /useful/ client to
impersonate, but usually, simply connecting to the server and askint
which clients are allowed is enough:
$ openssl s_client -connect host:port | grep 'Acceptable client'
Acceptable client certificate CA names
[...]
While we can't protect any *clients* against these attacks, we may be
able to protect *servers*.
What does the community think about Tomcat trying to prevent the use of
vulnerable configurations? Is it overstepping? Would it be helpful? I
think anyone running a vulnerable configuration should /really/ know
that they are vulnerable and be able to fix their environment. But lots
of environments are on auto-pilot.
I was thinking that on startup, we could check for a vulnerable
environment and simply refuse to start the server.
If there are no objections, I was thinking of putting this into the
SecurityListener. I assume that all the necessary information is
available to a LifecycleListener such as being able to enumerate the
Connectors to check on items #2 and #3 above?
Thanks,
-chris
[1] https://www.theregister.com/AMP/2022/04/20/java_authentication_bug/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat mitigations for CVE-2022-21449
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
Openj9 is not affected I think so version wouldnt be enough, jvm name
should be tested too.
Le sam. 30 avr. 2022 à 00:18, Mark Thomas <ma...@apache.org> a écrit :
> On 29/04/2022 19:41, Christopher Schultz wrote:
>
> <snip/>
>
> > 1. The underlying JVM is affected
> > 2. A Connector is defined with uses mutual TLS
> > 3. The client's key is ECDSA
>
> <snip/>
>
> > I was thinking that on startup, we could check for a vulnerable
> > environment and simply refuse to start the server.
> >
> > If there are no objections, I was thinking of putting this into the
> > SecurityListener. I assume that all the necessary information is
> > available to a LifecycleListener such as being able to enumerate the
> > Connectors to check on items #2 and #3 above?
>
> My understanding is that a CA with an RSA key can sign a client cert
> with an ECDSA key. In that scenario, if the Tomcat system has been
> configured with just the CA's trusted cert (a likely scenario since you
> don't want to have to updated the trusted certs every time you add a
> user) then test #3 won't work.
>
> I'm wondering if we want to introduce a Java version equivalent of the
> checks we have for Tomcat Native version. i.e. for each major Java
> version, have a minimum required version where Tomcat won't start if
> used and a recommended version where Tomcat starts with a warning.
>
> One of the arguments against adding checks like these is that they only
> work if folks update Tomcat. If folks are updating Tomcat regularly then
> they are likely updating the JRE too. So I wonder what the return on the
> investment is.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Tomcat mitigations for CVE-2022-21449
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 4/29/22 18:17, Mark Thomas wrote:
> On 29/04/2022 19:41, Christopher Schultz wrote:
>
> <snip/>
>
>> 1. The underlying JVM is affected
>> 2. A Connector is defined with uses mutual TLS
>> 3. The client's key is ECDSA
>
> <snip/>
>
>> I was thinking that on startup, we could check for a vulnerable
>> environment and simply refuse to start the server.
>>
>> If there are no objections, I was thinking of putting this into the
>> SecurityListener. I assume that all the necessary information is
>> available to a LifecycleListener such as being able to enumerate the
>> Connectors to check on items #2 and #3 above?
>
> My understanding is that a CA with an RSA key can sign a client cert
> with an ECDSA key. In that scenario, if the Tomcat system has been
> configured with just the CA's trusted cert (a likely scenario since you
> don't want to have to updated the trusted certs every time you add a
> user) then test #3 won't work.
Yup. I'm thinking that #1 and #2 should be the only things we consider.
> I'm wondering if we want to introduce a Java version equivalent of the
> checks we have for Tomcat Native version. i.e. for each major Java
> version, have a minimum required version where Tomcat won't start if
> used and a recommended version where Tomcat starts with a warning.
In this case, where there is a clear and present danger, I would
advocate for going beyond just a warning.
> One of the arguments against adding checks like these is that they only
> work if folks update Tomcat. If folks are updating Tomcat regularly then
> they are likely updating the JRE too. So I wonder what the return on the
> investment is.
Honestly, this is going to take less time to code that discuss, and I
think it may help some people. That's why I was asking on dev@ to see if
any non-committers had any thoughts.
The response so far has been lukewarm, so maybe it's not really worth it.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat mitigations for CVE-2022-21449
Posted by Mark Thomas <ma...@apache.org>.
On 29/04/2022 19:41, Christopher Schultz wrote:
<snip/>
> 1. The underlying JVM is affected
> 2. A Connector is defined with uses mutual TLS
> 3. The client's key is ECDSA
<snip/>
> I was thinking that on startup, we could check for a vulnerable
> environment and simply refuse to start the server.
>
> If there are no objections, I was thinking of putting this into the
> SecurityListener. I assume that all the necessary information is
> available to a LifecycleListener such as being able to enumerate the
> Connectors to check on items #2 and #3 above?
My understanding is that a CA with an RSA key can sign a client cert
with an ECDSA key. In that scenario, if the Tomcat system has been
configured with just the CA's trusted cert (a likely scenario since you
don't want to have to updated the trusted certs every time you add a
user) then test #3 won't work.
I'm wondering if we want to introduce a Java version equivalent of the
checks we have for Tomcat Native version. i.e. for each major Java
version, have a minimum required version where Tomcat won't start if
used and a recommended version where Tomcat starts with a warning.
One of the arguments against adding checks like these is that they only
work if folks update Tomcat. If folks are updating Tomcat regularly then
they are likely updating the JRE too. So I wonder what the return on the
investment is.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat mitigations for CVE-2022-21449
Posted by Konstantin Kolinko <kn...@gmail.com>.
пт, 29 апр. 2022 г. в 21:41, Christopher Schultz <ch...@christopherschultz.net>:
>
> All,
>
> CVE-2022-21449 is a bug in the JDK which allows a malicious signer using
> ECDSA to forge a signature which an affected (buggy) verifier fails to
> detect.
>
> I used deliberate language above instead of "client" and "server"
> because in many csases, the server is performing verification as well
> (e.g. of a client's TLS certificate in a mutually-authenticated TLS
> handshake).
>
> This affects JDK versions from 15 - 18. Notably, Java 15 and 16 are EOL
> and won't be getting any updates. This Isn't Good.
>
> This wasn't as popular in the press as "log4shell" nor does it have as
> exciting or sensational a name given to it, but it's still a pretty big
> problem.
It is named "Psychic Signatures"
https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/
https://neilmadden.blog/2022/04/25/a-few-clarifications-about-cve-2022-21449/
> Tomcat is, of course, transiently affected by this bug under the
> following conditions (all of which must be true, I believe):
>
> 1. The underlying JVM is affected
> 2. A Connector is defined with uses mutual TLS
> 3. The client's key is ECDSA
4. The SSL implementation that is used is JSSE.
Those using Tomcat Native + OpenSSL are not affected.
https://tomcat.apache.org/tomcat-10.1-doc/config/http.html#SSL_Support
> If all of the above are true, then anyone can impersonate any client to
> the server. An attacker may need to find a /useful/ client to
> impersonate, but usually, simply connecting to the server and askint
> which clients are allowed is enough:
>
> $ openssl s_client -connect host:port | grep 'Acceptable client'
> Acceptable client certificate CA names
> [...]
Those are CA names. Luckily those are not user names.
For a reference,
https://security.stackexchange.com/questions/139048/acceptable-client-certificate-ca-names-openssl
>
> While we can't protect any *clients* against these attacks, we may be
> able to protect *servers*.
>
> What does the community think about Tomcat trying to prevent the use of
> vulnerable configurations? Is it overstepping? Would it be helpful? I
> think anyone running a vulnerable configuration should /really/ know
> that they are vulnerable and be able to fix their environment. But lots
> of environments are on auto-pilot.
>
> I was thinking that on startup, we could check for a vulnerable
> environment and simply refuse to start the server.
>
> If there are no objections, I was thinking of putting this into the
> SecurityListener. I assume that all the necessary information is
> available to a LifecycleListener such as being able to enumerate the
> Connectors to check on items #2 and #3 above?
>
1. It does look like overstepping to me.
I am afraid that once we start it may result in pursuing a moving
target. It is hard to whack all the moles.
I think there is a worth in doing a check on the JRE version, but
implementing a check that combines 4 conditions is too hard to
maintain, and too limited in scope to be useful in the long run. There
may be 3rd-party software to better fill the role and maintain the
effort.
If we add a java version check, the next question is planning on how
to maintain it. Who and when updates it to start rejecting java 18?
2. Maybe as a start,
add a mention of this on the "Security Considerations" page
https://tomcat.apache.org/tomcat-10.1-doc/security-howto.html#Non-Tomcat_settings
a) "Use a recent and supported JRE, because there are bugs that may
affect your security, e.g. CVE-2022-21449".
BTW maybe also
b) "Plan for upgrades in advance" "Upgrading Tomcat is easiest if one
is configured with separate CATALINA_HOME and CATALINA_BASE".
3. That said, I see that SecurityListener is not enabled by default,
and as such I do not have a technical objection, if that is your itch.
My personal requirements are that
1) org.apache.catalina.security.SecurityListener continues to be not
enabled by default,
2) There should be an easy option to skip the check, e.g.
javaVersionCheck="false".
4. BTW, There may be ways to additionally validate the client's certificate.
E.g. "org.apache.catalina.realm.X509UsernameRetriever" (configured on
a Realm with "X509UsernameRetrieverClassName" attribute) was mentioned
in an unrelated discussion recently. It has access to the client's
certificate.
https://bz.apache.org/bugzilla/show_bug.cgi?id=66009#c3
https://tomcat.apache.org/tomcat-9.0-doc/config/realm.html
https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/realm/X509UsernameRetriever.html
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Tomcat mitigations for CVE-2022-21449
Posted by jo...@wellsfargo.com.INVALID.
Personally I like this approach. I would suggest putting a descriptive error description in the logs if this is detected and startup is aborted. From an environment where curtailing vulnerabilities is key, regardless of the source, this is truly a Martha Stuart moment. It's a good thing. :-)
Thanks,
Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His
Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions
8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508
jonmcalexander@wellsfargo.com
This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Friday, April 29, 2022 1:42 PM
> To: Tomcat Developers List <de...@tomcat.apache.org>
> Subject: Tomcat mitigations for CVE-2022-21449
>
> All,
>
> CVE-2022-21449 is a bug in the JDK which allows a malicious signer using
> ECDSA to forge a signature which an affected (buggy) verifier fails to detect.
>
> I used deliberate language above instead of "client" and "server"
> because in many csases, the server is performing verification as well (e.g. of a
> client's TLS certificate in a mutually-authenticated TLS handshake).
>
> This affects JDK versions from 15 - 18. Notably, Java 15 and 16 are EOL and
> won't be getting any updates. This Isn't Good.
>
> This wasn't as popular in the press as "log4shell" nor does it have as exciting
> or sensational a name given to it, but it's still a pretty big problem.
>
> Tomcat is, of course, transiently affected by this bug under the following
> conditions (all of which must be true, I believe):
>
> 1. The underlying JVM is affected
> 2. A Connector is defined with uses mutual TLS 3. The client's key is ECDSA
>
> If all of the above are true, then anyone can impersonate any client to the
> server. An attacker may need to find a /useful/ client to impersonate, but
> usually, simply connecting to the server and askint which clients are allowed
> is enough:
>
> $ openssl s_client -connect host:port | grep 'Acceptable client'
> Acceptable client certificate CA names
> [...]
>
> While we can't protect any *clients* against these attacks, we may be able to
> protect *servers*.
>
> What does the community think about Tomcat trying to prevent the use of
> vulnerable configurations? Is it overstepping? Would it be helpful? I think
> anyone running a vulnerable configuration should /really/ know that they are
> vulnerable and be able to fix their environment. But lots of environments are
> on auto-pilot.
>
> I was thinking that on startup, we could check for a vulnerable environment
> and simply refuse to start the server.
>
> If there are no objections, I was thinking of putting this into the
> SecurityListener. I assume that all the necessary information is available to a
> LifecycleListener such as being able to enumerate the Connectors to check
> on items #2 and #3 above?
>
> Thanks,
> -chris
>
> [1]
> https://urldefense.com/v3/__https://www.theregister.com/AMP/2022/04/
> 20/java_authentication_bug/__;!!F9svGWnIaVPGSwU!9ldUN4bpY-
> cQsJkrr7Hps8mQSzWFnodb8KZy6okiLIxBs4t382eRkvPY7KQ9BaG8USwy1z4$
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional
> commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org