Bug 1937901 (CVE-2021-27918)

It seems that all versions of golang are affected here sharing similar code: https://github.com/golang/go/blob/e71b61180aa19a60c23b3b7e3f6586726ebe4fd1/src/encoding/xml/xml.go#L289

So that's 1.13.15, 1.14.15 plus 1.15.8 and 1.16.0.

External References:

https://groups.google.com/g/golang-announce/c/MfiLYjG-RAw

In regards to OpenShift containers, there are 100+ containers which have some sort of reference to the stdlib encoding/xml. Scanning through all sources we cannot find any references to NewTokenDecoder except for: vendor/golang.org/x/tools/internal/imports/zstdlib.go This is just defining the stdlib symbols and does not indicate usage. So whilst yes we are building with a vulnerable version of the golang compiler, this means we're affected but not vulnerable (initialising with NewTokenDecoder is a requirement), hence we've taken the affected/wontfix approach here. 

It's the same for OSSM and Jaeger.

Upstream fix (1.16): https://github.com/golang/go/commit/d86e53e896eca907ad67300c0bb495e3dd925358
Upstream fix (1.15): https://github.com/golang/go/commit/91062c2e4cbbf78a108919f6ed3ded1173937cf3

Statement:

OpenShift Container Platform (OCP), OpenShift ServiceMesh (OSSM),  Red Hat OpenShift Jaeger (RHOSJ) and OpenShift Virtualization all do bundle a vulnerable versions of the golang standard library (stdlib). However, no component within each product utilizes the function xml.NewTokenDecoder which is a requirement to be vulnerable. Hence, all affected components are marked affected/wontfix and may be fixed in a future update. Additionally no OCP container has been listed, as nearly all available containers are compiled with an affected version of Go, but do not utilize the function xml.NewTokenDecoder.

Red Hat Ceph Storage (RHCS), Red Hat Gluster Storage 3 and OpenShift Container Storage 4 also bundles a vulnerable version of golang standard library 'encoding/xml', but does not utilize the function xml.NewTokenDecoder, and hence this issue has been rated as having a security impact of Low.

This issue has been addressed in the following products:

  Openshift Serverless 1 on RHEL 8

Via RHSA-2021:2704 https://access.redhat.com/errata/RHSA-2021:2704

This issue has been addressed in the following products:

  Openshift Serveless 1.16

Via RHSA-2021:2705 https://access.redhat.com/errata/RHSA-2021:2705

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2021-27918

Hello Team,

The customer is having the following query. Can you please help us with this?


~~~
We do appreciate the information you reiterated, but as I mentioned previously, the CU will have to renew internal security waiver on this one. And perhaps the GA term shouldn't have been mentioned. We see that 4.8 can now be installed as brand new platform, but the CU is really looking for approximate time he could have the upgrade available from a stable 4.7 to a stable 4.8 which includes the fix for this vulnerability. This vulnerability is not flagged for oc client in 4.8.2. Alternatively, if you could confirm if the oc client for 4.8.2 is backward compatible with OCP 4.7, he would consider that route and use the latest 4.8 client.
~~~

Regards,
Ayush Garg

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2021-27918

In reply to comment #30:
> Hello Team,
> 
> The customer is having the following query. Can you please help us with this?
> 
> 
> ~~~
> We do appreciate the information you reiterated, but as I mentioned
> previously, the CU will have to renew internal security waiver on this one.
> And perhaps the GA term shouldn't have been mentioned. We see that 4.8 can
> now be installed as brand new platform, but the CU is really looking for
> approximate time he could have the upgrade available from a stable 4.7 to a
> stable 4.8 which includes the fix for this vulnerability. This vulnerability
> is not flagged for oc client in 4.8.2. Alternatively, if you could confirm
> if the oc client for 4.8.2 is backward compatible with OCP 4.7, he would
> consider that route and use the latest 4.8 client.
> ~~~
> 
> Regards,
> Ayush Garg

Hi Ayush. We original set the status for the OpenShift oc client to wontfix, as the code makes no reference to the vulnerable function `xml.NewTokenDecoder` and some other code paths, including in it's dependencies. So whilst yes the oc client builds with a vulnerable version of Go, it makes no reference to that function. The customer is correct in that the oc client for 4.8 does indeed build with Go 1.16.4 which indeed includes a fix for this issue. 

I'm not quite sure what you mean by, an approximate time they could have the upgrade available for stable 4.8? It should be available in stable. Although checking this graph: https://ctron.github.io/openshift-update-graph/#fast-4.8 it might still only be for `fast`. 

In regards to backwards compatibility, see https://docs.openshift.com/container-platform/4.8/release_notes/versioning-policy.html. Based of this document, API's are backwards compatible, but it would depend if the customer is relying on any alpha/beta api's and if those have changed between versions. Generally it's advisable to match the client version with the cluster version, but depending on their usage it could be considered a low risk.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:3076 https://access.redhat.com/errata/RHSA-2021:3076