Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-h27c-6xm3-mcqp
No affected components available
Withdrawn Advisory
This advisory has been withdrawn because the vulnerability does not affect a released Go package. For more information, see github/advisory-database/issues/5029.
Original Advisory
Summary
This advisory affects the Kanister helm charts and not the go package
Details
The kanister has a deployment called default-kanister-operator, which is bound with a ClusterRole called edit via ClusterRoleBinding(https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/templates/rbac.yaml#L49). The "edit" ClusterRole is one of Kubernetes default-created ClusterRole, and it have create/patch/udpate verbs of daemonset resources, create verb of serviceaccount/token resources, and impersonate verb of serviceaccounts resources. If a malicious user can access the worker node which has this component, he/she can:
For the create/patch/update verbs of daemonset resources, the malicious user can abuse it to create or modify a set of Pods to mount a high-privilege service account (e.g., the cluster-admin service account). After that, he/she can abuse the high-privilege SA token of created Pod to take over the whole cluster.
For the create verb of serviceaccount/token resources, a malicious user can abuse this permission to generate new Service Account tokens and use them to operate with high-privilege roles, such as cluster administrators. These tokens can be used to access and manipulate any resources within the cluster.
For the impersonate verb of serviceaccounts resources, a malicious user can impersonate high-privilege Service Accounts, thereby gaining access to roles such as cluster administrators. This enables the attacker to perform all actions that the high-privilege account can, including creating, modifying, and deleting critical resources within the cluster.
PoC
We have discussed in the "Details" section
Impact
Privilege escalation
Mitigation
Currently kanister helm chart provides rbac.create flag (true by default), which controls whether the rbac rules for kanister service account will be created https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/values.yaml#L17 If this value set to false, the user needs to create rbac rules themselves and they can limit the role bindings for kanister service account, for example scope it to specific namespace. Service account can also be configured via helm https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/values.yaml#L19
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the confidentiality of the information. There is a high impact on the integrity of the data. There is a high impact on the availability of the system.
Exploitation activity has been observed. Apply available patches or mitigations urgently.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard