A critical privilege escalation vulnerability has been found in Kubernetes, the popular open-source container orchestration system that allows users to automate deployment, scaling and management of containerized applications.
The vulnerability, discovered by Rancher Labs Co-founder and Chief Architect Darren Shepherd, is tracked as CVE-2018-1002105 and it has been assigned a CVSS score of 9.8. It can allow an attacker to escalate privileges by sending specially crafted requests to the targeted server.
“With a specially crafted request, users that are allowed to establish a connection through the Kubernetes API server to a backend server can then send arbitrary requests over the same connection directly to that backend, authenticated with the Kubernetes API server’s TLS credentials used to establish the backend connection,” explained Jordan Liggitt, a Google software engineer and member of the Kubernetes product security team.
The security hole impacts versions 1.0.x-1.9.x, 1.10.0-1.10.10, 1.11.0-1.11.4 and 1.12.0-1.12.2. It has been patched with the release of versions 1.10.11, 1.11.5, 1.12.3 and 1.13.0-rc.1. Some mitigations also exist, but users have been warned that they are likely to be disruptive.
Red Hat, whose OpenShift products are impacted, has also released a blog post, a video and several advisories describing the impact of the vulnerability.
“[The] privilege escalation flaw makes it possible for any user to gain full administrator privileges on any compute node being run in a Kubernetes cluster,” said Red Hat’s Ashesh Badani. “This is a big deal. Not only can this actor steal sensitive data or inject malicious code, but they can also bring down production applications and services from within an organization’s firewall.”
Red Hat noted that while the patch was made available quickly, it may not always be easy to apply as it could have a negative impact on production systems.
While there is no indication that this vulnerability has been leveraged for malicious attacks, Liggitt pointed out that there is no easy way to detect exploitation attempts.
“Because the unauthorized requests are made over an established connection, they do not appear in the Kubernetes API server audit logs or server log. The requests do appear in the kubelet or aggregated API server logs, but are indistinguishable from correctly authorized and proxied requests via the Kubernetes API server,” he explained.
Related: Misconfiguration a Top Security Concern for Containers
Related: Code Execution in Alpine Linux Impacts Containers
Related: Microsoft Patches Critical Flaw in Open Source Container Library