T03 · Remote Payload Retrieval and Execution
- Location
references/error-codes.md:133- Finding
Mutable Remote Installer Is Piped Directly Into a Shell
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a plausible AMD SEV-SNP attestation helper, but it overstates what it verifies and includes privileged setup and mutable installer guidance that users should review before trusting it with secrets.
Install only if you understand SEV-SNP administration and can review the scripts. Do not treat a PASS result as sufficient proof to release secrets unless you add or independently perform nonce, measurement, debug-bit, and TCB policy checks. Avoid running the whole workflow as root where possible, review any sudo commands before use, do not enable persistent module or device-permission changes without a rollback plan, and prefer pinned, verified dependency installation over cargo install without a version or curl | sh.
references/error-codes.md:133Mutable Remote Installer Is Piped Directly Into a Shell
scripts/full-attestation.sh:171Attestation Success Does Not Enforce Nonce, Measurement, Debug, or TCB Policy
SKILL.md:112Security-Critical Dependency Is Installed Without Version or Integrity Pinning
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
echo "sev-guest" | sudo tee /etc/modules-load.d/sev-guest.conf
Piping curl output directly into sh is a classic dangerous command chain because it combines remote content retrieval with immediate shell execution. If the remote endpoint, transport, or dependency chain is compromised, the user may execute arbitrary code with their local privileges.
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rm -rf ./output/certs is a destructive filesystem operation that can delete data irreversibly if run from the wrong directory or if paths are modified. In docs intended for copy-paste use, this carries real risk despite being aimed at a troubleshooting directory.
rm -rf ./output/certs
./scripts/fetch-certificates.sh ./output/report.bin ./output
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
if [[ -f "$OUTPUT_DIR/certs/cert_2.pem" ]]; then
mv "$OUTPUT_DIR/certs/cert_2.pem" "$OUTPUT_DIR/certs/ark.pem"
fi
rm -f "$OUTPUT_DIR/certs/cert_0.pem" "$OUTPUT_DIR/certs/cert_"*.pem 2>/dev/null || true
echo -e "${GREEN}Fetched ARK and ASK certificates${NC}"
fi
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
fi
# Cleanup
rm -f "$CERTS_DIR/ca_bundle.pem"
echo ""
echo "=== Chain Verification Summary ==="
The README explicitly lists 'root 权限' as a dependency but does not warn users about the risks of running attestation scripts with elevated privileges or advise them to inspect the scripts first. In a security-sensitive skill that fetches certificates, invokes external tools, and performs system attestation, omission of privilege-safety guidance increases the chance of unnecessary root execution and magnifies the impact of any script defect or future compromise.
The skill instructs users to run local shell scripts and access privileged resources like /dev/sev-guest, but it does not declare any explicit tool scope or permissions boundary. In an agent environment, this mismatch can cause the agent to invoke shell and file-read capabilities without clear authorization, increasing the risk of unintended command execution or access to sensitive host resources.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Load the kernel module:
sudo modprobe sev-guest
Verify kernel config:
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Load the kernel module:
sudo modprobe sev-guest
Verify kernel config:
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Load the kernel module:
sudo modprobe sev-guest
Verify kernel config:
The documentation instructs users to make a kernel module load persistently via a privileged write to /etc/modules-load.d without any caution about the security or operational impact. While not inherently malicious, persistent system configuration changes can have unintended consequences and should be clearly framed as admin-only actions with rollback guidance.
This command pipes data into sudo tee to create a persistent module-load configuration file under /etc, which changes system behavior across reboots. The danger is not command injection from untrusted input here, but an undocumented persistent privileged modification that users may apply without understanding impact or rollback.
echo "sev-guest" | sudo tee /etc/modules-load.d/sev-guest.conf
The phrase 'Run as root' is a broad escalation recommendation that lacks least-privilege rationale. In security-sensitive tooling, blanket root guidance can lead to unnecessary privileged execution of local scripts.
Solutions:
sudo ./scripts/generate-report.sh ./output
Telling users to run the report-generation script as root increases the blast radius if the script or its dependencies behave unexpectedly. In documentation, recommending blanket root execution without discussing alternatives or trust boundaries is a risky practice.
Run as root:
sudo ./scripts/generate-report.sh ./output
Add user to sev group:
This section recommends running as root, changing group membership, and modifying device ownership/permissions on /dev/sev-guest, but does not warn that these actions expand access to a sensitive device node. Users may weaken least-privilege controls or apply unsafe permission changes without understanding the security implications.
Adding a user to the sev group changes long-term access control and may grant ongoing access to a sensitive device interface. Without warning or scope guidance, users may over-grant privileges beyond what is necessary for one-time troubleshooting.
sudo usermod -a -G sev $USER
# Log out and back in
Changing permissions on /dev/sev-guest with chmod 660 is not maximally permissive, but it still alters access control on a device node and may diverge from intended platform policy. Presented without caution, this can normalize ad hoc security-sensitive permission changes.
ls -la /dev/sev-guest
# Fix if needed:
sudo chmod 660 /dev/sev-guest
sudo chown root:sev /dev/sev-guest
Changing permissions on /dev/sev-guest with chmod 660 is not maximally permissive, but it still alters access control on a device node and may diverge from intended platform policy. Presented without caution, this can normalize ad hoc security-sensitive permission changes.
ls -la /dev/sev-guest
# Fix if needed:
sudo chmod 660 /dev/sev-guest
sudo chown root:sev /dev/sev-guest
Changing device ownership to root:sev grants the sev group access to the device node and may broaden access in a persistent or semi-persistent way depending on the system's device management. Without explanation, users may apply it without understanding who now gains hardware interface access.
ls -la /dev/sev-guest
sudo chmod 660 /dev/sev-guest sudo chown root:sev /dev/sev-guest
### snpguest not found
The documentation includes a recursive deletion command against a path under ./output without an explicit warning or validation step. Even if scoped, rm -rf is hazardous in copy-paste workflows and can become destructive if variables, paths, or working directories differ from expectations.
All user-facing documentation in this file is written in Chinese, with no indication that the skill is region-specific or that other language options are available. The policy requires avoiding language or locale constraints unless the user opts in or the restriction is clearly justified.
Skill requests more permissions than appear necessary for its stated functionality. Review if elevated access is justified.
3. **Check device permissions:**
```bash
ls -la /dev/sev-guest
# Fix if needed:
The documentation instructs users to execute a remotely fetched script directly with curl | sh, which bypasses meaningful review and makes supply-chain compromise or network interception highly impactful. Even over HTTPS, this pattern is dangerous because it delegates code execution to external content at runtime.
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
The script writes nonce.hex, request_data.bin, and report.bin into the provided output directory using shell redirection and the snpguest command, but there is no confirmation prompt or explicit warning that prior files in that directory may be replaced. Because these are filesystem-modifying operations in a generic output path, users are not clearly alerted to the overwrite risk.
This code creates a temporary CA bundle at "$CERTS_DIR/ca_bundle.pem" and later deletes it, which is a file write and deletion operation. Although the script prints verification progress, it does not disclose in the usage/help text or nearby comments that it will modify the target directory by creating a temporary file.
No suspicious patterns detected.