T09 · Insecure Skill Coding Practices
- Location
SKILL.md:82- Finding
Unimplemented Sandbox Controls May Cause Unsafe Execution of Untrusted Code
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 82-176
Vulnerability Type: Security controls represented as documentation rather than enforceable isolation
Risk Level: HighVulnerable Configuration
python NETWORK_RESTRICTIONS = { 'allow_outbound': False, 'allow_inbound': False, 'allow_dns': False, 'allow_internet': False, }python FILESYSTEM_RULES = { 'read_whitelist': ['/tmp', '/sandbox'], 'write_whitelist': ['/tmp/sandbox'], 'blocked_paths': [ '/', '/home', '/root', '/etc', '/var', '*.key', '*.pem', '.env', ], 'max_file_size': 10 * 1024 * 1024, }python DANGEROUS_APIS = { 'python': [ 'os.system', 'os.popen', 'subprocess', 'eval', 'exec', '__import__', 'open' ], 'javascript': [ 'eval', 'Function', 'require("child_process")', 'process.binding', 'fs.delete', ], }The documented execution process subsequently instructs the workflow to modify dangerous calls, configure a sandbox, execute the code in an isolated environment, collect results, and clean up the environment.
Technical Analysis
The project contains only
SKILL.md. It does not include an executable sandbox backend, container configuration, virtual machine launcher, syscall filter, network namespace setup, filesystem isolation mechanism, or resource-limit implementation.The displayed Python dictionaries are illustrative configuration values, not controls that the operating system or an execution engine enforces. Likewise, the listed regular expressions and API names are deny-list examples. Static deny-list matching cannot establish a security boundary and can be bypassed through aliasing, reflection, dynamic string construction, alter ...[truncated 2551 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not execute untrusted code unless a real, independently enforced sandbox backend is available and successfully initialized.
- Implement isolation outside the guest code using a container or virtual machine with:
- A dedicated unprivileged user and no host-user namespace equivalence.
- No outbound or inbound network interface and no DNS access.
- A minimal read-only root filesystem.
- A newly created writable temporary directory with strict size limits.
- No mounts containing the host project, home directory, credentials, sockets, or environment files.
- Linux capabilities removed and privilege escalation disabled.
- A restrictive syscall policy, mandatory access controls, and process-count limits.
- Enforced CPU, memory, disk, thread, process, and wall-clock limits.
- Treat pattern scanning only as defense in depth. Do not use regex or API deny lists as the primary security boundary.
- Fail closed when any isolation control cannot be verified. Never fall back to local interpreter or shell execution.
- Run each submission in a fresh disposable environment and destroy it after collecting size-limited output.
- Remove secrets from the sandbox environment, sanitize inherited environment variables, and prevent access to host service sockets and metadata endpoints.
- Add automated adversarial tests covering obfuscated imports, dynamic evaluation, alternate network clients, filesystem traversal, subprocess creation, fork bombs, resource exhaustion, and native-code escape attempts.
- Clearly distinguish illustrative policy from implemented behavior in the documentation and avoid reporting controls as active unless the backend confirms their enforcement.