dor control socket: predictable path, no server authentication, and a non-fatal bind failure on Windows

[nedtwigg]

Found by the nightly security audit's application-security pass (see SECURITY.md → CI Validation Contract), verified by hand. Three related weaknesses in the dor control channel; the third is what makes the first two reachable.

1. The path is predictable and lives in a shared namespace

https://github.com/diffplug/dormouse/blob/main/vscode-ext/src/pty-manager.ts#L182-L184

const dorControlSocket = process.platform === 'win32'
  ? `\\\\.\\pipe\\dormouse-vscode-${process.pid}-dor`
  : path.join(os.tmpdir(), `dormouse-vscode-${process.pid}-dor.sock`);

The standalone host does the same with dormouse-{pid}-dor (standalone/src-tauri/src/lib.rs). A PID is guessable and enumerable, and both os.tmpdir() and the Windows named-pipe namespace are writable by other principals.

2. The client authenticates to the server, never the reverse

DorControlClient writes the token as the first bytes on the wire, before the peer has proven anything about itself:

https://github.com/diffplug/dormouse/blob/main/dor/src/control-client.ts#L110-L116

socket.on('connect', () => {
  socket.write(`${JSON.stringify({ requestId, token: this.token, surfaceId, method, params })}\n`);
});

So whoever holds the path receives DORMOUSE_CONTROL_TOKEN from the first dor invocation that connects. The token itself is fine — randomBytes(24) — but it is a bearer credential handed to an unauthenticated peer, and it grants the full surface-control API: dor split, dor send (arbitrary keystrokes into any pane), dor read (screen contents and scrollback), dor kill.

3. On Windows, losing the bind is not fatal — and shells still get the token

https://github.com/diffplug/dormouse/blob/main/standalone/sidecar/dor-control-server.js#L129-L148

On POSIX the pre-listen unlinkSync rethrows anything that is not ENOENT, so a squatted path stops startup. On Windows there is no unlink, and a name already taken surfaces as a listen error that is logged and then swallowed:

server.on('error', (error) => {
  console.error(`[dor-control] ${error.message}`);
  rejectReady(error);
});
ready.catch(() => {
  // ... keeps the sidecar alive for normal PTY work.
});

Keeping the sidecar alive is right — PTY work should survive a dead control channel. The problem is that getDorRuntimeEnv keeps handing DORMOUSE_CONTROL_SOCKET and DORMOUSE_CONTROL_TOKEN to every shell it spawns regardless. So an attacker who wins the pipe race gets Dormouse to keep feeding it clients and tokens, while the only sign is one line on stderr.

The pattern to copy is already in the repo

vscode-ext/src/peer-link.ts defends this exact threat for the peer channel:

• a per-uid parent directory created 0o700, with the uid and mode re-checked on every use (peer-link.ts:167, :183-200) rather than trusting tmpdir();
• the server opens with a challenge and the client proves over that specific nonce (:786, :803, :674-684), so a squatter learns nothing by accepting a connection. The comment at :1010 — "Answering a challenge proves nothing about the challenger" — is precisely the property the control socket lacks.

Suggested shape

1. Move the POSIX socket into a uid-owned 0700 directory with the same checks as peerDirPath(), and stop deriving the name from the PID alone.
2. Make the server prove itself first (challenge/HMAC over the shared token) so dor never emits the token to an unproven peer.
3. On Windows, treat a lost bind as fatal to the control channel: keep the sidecar alive for PTY work, but stop putting DORMOUSE_CONTROL_TOKEN into spawned shells' environments, and surface it in the UI rather than only on stderr.

docs/specs/dor-cli.md owns the control-socket plumbing and should be updated alongside.

Severity

Local attacker only — someone already able to run code as another account on the machine, or as the same user. On a single-user laptop that is a low bar to clear only because the attacker already has a foothold; on a shared or multi-user Windows box it is more interesting, since the pipe namespace is machine-wide.

[dormouse-bot]

Reproduced all three and opened #433, which follows the suggested shape.

Path. The server picks it now, so neither host computes one — dor_control_socket_path() is gone from lib.rs and the socket const from pty-manager.ts. POSIX: <tmpdir>/dormouse-dor-<uid>/<8 random bytes>.sock, with the parent created 0700 and re-checked per use exactly as peerDirIsSafe() does. Windows: \\.\pipe\dormouse-dor-<8 random bytes>. 8 random bytes rather than 16 is load-bearing — macOS caps sun_path near 104 bytes and its os.tmpdir() is already ~50, so a 32-hex name lands within a byte or two of the cap and the bind starts failing on some machines; there's a test asserting the whole path stays under 104.

Authentication. Server speaks first with a challenge; client answers HMAC(token, "dor-control/client <nonce>") plus a nonce of its own; server answers over that nonce before the client sends anything. The token never crosses the wire in either direction now, so a squatter learns two nonces. A bad hello is hung up on with no reply. The regression test is the interesting one: it stands up a fake server that plays the challenge convincingly and then asserts the bytes it received never contain the token, and that the request line was never written.

Windows bind. The env vars are the fix, not the log line. Both pty-host.js and the sidecar now delete DORMOUSE_CONTROL_SOCKET/TOKEN from their own process.env at startup — that's the leak I'd missed reading it the first time, since pty-core merges process.env into every shell independently of the spawn env — and restore them only when ready resolves. Both hosts also hold their spawn path until ready settles (2s ceiling), so the first terminal can't race the bind and get a token for a channel that never came up. While I was there, the POSIX pre-listen unlinkSync now rejects ready instead of throwing: as written, a socket file it couldn't clear took down the sidecar and every PTY in it, which is the same asymmetry pointed at from the other side.

Left out: surfacing a dead channel in the UI. Both hosts know the outcome at ready, so the plumbing is there, but there's no shared place to put a notice — the Baseboard carries the standalone update notice and has no VS Code counterpart — so it's a design call rather than a mechanical one. Recorded as an item in docs/specs/dor-cli.md → ## Future rather than guessed at.

Verification

• node --test standalone/sidecar/*.test.js — 106 pass (10 in dor-control-server.test.js, rewritten for the handshake)
• pnpm --filter dor test — 104 pass, including a new dor/test/control-client.test.mjs that runs the real SocketControlClient against the real dor-control-server.js both hosts load
• pnpm --filter dormouse test — typecheck + 103 pass
• node scripts/spec-lint.mjs
• On the PR: Build & Test, Standalone Smoketest, and Standalone Platform Check on both macos-latest and windows-latest all green — the platform checks are what actually compile the lib.rs deletion on both cfg branches, since this runner has no GTK dev libs.

New security assertions worth naming, all in dor-control-server.test.js and control-client.test.mjs:

• a squatter that can't prove the token never receives it
• a peer that doesn't open with a challenge gets nothing at all
• a request carrying the token the way the old protocol did is refused
• a socket directory that's a symlink rather than a private directory of ours is refused, and the server reports socketPath: null with a rejected ready
• a lost bind rejects ready without throwing