Improper input validation in the Kubernetes API server in versions v1.0-1.12 and versions prior to v1.13.12, v1.14.8, v1.15.5, and v1.16.2 allows authorized users to send malicious YAML or JSON payloads, causing the API server to consume excessive CPU or memory, potentially crashing and becoming unavailable. 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.
cpe:2.3:a:kubernetes:kubernetes:*:*:*:*:*:*:*:*
F0820894-56B7-4CB8-AE5C-29639FA59718
1.12.10
1.1.0
cpe:2.3:a:kubernetes:kubernetes:*:*:*:*:*:*:*:*
9FF055F3-E11D-41DB-9ED7-434D9ED905B4
1.13.2
1.13.0
cpe:2.3:a:kubernetes:kubernetes:*:*:*:*:*:*:*:*
ADA3952E-8133-4E6A-A365-4FD74ABA962C
1.14.8
1.14.0
cpe:2.3:a:kubernetes:kubernetes:*:*:*:*:*:*:*:*
F9F7837F-DA69-453E-8B24-1EDF0A5CAB4C
1.15.5
1.15.0
cpe:2.3:a:kubernetes:kubernetes:*:*:*:*:*:*:*:*
E1BDF819-871C-4E34-978F-BAFF8D895B84
1.16.2
1.16.0
OR
cpe:2.3:a:redhat:openshift_container_platform:3.9:*:*:*:*:*:*:*
309CB6F8-F178-454C-BE97-787F78647C28
cpe:2.3:a:redhat:openshift_container_platform:3.10:*:*:*:*:*:*:*
4DBCD38F-BBE8-488C-A8C3-5782F191D915
cpe:2.3:a:redhat:openshift_container_platform:3.11:*:*:*:*:*:*:*
2F87326E-0B56-4356-A889-73D026DB1D4B
OR
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](https://www.first.org/cvss/calculator/3.0#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.

**Affected versions:**
* Kubernetes v1.0.0-1.12.x
* Kubernetes v1.13.0-1.13.11, resolved in v1.13.12 by https://github.com/kubernetes/kubernetes/pull/83436
* Kubernetes v1.14.0-1.14.7, resolved in v1.14.8 by https://github.com/kubernetes/kubernetes/pull/83435
* Kubernetes v1.15.0-1.15.4, resolved in v1.15.5 by https://github.com/kubernetes/kubernetes/pull/83434
* Kubernetes v1.16.0-1.16.1, resolved in v1.16.2 by https://github.com/kubernetes/kubernetes/pull/83433

All four patch releases are now available.

Fixed in master by #83261

**Mitigation:**

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](https://github.com/kubernetes/kubernetes/files/3735508/rbac.yaml.txt) as `rbac.yaml`, and run:

```sh
kubectl auth reconcile -f rbac.yaml --remove-extra-subjects --remove-extra-permissions 
```

**Note: this removes the ability for unauthenticated users to use `kubectl auth can-i`**

If you are running a version prior to v1.14.0:
* in addition to installing the restrictive policy, turn off autoupdate for this clusterrolebinding so your changes aren’t replaced on an API server restart:
    ```sh
    kubectl annotate --overwrite clusterrolebinding/system:basic-user rbac.authorization.kubernetes.io/autoupdate=false
    ```
* after upgrading to v1.14.0 or greater, you can remove this annotation to reenable autoupdate:
    ```sh
    kubectl annotate --overwrite clusterrolebinding/system:basic-user rbac.authorization.kubernetes.io/autoupdate=true
    ```

=============

**Original description follows:**

**Introduction** 

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](https://stackoverflow.com/questions/58129150/security-yaml-bomb-user-can-restart-kube-api-by-sending-configmap/58133282#58133282)

**What happened**:

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](https://en.wikipedia.org/wiki/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.

```
apiVersion: v1
data:
  a: &a ["web","web","web","web","web","web","web","web","web"]
  b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
  c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
  d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
  e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
  f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
  g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
  h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
  i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
kind: ConfigMap
metadata:
  name: yaml-bomb
  namespace: default
```
**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 `kube-apiserver` but both tests I did (1.16 client against 1.15 Kubeadm cluster and 1.16 client against 1.16 kubeadm cluster) showed the CPU usage client-side.

**How to reproduce it (as minimally and precisely as possible)**:

Get the manifest above and apply to a cluster as normal with `kubectl create -f <manifest>`.  Use `top` or another CPU monitor to observe the quantity of CPU time used.

**Anything else we need to know?**:

**Environment**:
- Kubernetes version (use `kubectl version`):

**test 1** (linux AMD64 client, Kubeadm cluster running in kind)
```
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-25T23:41:27Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
```

**test 2** (Linux AMD64 client, Kubeadm cluster running in VMWare Workstation)
```
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:27:17Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
```


CVE-2019-11253: Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : CVE-2019-11253: Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack
Issue date:

--- start body ---
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](https://www.first.org/cvss/calculator/3.0#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.

**Affected versions:**
* Kubernetes v1.0.0-1.12.x
* Kubernetes v1.13.0-1.13.11, resolved in v1.13.12 by https://github.com/kubernetes/kubernetes/pull/83436
* Kubernetes v1.14.0-1.14.7, resolved in v1.14.8 by https://github.com/kubernetes/kubernetes/pull/83435
* Kubernetes v1.15.0-1.15.4, resolved in v1.15.5 by https://github.com/kubernetes/kubernetes/pull/83434
* Kubernetes v1.16.0-1.16.1, resolved in v1.16.2 by https://github.com/kubernetes/kubernetes/pull/83433

All four patch releases are now available.

Fixed in master by #83261

**Mitigation:**

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](https://github.com/kubernetes/kubernetes/files/3735508/rbac.yaml.txt) as `rbac.yaml`, and run:

```sh
kubectl auth reconcile -f rbac.yaml --remove-extra-subjects --remove-extra-permissions 
```

**Note: this removes the ability for unauthenticated users to use `kubectl auth can-i`**

If you are running a version prior to v1.14.0:
* in addition to installing the restrictive policy, turn off autoupdate for this clusterrolebinding so your changes aren’t replaced on an API server restart:
    ```sh
    kubectl annotate --overwrite clusterrolebinding/system:basic-user rbac.authorization.kubernetes.io/autoupdate=false
    ```
* after upgrading to v1.14.0 or greater, you can remove this annotation to reenable autoupdate:
    ```sh
    kubectl annotate --overwrite clusterrolebinding/system:basic-user rbac.authorization.kubernetes.io/autoupdate=true
    ```

=============

**Original description follows:**

**Introduction** 

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](https://stackoverflow.com/questions/58129150/security-yaml-bomb-user-can-restart-kube-api-by-sending-configmap/58133282#58133282)

**What happened**:

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](https://en.wikipedia.org/wiki/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.

```
apiVersion: v1
data:
  a: &a ["web","web","web","web","web","web","web","web","web"]
  b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
  c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
  d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
  e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
  f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
  g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
  h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
  i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
kind: ConfigMap
metadata:
  name: yaml-bomb
  namespace: default
```
**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 `kube-apiserver` but both tests I did (1.16 client against 1.15 Kubeadm cluster and 1.16 client against 1.16 kubeadm cluster) showed the CPU usage client-side.

**How to reproduce it (as minimally and precisely as possible)**:

Get the manifest above and apply to a cluster as normal with `kubectl create -f <manifest>`.  Use `top` or another CPU monitor to observe the quantity of CPU time used.

**Anything else we need to know?**:

**Environment**:
- Kubernetes version (use `kubectl version`):

**test 1** (linux AMD64 client, Kubeadm cluster running in kind)
```
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-25T23:41:27Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
```

**test 2** (Linux AMD64 client, Kubeadm cluster running in VMWare Workstation)
```
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:27:17Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
```


--- end body ---

comments :
--- start comments ---

--- end comments ---