Kubernetes cloud computing bug could rain data for attackers

Kubernetes, a tool that powers much modern native cloud infrastructure, just got its first big security bug – and it’s a mammoth one. The flaw could give an attacker unfettered access to the software applications that rely on the tool to operate.
Kubernetes is a software tool that manages large numbers of containers. These are similar to the virtual machines that run multiple operating systems on the same physical computer, but they have a key difference. Instead of housing a complete operating system, containers house only what’s needed for a particular application to run (such as software dependencies, system libraries etc), while sharing a host operating system with other containers.
Containers are small, nimble operating environments that are designed to run the same way across multiple computing environments, removing “but it worked when we tested it!” issues. Companies can run tens or even hundreds of thousands of containers, and that can make deploying, updating and managing them all a serious challenge. That’s where Kubernetes comes in. It manages containers in groups called pods.
The program, which originally started as an open-source project from Google and is now managed by the Linux Foundation’s Cloud Native Computing Foundation (CNCF), sprang its first serious leak with the flaw, which gives an attacker deep access to a Kubernetes installation. It enables a specially crafted request to connect with Kubernetes servers and make their own requests.

The Kubernetes team announced the flaw as CVE-2018-1002105. The vulnerability lies with the Kubernetes API server – which is a software tool that enables Kubernetes users to send instructions to Kubernetes pods over an HTTP API (Application Programming Interface) – and the way that API server communicates with a Kubernetes pod.
The API server authorises user requests via certificate-based authentication. But if the user sends a malformed request designed to return an error, the server leaves the line of communication open with the pod and simply lets subsequent requests through without checking to see if the user is authorized. This effectively escalates the user’s privileges.
This issue enables a regular user to acquire exec (very high privileged) access to any container on the node, including those that have read/write access to the host filesystem. They get access to all running workloads, including all the data flowing between them.
Attackers could use this flaw to steal data, bring applications grinding to a halt, or run their own malicious commands.
There are two variants on the exploit, one that uses Kubernetes’ aggregated API servers, and which is accessible by all users. The other uses a call to an API known as an exec/attach/portforward, which is typically only available to users with admin/edit roles.
Red Hat provided more detail about how the flaw affects version 3.0 of OpenShift, its own container platform that uses Kubernetes as a core component.
Kubernetes has already patched the flaw, and users of systems that support automated patches should already be protected. Those that aren’t need to get their Kubernetes installations patched pronto.