Kubernetes Races to Fix Regressions Introduced by Recent Security Patches
Kubernetes recently received patches for two serious vulnerabilities that could allow attackers to bypass security barriers and read, write or delete files from host systems. The patches, however, seem to have caused functional regressions forcing developers to push out new builds to address some of them.
The first vulnerability, tracked as CVE-2017-1002101, can be used, in certain configurations, to gain read and write access to arbitrary files outside volumes specified in a pod, including files on the host’s filesystem.
“This can be accomplished with any volume type, including emptyDir, and can be accomplished with a non-privileged pod (subject to file permissions),” the Kubernetes developers wrote in their advisory.
The flaw is located in subpath volume mounts and was fixed in Kubernetes versions 1.7.14, 1.8.9 and 1.9.4, released on March 12. Its exploitation requires “a specially crafted pod spec combined with malicious container behavior.”
Vulnerable configurations include “clusters that allow untrusted users to control pod spec content and prevent host filesystem access via hostPath volumes (or other volume types) using PodSecurityPolicy (or custom admission plugins)” and “clusters that make use of subpath volume mounts with untrusted containers or containers that can be compromised.”
Red Hat patched the vulnerability in its OpenShift Container Platform and gave it a severity score of 7.2 (high) on the CVSS scale. Security researchers from Twistlock described it as one of most severe security bugs ever to be reported in Kubernetes and published a blog post that explains how it can be exploited.
The second vulnerability, identified as CVE-2017-1002102, is also rated as high severity (CVSS 7.1) by Red Hat because it allows containers that use a secret, configMap, projected, or downwardAPI volume to trigger deletion of arbitrary files and directories on the node host. This operation is performed by the Kubelet process, which runs as root, so any file is fair game.
“The best practice to fix the bug is to upgrade the cluster, otherwise Secrets, configMap, downwardAPI and projected volumes should be disabled,” Twistlock researcher Nitsan Bin-Nun said. “The upgrade will mount these volumes as read-only and will cause write calls to fail. Containers will need to be updated accordingly.”
Fixing the flaws, especially CVE-2017-1002101, required a design change and this had the effect of introducing functional regressions which caused problems for certain container configurations. The Kubernetes team is in the process of addressing these issues and has already released two new builds since then to fix the most serious ones (1.7.15, 1.8.10, 1.9.5 and 1.9.6). The regressions are tracked in this umbrella ticket on GitHub.
“If upgrading is not an option, a quick hack is available: use PodSecurityPolicy objects to limit container creation permissions and disable hostPath volumes completely,” Twistlock’s Bin-Nun said.
Red Hat OpenShift has a blog post about upgrading and Google also has instructions in the release notes of its Kubernetes Engine.
Red Hat and Twistlock are sponsors of The New Stack.
Feature image via Pixabay.
