Update module github.com/argoproj/argo-cd/v2 to v2.10.5 [SECURITY]

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
github.com/argoproj/argo-cd/v2	v2.10.1 -> v2.10.5

GitHub Vulnerability Alerts

CVE-2023-50726

Impact

"Local sync" is an Argo CD feature that allows developers to temporarily override an Application's manifests with locally-defined manifests. Use of the feature should generally be limited to highly-trusted users, since it allows the user to bypass any merge protections in git.

An improper validation bug allows users who have create privileges but not override privileges to sync local manifests on app creation. All other restrictions, including AppProject restrictions are still enforced. The only restriction which is not enforced is that the manifests come from some approved git/Helm/OCI source.

The bug was introduced in 1.2.0-rc1 when the local manifest sync feature was added.

Patches

The bug has been patched in the following versions:

• 2.10.3
• 2.9.8
• 2.8.12

Workarounds

To immediately mitigate the risk of branch protection bypass, remove applications, create RBAC access. The only way to eliminate the issue without removing RBAC access is to upgrade to a patched version.

Branch protection rules and review requirements are a great way to enforce security constraints in a GitOps environment, but they should be just one layer in a multi-layered approach. Make sure your AppProject and RBAC restrictions are as thorough as possible to prevent a review bypass vulnerability from permitting excessive damage.

References

• Argo CD RBAC documentation

For more information

• Open an issue in the Argo CD issue tracker or discussions
• Join us on Slack in channel #argo-cd

CVE-2024-28175

Summary

Due to the improper URL protocols filtering of links specified in the link.argocd.argoproj.io annotations in the application summary component, an attacker can achieve cross-site scripting with elevated permissions.

Impact

All unpatched versions of Argo CD starting with v1.0.0 are vulnerable to a cross-site scripting (XSS) bug allowing a malicious user to inject a javascript: link in the UI. When clicked by a victim user, the script will execute with the victim's permissions (up to and including admin).

This vulnerability allows an attacker to perform arbitrary actions on behalf of the victim via the API, such as creating, modifying, and deleting Kubernetes resources.

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

• v2.10.3
• v2.9.8
• v2.8.12

Workarounds

There are no completely-safe workarounds besides upgrading. The safest alternative, if upgrading is not possible, would be to create a Kubernetes admission controller to reject any resources with an annotation starting with link.argocd.argoproj.io or reject the resource if the value use an improper URL protocol. This validation will need to be applied in all clusters managed by ArgoCD.

Mitigations

1. Avoid clicking external links presented in the UI.
   The link's title is user-configurable. So even if you hover the link, and the tooltip looks safe, the link might be malicious. The only way to be certain that the link is safe is to inspect the page's source.
2. Carefully limit who has permissions to edit Kubernetes resource manifests (this is configured in RBAC for ArgoCD).
   The external-links are set as annotations on Kubernetes resources. Any persona with write access to resources managed by ArgoCD could be an actor.

References

Documentation for the external links feature

Credits

Disclosed by RyotaK (@​Ry0taK)

For more information

• Open an issue in the Argo CD issue tracker or discussions
• Join us on Slack in channel #argo-cd

CVE-2024-21652

Summary

An attacker can exploit a chain of vulnerabilities, including a Denial of Service (DoS) flaw and in-memory data storage weakness, to effectively bypass the application's brute force login protection. This makes the application susceptible to brute force attacks, compromising the security of all user accounts.

Details

The issue arises from two main vulnerabilities:

1. The application crashes due to a previously described DoS vulnerability caused by unsafe array modifications in a multi-threaded environment.
2. The application saves the data of failed login attempts in-memory, without persistent storage. When the application crashes and restarts, this data is lost, resetting the brute force protections.

// LoginAttempts is a timestamped counter for failed login attempts

type LoginAttempts struct {  
// Time of the last failed login LastFailed time.Time `json:"lastFailed"` // Number of consecutive login failures FailCount int `json:"failCount"`

}

By chaining these vulnerabilities, an attacker can circumvent the limitations placed on the number of login attempts.

PoC

1. Run the provided PoC script.
2. Observe that the script makes 6 login attempts, one more than the set limit of 5 failed attempts.
3. This is made possible because the script triggers a server restart via the DoS vulnerability after 5 failed attempts, thus resetting the counter for failed login attempts.

Impact

This is a critical security vulnerability that allows attackers to bypass the brute force login protection mechanism. Not only can they crash the service affecting all users, but they can also make unlimited login attempts, increasing the risk of account compromise.

CVE-2024-21662

Summary

An attacker can effectively bypass the rate limit and brute force protections by exploiting the application's weak cache-based mechanism. This loophole in security can be combined with other vulnerabilities to attack the default admin account. This flaw undermines a previously patched CVE intended to protect against brute-force attacks.

Details

The application's brute force protection relies on a cache mechanism that tracks login attempts for each user. This cache is limited to a defaultMaxCacheSize of 1000 entries. An attacker can overflow this cache by bombarding it with login attempts for different users, thereby pushing out the admin account's failed attempts and effectively resetting the rate limit for that account.

The brute force protection mechanism's code:

   if failed && len(failures) >= getMaximumCacheSize() {
       log.Warnf("Session cache size exceeds %d entries, removing random entry",

getMaximumCacheSize())
       idx := rand.Intn(len(failures) - 1)
       var rmUser string
       i := 0
       for key := range failures {

           if i == idx {
               rmUser = key

               delete(failures, key)

break

}

i++ }

       log.Infof("Deleted entry for user %s from cache", rmUser)
   }

PoC

1. Set up the application environment and identify the login page.
2. Execute 4 failed login attempts for the admin account.
3. Run a Burp Intruder attack to populate the cache with login attempts for usernames ranging from 1 to 10000.
4. After 1000 attempts, start monitoring to see if the admin entries in the cache have been cleared.
5. At this point, brute-force the admin account.

In just 15 minutes, the PoC was able to perform 230 brute force attempts on the admin account. This rate allows for approximately 1000 requests per hour, effectively rendering the older CVE rate limit patches useless.

Impact

This is a severe vulnerability that enables attackers to perform brute force attacks at an accelerated rate, especially targeting the default admin account.

CVE-2024-29893

Impact

All versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, it's possible to crash the repo server component through an out of memory error by pointing it to a malicious Helm registry.
The loadRepoIndex() function in the ArgoCD's helm package, does not limit the size nor time while fetching the data. It fetches it and creates a byte slice from the retrieved data in one go. If the registry is implemented to push data continuously, the repo server will keep allocating memory until it runs out of it.

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

v2.10.5
v2.9.10
v2.8.14

For more information

If you have any questions or comments about this advisory:

Open an issue in the Argo CD issue tracker or discussions
Join us on Slack in channel #argo-cd

Credits

This vulnerability was found & reported by Jakub Ciolek

The Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue

---

Release Notes

argoproj/argo-cd (github.com/argoproj/argo-cd/v2)

v2.10.5

Compare Source

Quick Start

Non-HA:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.10.5/manifests/install.yaml

HA:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.10.5/manifests/ha/install.yaml

Release Signatures and Provenance

All Argo CD container images are signed by cosign. A Provenance is generated for container images and CLI binaries which meet the SLSA Level 3 specifications. See the documentation on how to verify.

Upgrading

If upgrading from a different minor version, be sure to read the upgrading documentation.

Changelog

Full Changelog: argoproj/argo-cd@v2.10.4...v2.10.5

v2.10.4

Compare Source

Quick Start

Non-HA:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.10.4/manifests/install.yaml

HA:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.10.4/manifests/ha/install.yaml

Release Signatures and Provenance

All Argo CD container images are signed by cosign. A Provenance is generated for container images and CLI binaries which meet the SLSA Level 3 specifications. See the documentation on how to verify.

Upgrading

If upgrading from a different minor version, be sure to read the upgrading documentation.

Changelog

Full Changelog: argoproj/argo-cd@v2.10.3...v2.10.4

v2.10.3

Compare Source

Quick Start

Non-HA:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.10.3/manifests/install.yaml

HA:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.10.3/manifests/ha/install.yaml

Release Signatures and Provenance

All Argo CD container images are signed by cosign. A Provenance is generated for container images and CLI binaries which meet the SLSA Level 3 specifications. See the documentation on how to verify.

Upgrading

If upgrading from a different minor version, be sure to read the upgrading documentation.

Changelog

Full Changelog: argoproj/argo-cd@v2.10.2...v2.10.3

v2.10.2

Compare Source

Quick Start

Non-HA:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.10.2/manifests/install.yaml

HA:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.10.2/manifests/ha/install.yaml

Release Signatures and Provenance

All Argo CD container images are signed by cosign. A Provenance is generated for container images and CLI binaries which meet the SLSA Level 3 specifications. See the documentation on how to verify.

Upgrading

If upgrading from a different minor version, be sure to read the upgrading documentation.

Changelog

Full Changelog: argoproj/argo-cd@v2.10.1...v2.10.2

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.