T03 · Remote Payload Retrieval and Execution
- Location
install.sh:6- Finding
Unverified Remote Installer Is Piped Directly Into a Shell
- Content
View full analysis
/dev/null 2>&1 || brew install uv || (curl -LsSf https://astral.sh/uv/install.sh | sh) ``` ### Technical Analysis When `uv` is unavailable and `brew install uv` fails or cannot run, the script retrieves content from `https://astral.sh/uv/install.sh` and immediately executes it with `sh`. Although this domain is associated with the official `uv` project, the downloaded content is not pinned to a specific version and is not validated using a cryptographic checksum or signature. Consequently, the code that executes can change after the Skill has been reviewed. Piping a network response directly into a shell also prevents meaningful inspection before execution. This behavior is not necessary to provision the declared virtual environment. The Skill could instead require a separately installed `uv` binary or use a pinned and verified release artifact. ### Attack Path 1. A user runs `bash install.sh` on a system where `uv` is not installed. 2. `brew install uv` fails, or Homebrew is unavailable or unsuitable. 3. The fallback downloads the current response from `astral.sh`. 4. The remote endpoint, hosting infrastructure, DNS/TLS trust path, or upstream installer is compromised or serves an unexpectedly changed payload. 5. The response is passed directly to `sh` without integrity verification. 6. The payload executes with all permissions available to the user who invoked the installer. ### Impact Assessment A malicious remote payload could execute arbitrary commands with the invoking user's privileges. It could read or modify user-accessible files, steal credentials and environment data, alter shell configuration, install additional programs, or establish user-level persistence. The script does not invoke `sudo`, so no direct root privilege escalation is demonstrated. However, the ...[truncated 119 chars]- Remediation
View remediation
