Kubernetes ‘Billion Laughs’ Vulnerability Is No Laughing Matter

A new vulnerability has been discovered within the Kubernetes API. This flaw is centered around the parsing of YAML manifests by the Kubernetes API server. During this process, the API server is open to potential Denial of Service (DoS) attacks. The issue (CVE-2019-11253 — which has yet to have any details fleshed out on the page) has been labeled a “Billion Laughs” attack because it targets the parsers to carry out the attack.

What Is a ‘Billion Laughs’ Attack?

A Billion Laughs attack is a particular type of denial of service (DoS) attack which is aimed specifically at XML document parsers. This attack is also referred to as an XML bomb or an exponential entity expansion attack.

How This Works

The Kubernetes API is the main point of interaction between the Kubernetes master and nodes, and is backed by the Kubernetes apiserver (kube-apiserver). This API server validates and configures data for the various API objects — such as pods, services, and replication controllers — and authenticates incoming connections to ensure the entity requesting the connection is authorized to make the request. This particular API Server services REST (Representational State Transfer) operations and provides a frontend to a Kubernetes cluster’s shared state, but kube-apiserver doesn’t conduct input validation on the YAML manifests, nor does it impose a limit on the YAML manifest file size.

What happens with this Billion Laughs attack is that nested references to nodes can grow very large when expanded. Because the kube-apiserver doesn’t perform validation on the manifest, it doesn’t detect if those nested references will cause a problem. If the nesting references grow too large, excessive CPU and RAM usage can render the apiserver unresponsive to connections … hence the Denial of Service.

This threat should be considered substantial, and although no details have been pushed to the CVE, there are still steps you can take to protect your data and your clusters.

What You Can Do

The first (and most important) step to take is to review your RBAC policies and make sure you understand how access is granted to the cluster. You want to verify that only trusted entities can gain privileged access to any given resource on the cluster. Any role that allows the modification of resources should be audited carefully. Check every role (such as edit, delete, patch, create) and make sure every associated user who has assigned roles must have those roles. Make sure to audit these roles and user regularly.

Also, make sure to disable anonymous access to both the API server and Kubelets. This is done with the –anonymous-auth=false option. How you pass this option to the API server and Kubletes will depend on the platform you used to deploy Kubernetes.

Finally, under no circumstances, should you expose the Kubernetes API server to the internet. Because this service is particularly vulnerable at the moment, you should have it protected with a firewall and only allow access to it via trusted networks, subnets, or a VPN with strong encryption.

Until the developers responsible for the kube-apiserver resolve this issue, it is crucial that you and your company make sure you are following any and all best practices for deploying a Kubernetes cluster.