Skip to content
Jeff FriedmanJun 12, 2023 12:20:12 PM3 min read

CVE-2023-22647: Rancher Kubernetes Vulnerability

Intro

In 2023 we have seen a number of vulnerabilities in Kubernetes and its broad third-party ecosystem, including new CVEs in Clusternet, the Jenkins plugin (rated Medium), CubeFS, and Crossplane (rated High). A critical vulnerability (CVE-2023-22647) has recently been published for Rancher SUSE, the most widely used tool with any vulnerability this year apart from Kubernetes itself. To address this vulnerability, you will need to update to a new version of Rancher and also audit privileges to ensure the vulnerability has not already been exploited.

What is Rancher?

Rancher is a popular open source Kubernetes platform (21,000 stars on GitHub) that simplifies how teams administer and manage Kubernetes. In comparison to a managed Kubernetes platform, Rancher abstracts more capabilities on top of the underlying compute to help streamline management and workflows. Rancher has a single UI and is compatible with the different cloud providers and open source Kubernetes projects. It also works if you are deploying on bare metal or something other than the managed Kubernetes platforms.

To be clear, the vulnerability was identified in Rancher SUSE, and not in its specific managed Kubernetes service, the Rancher Kubernetes Engine (RKE). 

How does CVE-2023-22647 work?

The benefit of a single UI through Rancher is possible because of its architecture that puts the Rancher server at the top of the hierarchy of operations. The Rancher server needs what it calls its own ‘local’ cluster for deployment (‘local’ is Rancher verbiage that means ‘the cluster where Rancher is installed’). It is in this cluster where the vulnerability is present. 

In CVE-2023-22647, a regular user could access and make changes to secrets in this local cluster, such that they could maintain read level permissions to the secret even if the secret itself was deleted. The descriptions of the vulnerability become more vague at this point of the exploit, but basically there is then another way to follow-up this specific action with other commands that allow improper access to tokens for service accounts in this local cluster. We should recall that this local cluster is where Rancher is installed, so it is the top level of abstraction available; this means access could be quite broad. 

This vulnerability would also be available to any users that are able to grant create and delete permissions on secrets; like a custom global role, for example. 

What can you do?

This vulnerability has been rated Critical with a CVSS score of 9.9, which is not surprising given the broad scope of privilege that could be gained by anybody successfully exploiting it. Rancher released patched versions and advises to upgrade in order to avoid being exposed to the vulnerability. Any version of 2.6.13, 2.7.4 or higher is recommended.

It is worth noting that in the 2.6.13 version, in order to upgrade successfully, you must have a Helm version of 3.2x or more and you must be able to upgrade the Rancher server onto a Kubernetes cluster with versions of 1.18 or higher. Most Kubernetes environments are on 1.18 or higher already, so this is a bit of good news in terms of how quickly many teams will be able to patch their systems.

Apart from patching and prevention of future exploitation, Rancher also recommends a thorough look-back through audit logs (if you had them turned on) to understand if the vulnerability has been exploited. They also recommend a review of all access to Rancher (e.g. RBAC policies, tokens, host-level node access) to identify any attempted persistence of elevated privileges.  

How KSOC can help

KSOC can help with an audit of RBAC permissions to identify any changes over time, significantly shortening the amount of time to identify any impact. With KSOC admission control installed and real-time Kubernetes Security Posture Management, you can also understand immediately if somebody is attempting to take unwanted action in your clusters, as well as prevent them from doing so in the first place. For example, you could block privilege escalation, thereby eliminating the blast radius of this vulnerability.

Conclusion

Though the CVSS score of a vulnerability is not always indicative of its overall risk or impact (according to this experiment we ran with the Exploit Prediction Scoring System or EPSS), the critical vulnerability affecting Rancher is clearly severe and must be addressed. This particular vulnerability also calls to light the importance of having capabilities that allow you to immediately address new vulnerabilities as they come up, for example with RBAC audits and a real-time view into your clusters. To see how real-time KSPM can audit privilege escalation and permissions, sign up today for a demo. 

avatar

Jeff Friedman

Jeff Friedman is a staff software engineer at RAD Security. He has built cloud-native, high-performance distributed systems in product engineering teams at CircleCI and EverQuote, ranging from real time data analysis and data visualization applications to auction engines for insurance marketplaces. Prior to software engineering, Jeff worked in investment banking and management consulting.

RELATED ARTICLES