Improper input validation in Kubernetes CSI sidecar containers for external-provisioner (<v0.4.3, <v1.0.2, v1.1, <v1.2.2, <v1.3.1), external-snapshotter (<v0.4.2, <v1.0.2, v1.1, <1.2.2), and external-resizer (v0.1, v0.2) could result in unauthorized PersistentVolume data access or volume mutation during snapshot, restore from snapshot, cloning and resizing operations.
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/
-->

**Am I vulnerable?**

CSI snapshot, cloning and resizing features are affected. Prior to Kubernetes 1.16, these features were all alpha and disabled by default. Starting in Kubernetes 1.16, CSI cloning and resizing features are beta and enabled by default. 

These features also require CSI drivers to be installed in a Kubernetes cluster and the CSI driver also has to support those features. An unofficial list of CSI drivers and their supported features is available [here](https://kubernetes-csi.github.io/docs/drivers.html), however it is best to check with the CSI driver vendor for the latest information.

Check if you have the following Kubernetes feature gates enabled:

```
VolumeSnapshotDataSource: alpha starting with K8s 1.12
ExpandCSIVolumes: alpha starting with K8s 1.14, beta starting with K8s 1.16
VolumePVCDataSource: alpha starting with K8s 1.15, beta starting with K8s 1.16
```

Check if you are using CSI drivers in your cluster. If so, the following command’s output will be non-empty:

```
$ kubectl get nodes -o jsonpath='{.items[*].metadata.annotations.csi\.volume\.kubernetes\.io\/nodeid}'
      {"my-csi-plugin":"kubernetes-minion-group-433q"}
```

Then, check the CSI driver’s pod specifications to see if they are using the following vulnerable versions of sidecars:

```
external-provisioner: v0.4.1-0.4.2, v1.0.0-1.0.1, v1.1.0-1.2.1, v1.3.0
external-snapshotter: v0.4.0-0.4.1, v1.0.0-1.0.1, v1.1.0-v1.2.1
external-resizer: v0.1.0-0.2.0
```

An example query:
```
$ kubectl get pods --all-namespaces -o jsonpath='{..image}' | tr ' ' $'\n' | grep "csi-provisioner\|csi-snapshotter\|csi-resizer"
      image: quay.io/k8scsi/csi-provisioner:v1.2.0
```

Note that the exact container image name may vary across CSI driver vendors. It is recommended to inspect the Pod specifications directly.

**How do I mitigate the vulnerability?**

As a short term mitigation, disable the `VolumeSnapshotDataSource`, `ExpandCSIVolumes`, and `VolumePVCDataSource` Kubernetes feature gates in kube-apiserver and kube-controller-manager. This will cause new PersistentVolumeClaims to be provisioned ignoring the DataSource and resizing requests will also be ignored. Note that this will cause new PVCs that are intended to be provisioned from a snapshot or clone to instead provision a blank disk.

Also, to disable taking volume snapshots, either remove the external-snapshotter sidecar from any CSI drivers or revoke the CSI driver’s RBAC permissions on the `snapshot.storage.k8s.io` API group.

Longer term, upgrade your CSI driver with patched versions of the affected sidecars. Fixes are available in the following sidecar versions:

external-provisioner: 
v0.4.3
v1.0.2
v1.2.2
v1.3.1
v1.4.0 

external-snapshotter:
v0.4.2
v1.0.2
v1.2.2

external-resizer
v0.3.0

Fixes for each of the sidecars can be tracked by:
https://github.com/kubernetes-csi/external-provisioner/issues/380
https://github.com/kubernetes-csi/external-snapshotter/issues/193
https://github.com/kubernetes-csi/external-resizer/issues/63

**How do I upgrade?**

Check with your CSI driver vendor for upgrade instructions. No Kubernetes control plane or node upgrades are required unless the CSI driver is bundled into the Kubernetes distribution.

**Vulnerability details**

There are two different vulnerabilities impacting the same features.

When PersistentVolumeClaim and PersistentVolume objects are bound, they have bidirectional references to each other. When dereferencing a PersistentVolumeClaim to get a PersistentVolume, the impacted sidecar controllers were not validating that the PersistentVolume referenced back to the same PersistentVolumeClaim, potentially operating on unauthorized PersistentVolumes for snapshot, cloning and resizing operations.

A similar issue exists for VolumeSnapshot and VolumeSnapshotContent objects when creating a new PersistentVolumeClaim from a snapshot.

The second issue is related to the property that CSI volume and snapshot ids are only required to be unique within a single CSI driver. Impacted sidecar controllers were not validating that the requested source VolumeSnapshot or PersistentVolumeClaim specified were from the same driver processing the request, potentially operating on unauthorized volumes during snapshot, restore from snapshot, or cloning operations.


CVE-2019-11255: CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : CVE-2019-11255: CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation
Issue date:

--- start body ---
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/
-->

**Am I vulnerable?**

CSI snapshot, cloning and resizing features are affected. Prior to Kubernetes 1.16, these features were all alpha and disabled by default. Starting in Kubernetes 1.16, CSI cloning and resizing features are beta and enabled by default. 

These features also require CSI drivers to be installed in a Kubernetes cluster and the CSI driver also has to support those features. An unofficial list of CSI drivers and their supported features is available [here](https://kubernetes-csi.github.io/docs/drivers.html), however it is best to check with the CSI driver vendor for the latest information.

Check if you have the following Kubernetes feature gates enabled:

```
VolumeSnapshotDataSource: alpha starting with K8s 1.12
ExpandCSIVolumes: alpha starting with K8s 1.14, beta starting with K8s 1.16
VolumePVCDataSource: alpha starting with K8s 1.15, beta starting with K8s 1.16
```

Check if you are using CSI drivers in your cluster. If so, the following command’s output will be non-empty:

```
$ kubectl get nodes -o jsonpath='{.items[*].metadata.annotations.csi\.volume\.kubernetes\.io\/nodeid}'
      {"my-csi-plugin":"kubernetes-minion-group-433q"}
```

Then, check the CSI driver’s pod specifications to see if they are using the following vulnerable versions of sidecars:

```
external-provisioner: v0.4.1-0.4.2, v1.0.0-1.0.1, v1.1.0-1.2.1, v1.3.0
external-snapshotter: v0.4.0-0.4.1, v1.0.0-1.0.1, v1.1.0-v1.2.1
external-resizer: v0.1.0-0.2.0
```

An example query:
```
$ kubectl get pods --all-namespaces -o jsonpath='{..image}' | tr ' ' $'\n' | grep "csi-provisioner\|csi-snapshotter\|csi-resizer"
      image: quay.io/k8scsi/csi-provisioner:v1.2.0
```

Note that the exact container image name may vary across CSI driver vendors. It is recommended to inspect the Pod specifications directly.

**How do I mitigate the vulnerability?**

As a short term mitigation, disable the `VolumeSnapshotDataSource`, `ExpandCSIVolumes`, and `VolumePVCDataSource` Kubernetes feature gates in kube-apiserver and kube-controller-manager. This will cause new PersistentVolumeClaims to be provisioned ignoring the DataSource and resizing requests will also be ignored. Note that this will cause new PVCs that are intended to be provisioned from a snapshot or clone to instead provision a blank disk.

Also, to disable taking volume snapshots, either remove the external-snapshotter sidecar from any CSI drivers or revoke the CSI driver’s RBAC permissions on the `snapshot.storage.k8s.io` API group.

Longer term, upgrade your CSI driver with patched versions of the affected sidecars. Fixes are available in the following sidecar versions:

external-provisioner: 
v0.4.3
v1.0.2
v1.2.2
v1.3.1
v1.4.0 

external-snapshotter:
v0.4.2
v1.0.2
v1.2.2

external-resizer
v0.3.0

Fixes for each of the sidecars can be tracked by:
https://github.com/kubernetes-csi/external-provisioner/issues/380
https://github.com/kubernetes-csi/external-snapshotter/issues/193
https://github.com/kubernetes-csi/external-resizer/issues/63

**How do I upgrade?**

Check with your CSI driver vendor for upgrade instructions. No Kubernetes control plane or node upgrades are required unless the CSI driver is bundled into the Kubernetes distribution.

**Vulnerability details**

There are two different vulnerabilities impacting the same features.

When PersistentVolumeClaim and PersistentVolume objects are bound, they have bidirectional references to each other. When dereferencing a PersistentVolumeClaim to get a PersistentVolume, the impacted sidecar controllers were not validating that the PersistentVolume referenced back to the same PersistentVolumeClaim, potentially operating on unauthorized PersistentVolumes for snapshot, cloning and resizing operations.

A similar issue exists for VolumeSnapshot and VolumeSnapshotContent objects when creating a new PersistentVolumeClaim from a snapshot.

The second issue is related to the property that CSI volume and snapshot ids are only required to be unique within a single CSI driver. Impacted sidecar controllers were not validating that the requested source VolumeSnapshot or PersistentVolumeClaim specified were from the same driver processing the request, potentially operating on unauthorized volumes during snapshot, restore from snapshot, or cloning operations.


--- end body ---

CVE-2019-11255 is a security vulnerability in Kubernetes affecting the CSI volume snapshot, cloning, and resizing features. It allows unauthorized access or mutation of volume data due to improper validation of PersistentVolumeClaim and PersistentVolume references, as well as insufficient checks on VolumeSnapshot and VolumeSnapshotContent objects. This can lead to potential data leaks or corruption if exploited by an attacker with access to the Kubernetes cluster.