Skip to content

GHSA-c45c-39f6-6gw9

Rancher generated tokens not revoked after modifications made to authentication provider

High Go
Severity
8.8 / 10
High · CVSS 3.1
Exploit chance (EPSS)
—
No score published
Known exploited
No
Not in CISA's catalog
Weakness
CWE-287 Improper Authentication
Fix
2.5.17
Upgrade github.com/rancher/rancher to this version or later

Description

Impact

This issue affects Rancher versions from 2.5.0 up to and including 2.5.16, from 2.6.0 up to and including 2.6.9 and 2.7.0. It only affects Rancher setups that have an external authentication provider configured or had one configured in the past.

It was discovered that when an external authentication provider is configured in Rancher and then disabled, the Rancher generated tokens associated with users who had access granted through the now disabled auth provider are not revoked. This allows users to retain access to Rancher and kubectl access to clusters managed by Rancher, according to their previous configured permissions, even after they are supposed to have lost it due to the auth provider been disabled.

The problem also occurs if the auth provider is configured (and is still enabled) to use the access level scopes allow members of clusters and projects, plus authorized users & groups and restrict access to only the authorized users & groups. In this case, removing users and groups from the authorized lists will not revoke the access tokens and they will remain valid.

An example scenario is:

  1. OpenLDAP, MS Active Directory (AD) or any other external authentication provider is configured as an auth provider.
  2. A user (cluster-owner) is granted cluster-owner permissions on a downstream cluster (test-cluster).
  3. cluster-owner logs in using their external auth provider username and password.
  4. cluster-owner generates a kubeconfig token for test-cluster.
  5. The configured external auth provider is disabled.

In this scenario, the kubeconfig generated in step 4 will still be valid after step 5, and test-cluster can still be accessed using the kubeconfig token.

By default, tokens for authenticated session have their ttl (time to live) set to 960 minutes, so they will expire after 16 hours. kubeconfig tokens are configured to never expire, and their ttl is set to 0. These configurations can be changed in the Rancher's settings (Configuration > Global Settings > Settings) with the parameters auth-user-session-ttl-minutes and kubeconfig-default-token-ttl-minutes, respectively.

Workarounds

If you cannot update to a patched Rancher version, the recommended workaround is to review and remove tokens associated with auth providers manually.

The tokens can be reviewed by executing kubectl get tokens in Rancher's local cluster. Each found token must be manually reviewed to check if it belongs to a user from a disabled auth provider or a user who's access was previously removed from the auth provider (when the auth provider is still enabled and is or was configured to use access level scopes, as mentioned above). The identified tokens can be removed with kubectl delete tokens <token_name>.

It is important to mention that this workaround must be done every time an auth provider is disabled in case you cannot update to a patched version.

Patches

Patched versions include releases 2.5.17, 2.6.10, 2.7.1 and later versions. After updating to a patched version, it is highly recommended to review the existing tokens and remove tokens related to disabled auth providers as described above in the workaround section.

For more information

If you have any questions or comments about this advisory:

Affected versions

Go

PackageVulnerableFixed in
github.com/rancher/rancher
>= 2.5.0, < 2.5.17
2.5.17
github.com/rancher/rancher
>= 2.6.0, < 2.6.10
2.6.10
github.com/rancher/rancher
>= 2.7.0, < 2.7.1
2.7.1

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/rancher/rancher Go → 2.5.17

go
go get github.com/rancher/rancher@v2.5.17 && go mod tidy

Severity breakdown

CVSS 3.1 8.8

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Weakness

CWE-287: Improper Authentication

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

How to prevent it
  • Architecture and Design: Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

References

Timeline

  1. Published
AdvisorySeverityWhy it's related
GHSA-4j6x-2764-m8gh
Rancher has over-inclusive team membership expansion in GitHub App authentication provider
High Also affects github.com/rancher/rancher
GHSA-vx8h-4prv-g744
Rancher has Privilege Escalation from Project Owner to Host
High Also affects github.com/rancher/rancher
GHSA-mhc6-2gfq-xx62
Rancher vulnerable to command injection through unsanitized YAML parameter
Critical Also affects github.com/rancher/rancher
GHSA-5v3h-x4wf-5c35
Rancher Extensions have arbitrary file access via path traversal
High Also affects github.com/rancher/rancher
GHSA-gqf8-rvrh-g7w6
Rancher cloud credentials can be used through proxy API by users without access
Critical Also affects github.com/rancher/rancher
GHSA-hwm2-4ph6-w6m5
Rancher's restricted PodSecurityPolicy does not prevent containers from running as a privileged user
High Also affects github.com/rancher/rancher
GHSA-mc24-7m59-4q5p
Rancher CLI skips TLS verification on Rancher CLI login command
Medium Also affects github.com/rancher/rancher
GHSA-mw39-9qc2-f7mg
Rancher exposes sensitive information through audit logs
Medium Also affects github.com/rancher/rancher
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor