fix(downloads): sanitize LLM-controlled filenames and folder paths (CWE-22)

[sebastiondev]

Summary

The download tools in packages/browser-runtime/src/tools/tools/downloads/index.ts pass LLM-supplied filename, folderPath, and folderPrefix arguments directly to chrome.downloads.download() without sanitization. This PR adds a small sanitization layer plus unit tests.

• CWE-22: Improper limitation of a pathname to a restricted directory
• Affected file: packages/browser-runtime/src/tools/tools/downloads/index.ts
• Affected tools: downloadTextAsMarkdown, downloadImageTool, downloadChatImagesTool

Data flow

1. The AI agent reads attacker-influenced content (web page text, chat content, tool output).
2. Via prompt injection, the model is convinced to invoke a download tool with a crafted filename / folderPath / folderPrefix (e.g. ../../Desktop/evil, names with control chars or Windows-illegal characters, leading dots, etc.).
3. The raw string flows into chrome.downloads.download({ filename: ... }).
4. For downloadImageTool and downloadChatImagesTool the call uses saveAs: false, so no Save-As dialog is shown — the user does not get a chance to notice the unusual path.

Fix

New helpers in downloads/sanitize-path.ts:

• sanitizeSegment(name, fallback) — strips / and \, removes .. sequences, drops control chars (U+0000–U+001F, U+007F), strips Windows-illegal chars < > : " | ? *, trims leading/trailing dots and spaces, and falls back to a safe default if the result is empty.
• sanitizeDownloadPath(path, fallback) — splits on / or \, sanitizes each segment, drops empty/..-only segments, and rejoins with /.

Applied at every sink in downloads/index.ts:

• downloadTextAsMarkdown — sanitize filename.
• downloadImageTool — sanitize filename and folderPath.
• downloadChatImagesTool — sanitize folderPrefix once and reuse, sanitize each per-image baseFilename, and return the sanitized folder in the result so the response reflects what was actually written.

The change is intentionally scoped: it does not alter tool schemas, behaviour for benign inputs, or any unrelated code paths.

Tests

Added downloads/sanitize-path.test.ts with 15 cases covering:

• Identity for safe names (hello, my-file, folder/file).
• Path-separator stripping (a/b, a\b, /etc/passwd).
• .. traversal (.., ...., ../../../etc/passwd, ..\..\Desktop\malware, folder/../../secret).
• Control characters (\x00, \x1f).
• Windows-illegal chars (< > : " | ? *).
• Leading/trailing dots and spaces.
• Empty / fully-malicious input → fallback.
• Realistic payload (../../../Desktop/malware → Desktop/malware).

All tests pass under vitest, and the repo's npm run preflight (lint/typecheck/format) passes on the branch.

Security analysis

The realistic threat model is prompt injection from page or chat content the agent is asked to process. The saveAs: false calls in the image tools are the most user-invisible sink, since no dialog warns the user about the destination.

Chrome's downloads API already rejects literal .. back-references and absolute paths at the platform level, so this isn't an arbitrary-write-anywhere primitive — files still land under the user's Downloads root. The remaining risk that this PR addresses is:

• crafted filenames with control chars / illegal characters causing Chrome download errors (UX) or misleading filenames (e.g. RTL override, \x00 truncation tricks),
• subtle traversal attempts that Chrome may or may not normalize the same way across platforms,
• attacker-chosen subpaths inside Downloads (this PR doesn't restrict to an allowlist — that was out of scope and matches existing behaviour),
• the response object accurately reporting the path that was actually written.

So this is best characterised as defense-in-depth and hardening of an LLM-reachable sink, not a sandbox escape patch.

Adversarial review

Before submitting, we tried to disprove this. The main candidate mitigation is Chrome itself: chrome.downloads.download does sanitize obvious traversal. That eliminates the worst case (writing outside Downloads), which is why we're framing this as hardening rather than a critical bug. However, the tool args still flow into a security-relevant API from an LLM-controlled source with no validation, the image tools bypass the Save-As dialog, and there is no upstream framework protection between the tool argument and the Chrome API call — so the small sanitizer is genuinely useful and worth landing.

Files changed

• packages/browser-runtime/src/tools/tools/downloads/sanitize-path.ts (new, 57 lines)
• packages/browser-runtime/src/tools/tools/downloads/sanitize-path.test.ts (new, 90 lines)
• packages/browser-runtime/src/tools/tools/downloads/index.ts (sanitize calls at three sinks)

Happy to adjust scope, naming, or fallback behaviour if you'd prefer a different convention.

cc @lewiswigmore