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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
