Bug 1937901 (CVE-2021-27918) - CVE-2021-27918 golang: encoding/xml: infinite loop when using xml.NewTokenDecoder with a custom TokenReader
Summary: CVE-2021-27918 golang: encoding/xml: infinite loop when using xml.NewTokenDec...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2021-27918
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1940636 1940637 1940638 1946567 1946568 1946569 1946602 1946603 1937902 1937904 1940634 1940635 1942898 1942899 1942900 1943717 1943718 1946570 1946571 1946601 1990704
Blocks: 1937912
TreeView+ depends on / blocked
 
Reported: 2021-03-11 17:41 UTC by Guilherme de Almeida Suckevicz
Modified: 2021-08-24 07:15 UTC (History)
78 users (show)

Fixed In Version: go 1.15.9, go 1.16.1
Doc Type: If docs needed, set a value
Doc Text:
An infinite loop vulnerability was found in golang. If an application defines a custom token parser initializing with `xml.NewTokenDecoder` it is possible for the parsing loop to never return. An attacker could potentially craft a malicious XML document which has an XML element with `EOF` within it, causing the parsing application to endlessly loop, resulting in a Denial of Service (DoS).
Clone Of:
Environment:
Last Closed: 2021-07-29 19:06:49 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:2704 0 None None None 2021-07-13 16:54:05 UTC
Red Hat Product Errata RHSA-2021:2705 0 None None None 2021-07-13 21:43:53 UTC
Red Hat Product Errata RHSA-2021:3076 0 None None None 2021-08-10 13:58:08 UTC

Description Guilherme de Almeida Suckevicz 2021-03-11 17:41:27 UTC
encoding/xml in Go before 1.15.9 and 1.16.x before 1.16.1 has an infinite loop if a custom TokenReader (for xml.NewTokenDecoder) returns EOF in the middle of an element. This can occur in the Decode, DecodeElement, or Skip method.

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

Comment 1 Mark Cooper 2021-03-15 12:55:06 UTC
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.

Comment 2 Mark Cooper 2021-03-15 12:56:00 UTC
External References:

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

Comment 7 Mark Cooper 2021-03-18 02:47:46 UTC
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.

Comment 22 Stoyan Nikolov 2021-04-07 08:37:49 UTC
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.

Comment 27 errata-xmlrpc 2021-07-13 16:54:03 UTC
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

Comment 28 errata-xmlrpc 2021-07-13 21:43:50 UTC
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

Comment 29 Product Security DevOps Team 2021-07-13 21:54:39 UTC
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

Comment 30 aygarg 2021-07-29 14:24:41 UTC
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

Comment 32 Product Security DevOps Team 2021-07-29 19:06:49 UTC
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

Comment 33 Mark Cooper 2021-07-30 02:34:35 UTC
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.

Comment 35 errata-xmlrpc 2021-08-10 13:58:02 UTC
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


Note You need to log in before you can comment on or make changes to this bug.