CVE-2020-8569: snapshot-controller DoS (NULL pointer dereference)

[jsafrane]

CVSS Rating: TBD

The Kubernetes snapshot-controller has been found to be vulnerable to a denial of service attack via authorized API requests.

The snapshot-controller is an optional Kubernetes component that enables volume snapshot feature, which is beta in Kubernetes 1.17 It is installed typically as an add-on into a Kubernetes cluster. See https://kubernetes-csi.github.io/docs/snapshot-controller.html for details.

The snapshot-controller could dereference a NULL pointer when processing a VolumeSnapshot custom resource when:

• The VolumeSnapshot referenced a non-existing PersistentVolumeClaim;
• And the VolumeSnapshot did not reference any VolumeSnapshotClass.

The snapshot-controller crashes and it is automatically restarted by Kubernetes, however, it processes the same VolumeSnapshot custom resource after the restart and crashes again, entering an endless crashloop.

Only the volume snapshot feature is affected by this vulnerability. When exploited, users can’t take snapshots of their volumes or delete the snapshots. All other Kubernetes functionality is not affected.

Am I vulnerable?

You may be vulnerable if:

• You run Kubernetes CSI snapshot-controller;
• You are running a vulnerable version (see below);
• Untrusted users can create VolumeSnapshot custom resources in API group snapshot.storage.k8s.io.

Affected Versions

• snapshot-controller v2.1.0 - v2.1.2
• snapshot-controller v3.0.0 - v3.0.1

How do I mitigate this vulnerability?

Prior to upgrading, this vulnerability can be mitigated by restricting creation of VolumeSnapshot custom resources in API group snapshot.storage.k8s.io only to trusted users.

Fixed Versions

• snapshot-controller v2.1.3
• snapshot-controller v3.0.2

To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster

Detection

The snapshot-controller Pod crashlooping could be an indication of this CVE being exploited. Check the health of the snapshot-controller Deployment and Pods.
If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

Additional Details

See #380 for a detailed reproducer and #381 for a fix.

Acknowledgements

This vulnerability was reported by Qin Ping and Jan Šafránek.

/area security
/kind bug
/committee product-security
/sig storage

[k8s-ci-robot]

@jsafrane: The label(s) area/security cannot be applied, because the repository doesn't have them

In response to this:

CVSS Rating: TBD

The Kubernetes snapshot-controller has been found to be vulnerable to a denial of service attack via authorized API requests.

The snapshot-controller is an optional Kubernetes component that enables volume snapshot feature. It is installed typically as an add-on into a Kubernetes cluster. See https://kubernetes-csi.github.io/docs/snapshot-controller.html for details.

The snapshot-controller did not properly handle all error cases and could dereference a NULL pointer when a VolumeSnapshot custom resource referenced a non-existing PersistentVolumeClaim. The snapshot-controller crashes and it is automatically restarted by Kubernetes, however, it processes the same VolumeSnapshot custom resource after restart and crashes again, entering an endless crashloop.

Only the volume snapshot feature is affected by this vulnerability. Volume snapshots is a beta feature of Kubernetes 1.19. Even when this vulnerability is exposed, it can affect only the volume snapshot feature - users can’t take snapshots of their volumes or delete the snapshots. All other Kubernetes functionality is not affected.

Am I vulnerable?

You may be vulnerable if:

• You run Kubernetes CSI snapshot-controller;
• You are running a vulnerable version (see below);
• Untrusted users can create VolumeSnapshot custom resources in API group snapshot.storage.k8s.io;

Affected Versions

• snapshot-controller v3.0.0 - v3.0.1

How do I mitigate this vulnerability?

Prior to upgrading, this vulnerability can be mitigated by restricting creation of VolumeSnapshot custom resources in API group snapshot.storage.k8s.io only to trusted users.

Fixed Versions

• snapshot-controller v3.0.2

To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster

Detection

The snapshot-controller Pod crashlooping could be an indication of this CVE being exploited. Check the health of the snapshot-controller Deployment and Pods.
If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

Additional Details

See #380 for a detailed reproducer and #381 for a fix.

Acknowledgements

This vulnerability was reported by Qin Ping and Jan Šafránek.

/area security
/kind bug
/committee product-security
/sig storage

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[xing-yang]

The snapshot-controller did not properly handle all error cases and could dereference a NULL pointer when a VolumeSnapshot custom resource referenced a non-existing PersistentVolumeClaim.

Can you clarify that this only happens if user tries to create a VolumeSnapshot that does not have a VolumeSnapshotClassName specified?

[jsafrane]

this only happens if user tries to create a VolumeSnapshot that does not have a VolumeSnapshotClassName specified?

Added. And cut the rest a bit.

[msau42]

Does 2.x have this issue?

[jsafrane]

Does 2.x have this issue?

No

[xing-yang]

This was probably introduced when we fixed the bug where the VolumeSnapshot cannot be deleted if VolumeSnapshotClass is not found.

[msau42]

Announcement has been sent out to kubernetes security, storage and csi lists.

/close

[k8s-ci-robot]

@msau42: Closing this issue.

In response to this:

Announcement has been sent out to kubernetes security, storage and csi lists.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[msau42]

I modified the description to say the feature has been beta since 1.17. I think the announcement said 1.19, which is not correct.