T03 · Remote Payload Retrieval and Execution
Error
- Location
- SKILL.md:26
- Finding
- Mutable Remote Installer Is Downloaded and Executed Directly## Vulnerability Details **File Location**: `SKILL.md`, lines 26-32 **Vulnerability Type**: Remote payload retrieval and immediate shell execution **Risk Level**: High ### Vulnerable Code ```bash curl -fsSL "https://raw.githubusercontent.com/linsheng9731/clawsync/main/scripts/install.sh" | CLAWSYNC_GH_REPO="linsheng9731/clawsync" bash ``` Install a specific version: ```bash curl -fsSL "https://raw.githubusercontent.com/linsheng9731/clawsync/main/scripts/install.sh" | CLAWSYNC_GH_REPO="linsheng9731/clawsync" bash -s -- v0.1.8 ``` ### Technical Analysis Both documented installation methods retrieve `scripts/install.sh` from the mutable `main` branch of a personal GitHub repository and pipe the response directly into Bash. The downloaded script is not present in the audited project, so its behavior, integrity validation, release provenance, and actual installation scope cannot be reviewed. The command labeled as installing a specific version does not pin the installer itself. Although `v0.1.8` is passed as an argument, the script interpreting that argument is still downloaded from `main` and can change after this skill has been reviewed. Direct `curl | bash` execution eliminates the opportunity to validate a checksum, verify a cryptographic signature, inspect the downloaded content, or confirm that the response is the expected installer before execution. This creates a time-of-review versus time-of-use supply-chain risk. The declared functionality does not require executing mutable upstream code. A version-pinned and integrity-verified installer or packaged executable would provide the same installation functionality with substantially less risk. ### Attack Path 1. An attacker compromises the upstream GitHub account, repository, maintainer credentials, or publishing workflow, or a malicious maintainer modifies `scripts/install.sh`. 2. The attacker adds arbitrary shell commands to the installer on the `main` branch. ...[truncated 1390 chars]
- Remediation
- ## Remediation Suggestions 1. Do not pipe network responses directly into a shell. Download the installer to a local file before execution. 2. Pin the installer itself to an immutable release tag or full Git commit hash rather than the mutable `main` branch. 3. Publish a SHA-256 or stronger digest through an independently protected release process and verify it before execution. 4. Prefer cryptographic release signatures, such as Sigstore or GPG signatures, and document signature verification. 5. Package the reviewed installer or executable with the skill where feasible so that the installed code is part of the audited artifact. 6. Ensure that selecting a version pins every executed component, including the installer, rather than only passing a version argument to mutable code. 7. Use a fail-closed installation sequence, for example: ```bash curl -fL -o /tmp/clawsync-install.sh \ "https://raw.githubusercontent.com/linsheng9731/clawsync/<immutable-commit>/scripts/install.sh" printf '%s %s\n' '<trusted-sha256>' '/tmp/clawsync-install.sh' | sha256sum -c - bash /tmp/clawsync-install.sh v0.1.8 rm -f /tmp/clawsync-install.sh ``` 8. Document all files, scheduled tasks, network listeners, and configuration changes created by installation. 9. Make scheduling optional and request `crontab` access only when the user explicitly enables periodic backups. Display and confirm the exact cron entry before installing it. 10. Run installation with ordinary user privileges and explicitly warn users not to invoke the installer with `sudo`.