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.namespaces in the argocd-cmd-params-cm ConfigMap or otherwise setting the --application-namespaces flags on the Application controller and API server components. The apps-in-any-namespace feature is in beta as of this Security Advisory's publish date.

The bug is also limited to Argo CD instances where sharding is enabled by increasing the replicas count for the Application controller.

Finally, the AppProjects' sourceNamespaces field acts as a secondary check against this exploit. To cause reconciliation of an Application in an out-of-bounds namespace, an AppProject must be available which permits Applications in the out-of-bounds namespace.

Patches

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

v2.5.8 v2.6.0-rc5

Workarounds

Running only one replica of the Application controller will prevent exploitation of this bug.

Making sure all AppProjects' sourceNamespaces are restricted within the confines of the configured Application namespaces will also prevent exploitation of this bug.

Credits

Thanks to ChangZhuo Chen (@czchen) for finding the issue and for contributing the fix!

References

Documentation for apps-in-any-namespace

For more information

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

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Versions of Argo CD starting with v1.8.2 and prior to 2.3.13, 2.4.19, 2.5.6, and 2.6.0-rc-3 are vulnerable to an improper authorization bug causing the API to accept certain invalid tokens. OIDC providers include an aud (audience) claim in signed tokens. The value of that claim specifies the intended audience(s) of the token (i.e. the service or services which are meant to accept the token). Argo CD does validate that the token was signed by Argo CD's configured OIDC provider. But Argo CD does not validate the audience claim, so it will accept tokens that are not intended for Argo CD. If Argo CD's configured OIDC provider also serves other audiences (for example, a file storage service), then Argo CD will accept a token intended for one of those other audiences. Argo CD will grant the user privileges based on the token's groups claim, even though those groups were not intended to be used by Argo CD. This bug also increases the impact of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD. A patch for this vulnerability has been released in versions 2.6.0-rc3, 2.5.6, 2.4.19, and 2.3.13. There are no workarounds.

Impact All versions of Argo CD starting with v2.6.0-rc1 have an output sanitization bug which leaks repository access credentials in error messages. These error messages are visible to the user, and they are logged. The error message is visible when a user attempts to create or update an Application via the Argo CD API (and therefor the UI or CLI). The user must have applications, create or applications, update RBAC access to reach the code which may produce the error.

The user is not guaranteed to be able to trigger the error message. They may attempt to spam the API with requests to trigger a rate limit error from the upstream repository.

If the user has repositories, update access, they may edit an existing repository to introduce a URL typo or otherwise force an error message. But if they have that level of access, they are probably intended to have access to the credentials anyway.

Patches

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

v2.6.1

Workarounds

The only way to completely resolve the issue is to upgrade.

Mitigations

To mitigate the issue, make sure that your repo credentials have only least necessary privileges. For example, the credentials should not have push access, and they should not have access to more resources than what Argo CD actually needs (for example, a whole GitHub org when only one repo is needed).

To further mitigate the impact of a leaked write-capable repo credential, you could enable commit signature verification. Even if someone could push a malicious commit, the commit would not by synced.

You should also enforce least privileges in Argo CD RBAC. Make sure users only have repositories, update, applications, update, or applications, create access if they absolutely need it.

References

The problem was initially reported in a GitHub issue Argo CD RBAC configuration documentation

For more information

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