T03 · Remote Payload Retrieval and Execution
Error
- Location
- docs/FAQ.md:289
- Finding
- Unverified Remote Installation Script Executed Directly by the Shell<![CDATA[ ## Vulnerability Details **File Location**: `docs/FAQ.md:281-293`; mirrored in `docs/FAQ_en.md:284-296` **Vulnerability Type**: Remote payload retrieval and immediate execution **Risk Level**: High ### Vulnerable Code `docs/FAQ.md:281-293`: ```bash ### Q17: 检测不到 Ollama **解决:** ```bash # 检查 Ollama 服务 ollama list # 如未安装 curl -fsSL https://ollama.com/install.sh | sh # 重启服务 systemctl restart ollama ``` ``` The equivalent English instruction appears in `docs/FAQ_en.md:284-296`: ```bash ### Q17: Can't detect Ollama **Solution:** ```bash # Check Ollama service ollama list # If not installed curl -fsSL https://ollama.com/install.sh | sh # Restart service systemctl restart ollama ``` ``` ### Technical Analysis The documentation retrieves a mutable shell script from an external server and streams it directly into `sh`. The downloaded content is neither pinned to a specific release nor verified using a cryptographic checksum or signature. The user is also given no opportunity to inspect the script before it executes. Although `ollama.com` appears to be the official Ollama domain and Ollama is relevant to the declared local-model functionality, transport security alone does not establish the integrity of a mutable installation script over time. Compromise of the remote distribution infrastructure, domain, DNS resolution, TLS trust chain, or installation script could change the effective payload after this Skill has been reviewed. The adjacent `systemctl restart ollama` command is a documented service-management operation, not evidence that this project itself creates persistence. Nevertheless, users may execute these commands with elevated privileges if required by their environment, increasing the possible impact of a compromised installer. ### Attack Path 1. A user follows the Ollama troubleshooting instructions. 2. An attacker compromises the remote installation endpoint or another component in its delivery chain. 3. The attacker replaces or mo ...[truncated 1323 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the `curl ... | sh` pipeline from both language versions of the FAQ. 2. Direct users to a versioned official package or release artifact. 3. Require users to download the artifact separately before execution. 4. Pin the documented download to a specific trusted release rather than a mutable installer URL. 5. Verify a publisher-provided digital signature or SHA-256 checksum before installation. 6. Encourage users to inspect installation scripts before executing them. 7. Avoid recommending root execution unless it is explicitly necessary, and document which operations require elevation. 8. Keep the Chinese and English documentation synchronized so the unsafe command is not reintroduced in one version. A safer general workflow is: ```bash curl -fLO https://trusted.example/releases/<pinned-version>/installer.sh printf '%s installer.sh\n' '<publisher-provided-sha256>' | sha256sum --check - less installer.sh sh installer.sh ``` The actual URL, version, checksum, and verification mechanism must come from an authenticated official release channel. ]]>
