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
The text was updated successfully, but these errors were encountered:
this rbac of secret will be removed to avoid the potential attack.
I don't know if anyone has been affected for this issue, maybe most of the cubefs users is on premise, so the external attack is hard to get it.
and I find that most of the csidrivers on github have the same issue, include alibaba/azure/ceph...
@GongWilliam Thanks! I have give multiple security reports to the cloud vendors, including the Alibaba/Azure/Amazon EKS, and Google GKE. The EKS, Alibaba ACK, Google GKE has confirmed the issue I reported and trying to fix the related problems.
Can cubefs give me a moderate CVE number for awarding my efforts after fixing this issue?
Thanks! I am very appreciative of all maintainers' work and patience:) Please add my name to the related security advisory. Thank you again for your work @GongWilliam , have a nice day:)
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:
it:)
Looking forward to your reply.
Regards,
Nanzi Yang
The text was updated successfully, but these errors were encountered: