CVE-2023-4586: Does Spring Boot enable host name verification with Netty in all cases?

[candrews]

CVE-2023-4586: Improper Certificate Validation applies to netty 4.x (there is no netty 5 [yet?]) upon which Spring Boot depends.

Netty's documentation for how to enable hostname verification: https://netty.io/4.1/api/io/netty/handler/ssl/SslContext.html#newHandler-io.netty.buffer.ByteBufAllocator-java.util.concurrent.Executor-

I'm trying to find all relevant netty references in Spring Boot to ensure that hostname verification is enabled for each. Some potentially relevant classes I've found include: ReactorNettyWebSocketClient, ReactorNetty2WebSocketClient, ReactorNetty2ClientHttpConnector, ReactorClientHttpConnector, ReactorClientHttpConnectorFactory, ReactiveCloudFoundrySecurityService.

I'm finding it quite difficult to verify if Spring Boot enabled host name verification in all paths. Could Spring Boot please let us know if it does?

I think it would really benefit the community to get a clear statement as to whether CVE-2023-4586 impacts Spring Boot or not.

Thank you!

[bclozel]

Thanks for reaching out.

All the classes you've listed use Reactor Netty's HttpClient. By default, Reactor Netty is safe in that regard as it enables hostname verification. It is highlighted in the Javadoc for the secure() methods here and here. Creating a default HttpClient.create() does as well.

I think it would really benefit the community to get a clear statement as to whether CVE-2023-4586 impacts Spring Boot or not.

We can't give a clear statement on that for several reasons.

1. the CVE itself is considered as a false positive by the Netty team. The same "vulnerability" is also applicable with plain Java, if hostname verification is not enabled. The Spring team knows this too well because of CVE-2016-1000027: once a CVE id is created it's hard to get them updated/re-scored.
2. If applications provide their own SslProvider to Reactor Netty, it's the application's responsibility to enable this feature. This is highlighted in the Javadoc as well
3. Same applies to dependencies that shade Netty - they're responsible for enabling this feature, unless the application provides an SslContext
4. the situation is not clear, as the original CVE was allocated by Red Hat for the hotrod client with a 5.3 score, and yet that same entry is pinned to Netty proper with a 7.5 score by NVD.

I'm closing this issue as there's nothing actionable on our side.