Security vulnerabilities in golang modules

[petrovicboban]

CVE-2018-15664
Severity: High
Component: github.com/docker/docker
Fix version: 18.09.7-rc1, 19.03.0-rc2

CVE-2021-43565
Severity: High
Component: golang.org/x/crypto
Fix version: 0.0.0-20211202192323-5770296d904e

CVE-2021-32690
Severity: High
Component: k8s.io/helm
Fix version: 3.6.1

[petrovicboban]

Why are two helm modules in use here? helm.sh/helm/v3 and k8s.io/helm.

[mumoshu]

Thanks for reporting! Yeah we should upgrade them all.

Why are two helm modules in use here? helm.sh/helm/v3 and k8s.io/helm.

That's because helm-diff still uses k8s.io/hlm for helm 2 support.

[petrovicboban]

How long do you plan to support helm v2? Until then, this plugin will be out of reach for corporate users, who often have strict security policies.
Security report above is from JFrog Xray, widely used in corporate systems.

[mumoshu]

@petrovicboban Just wondering, but wan't we just upgrade the helm v2 dependency to latest?

[petrovicboban]

@mumoshu the latest v2 is 2.17 and it's good path forward, but it's very likely Xray would still complain about using helm library with vulnerability which is fixed in 3.6.1.

[petrovicboban]

How hard is to maintain two release branches, one for helm v2 and one for helm v3?

[mumoshu]

I won't maintain two release branches for free :) It's just too much work without real benefits.

Looking deeper, the docker and helm CVEs seems impossible to be exploited via helm-diff as it doesn't use mentioned features of docker and helm from helm-diff's code.
For x/crypto issue, helm-diff might be affected only when it directly contacts any endpoint that requires TLS and the endpoint is malicious, and the end result is helm-diff "may" panic, as the CVE states.

So, let's just go head upgrading x/crypto and docker dependencies. Leave helm2 dependency as-is, until we eventually drop helm2 support.

[petrovicboban]

I updated PR, excluding k8s.io/helm update.
However, when I change version of github.com/docker/docker to v18.09.7 , go mod tidy reverts it back. I'm not golang dev, but it seems current version of that package is dependency for one already listed and pinned.
Any help?

[mumoshu]

@petrovicboban Thanks for your support.

Yeah, the docker dependency is marked "indirect", which means it's a transitive dependency afaik. I.e. you can't alter the version of transitive dependency. It needs to be a direct dependency to helm-diff if you want strict control. But then it's subject to collision, like helm-diff requires v18 but one of helm-diff's dependency requires v17, and may result in a build error.

docker dependency seems to be coming from helm v3
https://github.com/helm/helm/blob/61d8e8c4a6f95540c15c6a65f36a6dd0a45e7a2f/go.mod#L17
I saw it's more up-to-date in the head of their main branch so probably upgrading helm v3 dependency to the latest results in fixing the docker dependency too.

[petrovicboban]

@mumoshu I updated helm v3 to the latest, v3.8.0. It pulled a lot of dependencies to be updated. Pipeline run is successful.