T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/render.mjs:190
- Finding
- Chromium Browser Sandbox Is Unconditionally Disabled## Vulnerability Details **File Location**: `scripts/render.mjs`, lines 190–197 **Vulnerability Type**: Browser sandbox disabled during processing of user-controlled input **Risk Level**: High ```js const browser = await puppeteer.launch({ executablePath: chrome.includes("\\") || chrome.includes("/") ? chrome : undefined, headless: true, args: [ "--disable-gpu", "--no-sandbox", "--disable-dev-shm-usage", ], ``` ### Technical Analysis The script unconditionally launches Chrome or Edge with the `--no-sandbox` argument. The Chromium sandbox is a primary defense-in-depth boundary that limits the operating-system access available to compromised renderer processes. The browser loads the bundled `assets/regulex.html` page and processes a user-supplied regular expression through its embedded JavaScript renderer. No malicious behavior was identified in that bundled page. However, if specially crafted input triggers a vulnerability in the browser or rendering code, disabling the sandbox substantially increases the potential consequences. Code executing through a compromised renderer would not benefit from Chromium's normal sandbox containment. The regular expression is URL-encoded before being placed in the fragment, so the reviewed code does not establish direct HTML or JavaScript injection. Exploitation would require a separate vulnerability in Chromium or the bundled rendering implementation; therefore, this finding represents unsafe hardening rather than a demonstrated direct code-execution primitive. ### Attack Path 1. An attacker supplies a specially crafted regular expression to the `--re` argument. 2. The script URL-encodes the expression and includes it in the fragment of the local `assets/regulex.html` URL. 3. Puppeteer launches the local browser with `--no-sandbox`. 4. The bundled JavaScript renderer and browser process the attacker-controlled expression. 5. If the input triggers an exploitable vulnerability in Chromium or the render ...[truncated 855 chars]
- Remediation
- ## Remediation Suggestions 1. Remove `--no-sandbox` from the default Chromium arguments and run with the browser sandbox enabled. 2. If a deployment environment cannot support Chromium sandboxing, fail safely and document the required host or container configuration instead of silently weakening isolation. 3. If sandbox disabling must remain available for compatibility, require an explicit opt-in command-line option with a prominent security warning. 4. Run any explicitly unsandboxed browser inside an additional isolation boundary, such as a locked-down container, virtual machine, or dedicated low-privilege operating-system account. 5. Restrict container permissions, mount only required files, use a read-only root filesystem where possible, disable unnecessary capabilities, and deny access to sensitive host paths and metadata services. 6. Keep Chrome or Edge and the bundled renderer updated to minimize exposure to known browser and rendering vulnerabilities. 7. Consider validating limits for input length, rendering scale, and timeout to reduce the attack surface for resource-exhaustion inputs.