A security issue was discovered with Kubernetes that could enable users to send network traffic to locations they would otherwise not have access to via a confused deputy attack.
Upstream advisory: https://groups.google.com/g/kubernetes-security-announce/c/WYE9ptrhSLE Upstream issue: https://github.com/kubernetes/kubernetes/issues/103675
Created origin tracking bugs for this issue: Affects: fedora-all [bug 1982472]
Regarding the mitigation described on https://groups.google.com/g/kubernetes-security-announce/c/WYE9ptrhSLE, may be there any side effect or collateral issue if it is applied? My understanding is that there should not be, but please kindly confirm it. Thank you.
In reply to comment #5: > Regarding the mitigation described on > https://groups.google.com/g/kubernetes-security-announce/c/WYE9ptrhSLE, may > be there any side effect or collateral issue if it is applied? My > understanding is that there should not be, but please kindly confirm it. > Thank you. There's no known side effects or collateral issues.
In reply to comment #9: > Team, please share any updates on the backport so that we can set the right > expectation with the customer. > > Thanks. Given the severity of this CVE (Low), it's an Engineering decision whether or not fix it, and which potential versions to backport it to. Moderate and Low rated CVEs are not guaranteed under the OpenShift support policy: https://access.redhat.com/support/policy/updates/openshift Please refer to the tracking bug filed for Engineering to follow up if there are any plans to address this: https://bugzilla.redhat.com/show_bug.cgi?id=1982476
changing affected state of openshift to notaffected per Dan Winship: The CVE never applied to OpenShift, because OpenShift has an admission controller that specifically prevents the bad behavior described in the CVE, while still allowing "safe" modifications of Endpoints. This admission controller has always been in OpenShift, so we were immune to the attack described in the CVE even before the upstream mitigations were added. (The OCP admission controller prevents ordinary users from modifying Endpoints objects to point to pod IPs; manually-created/edited Endpoints objects can only point to IPs outside the cluster. We can do that in OCP because there is a OCP-specific config object that includes the pod network CIDR range, and so the admission controller can configure itself based on that. In upstream Kubernetes, there is no way to figure out the pod network CIDR range of an arbitrary cluster, so there's no way they could have *automatically* deployed such an admission controller to existing clusters to mitigate the CVE; they would have to have said "administrators, please run this controller, passing it the proper configuration for your cluster, and until you do that, you're vulnerable". So instead of that, they went with the brute-force approach of just blocking *all* Endpoints modifications.)
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-25740