sev-attestation

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:06 AM UTC
• Version: 1.0.2

Overview

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.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (3)

T03 · Remote Payload Retrieval and Execution

Error

• Location: references/error-codes.md:133
• Finding: Mutable Remote Installer Is Piped Directly Into a Shell<![CDATA[ ## Vulnerability Details **File Location**: `references/error-codes.md:133-136` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High ### Vulnerable Code ```bash 3. **Install Rust if needed:** ```bash curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh ``` ``` ### Technical Analysis The troubleshooting instructions download a mutable script from an external URL and immediately execute the response through `sh`. The downloaded content is not pinned to an audited version, saved for inspection, or verified using an independently obtained checksum or digital signature. The HTTPS and TLS restrictions protect the connection in transit, but they do not protect against compromise of the upstream service, its deployment infrastructure, its signing account, DNS/CA trust, or a future unintended change to the remote installer. Consequently, the effective code executed by this Skill's instructions can change after the Skill package has been reviewed. Installing Rust may be useful for obtaining the `snpguest` dependency, but direct remote-to-shell execution is not the minimum-risk mechanism needed to satisfy that requirement. ### Attack Path 1. An attacker compromises the remote installer, its hosting infrastructure, or another component in the delivery chain. 2. A user follows the Skill's troubleshooting instructions. 3. `curl` retrieves the attacker-controlled response from `https://sh.rustup.rs`. 4. The pipe passes the response directly to `sh` without inspection or integrity verification. 5. The payload executes commands with all permissions held by the invoking user. 6. If the command is invoked from a privileged shell, the remote payload receives corresponding elevated privileges. ### Impact Assessment Successful exploitation provides arbitrary command execution under the invoking user's account. This may permit theft or modification of user files, installation of additional software, credential acc ...[truncated 375 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the `curl | sh` installation instruction. 2. Prefer a trusted operating-system package manager where an appropriate Rust package is available. 3. If a standalone installer is necessary: - Download a versioned installer to a local file. - Obtain its expected checksum or signature through an independently authenticated channel. - Verify the checksum or signature before execution. - Allow the user to inspect the downloaded script. - Execute the verified file as a separate command. 4. Pin and document the expected Rust toolchain and installer version. 5. Explicitly instruct users not to run the installer as root. 6. Document all filesystem and environment changes made by the selected installation process. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/full-attestation.sh:171
• Finding: Attestation Success Does Not Enforce Nonce, Measurement, Debug, or TCB Policy<![CDATA[ ## Vulnerability Details **File Locations**: - `scripts/generate-report.sh:67-77` - `scripts/verify-report.sh:49-64` - `scripts/verify-report.sh:173-184` - `scripts/full-attestation.sh:171-183` **Vulnerability Type**: Incomplete attestation policy enforcement **Risk Level**: Critical ### Vulnerable Code The report generator creates and stores a nonce: ```bash if [[ -z "$REPORT_DATA_HEX" ]]; then echo "Generating random nonce (64 bytes)..." REPORT_DATA_HEX=$(openssl rand -hex 64) else # Validate hex string length (64 bytes = 128 hex chars) if [[ ${#REPORT_DATA_HEX} -ne 128 ]]; then echo -e "${RED}Error: report_data_hex must be exactly 128 hex characters (64 bytes)${NC}" exit 1 fi fi echo "Nonce: ${REPORT_DATA_HEX:0:32}..." echo "$REPORT_DATA_HEX" > "$OUTPUT_DIR/nonce.hex" ``` The preferred verification path treats successful signature verification as sufficient: ```bash if command -v snpguest &>/dev/null; then echo "Verifying report using snpguest..." echo "" if snpguest verify attestation "$CERTS_DIR" "$REPORT_FILE" 2>&1; then echo "" echo -e "${GREEN}Report signature verification PASSED${NC}" # Display report details echo "" echo "=== Attestation Report Details ===" snpguest display report "$REPORT_FILE" 2>/dev/null || true exit 0 else echo "" echo -e "${RED}Report signature verification FAILED${NC}" exit 1 fi fi ``` The OpenSSL fallback likewise exits successfully after signature validation without applying an attestation policy: ```bash if openssl dgst -sha384 -verify "$WORK_DIR/vcek_pub.pem" -signature "$WORK_DIR/signature.der" "$WORK_DIR/signed_data.bin" 2>/dev/null; then echo "" echo -e "${GREEN}Report signature verification PASSED${NC}" # Display basic report info echo "" echo "=== Report Summary ===" echo "Report version: $(xxd -p -s 0 -l 4 "$REPORT_FILE" | fold -w2 | tac | ...[truncated 3786 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Treat the challenge as verifier-controlled input: - Generate the nonce outside the attested guest where possible. - Pass it explicitly to report generation. - Preserve the exact expected 64-byte value for verification. 2. After signature validation, extract all 64 bytes of `REPORT_DATA` and compare them byte-for-byte with the expected challenge using a failure-closed comparison. 3. Never accept a nonce merely because it is stored beside the report; bind the expected challenge to the verification request or verifier session. 4. Require a deployment-specific attestation policy containing: - Allowed `MEASUREMENT` values. - Required report format version. - Required signature algorithm. - Allowed VMPL. - Required policy bits and mandatory rejection of `POLICY.DEBUG`. - Minimum boot loader, TEE, SNP, microcode, and other relevant TCB values. 5. Validate the complete report size and reserved-field requirements before parsing. 6. Return success only if certificate validation, signature validation, freshness validation, identity validation, and security-policy validation all pass. 7. Change the final message so it accurately distinguishes: - Cryptographic authenticity. - Freshness. - Workload identity. - Policy compliance. 8. Add negative tests for replayed nonces, mismatched measurements, debug-enabled reports, unsupported versions, and insufficient TCB levels. ]]>

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:112
• Finding: Security-Critical Dependency Is Installed Without Version or Integrity Pinning< - **openssl**: For certificate operations - **curl**: For fetching certificates from AMD KDS - **Root access**: Required to access `/dev/sev-guest` Install snpguest: ```bash cargo install snpguest ``` ``` The troubleshooting document repeats the unpinned installation command: ```bash 1. **Install snpguest:** ```bash cargo install snpguest ``` ``` ### Technical Analysis The command installs whichever version of `snpguest` the configured Cargo registry currently resolves. It does not pin an audited version, require a locked dependency graph, identify the expected package source, or verify an independently documented artifact checksum. This dependency is security-critical: the scripts trust it to access `/dev/sev-guest`, generate and parse reports, fetch certificates, and determine whether attestation verification succeeds. Cargo installation can also execute package build scripts during compilation. A compromised publisher account, registry, package release, transitive dependency, or local Cargo registry configuration could therefore introduce arbitrary code or alter verification outcomes. The audit did not find evidence that `snpguest` is currently malicious. The finding concerns the unsafe, non-reproducible dependency acquisition process. ### Attack Path 1. An attacker compromises the package publisher, registry, a transitive dependency, or the user's Cargo source configuration. 2. A malicious or altered release becomes the version selected by `cargo install snpguest`. 3. A user follows the Skill's installation instructions. 4. Cargo downloads and builds the attacker-controlled package or dependency. 5. Malicio ...[truncated 1046 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin `snpguest` to an exact version that has been reviewed: ```bash cargo install snpguest --version '&lt;audited-exact-version&gt;' --locked ``` 2. Document the expected registry or source repository and prevent silent substitution through an unexpected Cargo source configuration. 3. Publish and verify a checksum or signed provenance record for the expected source or binary artifact. 4. Review the pinned package's transitive dependency graph and Cargo build scripts. 5. Use reproducible builds or a trusted, signed binary distribution where available. 6. Run installation and routine attestation as an unprivileged user. 7. Grant only the narrowly required `/dev/sev-guest` access, such as through the appropriate device group, rather than recommending general root execution. 8. Establish an explicit dependency-update process that requires security review before changing the pinned version. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration

Findings (25)

Chaining Abuse

High

• Category: Tool Misuse

Content

2. **Make it persistent:**
   ```bash
   echo "sev-guest" | sudo tee /etc/modules-load.d/sev-guest.conf
   ```

### SEV-SNP not detected in firmware/CPU

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

3. **Install Rust if needed:**
   ```bash
   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
   ```

### IOCTL failure

• Confidence: 99% confidence
• Finding: 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.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

1. **Re-fetch certificates:**
   ```bash
   rm -rf ./output/certs
   ./scripts/fetch-certificates.sh ./output/report.bin ./output
   ```

• Confidence: 96% confidence
• Finding: 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.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

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

• Confidence: 95% confidence
• Finding: 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).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

fi

# Cleanup
rm -f "$CERTS_DIR/ca_bundle.pem"

echo ""
echo "=== Chain Verification Summary ==="

• Confidence: 95% confidence
• Finding: 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).

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: 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.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 89% confidence
• Finding: 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.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

2. **Load the kernel module:**
   ```bash
   sudo modprobe sev-guest
   ```

3. **Verify kernel config:**

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

2. **Load the kernel module:**
   ```bash
   sudo modprobe sev-guest
   ```

3. **Verify kernel config:**

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

2. **Load the kernel module:**
   ```bash
   sudo modprobe sev-guest
   ```

3. **Verify kernel config:**

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: 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.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

2. **Make it persistent:**
   ```bash
   echo "sev-guest" | sudo tee /etc/modules-load.d/sev-guest.conf
   ```

### SEV-SNP not detected in firmware/CPU

• Confidence: 90% confidence
• Finding: 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.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

**Solutions:**

1. **Run as root:**
   ```bash
   sudo ./scripts/generate-report.sh ./output
   ```

• Confidence: 80% confidence
• Finding: 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.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

1. **Run as root:**
   ```bash
   sudo ./scripts/generate-report.sh ./output
   ```

2. **Add user to sev group:**

• Confidence: 78% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: 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.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

2. **Add user to sev group:**
   ```bash
   sudo usermod -a -G sev $USER
   # Log out and back in
   ```

• Confidence: 87% confidence
• Finding: 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/Root Execution

Medium

• Category: Privilege Escalation

Content

```bash
   ls -la /dev/sev-guest
   # Fix if needed:
   sudo chmod 660 /dev/sev-guest
   sudo chown root:sev /dev/sev-guest
   ```

• Confidence: 88% confidence
• Finding: 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.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

```bash
   ls -la /dev/sev-guest
   # Fix if needed:
   sudo chmod 660 /dev/sev-guest
   sudo chown root:sev /dev/sev-guest
   ```

• Confidence: 88% confidence
• Finding: 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.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

ls -la /dev/sev-guest
   # Fix if needed:
   sudo chmod 660 /dev/sev-guest
   sudo chown root:sev /dev/sev-guest
   ```

### snpguest not found

• Confidence: 86% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: 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.

Natural-Language Policy Violations

Low

• Confidence: 95% confidence
• Finding: 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.

Excessive Permissions

Low

• Category: Privilege Escalation

Content

# Log out and back in
   ```

3. **Check device permissions:**
   ```bash
   ls -la /dev/sev-guest
   # Fix if needed:

• Confidence: 80% confidence
• Finding: Skill requests more permissions than appear necessary for its stated functionality. Review if elevated access is justified.

External Script Fetching

Low

• Category: Supply Chain

Content

3. **Install Rust if needed:**
   ```bash
   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
   ```

### IOCTL failure

• Confidence: 98% confidence
• Finding: 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.

Missing User Warnings

Low

• Confidence: 88% confidence
• Finding: 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.

Missing User Warnings

Low

• Confidence: 92% confidence
• Finding: 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.

Static analysis

No suspicious patterns detected.