T03 · Remote Payload Retrieval and Execution
Error
- Location
- SKILL.md:98
- Finding
- Remote CLI Installers Are Downloaded and Executed Without Integrity Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 98–106 **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High The first-time setup instructions execute remotely hosted installation scripts directly in the user's shell: ```markdown - **`oo: command not found`** — install the oo CLI (other platforms: <https://cli.oomol.com/install-guide.md>): ```bash curl -fsSL https://cli.oomol.com/install.sh | bash # macOS / Linux ``` ```powershell irm https://cli.oomol.com/install.ps1 | iex # Windows PowerShell ``` ``` ### Technical Analysis Both installation commands combine retrieval and execution without giving the user or agent an opportunity to inspect the downloaded content: - On macOS and Linux, `curl` sends the response body directly to `bash`. - On Windows, `Invoke-RestMethod` (`irm`) sends the response directly to `Invoke-Expression` (`iex`). - No expected version, cryptographic hash, or digital signature is specified or verified. - The effective code is controlled by the content served from `cli.oomol.com` at execution time and can therefore differ from the content reviewed during this audit. - HTTPS protects data in transit but does not protect against a compromised hosting account, origin server, deployment pipeline, DNS/TLS trust chain, or malicious future modification by an authorized publisher. Installing the CLI may be necessary for the skill's declared Gmail functionality. However, immediate execution of mutable remote code exceeds the minimum safe installation privilege because the same objective can be achieved through a versioned package, a separately downloaded script, or a signed artifact verified before execution. The document limits installation to cases where `oo` is missing, which reduces exposure, but it does not eliminate the remote-code-execution risk when that fallback is used. ### Attack Path 1. An attacker compromises the installer host, publishing pipelin ...[truncated 2295 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove direct `curl | bash` and `irm | iex` installation patterns. 2. Pin installation instructions to a specific, reviewed CLI release rather than a mutable generic installer endpoint. 3. Download the artifact and its checksum or signature as separate steps. 4. Verify a SHA-256 digest against a value published through an independently protected release channel, or verify a digital signature using a pinned publisher key. 5. Execute the installer only after successful verification and, where practical, explicit user review and approval. 6. Prefer an authenticated operating-system package manager or signed platform-native installer with version pinning. 7. Do not request administrator privileges unless a documented installation step strictly requires them. 8. Store temporary downloads in a newly created, permission-restricted directory and remove them after installation. 9. Document the external processing boundary for Gmail payloads, including the categories of data transmitted, retention policy, and relevant privacy controls. 10. A safer Unix-style workflow would follow this pattern, using a real release-specific digest supplied by the publisher: ```bash curl -fL -o oo-install.sh "https://cli.oomol.com/releases/<pinned-version>/install.sh" printf '%s %s\n' '<trusted-sha256>' 'oo-install.sh' | sha256sum --check - less oo-install.sh bash oo-install.sh rm -f oo-install.sh ``` The Windows process should likewise download a pinned artifact, validate an Authenticode signature or independently published cryptographic hash, and only then execute it. ]]>