T09 · Insecure Skill Coding Practices
- Location
index.js:89- Finding
Unsandboxed Execution of Untrusted Candidate Code
- Content
View full analysis
Vulnerability Details
File Location:
index.js:89-110
Vulnerability Type: Arbitrary code execution without security isolation
Risk Level: HighVulnerable Code
javascript runCode(code, input, language = 'python') { const filename = `test_run_${Date.now()}.${language === 'python' ? 'py' : 'js'}`; const filepath = path.join(this.tempDir, filename); fs.writeFileSync(filepath, code); let command; if (language === 'python') { command = `python3 ${filepath}`; } else { command = `node ${filepath}`; } try { // Basic execution with input piping // Note: This is simplified. Real competitive coding runners need sandboxing. const output = execSync(command, { input: input, timeout: 5000, encoding: 'utf-8' }); return { success: true, actualOutput: output.trim() }; } catch (error) { return { success: false, error: error.message, actualOutput: error.stdout ? error.stdout.toString() : '' }; } finally { if (fs.existsSync(filepath)) fs.unlinkSync(filepath); } }Technical Analysis
The
codeparameter is written directly to a temporary source file and executed using the locally installed Python or Node.js interpreter. No sandbox, container, privilege boundary, filesystem restriction, network restriction, environment sanitization, or syscall policy is applied.The five-second
execSynctimeout is only an execution-duration control. It does not prevent the submitted program from reading files, accessing environment variables, making network requests, modifying resources, invoking additional executables, or starting detached child processes. Deleting the source file afterward does not reverse actions already performed by the submitted program.Although command construction uses an internally generated path rather than directly interpolating attacker-controlled shell text, the intended input to this function is itself executab ...[truncated 1465 chars]
- Remediation
View remediation
Remediation Suggestions
- Execute every candidate program inside a disposable sandbox or container rather than directly on the verifier host.
- Run the sandbox as a dedicated, unprivileged user with no access to host credentials, application secrets, source files, or sensitive mounted volumes.
- Remove secrets such as
OPENAI_API_KEYfrom the execution environment by using a strict environment-variable allowlist. - Disable outbound and inbound network access unless explicitly required.
- Use an isolated, size-limited temporary filesystem and mount all other filesystems read-only or make them inaccessible.
- Enforce CPU, memory, wall-clock, file-size, open-file, and process-count limits. Terminate the complete process group when a timeout occurs.
- Apply syscall filtering and mandatory access controls where available, such as seccomp, AppArmor, SELinux, or an established code-execution sandbox.
- Use random, securely created per-execution directories and ensure concurrent requests cannot share files.
- Destroy the entire sandbox after every run and monitor for failed teardown.
- Document sandboxing as a mandatory deployment requirement rather than an optional recommendation.