CVE-2019-11253: Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack #83253
CVE-2019-11253 is a denial of service vulnerability in the kube-apiserver, allowing authorized users sending malicious YAML or JSON payloads to cause kube-apiserver to consume excessive CPU or memory, potentially crashing and becoming unavailable. This vulnerability has been given an initial severity of High, with a score of 7.5 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
Prior to v1.14.0, default RBAC policy authorized anonymous users to submit requests that could trigger this vulnerability. Clusters upgraded from a version prior to v1.14.0 keep the more permissive policy by default for backwards compatibility. See the mitigation section below for instructions on how to install the more restrictive v1.14+ policy.
All four patch releases are now available.
Fixed in master by #83261
Requests that are rejected by authorization do not trigger the vulnerability, so managing authorization rules and/or access to the Kubernetes API server mitigates which users are able to trigger this vulnerability.
To manually apply the more restrictive v1.14.x+ policy, either as a pre-upgrade mitigation, or as an additional protection for an upgraded cluster, save the attached file as
kubectl auth reconcile -f rbac.yaml --remove-extra-subjects --remove-extra-permissions
Note: this removes the ability for unauthenticated users to use
If you are running a version prior to v1.14.0:
Original description follows:
Posting this as an issue following report to the security list who suggested putting it here as it's already public in a Stackoverflow question here
When creating a ConfigMap object which has recursive references contained in it, excessive CPU usage can occur. This appears to be an instance of a "Billion Laughs" attack which is quite well known as an XML parsing issue.
Applying this manifest to a cluster causes the client to hang for some time with considerable CPU usage.
What you expected to happen:
Ideally it would be good for a maximum size of entity to be defined, or perhaps some limit on recursive references in YAML parsed by kubectl.
One note is that the original poster on Stackoverflow indicated that the resource consumption was in
How to reproduce it (as minimally and precisely as possible):
Get the manifest above and apply to a cluster as normal with
Anything else we need to know?:
test 1 (linux AMD64 client, Kubeadm cluster running in kind)
test 2 (Linux AMD64 client, Kubeadm cluster running in VMWare Workstation)
The text was updated successfully, but these errors were encountered:
To update based on ideas from @liggitt and @bgeesaman , it's also possible to use this issue to cause a denial of service to the
Steps to reproduce.
I don't think we can simply drop a supported format. Disabling alias/anchor expansion or bounding allocations seem more reasonable. I have a fix in progress that does the latter.
@roycaihw: GitHub didn't allow me to assign the following users: jktomer.
Note that only kubernetes members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
I'm not disagreeing, but: We could drop yaml, and communicate that through Accept headers in an unambiguous way. On the other hand, claiming to accept "yaml" but then dropping support for some features of yaml seems harder for a client to respond to automatically :/
Also note we have patch variants like
(I completely agree that almost no "legitimate" client is sending yaml with anchors, except maybe in a hypothetical CRD that is human authored and contains lots of internal duplication (argo pipeline??). I personally have no problems with nuking yaml anchor support, just as we also don't support !!foo, etc)