Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: A potential risk in kubefs which can be leveraged to make a cluster-level privilege escalation #1882

Closed
younaman opened this issue Apr 9, 2023 · 5 comments
Assignees
Labels
bug Something isn't working

Comments

@younaman
Copy link

younaman commented Apr 9, 2023

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:

  1. 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.

  2. 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.

  3. 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:

  1. 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.

  2. Using the Rolebinding, not the clusterRoleBinding is another way to restrain the DaemonSet can only access the secrets of "cubefs" Kubernetes namespace.

  3. 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:

  1. Is it a real issue in cubefs?
  2. If it's a real issue, can cubefs mitigate the risks following my suggestion?
  3. 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

@GongWilliam
Copy link
Member

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...

@younaman
Copy link
Author

@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?

@younaman
Copy link
Author

younaman commented Apr 11, 2023

@GongWilliam @leonrayang @xiaochunhe Are there any updates? I have approved the PR. Can cubefs give me a CVE number after fixing this issue?

@GongWilliam
Copy link
Member

@younaman CVE-2023-30512

@younaman
Copy link
Author

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:)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants