Permission check due: Kubernetes fixes information leak in kube-controller-manager

Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now

Source:-devclass.com

A medium severity Server Side Request Forgery vulnerability has been found in Kubernetes’ kube-controller-manager – fixes are now available, so get updating.

The security issue, which has been assigned the CVE ID CVE-2020-8555, allows users with a permission to either create a pod with GlusterFS, Quobyte, StorageFS, or ScaleIO, or a StorageClass “to leak up to 500 bytes of arbitrary information from unprotected endpoints within the master’s host network”.

The vulnerability affects all versions of kube-controller-manager older than 1.15.11, as well as versions 1.18.0, 1.17.0 to 1.17.4, and 1.16.0 to 1.16.8. Interceptable endpoints include link-local metadata endpoints, unauthenticated services listening on localhost, or other services in the master’s private network.

Since the right to create pods and modify storage classes are normally only granted to admins or developers in an organisation, the chances of the issue being used for an attack are comparatively slim. It could, however, serve as an impetus to check only trusted users are granted those permissions.

To mitigate the issue, Kubernetes users working with any of the affected volume types can implement appropriate policies through PodSecurityPolicy or third-party tool Gatekeeper, or restrict StorageClass write permissions via Kubernetes access controls. Updating to a patched version might be the better choice, just to be safe – fixes are already available.

Teams working with specific distributions might have to check if there’s something available to them, as the issue affects various distros differently. D2iQ for example already updated its Konvoy and MKE offerings, providing users with a detailed upgrade guide.

Red Hat, meanwhile, wasted no time in letting everyone know that “OpenShift Container Storage 4.2 is not affected by this vulnerability as rook-ceph-operator container does not include support for affected volume plugins.”

It also sees the impact on other products as low, since they either don’t use the affected functionality or expose not all of the endpoints mentioned. Products marked as affected, so Red Hat OpenShift Container Platform 4 and 3.11, as well as Red Hat Storage 3, might receive fixes “in the near future”.

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x