T03 · Remote Payload Retrieval and Execution
Error
- Location
- SKILL.md:81
- Finding
- Execution of Untrusted Container Images Discovered Through Web Search## Vulnerability Details **File Location**: `SKILL.md:81-105`; additional guidance in `references/image-sources.md:211-231` and `references/image-sources.md:295-320` **Vulnerability Type**: Remote payload retrieval and supply-chain compromise **Risk Level**: Critical ### Vulnerable Code ```markdown #### Step 4.3: Web Search (fallback) Only if Steps 4.1 and 4.2 fail. Search for `"<vendor> pytorch docker official"`. #### Step 4.4: Local Images (fallback) Only if Steps 4.1-4.3 fail. Check `docker images | grep pytorch`. #### Test Before Use ```bash docker pull "${IMAGE}" && docker run --rm "${IMAGE}" python -c "import torch; print(torch.__version__)" ``` If test fails, try next source. If all fail, ask user for image. #### Step 4.5: Update Skill (self-improvement) **IMPORTANT**: If image found via Web Search (Step 4.3) passes all tests, update `references/image-sources.md` to add the newly discovered vendor hub as a primary source. ``` The corresponding image-discovery instructions state: ```markdown ### Extract and Verify From search results: 1. Find registry URL pattern 2. Test API endpoint 3. Query available tags 4. Select and pull image ``` ### Technical Analysis The Skill permits a container image found through unrestricted web search to be pulled and executed without enforcing: - A registry or repository allowlist - Publisher identity verification - Cryptographic image-signature verification - An immutable image digest - A trusted transparency record or software bill of materials - A controlled entrypoint - Network isolation during initial validation Running a command such as `python -c "import torch; ..."` does not prevent execution of an image-defined `ENTRYPOINT`. A malicious image can configure an entrypoint that executes attacker-controlled code before forwarding to, or impersonating, the requested Python process. Passing a basic PyTorch import or GPU test demonstrat ...[truncated 2319 chars]
- Remediation
- ## Remediation Suggestions 1. Remove automatic execution of images discovered through general web search. 2. Restrict image selection to a centrally maintained allowlist of exact registries, namespaces, and repositories. 3. Require explicit, informed user approval before pulling any image outside the allowlist. 4. Resolve approved tags to immutable OCI digests and launch images as `repository@sha256:digest`. 5. Verify image signatures using a defined trust policy, such as Sigstore Cosign with pinned issuer and identity constraints or Notary v2. 6. Validate publisher ownership independently of search-result content. 7. Perform initial inspection without GPU devices, host data mounts, credentials, or other host directories. 8. Override the image entrypoint during inspection and verify the image configuration before execution. 9. Disable networking during validation where possible, for example with `--network=none`. 10. Apply container hardening controls such as a non-root user, `--read-only`, `--cap-drop=ALL`, `--security-opt=no-new-privileges`, resource limits, and a restrictive seccomp profile. 11. Scan the exact digest for known vulnerabilities and malware, and retain an audit record of the verified digest and signature. 12. Never treat a successful framework import or GPU test as proof that an image is trustworthy.