Use latest oc binary to avoid known CVE issues

[nickboldt]

/kind enhancement

Which functionality do you think we should update/improve?

Update to newer oc binary to fix known CVE issues.

Why is this needed?

Known CVE issue: https://access.redhat.com/errata/RHSA-2019:3905

Fix: move to atomic-openshift-clients-3.11.154-1.git.0.7a097ad.el7.x86_64.rpm (or newer).

For example:

https://mirror.openshift.com/pub/openshift-v3/clients/ (3.11.156 currently latest)

Alternatively it might be worth considering moving to the oc 4.2 binary instead:

https://mirror.openshift.com/pub/openshift-v4/clients/ocp/ (4.2.8 currently latest)

[mohammedzee1000]

Thanks, I think this also applies to our vendor client-go (occlient) library
/kind bug
/priority medium
@kadel wdyt

[kadel]

There are two CVEs.
What I understand from reading through it is that they don't effect client-go. But one of them might be effecting us.

https://nvd.nist.gov/vuln/detail/CVE-2019-11253
This one is effecting apiserver, not a client-side.

https://bugzilla.redhat.com/show_bug.cgi?id=1753495
The discovered vulnerability is in kubectl cp command. We don't use that command, but our code is based on the same login.
We need to check if the attack can be applied to the odo.

[mik-dass]

Interesting read regarding this issue https://www.stackrox.com/post/2019/09/beyond-patching-fixing-kubectl-cp-cve-2019-11251/

[mik-dass]

@kadel I don't see any changes which will be required in odo's tarring logic
kubernetes/kubernetes@786acdb

The resursiveTar() in the upstream has the same logic as ours.
https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/cp/cp.go

The changes were done in the unTarAll function but I couldn't find any usage of it in our code base.
https://github.com/kubernetes/kubernetes/blob/f6337c762483e60e41dd775166afd536b130455e/pkg/kubectl/cmd/cp/cp.go#L429

[mik-dass]

@kadel @cdrage @nickboldt Looking at kubernetes/kubernetes@786acdb, I could find that the changes were done in the unTarAll() function which is used in the copyFromPod() function https://github.com/kubernetes/kubernetes/blob/2fbe432d2347d7f808054f92f2b146e8a7dd2de8/pkg/kubectl/cmd/cp/cp.go#L324

Thus looking at the above code base, I think the vulnerability exists when the attacker places the malicious software in a pod and the victim copies files from the pod back to his source computer. Since we don't copy files from the pod to a user's computer, I don't think we affected by this issue. Also I couldn't find the usage of the unTarAll() logic anywhere in our code. So I guess we can close this issue.

[nickboldt]

Well, you're still better off IMHO being based on newer versions of oc than 3.11.0 (as 3.11.156 is the latest) or moving to 4.2.latest...

but it's good to now this specific CVE issue might not affect you.

(There are others. Or there wouldn't haven been a need for 156 z-stream updates to 3.11.0 since Oct 2018.)

[mik-dass]

Well, you're still better off IMHO being based on newer versions of oc than 3.11.0 (as 3.11.156 is the latest) or moving to 4.2.latest...

@nickboldt Do you mean the OC binary or the client-go? We don't use the OC binary in our code base. As for the client-go, we have plans to update it to a newer version in a upcoming PR.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[girishramnani]

closing this due to inactivity.

[nickboldt]

@nickboldt Do you mean the OC binary or the client-go? We don't use the OC binary in our code base. As for the client-go, we have plans to update it to a newer version in a upcoming PR.

I meant the oc binary.

[mik-dass]

I meant the oc binary.

@nickboldt We don't use the OC binary anymore in ODO. We have moved to client-go long back. We even updated client-go to release-4.1 recently https://github.com/openshift/odo/blob/18f9f3b33404b5a2d5f662f9dd494128c41d093f/glide.yaml#L17