GitHub Advisoryadvisory · Go
GHSA-h36c-m3rf-34h9 Access to Archived Argo Workflows with Fake Token in `client` mode
MEDIUM
Official page ↗
- Aliases
- CVE-2024-53862
- Ecosystem
- Go
- Packages
- github.com/argoproj/argo-workflows/v3
- Severity
- Moderate
- CVSS vector
- CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
- Weaknesses
- CWE-200
- Reviewed
- 2024-12-02
Affected packages
• Go github.com/argoproj/argo-workflows/v3: >= 3.5.7, < 3.5.13 → fixed in 3.5.13
• Go github.com/argoproj/argo-workflows/v3: >= 3.6.0, < 3.6.2 → fixed in 3.6.2
Description
Summary
When using `--auth-mode=client`, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: `/api/v1/workflows/{namespace}/{name}`
When using `--auth-mode=sso`, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: `/api/v1/workflows/{namespace}/{name}`
Details
No authentication is performed by the Server itself on `client` tokens[^1]. Authentication & authorization is instead delegated to the k8s API server.
However, the Workflow Archive does not interact with k8s, and so any token that _looks_ valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a `kubectl auth can-i` check for respective methods.
In #12736 / v3.5.7 and #13021 / v3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token.
PoC
Configuration
Controller `ConfigMap`:
```yaml
config: |
persistence:
archive: true
postgresql:
database: argoworkflows
host: db-host
passwordSecret:
key: postgresPassword
name: argo-wf-postgres-credentials
port: 5432
tableName: argo_workflows
userNameSecret:
key: username
name: argo-wf-postgres-credentials
```
Server: `--auth-mode=client`
Reproduction
Visit a completed, archived workflow URL with an invalid authorization token, this results in the workflow being displayed.
For example, directly query the API and retrieve the workflow data (where `Bearer thisisatest` is not a valid token):
```sh
curl -H 'Authorization: Bearer thisisatest' -v http://localhost:8000/api/v1/workflows/argo/hello-world-7tv5g
```
Results in a returned workflow:
```
• Host localhost:8000 was resolved.
• IPv6: ::1
• IPv4: 127.0.0.1
• Trying [::1]:8000...
• Connected to localhost (::1) port 8000
> GET /api/v1/workflows/argo/hello-world-7tv5g HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/8.7.1
> Accept: */*
> Authorization: Bearer thisisatest
>
• Request completely sent off
Impact
Users of the Server with `--auth-mode=clie…
Related
Alias · CVE (1)
- CVE-2024-53862 Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. vulnerability
Weakness · CWE (1)
- CWE-200 Exposure of Sensitive Information to an Unauthorized Actor weakness
References
- https://github.com/argoproj/argo-workflows/security/advisories/GHSA-h36c-m3rf-34h9 web
- https://nvd.nist.gov/vuln/detail/CVE-2024-53862 advisory
- https://github.com/argoproj/argo-workflows/pull/13021/files#diff-a5b255abaceddc9cc20bf6da6ae92c3a5d3605d94366af503ed754c079a1171aL668-R715 web
- https://github.com/argoproj/argo-workflows package