CVE-2020-8554
Description
A flaw was found in kubernetes. If a potential attacker can already create or edit services and pods, then they may be able to intercept traffic from other pods (or nodes) in the cluster.
Statement
OpenShift Container Platform (OCP) includes a builtin externalIP admission plugin, which restricts the use of Service eternalIPs to those configured by a cluster-admin. In OCP4 all externalIP ranges are disabled by default. In OCP 3.11, the default range is "0.0.0.0/0", which allows all IP addresses.
The second attack vector, via patching the Status of a LoadBalancer Service, is not possible unless permission to patch service/status is granted. OCP does not grant this permission to users who are not cluster-admins.
OCP 4 is not affected by this vulnerability as it is secure by default. OCP 3.11 is affected, however the vulnerability can be by mitigated by configuring the builtin externalIP admission plugin.
Mitigation
ExternalIP addresses ranges can be configured as described below. OCP 4 is secure by default, though cluster-admins can whitelist externalIP addresses as needed. OCP 3.11 can be secured by changing `externalIPNetworkCIDR` to "0.0.0.0/32", which blocks all externalIP address values.
https://docs.openshift.com/container-platform/4.6/networking/configuring_ingress_cluster_traffic/configuring-externalip.html
https://docs.openshift.com/container-platform/3.11/admin_guide/tcp_ingress_external_ports.html#service-externalip
Users can check if they have permission to patch the Status of a LoadBalancer Service with the command: `kubectl auth can-i patch service --subresource=status`. In OCP, by default only cluster-admins are granted this permission.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 6.3 | 5 | N/A |
| Attack Vector | Network | Network | N/A |
| Attack Complexity | Low | High | N/A |
| Privileges Required | Low | Low | N/A |
| User Interaction | None | None | N/A |
| Scope | Unchanged | Unchanged | N/A |
| Confidentiality | Low | Low | N/A |
| Integrity Impact | Low | Low | N/A |
| Availability Impact | Low | Low | N/A |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
NVD: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
Red Hat CVSS v3 Score Explanation
Proposed changes to NIST's current CVSSv3 scoring: AC:H -> AC:L C:H -> C:L I:H -> I:L A:H -> A:L
To successfully exploit this vulnerability a potential attacker needs access to create or edit services and pods and then they may be able to intercept traffic from other pods or even cluster nodes. Hence proposing a change to Attack Complexity (AC) from High to Low. Access to some restricted information can be obtained, but the attacker does not have control over what information is obtained. The same situation is in regards to the possible data modification, the attacker does not have control over the consequence of a modification. The attacker also does not have the ability to completely deny service. The Confidentiality, Integrity and Availability (CIA) metrics should be changed from High to Low.
Understanding the Weakness (CWE)
Confidentiality
Technical Impact: Read Application Data
Acknowledgements
Red Hat would like to thank the Kubernetes Product Security Committee for reporting this issue. Upstream acknowledges Etienne Champetier (Anevia) as the original reporter.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
