The openshift-service-ca service contains unexpected CAs. In OpenShift 4.8 the service-ca.crt file only contains the self-signed certificate of the openshift-service-serving-signer CA certificate. In older versions of OpenShift there were more, additional CAs: - OU = openshift, CN = kube-apiserver-lb-signer - OU = openshift, CN = kube-apiserver-localhost-signer - OU = openshift, CN = kube-apiserver-service-network-signer - CN = openshift-kube-apiserver-operator_localhost-recovery-serving-signer - CN = ingress-operator - CN = *.apps.cluster.example.com - CN = openshift-service-serving-signer This means that an attacker who owns the ingress CA can impersonate as any in-cluster service-ca signed process. The issue impacts Confidentiality and Integrity of the OCP cluster. OCP 4.8 is not impacted by this vulnerability.
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.