T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:21- Finding
Unpinned Remote Build Inputs and Broadly Trusted Repository Key
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 21–31, 50–52, and 134–136
Vulnerability Type: Unpinned remote code and insecure dependency trust configuration
Risk Level: MediumVulnerable Code
bash # 1. Clone ROSE git clone git@github.com:rose-compiler/rose.git cd rose && git checkout weekly # 2. Create Docker environment mkdir ../rose-docker && cd ../rose-docker # 3. Build and run container (see Dockerfile below) docker build -t rose-dev . docker run -d --name rose-dev -v $(pwd)/../rose:/rose/src rose-dev # 4. Build ROSE inside container docker exec rose-dev bash -c 'cd /rose/src && ./build'The CMake workflow also checks out the moving branch:
bash # 1. Clone ROSE git clone git@github.com:rose-compiler/rose.git cd rose && git checkout weeklyThe documented Dockerfile installs a remotely retrieved signing key without fingerprint verification:
dockerfile RUN wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2>/dev/null | apt-key add - \ && echo 'deb https://apt.kitware.com/ubuntu/ focal main' > /etc/apt/sources.list.d/kitware.list \ && apt-get update && apt-get install -y cmake \ && rm -rf /var/lib/apt/lists/*Technical Analysis
The instructions check out the mutable
weeklybranch rather than a reviewed commit hash or verified signed tag. They subsequently run./buildand other build-system commands from that checkout. Consequently, the effective code executed by users can change after the Skill itself has been reviewed.The Autotools workflow mounts the host ROSE source directory at
/rose/srcwithout the read-only option. Although the build runs as the unprivilegeddevelopercontainer user, writable bind-mount permissions can allow compromised build logic to alter files in the host source tree under the permissions represented insi ...[truncated 2393 chars]- Remediation
View remediation
Remediation Suggestions
-
Pin the ROSE checkout to a reviewed, immutable commit hash instead of the moving
weeklybranch:bash git clone git@github.com:rose-compiler/rose.git cd rose git checkout --detach <reviewed-commit-sha> test "$(git rev-parse HEAD)" = "<reviewed-commit-sha>" -
Prefer a signed release tag and explicitly verify its signature against an independently validated maintainer key. A branch name alone must not be treated as an integrity guarantee.
-
Replace
apt-keywith a repository-specific keyring and restrict the key usingsigned-by=. Verify the downloaded key's full fingerprint before enabling the repository:dockerfile RUN wget -O /tmp/kitware.asc https://apt.kitware.com/keys/kitware-archive-latest.asc \ && gpg --show-keys --with-colons /tmp/kitware.asc \ && test "<verified-full-fingerprint>" = "$(gpg --show-keys --with-colons /tmp/kitware.asc | awk -F: '/^fpr:/ {print $10; exit}')" \ && gpg --dearmor -o /usr/share/keyrings/kitware-archive-keyring.gpg /tmp/kitware.asc \ && echo 'deb [signed-by=/usr/share/keyrings/kitware-archive-keyring.gpg] https://apt.kitware.com/ubuntu/ focal main' > /etc/apt/sources.list.d/kitware.list -
Pin the Docker base image by digest and pin critical dependency versions where reproducibility requirements permit. Preserve and review a dependency lock or image provenance record.
-
Use a read-only source mount where the workflow does not require source-tree changes:
bash docker run -d --name rose-dev -v "$(pwd)/../rose:/rose/src:ro" rose-devIf generated source files are required, mount a separate writable output directory rather than granting write access to the complete source checkout.
-
Verify downloaded archives and binary dependencies with maintainer-provided cryptographic hashes or signatures before extractio ...[truncated 209 chars]
-