T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:52
- Finding
- Unsafe Evaluation of Server-Controlled Arithmetic Expressions## Vulnerability Details **File Location**: `SKILL.md`, lines 52–60 **Vulnerability Type**: Unsafe evaluation of untrusted remote input **Risk Level**: High ### Vulnerable Code ```text 1. Fetch a challenge: curl https://project-zoo.com/api/challenge \ -H "Authorization: Bearer $ZOO_API_KEY" Returns: { challengeId, steps: [expr0, expr1, expr2] } 2. Compute the solution: H = first 16 hex chars of SHA-256(post content) A = eval(steps[0]) B = eval(steps[1], substituting A) C = eval(steps[2], substituting B) Solution string: H:A:B:C ``` ### Technical Analysis The Skill instructs implementations to evaluate expressions supplied by the remote `project-zoo.com` challenge endpoint using `eval`. General-purpose evaluation functions interpret input as programming-language code rather than strictly as arithmetic. The instructions do not define a restricted expression grammar, require token validation, or mandate a safe arithmetic parser. Consequently, an agent implementation that follows these instructions literally may execute arbitrary code if the service, its infrastructure, DNS resolution, or the returned challenge data is compromised. HTTPS reduces interception risk but does not protect against a compromised or malicious origin. ### Attack Path 1. An attacker compromises the challenge service or another component capable of controlling its response. 2. The attacker returns a `steps` entry containing executable language syntax instead of a valid arithmetic expression. 3. An implementation follows the Skill and passes that entry to a general-purpose `eval`. 4. The injected expression executes inside the agent process. 5. The payload acts with the process's existing permissions and may access credentials, files, environment variables, network capabilities, or available agent tools. ### Impact Assessment Successful exploitation could permit arbitrary code execution with the privileges ...[truncated 854 chars]
- Remediation
- ## Remediation Suggestions Replace the `eval` instruction with a narrowly scoped arithmetic evaluator: 1. Define the complete accepted grammar, including permitted integer formats, operators, parentheses, and the single placeholder representing the previous result. 2. Parse expressions with a dedicated arithmetic parser rather than a programming-language evaluation function. 3. Reject identifiers, property access, function calls, string literals, imports, shell metacharacters, comments, and every token not explicitly allowed. 4. Enforce strict expression-length, nesting-depth, execution-time, and numeric-range limits to prevent denial-of-service conditions. 5. Validate the remote response schema and require exactly the expected number and type of challenge steps. 6. Run challenge computation without filesystem, process-execution, credential, tool, or unrestricted network access where sandboxing is available. 7. Update the documentation to explicitly prohibit `eval`, `exec`, shell evaluation, and equivalent dynamic-code mechanisms. 8. Add negative tests containing function calls, object/property access, imports, command-execution syntax, oversized numbers, excessive nesting, and malformed operators.