ghsa

### Impact A denial of services (DoS) vulnerability was discovered in Wrangler Git package affecting versions up to and including `v1.0.0`. Specially crafted Git credentials can result in a denial of service (DoS) attack on an application that uses Wrangler due to the exhaustion of the available memory and CPU resources. This is caused by a lack of input validation of Git credentials before they are used, which may lead to a denial of service in some cases. This issue can be triggered when accessing both private and public Git repositories. ### Workarounds A workaround is to sanitize input passed to the Git package to remove potential unsafe and ambiguous characters. Otherwise, the best course of action is to update to a patched Wrangler version. ### Patches Patched versions include `v1.0.1` and later and the backported tags - `v0.7.4-security1`, `v0.8.5-security1` and `v0.8.11`. ### For more information If you have any questions or comments about this advisory: * Reach out t...

### Impact All Argo CD versions starting with 2.5.0-rc1 are vulnerable to an authorization bypass bug which allows a malicious Argo CD user to deploy Applications outside the configured allowed namespaces. #### Description of exploit Reconciled Application namespaces are specified as a comma-delimited list of glob patterns. When sharding is enabled on the Application controller, it does not enforce that list of patterns when reconciling Applications. For example, if Application namespaces are configured to be `argocd-*`, the Application controller may reconcile an Application installed in a namespace called `other`, even though it does not start with `argocd-`. Reconciliation of the out-of-bounds Application is only triggered when the Application is updated, so the attacker must be able to cause an update operation on the Application resource. #### Limitations This bug only applies to users who have explicitly enabled the "apps-in-any-namespace" feature by setting `application.n...

### 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](https://ranchermanager.docs.rancher.com/pages-for-subheaders/authentication-config) 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](https://ranchermanager.docs.rancher.com/reference-guides/about-the-api/api-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 [a...

### 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 was discovered that the security advisory CVE-2021-36782 (GHSA-g7j7-h4q8-8w2f), previously released by Rancher, missed addressing some sensitive fields, secret tokens, encryption keys, and SSH keys that were still being stored in plaintext directly on Kubernetes objects like `Clusters`. The exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners` and `Project Members` of that cluster on the endpoints: - `/v1/management.cattle.io.cluster` - `/v1/management.cattle.io.clustertemplaterevisions` The remaining sensitive fields are now stripped from `Clusters` and other objects and moved to a `Secret` before the object is stored. The `Secret` is retrieved when the credential is needed. For objects that existed before this security fix, a one-time migration happens on startup. The fields that have ...

### Impact An issue was discovered in Rancher from versions 2.5.0 up to and including 2.5.16, 2.6.0 up to and including 2.6.9 and 2.7.0, where a command injection vulnerability is present in the Rancher Git package. This package uses the underlying Git binary available in the Rancher container image to execute Git operations. Specially crafted commands, when not properly disambiguated, can cause confusion when executed through Git, resulting in command injection in the underlying Rancher host. This issue can potentially be exploited in Rancher in two ways: 1. Adding an untrusted Helm catalog, in the Catalogs menu, that contains maliciously designed repo URL configuration in Helm charts. 2. Modifying the URL configuration used to download KDM (Kontainer Driver Metadata) releases. By default, only the Rancher admin has permission to manage both configurations for the local cluster (the cluster where Rancher is provisioned). Note: More information about this category of issue in ver...

### Impact An issue was discovered in Rancher where an authorization logic flaw allows an authenticated user on any downstream cluster to (1) open a shell pod in the Rancher `local` cluster and (2) have limited `kubectl` access to it. The expected behavior is that a user does not have such access in the Rancher `local` cluster unless explicitly granted. This issue does not allow the user to escalate privileges in the `local` cluster directly (this would require another vulnerability to be exploited). The security issue happens in two different ways: 1. Shell pod access - This is when a user opens a shell pod in the Rancher UI to a downstream cluster that the user has permission to access. The web request can be intercepted using the browser's web inspector/network console or a proxy tool to change the shell's destination to the Rancher `local` cluster instead of the desired downstream cluster. - This flaw cannot be exploited to access a downstream cluster that the user has no p...

### Impact An issue was discovered in Rancher versions from 2.5.0 up to and including 2.5.16 and from 2.6.0 up to and including 2.6.9, where an authorization logic flaw allows privilege escalation via project role template binding (PRTB) and `-promoted` roles. This issue is not present in Rancher 2.7 releases. Note: Consult Rancher [documentation](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles) for more information about cluster and project roles and [KB 000020097](https://www.suse.com/support/kb/doc/?id=000020097) for information about `-promoted` roles. This privilege escalation is possible for users with access to the `escalate` verb on PRTBs (`projectroletemplatebindings.management.cattle.io`), including users with `*` verbs on PRTBs (see notes below for more information). These users can escalate permissions for any `-promoted` resource (see...

### Impact An issue was discovered in Rancher versions up to and including 2.6.9 and 2.7.0, where the `cattle-token` secret, used by the `cattle-cluster-agent`, is predictable. Even after the token is regenerated, it will have the same value. This issue is not present in Rancher 2.5 releases. The `cattle-token` is used by Rancher's `cattle-cluster-agent` to connect to the Kubernetes API of Rancher provisioned downstream clusters. The problem occurs because the `cattle-token` secret does not use any random value in its composition, which causes it to always be regenerated with the same value. This can pose a serious problem if the token is compromised and needs to be recreated for security purposes. The usage of the `cattle-token` by an unauthorized user allows to escalate privileges to the cluster owner of the affected downstream cluster. It does not allow access to Rancher's own local cluster (the cluster where Rancher is provisioned). ### Workarounds In case it is not possible t...

### Advisory title: Field-level security issue with .keyword fields ### Affected versions: OpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1 ### Patched versions: OpenSearch 1.3.8 and 2.5.0 ### Impact: There is an issue in the implementation of field-level security (FLS) and field masking where rules written to explicitly exclude fields are not correctly applied for certain queries that rely on their auto-generated .keyword fields. This issue is only present for authenticated users with read access to the indexes containing the restricted fields. ### Workaround: FLS rules that use explicit exclusions can be written to grant explicit access instead. Policies authored in this way are not subject to this issue. ### Patches: OpenSearch versions 1.3.8 and 2.5.0 contain a fix for this issue. ### For more information: If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/)...

### Advisory title: Issue with whitespace in JWT roles ### Affected versions: OpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1 ### Patched versions: OpenSearch 1.3.8 and 2.5.0 ### Impact: OpenSearch uses JWTs to store role claims obtained from the Identity Provider (IdP) when the authentication backend is SAML or OpenID Connect. There is an issue in how those claims are processed from the JWTs where the leading and trailing whitespace is trimmed, allowing users to potentially claim roles they are not assigned to if any role matches the whitespace-stripped version of the roles they are a member of. This issue is only present for authenticated users, and it requires either the existence of roles that match, not considering leading/trailing whitespace, or the ability for users to create said matching roles. In addition, the Identity Provider must allow leading and trailing spaces in role names. ### Patches: OpenSearch versions 1.3.8 and 2.5.0 contain a fix for this issue. ### For more informa...