[Bug]: CVE-2024-57699 in /opt/strimzi/lib/net.minidev.json-smart-2.5.0.jar

[ngton]

Bug Description

Our scanning tool found this high sev CVE in the json-smart dependency. Updating to 2.5.2 would fix

Steps to reproduce

No response

Expected behavior

No response

Strimzi version

0.45

Kubernetes version

Openshift

Installation method

No response

Infrastructure

No response

Configuration files and logs

No response

Additional context

No response

[ppatierno]

This is coming from the oauth library. @mstruk is already working on it to have an oauth 0.16.1 out soon so we can update it within the operator. Anyway it will come with the operator 0.46.0 release coming end of April, beginning of May.

[unguiculus]

Any chance we can get this in a 0.45.1 release? The reason is that 0.46.0 will require KRaft, so an upgrade will not be so easy.

[ppatierno]

I am not sure how much of impact it could have porting the oauth 0.16.2 in the 0.45.x branch and needed changes for it (not specifically related to the CVE but because of a new versions of oauth with new stuff). @mstruk any opinions?

[mstruk]

The OAuth library 0.16.2 does not support Zookeeper any more, and 0.45.0 still supports it. For this reason we would need to release 0.15.1 with the fix, and only then we could do the 0.45.1 release. It would take the usual release time (now that we know how to properly fix this).

Then, there is always another way to address this for one's own use - one can create their own docker image based on 0.45.0-kafka-3.9.0 image and remove json-smart-2.5.0.jar from /opt/kafka/libs dir, and add there json-smart-2.5.2.jar instead. But that may not address the issue in a way that the users like very much.

It's up to the project's general approach to doing minor releases for previous versions to decide whether to do this release or not. Once new OAuth would be released, another Strimzi Operator release could be done.

And also to point out - I believe this CVE doesn't affect us in terms of any kind of exploitability. But it is inconvenient as the scanners detect the version of the jar and flag the project / images.

[scholzj]

I think this would be worth fixing. We already have some overrides for JSON Smart version in the 3rd party libs, so I assume we can override it there if we do not want to do 0.15.1 release (the override in 3rd party libs should be eaiser assumign that is all what is needed).

[ppatierno]

@scholzj good point! It should be a matter of bumping json-smart in these places:

https://github.com/strimzi/strimzi-kafka-operator/blob/release-0.45.x/docker-images/artifacts/kafka-thirdparty-libs/3.8.x/pom.xml#L28
https://github.com/strimzi/strimzi-kafka-operator/blob/release-0.45.x/docker-images/artifacts/kafka-thirdparty-libs/3.9.x/pom.xml#L28

As we are already overriding it for a different reason (logstash).

@mstruk taking into account your PR on oauth to fix the CVE here strimzi/strimzi-kafka-oauth#265 I guess that it would be enough doing the same as per the above proposal. Wdyt? Or do we would need more?

[mstruk]

@mstruk taking into account your PR on oauth to fix the CVE here strimzi/strimzi-kafka-oauth#265 I guess that it would be enough doing the same as per the above proposal. Wdyt? Or do we would need more?

I think if we want to do it properly, also for anyone pulling in cluster-operator as a dependency for their project, then we should also take strimzi/strimzi-kafka-oauth#266 into account, and make version override in main pom.xml and inside cluster-operator module.

I prepared a patch here: https://github.com/strimzi/strimzi-kafka-operator/compare/release-0.45.x...mstruk:strimzi-kafka-operator:bump-jsonsmart?expand=1

[ppatierno]

pulling in cluster-operator as a dependency for their project

I am confused about this. I don't think this is a real use case. The cluster-operator can't be used as a dependency on its own. @scholzj wdyt?

[scholzj]

Nobody should be using CO as a Maven dependency. We do not even push it to Maven Central IIRC. (that said, if the CVE is in the operator container image as well, we should bump it in the Cluster Operator dependencies as well and not only in 3rd party libs)

[ppatierno]

that said, if the CVE is in the operator container image as well, we should bump it in the Cluster Operator dependencies as well and not only in 3rd party libs

Yeah, quay.io scanning is reporting the CVE so it has to be fixed at operator level as well. I will open a PR for it.