Bug 1978621 (CVE-2021-3636)

Fix:

https://github.com/openshift/kubernetes/pull/714

In Kubernetes 1.21, which OpenShift 4.8 is based on, the method in which service accounts are mounted in pods changed, to now use projected volumes:

https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume

OpenShift rewrote the way service-ca.crt is injected into pods in 4.8, and now no longer includes the incorrect additional CAs.

Below is a comparison of podspecs using the old and new methods of mounting service accounts into pods. In both versions, the injected Service CA will end up in the same filepath, /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt. 

4.7:
---
spec:
  containers:
    ...
    volumeMounts:
    - mountPath: /tmp
      name: tmp
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-5rk4g
      readOnly: true
        ...
  volumes:
  - emptyDir: {}
    name: tmp
  - name: default-token-5rk4g
    secret:
      defaultMode: 420
      secretName: default-token-5rk4g

4.8
---
spec:
  containers:
    ...
    volumeMounts:
    - mountPath: /tmp
      name: tmp
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-jgdq2
      readOnly: true
  volumes:
  - emptyDir: {}
    name: tmp
  - name: kube-api-access-jgdq2
    projected:
      defaultMode: 420
        ...
      - configMap:
          items:
          - key: service-ca.crt
            path: service-ca.crt
          name: openshift-service-ca.crt

In fixed versions of OpenShift, servica-ca.crt will contain only a single certificate, for the openshift-service-signer-server. Vulnerable versions will include multiple internal CAs. This can be checked with a command like below:

$ openssl crl2pkcs7 -nocrl --certfile service-ca.crt  | openssl pkcs7 -print_certs --text -noout | grep 'CN='
        Issuer: CN=ingress-operator@1626066148
        Subject: CN=ingress-operator@1626066148
        Issuer: CN=openshift-service-serving-signer@1626066048
        Subject: CN=openshift-service-serving-signer@1626066048
        ...

This issue has been addressed in the following products:

  Red Hat OpenShift Container Platform 4.8

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

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-3636

Are other OpenShift version 4 releases impacted by this CVE?  Based on https://access.redhat.com/security/cve/cve-2021-3636, it sounds like they are with the only resolution requiring version 4.8.  Are there any plans to fix previous version?

https://access.redhat.com/security/cve/CVE-2021-3636, only documents the fix at 4.8 but that releases before 4.8 are affected, can anyone tell me whether CVE-2021-3636 will be fixed in OpenShift 4.7 and 4.6?

Or is this a similar case to https://bugzilla.redhat.com/show_bug.cgi?id=1963232#c26 (CVE-2021-33194) where this vulnerability won't be addressed in OpenShift (OCP) 4.7 and 4.6 as both these releases are already in the maintenance support phase?

(In reply to Rachel A from comment #14)
> https://access.redhat.com/security/cve/CVE-2021-3636, only documents the fix
> at 4.8 but that releases before 4.8 are affected, can anyone tell me whether
> CVE-2021-3636 will be fixed in OpenShift 4.7 and 4.6?

OpenShift 4.8.2 is the first released version of OpenShift 4 that has been fixed. Earlier released versions of OpenShift 4 are affected.

> Or is this a similar case to
> https://bugzilla.redhat.com/show_bug.cgi?id=1963232#c26 (CVE-2021-33194)
> where this vulnerability won't be addressed in OpenShift (OCP) 4.7 and 4.6
> as both these releases are already in the maintenance support phase?

This CVE is also rated Moderate, like CVE-2021-33194. Even in Full Support phase, only Important and Critical rated vulnerabilities are covered under our support policy:

https://access.redhat.com/support/policy/updates/openshift

Does the support policy prevent such CVEs from being fixed?  We are really looking for an answer as to whether we may get a fix or we will never get a fix.

(In reply to Richard Theis from comment #16)
> Does the support policy prevent such CVEs from being fixed?  We are really
> looking for an answer as to whether we may get a fix or we will never get a
> fix.

No, it does not prevent them from being fixed. Fixes for Moderate and Low CVEs can be requested by raising a support ticket.

Thank you.  I've opened a support case.