sim 7086dcbbc9 test(#4636): failing-first coverage for symlink escape past lexical confinement ...

Tests only; no fix. These MUST fail.

Found while draining the containment duplicates in Phase 3, not by looking for
it: isPathConfined's docstring claims its callers are kept symlink-safe
upstream, and checking that claim showed it does not hold for three of its four
call sites. isPathConfined is lexical by design and structurally cannot see a
symlink, so where the claim fails there is no defense at all.

  install-engine.cts:1608     mkdirSync(recursive) + writeFileSync under dest
  install-profiles.cts:880    the same shape under stageDir
  install-profiles.cts:755    statSync/readFileSync, and statSync FOLLOWS links

SEVERITY, STATED HONESTLY, because the three are not equal and the first
impression was wrong.

  :755 is the real one and needs no race. It reads
  <capDir>/skills/<stem>/SKILL.md. Nothing prunes that path and nothing
  randomizes it, so a symlink planted there is followed and its content is
  returned — and then written into the install tree as a skill body.

  :1608 and :880 are defense-in-depth against a local race, not plain
  write-through. _removeGsdEntries (install-engine.cts:851-854) rmSyncs every
  entry whose name starts with kind.prefix, and the skill names ARE
  prefix+stem — so a symlink planted before the call is unlinked before the
  write loop reaches it. :880's stageDir is a fresh mkdtempSync path, so its
  name cannot be guessed in advance either. Both require winning a window.

That is also why the first two tests do not simply pre-plant a link and call
the function: written that way they PASS today, against vulnerable code, for
the wrong reason. They instead open the window deterministically by hooking a
call the function is guaranteed to make — the technique CLAUDE.md section 4
prescribes for injecting filesystem conditions, and the one already used in
tests/install-runtime-artifacts.test.cjs. No sleeps, no concurrency, no
flakiness: the window is opened by a synchronous side effect, not raced for.

Each test asserts the OUTCOME rather than the mechanism — the canary file
outside the root is byte-identical afterwards, or the installed content does
not contain it — so a fix is free to close the hole any way it likes. Symlink
creation is guarded so the Windows lanes skip rather than fail, and no test
uses chmod 0o000, which is vacuous on a bench running as root.

Folded into tests/install-write-confinement.test.cjs, the owning suite, whose
existing F2/M1 coverage coincidentally proves the gap: it tests the case where
the destination DIRECTORY is a symlink, which is already defended, and never
the per-entry case.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-12 13:30:16 -04:00

206 KiB

Raw Blame History

View Raw