[Bug] DaemonSet hwameistor-local-disk-manager has too much RBAC permission which may leads the whole cluster being hijacked

[Yseona]

Hi community! I just found a possible security issue when reading the code. I would like to discuss whether it is a real vulnerability.

Description

The bug is that the DaemonSet hwameistor-local-disk-manager in the charts has too much RBAC permission than it needs, which may cause some security problems, and the worse one leads cluster being hijacked. The problem is that the hwameistor-local-disk-manager uses a sharing service account (local-disk-manager.yaml#L17) instead of creating a separate one. This causes the hwameistor-local-disk-manager have the following sensitive permissions:

• create/update/patch/delete verb of deployments/statefulsets/daemonsets/cronjobs/replicasets/job resource (ClusterRole)
• get/list verb of secrets resource (ClusterRole)
• update/patch verb of nodes resource (ClusterRole)

After reading the source code of hwameistor-local-disk-manager, I didn't find any Kubernetes API usages using these permissions. However, these unused permissions may have some potential risks:

• create/update/patch/delete verb of deployments/statefulsets/daemonsets/cronjobs/replicasets/job resource
  • A malicious user can create a privileged container with a malicious container image capable of container escape. This would allow him/she gaining ROOT privilege of the worker node the created container deployed. Since the malicious user can control the pod scheduling parameters (e.g., replicas number, node affinity, …), he/she should be able to deploy the malicious container to every (or almost every) worker node. This means the malicious user will be able to control every (or almost every) worker node in the cluster.
• get/list verb of secrets resource
  • A malicious user can get/list all the secrets in the cluster (since this is declared in a ClusterRole), including database passwords, tokens of external cloud servers, etc. Even worse, if the cluster admin's token is stored in the cluster secret, he/she can use it to make a cluster-level privilege escalation. This means the malicious user will be able to hijack the whole cluster.
• update/patch verb of nodes resource
  • This permission allows malicious users to patch all nodes in the cluster, e.g., changing their pod taints. This could help the first attack to allocate malicious containers. Also, this allows the attacker to hijack some pods with high RBAC permissions to attacker-controlled nodes.

The malicious users only need to get the service account token to perform the above attacks. There are several ways have already been reported in the real world to achieve this:

• Supply chain attacks: Like the xz backdoor in the recent. The attacker only needs to read /var/run/secrets/kubernetes.io/serviceaccount/token.
• RCE vulnerability in the APP: Any remote-code-execution vulnerability that can read local files can achieve this.
• Control one worker node: Since hwameistor-local-disk-manager is a DaemonSet, it will be deployed on every worker node in the cluster. Any attacker who controls one worker node can further control the whole cluster with these permissions.

Mitigation Suggestion

• Create a separate service account and remove all the unnecessary permissions
• Specify the resource names in the role rules if it can be determined. For example, list all the secret names the APP needs to read. However, it may need a careful review of the source code to identify all the secrets needed exactly.
• Write Kyverno or OPA/Gatekeeper policy to:
  • Limit the container image, entrypoint and commands of newly created pods. This would effectively avoid the creation of malicious containers.
  • Restrict the securityContext of newly created pods, especially enforcing the securityContext.privileged and securityContext.allowPrivilegeEscalation to false. This would prevent the attacker from escaping the malicious container. In old Kubernetes versions, PodSecurityPolicy can also be used to achive this (it is deprecated in v1.21).

Few Questions

• Are these permissions really unused for hwameistor-local-disk-manager?
• Would these mitigation suggestions be applicable for the hwameistor?

References

Several CVEs had already been assigned in other projects for similar issues:

• 2023-30512
• 2023-30617
• 2023-26484
• 2023-30840

[Yseona]

Hi community:
I noticed that this issue hasn't been answered yet, please feel free to let me know if you need more information. Our team is happy to cooperate and do what we can to resolve this issue.

[SSmallMonster]

@Yseona Thanks for your feedback. We will limit the RBAC permission to solve this issue.