The Kubernetes kube-apiserver mistakenly allows access to a cluster-scoped custom resource if the request is made as if the resource were namespaced. Authorizations for the resource accessed in this manner are enforced using roles and role bindings within the namespace, meaning that a user with access only to a resource in one namespace could create, view update or delete the cluster-scoped resource (according to their namespace role privileges). Kubernetes affected versions include versions prior to 1.13.9, versions prior to 1.14.5, versions prior to 1.15.2, and versions 1.7, 1.8, 1.9, 1.10, 1.11, 1.12.
Workaround:
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
| Link | Tags |
|---|---|
| https://github.com/kubernetes/kubernetes/issues/80983 | third party advisory |
| https://groups.google.com/d/msg/kubernetes-security-announce/vUtEcSEY6SM/v2ZZxsmtFQAJ | third party advisory mailing list |
| https://access.redhat.com/errata/RHSA-2019:2690 | third party advisory vendor advisory |
| https://security.netapp.com/advisory/ntap-20190919-0003/ | third party advisory |
| https://access.redhat.com/errata/RHBA-2019:2816 | third party advisory vendor advisory |
| https://access.redhat.com/errata/RHBA-2019:2824 | third party advisory vendor advisory |
| https://access.redhat.com/errata/RHSA-2019:2769 | third party advisory vendor advisory |