Re: Tomcat mitigations for CVE-2022-21449

[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