T08 · Insecure Dependencies
Warning
- Location
- README.md:48
- Finding
- Unpinned Third-Party Installation Can Execute Mutable Upstream Code with Elevated Privileges## Vulnerability Details **File Location**: `README.md`, lines 48–70 **Vulnerability Type**: Supply-chain risk from unpinned third-party installation sources **Risk Level**: Medium ### Vulnerable Code ```sh brew tap lstpsche/tap brew install openmeteo-sh ``` ```sh # Import the signing key curl -fsSL https://lstpsche.github.io/apt-repo/pubkey.gpg \ | sudo gpg --dearmor -o /usr/share/keyrings/openmeteo-sh.gpg # Add the repository echo "deb [signed-by=/usr/share/keyrings/openmeteo-sh.gpg] https://lstpsche.github.io/apt-repo stable main" \ | sudo tee /etc/apt/sources.list.d/openmeteo-sh.list # Install sudo apt update sudo apt install openmeteo-sh ``` ```sh git clone https://github.com/lstpsche/openmeteo-sh.git cd openmeteo-sh sudo make install ``` ### Technical Analysis The documented installation methods trust mutable external repositories without pinning a reviewed release tag, commit hash, package version, checksum, or signature identity. The source installation is particularly sensitive because it clones the upstream repository's current default branch and then invokes `make install` with `sudo`. A Makefile can execute arbitrary commands, so this grants mutable upstream content root-level execution during installation. The APT procedure downloads a signing key from an externally controlled site and installs it into the system trust configuration without verifying its expected fingerprint through an independent channel. The package repository is hosted under the same upstream-controlled namespace. Consequently, compromise of that namespace could allow an attacker to replace both the repository content and the key presented to new users. The Homebrew procedure similarly adds and installs from a mutable third-party tap without version or artifact-integrity pinning. These practices create a dependency supply-chain exposure beyond the minimum runtime privileges needed to query weather data. ### Attack Path 1. An attacker compromises the upstream Git ...[truncated 1440 chars]
- Remediation
- ## Remediation Suggestions 1. Pin source installations to a reviewed, immutable release tag and full commit hash instead of cloning and executing the current default branch. 2. Publish SHA-256 checksums for release archives and package artifacts, and require users to verify them before installation. 3. Cryptographically sign releases and document a trusted, independently verifiable signing identity. 4. Publish the expected APT signing-key fingerprint and require fingerprint verification before placing the key in the system keyring. 5. Avoid obtaining the APT repository and its initial trust anchor exclusively from the same administrative namespace where practical. 6. Pin package versions in installation examples and document a controlled update process. 7. Replace `sudo make install` on an unverified checkout with installation from a verified release artifact. Where possible, build without privileges and elevate only for the narrowly scoped file-copy step. 8. Document the files, commands, and privileges used by installation so users can review the privileged changes. 9. Consider sandboxing or packaging the CLI so its installation and runtime permissions are limited to those necessary for HTTPS weather queries.
