An unpatched security issue in the Kubernetes API is vulnerable to a “billion laughs” attack

Last week, a potentially serious and unpatched security issue was revealed in the Kubernetes API server GitHub repository by StackRox. The security lapse was due to the parsing of a Kubernetes API server deployment called YAML (Yet Another Markup Language) which is used for specifying configuration-type information. This security issue makes the cluster’s Kubernetes API service vulnerable to an attack called “billion laughs”. The billion laughs attack is a type of denial-of-service (DoS) attack.

The vulnerability has got a CVE-2019-11253, however, the details of the security attack are reserved till the Kubernetes organization makes the security problem public. Kubernetes has not yet released a security patch to fix the underlying vulnerability.

StackRox states, “The issue once again serves as a reminder that, like all software, Kubernetes is vulnerable to zero-day exploits. Thus, mere access to your Kubernetes API server should be treated as sensitive, regardless of how tight your application-level authorization policies (i.e., Kubernetes RBAC) are.”

Read Also: CNCF-led open-source Kubernetes security audit reveals 37 flaws in Kubernetes cluster; recommendations proposed

The Kubernetes cluster’s master and its resources are contacted by the Kubernetes API service which is backed by the Kubernetes apiserver. The Kubernetes apiserver accepts the incoming connections, after checking their authenticity of the entity and then applies the corresponding request handlers. One of the types of payloads that is accepted by the Kubernetes API service is exclusive to the YAML manifests and is concerned with the use of “references”. These references to nodes can be used in nodes that are themselves referenced in other nodes. This nesting of references and its subsequent expansion is the reason behind the current security vulnerability in the Kubernetes API.

The Kubernetes apiserver does not perform any input validation on the uploaded YAMLs, and also does not impose hard limits on the size of the expanded file. These non-responsive actions make the Kubernetes apiserver an easy target.

Thus, StackRox believes that only a clear fix to the Kubernetes apiserver code can safeguard the Kubernetes GitHub repository from this “billion laughs” attack.

Read Also: Kubernetes 1.16 releases with Endpoint Slices, general availability of Custom Resources, and other enhancements

StackRox recommends to protect the Kubernetes API server

Users should analyze the Role-based access control (RBAC) policies of the Kubernetes to ensure that only reliable entities hold privileged access to a cluster’s resources.

The cluster roles must be audited regularly. Users should be cautioned to keep the privileges of entities with low or no trust as unauthenticated users.

Users should also disable any anonymous access by passing the --anonymous-auth=false flag to both the API server and the Kubelets. It should be noted that any small information like the API server version or the fact that the Kubernetes API server is running on a particular host can also be a piece of valuable information to the attacker.

The Kubernetes API server endpoint should not be exposed to the internet, instead, it should be made secure using network firewalls. The API server access should only be given to trustworthy (private) subnets or VPC networks.