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