How to fix Security Vulnerability CVE-2023-44981 in strimzi kafka 3.6.0

[vino-architect]

Below are the vulnerability shown in MS Defender for Strimzi Kafka. How to fix these issues in AKS.

CVE-2023-44981, org.apache.zookeeper, Installed Version: 3.6.3.0, zookeeper, Fixed Version: 3.7.2
CVE-2023-44981, org.apache.zookeeper, Installed Version: 3.8.2.0, zookeeper, Fixed Version: 3.8.3
CVE-2023-4586, io.netty, Installed Version: 4.1.94.0, Package Name: netty-handler,
CVE-2023-43642, org.xerial.snappy, Installed Version: 1.1.10.1, Package Name: netty-handler, Fixed Version: 1.1.10.4

[scholzj]

• You should probably try to understand if you are affected by those vulnerabilities or not. For example, the ZooKeeper CVEs are around SASL authentication not used in the context of Strimzi as we use mTLS.
• You also need to understand from which project is the dependency coming. Knowing the exact image and path where it was found gives you some pointers. Then, you have to see if that is something that can be just bumped in Strimzi, or if it needs a newer version of some high-level dependency such as Kafka (or possibly also Cruise Control in this case) or if it isn't fixed in those projects yet and it would first require a new release on their side.

[vino-architect]

This vulnerability is coming in our Production setup. Customer not accepted this vulnerability. So I need to fix this.

As its suggested, I need to upgrade zookeeper version. But in Strimzi, there is no option to modify the zookeeper version.

Any idea How can i fix this vulnerability.

[scholzj]

ZooKeeper is part of Apache Kafka. That is why you cannot choose a ZooKeeper version -> you have to use what Kafka does and what Kafka was tested with. Also, from our experience, upgrading ZooKeeper tends to bring all kinds of unexpected issues. So just bumping a ZooKeeper version can cause a lot of problem.

Or to put it a different way -> how many hours of outage per month is your customer willing to accept in order to solve a CVE that is quite clearly not affecting them? Based on that, you can decide what do you want to do ...

• The proper thing is to address this in the lower level projects (e.g. Kafka or Cruise Control - it might have happened in them already) and wait until their releases bubble up into a Strimzi release. You can check if the latest build from the main branch of Strimzi are affected or not for example.
• A slightly harder and dirtier ... build the lower projects yourself and do the quality assurance on them and then use them in your own build of Strimzi.
• A completely dirty hack ... just replace the JAR in the container image with your own JAR and pray it works.