T09 · Insecure Skill Coding Practices
Error
- Location
- strategies/Main.md:227
- Finding
- Unsandboxed Execution of User-Submitted Code<![CDATA[ ## Vulnerability Details **File Location**: `strategies/Main.md:227-240` **Vulnerability Type**: Unsafe execution of untrusted code **Risk Level**: High ### Vulnerable Code ```markdown ## Step 6: Scoring & Evaluation ### 6.1 Apply Rubrics For each answered question: **Load scoring criteria** from knowledge/Scoring.md: - Criteria definitions - Point scale (0-5) - Weights **Score each criterion**: - **For automated criteria**: Apply validation rules - Code correctness: Run against tests ``` ### Technical Analysis The Skill accepts code answers from examination participants and instructs the automated scoring process to run those answers against tests. User-submitted code is untrusted input, but the strategy does not require any execution isolation or security controls. No sandbox, container boundary, network restriction, read-only filesystem, privilege reduction, process limit, resource quota, or explicit execution consent is specified. If an implementation follows this strategy by running submissions directly in the Agent or host environment, arbitrary code included in an answer would execute with the privileges of the scoring process. Merely running a fixed test suite does not make a submission safe. Malicious behavior can execute during module import, initialization, test discovery, object construction, or invocation of the function under test. ### Attack Path 1. An attacker starts or participates in a Code Generation examination. 2. The examiner requests a code answer. 3. The attacker submits code containing a malicious initialization routine or function body. 4. The automated scorer follows the instruction to run the submission against tests. 5. The malicious code executes in the scoring environment. 6. Depending on the process privileges and environment, the payload attempts to read files or environment variables, modify accessible data, invoke local commands, make network requests, or consume excessive resources. ### Impact Assessme ...[truncated 688 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Treat every submitted program and generated test artifact as hostile input. - Default to static analysis without execution unless runtime validation is necessary. - Require explicit user authorization before executing submitted code. - Run code only inside a disposable, ephemeral sandbox or container. - Use a dedicated unprivileged account with no access to host credentials or user data. - Disable outbound network access by default. - Mount only the required test fixtures and mount them read-only. - Do not expose host environment variables, sockets, package-manager credentials, cloud metadata, or Agent configuration. - Apply strict CPU, memory, execution-time, disk, process-count, and output-size limits. - Disable privileged containers, host filesystem mounts, host networking, and access to container-management sockets. - Destroy the execution environment after each submission. - Validate submitted language, file count, file size, and execution entry point before testing. - Record execution failures safely without returning secrets or unrestricted process output. - Document the sandbox security boundary and test it against malicious imports, fork bombs, infinite loops, filesystem access, and network access. ]]>