This article is more than 1 year old
Container code cluster-fact: There's a hole in Kubernetes that lets miscreants cause havoc
Critical bug brings bevy of patches
The keepers of Kubernetes, the rather popular software container orchestration system, have pushed out three new releases that patch a critical flaw.
In a post to the Kubernetes announcement list on Monday, Google senior staff engineer Jordan Liggitt says Kubernetes version v1.10.11, v1.11.5, and v1.12.3 have been made available to fix CVE-2018-1002105, a privilege escalation vulnerability.
The code error in the open source project has been designated severity 9.8 out of 10 because it can be executed remotely, the attack is not complex and no user interaction or special privileges are required .
According to Liggitt, a malicious user could use the Kubernetes API server to connect to a backend server to send arbitrary requests, authenticated by the API server's TLS credentials.
The API server is the main management entity in Kubernetes. It talks to the distributed storage controller etcd and to kublets, the agents overseeing each node in a cluster of software containers.
The bug was spotted by Darren Shepherd, chief architect and co-founder at Rancher Labs.
Red Hat OpenShift, an enterprise-oriented container platform, has introduced patches for all product variants.
"This is a big deal," said Ashesh Badani, veep and general manager of OpenShift at Red Hat, in a blog post. "Not only can [miscreants] steal sensitive data or inject malicious code, but they can also bring down production applications and services from within an organization’s firewall."
There are two primary attack vectors. Using the first, an individual possessing the Pod
exec/attach/portforward privileges granted to a normal user by default can become a cluster-admin, thereby gaining access to any container in the Pod and potentially any information therein.
The second method lets an unauthenticated user access the API to create unapproved services, which could be used to inject malicious code.
"Any unauthenticated user with access to a Kubernetes environment can hit the discovery endpoint which proxies the aggregated API server (not the kube-apiserver)," explained Christopher Robinson, manager of product security assurance at Red Hat, in an email to The Register.
"Crafting a message to the API so that an upgrade fails can leave the connection alive and allows re-use with arbitrary headers, and then allows cluster-admin level access to that aggregated API server. This could be used against the service-catalog that would allow for the creation of arbitrary service instances."
The vulnerability is particularly troubling because any unauthorized requests cannot be easily detected. According to Liggitt, they do not show up in the Kubernetes API server audit logs or server log. Malicious requests are visible in kublet or aggregated API server logs, but there's nothing that distinguishes them from authorized and proxied requests via the Kubernetes API server. ®