Kubernetes Vulnerability Can Turn Containers Into Zombies

Over the past several years, Kubernetes has become the leading cloud container orchestration system. It groups data containers that make up an application into logical units for easy management.

Additionally, Kuberneteshas benefited from 15 years of on-the-job training at Google, and is considered to be an underpinning of cloud computing.

Except one guy found a way to make it roll over and turn into a zombie. While it is the first major vulnerability to be discovered in the container system, it's a corker. (See Kubernetes & Containers Stir Security Concerns in the Cloud.)

Darren Shepherd, the co-founder of Rancher Labs and its chief architect, found the vulnerability, which is tracked as CVE-2018-1002105. It has been assigned a CVSS score of 9.8 out of 10, and it is considered critical.

Affected versions of Kubernetes include, Kubernetes v1.0.x-1.9.x, Kubernetes v1.10.0-1.10.10, Kubernetes v1.11.0-1.11.4, and Kubernetes v1.12.0-1.12.2.

(Source: Pixabay)

Specifically, this vulnerability allows an attacker to escalate privileges within a system when specially crafted requests are sent to the targeted server.

Jordan Liggitt, who is part of the Kubernetes security team, describes the vulnerability in his blog:

"With a specially crafted request, users that are authorized 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."

That's geekspeak for making it a zombie sock-puppet.

It gets worse. The problem affects configurations that should not let users near the backend servers. Liggett wrote that affected configurations include clusters that run extension API servers -- such as the metrics server -- that are directly accessible from the Kubernetes API server's network, as well as clusters that grant pod exec/attach/portforward permissions to users who are not expected to have full access to kubelet APIs.

Indeed, in default configurations, all users -- authenticated and unauthenticated -- are allowed to perform discovery API calls that pave the way for the escalation to occur.

You can't even detect in a system if this vulnerability has been exploited.

Since the unauthorized requests are made over an established legitimate connection, they won't appear in the Kubernetes API server audit logs or server log. The requests may appear in other logs, but they are indistinguishable from the correctly authorized and proxied requests that come in through the Kubernetes API server.

While there are some mitigations, such as removing all anonymous access to all aggregated APIs, including discovery permissions granted by the default discovery role bindings, many of these are likely to be disruptive, and upgrading to a fixed version is strongly recommended by the security team.

The way out of this one is to patch. It may be a pain and difficult to get everything patched, but it is also absolutely necessary.

Related posts:

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.