Summary
The Amazon EFS CSI Driver is an open-source Kubernetes Container Storage Interface (CSI) driver that lets Kubernetes workloads use Amazon EFS file systems. An issue exists where, under certain circumstances, the driver's volume-deletion path does not verify that the EFS access point referenced by a PersistentVolume's volume handle belongs to the file system referenced by that same volume handle, allowing recursive deletion of data on an unrelated file system.
Impact
When the controller is configured with the non-default --delete-access-point-root-dir=true option, the volume handle has the form efs:<fileSystemId>::<accessPointId>. On volume deletion the controller resolves the access point's configured root directory path and then mounts the file system named in the handle and recursively deletes that path from it, without first confirming that the access point actually belongs to that file system. An authenticated Kubernetes user who can create (or influence) a PersistentVolume can pair a target file system with an access point owned by a different file system.
On deletion, the controller uses its own broad IAM and EFS data-plane permissions to mount the an actor-named victim file system and recursively delete the access point's root-directory path from it — a confused-deputy pattern. No workload Pod is required; binding and then deleting a PersistentVolumeClaim is sufficient. The result is targeted, recursive deletion of directories and files on an Amazon EFS file system the user is not authorized to mount, write to, or administer, causing loss of data integrity and availability. No data disclosure occurs. The issue is can be leveraged across accounts where the controller's role can describe the access point and the target file system's mount target is reachable.
The following conditions must all be met:
-
The controller is configured with --delete-access-point-root-dir=true (off by default).
-
The user can create or influence a PersistentVolume's volume handle.
-
The PersistentVolume uses persistentVolumeReclaimPolicy: Delete.
-
The controller can describe the referenced access point and reach and mount the victim file system's mount target.
Impacted versions: <=3.4.0
Patches
This issue has been addressed in Amazon EFS CSI Driver version v3.4.1. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. The fix adds a check that rejects any volume handle whose file system ID does not match the access point's true owning file system before any mount or deletion is performed.
Workarounds
Customers who cannot upgrade immediately can keep --delete-access-point-root-dir disabled (the default), restrict PersistentVolume-creation RBAC to trusted administrators, scope the controller's IAM role to only the file systems it must manage, and attach explicit EFS resource policies to file systems.
References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
Acknowledgement
We would like to thank Marcel Karlsson for collaborating on this issue through the coordinated disclosure process.
Summary
The Amazon EFS CSI Driver is an open-source Kubernetes Container Storage Interface (CSI) driver that lets Kubernetes workloads use Amazon EFS file systems. An issue exists where, under certain circumstances, the driver's volume-deletion path does not verify that the EFS access point referenced by a PersistentVolume's volume handle belongs to the file system referenced by that same volume handle, allowing recursive deletion of data on an unrelated file system.
Impact
When the controller is configured with the non-default
--delete-access-point-root-dir=trueoption, the volume handle has the formefs:<fileSystemId>::<accessPointId>. On volume deletion the controller resolves the access point's configured root directory path and then mounts the file system named in the handle and recursively deletes that path from it, without first confirming that the access point actually belongs to that file system. An authenticated Kubernetes user who can create (or influence) a PersistentVolume can pair a target file system with an access point owned by a different file system.On deletion, the controller uses its own broad IAM and EFS data-plane permissions to mount the an actor-named victim file system and recursively delete the access point's root-directory path from it — a confused-deputy pattern. No workload Pod is required; binding and then deleting a PersistentVolumeClaim is sufficient. The result is targeted, recursive deletion of directories and files on an Amazon EFS file system the user is not authorized to mount, write to, or administer, causing loss of data integrity and availability. No data disclosure occurs. The issue is can be leveraged across accounts where the controller's role can describe the access point and the target file system's mount target is reachable.
The following conditions must all be met:
The controller is configured with
--delete-access-point-root-dir=true(off by default).The user can create or influence a PersistentVolume's volume handle.
The PersistentVolume uses
persistentVolumeReclaimPolicy: Delete.The controller can describe the referenced access point and reach and mount the victim file system's mount target.
Impacted versions: <=3.4.0
Patches
This issue has been addressed in Amazon EFS CSI Driver version v3.4.1. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. The fix adds a check that rejects any volume handle whose file system ID does not match the access point's true owning file system before any mount or deletion is performed.
Workarounds
Customers who cannot upgrade immediately can keep
--delete-access-point-root-dirdisabled (the default), restrict PersistentVolume-creation RBAC to trusted administrators, scope the controller's IAM role to only the file systems it must manage, and attach explicit EFS resource policies to file systems.References
If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
Acknowledgement
We would like to thank Marcel Karlsson for collaborating on this issue through the coordinated disclosure process.