Headline
CVE-2023-30512: [Bug]: A potential risk in kubefs which can be leveraged to make a cluster-level privilege escalation · Issue #1882 · cubefs/cubefs
CubeFS through 3.2.1 allows Kubernetes cluster-level privilege escalation. This occurs because DaemonSet has cfs-csi-cluster-role and can thus list all secrets, including the admin secret.
Dear cubefs maintainers:
I am Nanzi Yang, and I find a potential risk in cubefs that can be leveraged to make cluster-level privilege escalation.
Detailed analysis:
The cubefs has one DaemonSet "cfs-csi-node", which runs pods on each node of a Kubernetes cluster. And the cubefs has one deployment "cfs-csi-controller", which runs a pod on a worker node randomly.
The DaemonSet and Deployment both use service account cfs-csi-service-account, which has a cluster role called “cfs-csi-cluster-role” via cluster role binding "cfs-csi-cluster-role-binding". And the Cluster Role has a “get list” verb of the secrets resources. Thus, the DaemonSet and Deployment’s can leverage their service account token to list/get ALL secrets in the Kubernetes cluster.
If a malicious user controls one worker node, he/she can leverage the DaemonSet’s pod to get/list ALL secrets (e.g., the cluster’s admin secret), escaping from a worker node to the cluster’s administrator. In other words, he/she can make a cluster-level privilege escalation.
Mitigation Discussion:
The DaemonSet of cubefs should restrain the secrets which can be accessed by the DaemonSet itself. For example, the cubefs maintainers can use the “secret name” to restrain the secrets which can be accessed by this DaemonSet.
Using the Rolebinding, not the clusterRoleBinding is another way to restrain the DaemonSet can only access the secrets of “cubefs” Kubernetes namespace.
The cubefs’s maintainers should use a more complex service account without using “cfs-csi-service-account” in both deployments and DaemonSets. I am afraid that it would be better to remove the “get/list” verb of “secret” resources from DaemonSet’s service
account.
A few questions:
- Is it a real issue in cubefs?
- If it’s a real issue, can cubefs mitigate the risks following my suggestion?
- If it’s a real issue, can cubefs give me a CVE number after fixing this problem for awarding my efforts? I will be very appreciative of
it:)
Looking forward to your reply.
Regards,
Nanzi Yang
Related news
CubeFS through 3.2.1 allows Kubernetes cluster-level privilege escalation. This occurs because DaemonSet has cfs-csi-cluster-role and can thus list all secrets, including the admin secret.