OrcaWinandOrca Worker
c252d855ac
* fix(windows): resolve npm/pnpm .cmd shims past cmd.exe
A `.cmd` target forces every spawn through `cmd.exe /c` with each argument
caret-escaped, and Microsoft Defender for Endpoint scores a long `cmd.exe /c`
line carrying caret-escaped natural language as obfuscation. `codex.cmd` is
named in the spawn cluster of the MDE incident this addresses.
npm's `cmd-shim` and pnpm's `@zkochan/cmd-shim` generate files whose whole body
is "find node, run this script". Read one, and the spawn can go straight to
`node.exe <script> <args>` — no cmd.exe, no caret escaping. Anything the parser
does not recognise exactly, or whose target cannot be confirmed on disk, keeps
the existing cmd.exe path.
Incidentally fixes a real bug: cmd ends its command at a raw CR/LF whatever the
quote state, so a multi-line agent prompt through a `.cmd` shim had to be
rejected. Resolved shims have no such limit.
* fix(windows): refuse drive-relative shim paths and run the win32 tests in CI
Two blocking findings from review.
A drive-relative path defeated the absolute-path guard:
`win32.isAbsolute('D:evil.js')` is false, but `win32.resolve` reads the drive
letter and lands on `D:\evil.js`, outside the shim directory. cmd would have
built `C:\shim\D:evil.js` and failed; we would have executed the wrong file.
Adding `:` to the unsafe-character set closes it, and the alternate-data-stream
spelling `a.js:zone` with it. It costs no coverage: 84 of the 91 real shims on
this box still resolve, the same seven fall back.
Neither `windows-cmd-shim-resolution.test.ts` nor its `.win32` sibling was in
the Windows package job's file list, so the whole filesystem/resolution half and
the real-spawn equivalence suite ran nowhere. Both are now in
`WINDOWS_PACKAGE_TESTS` and in the pr.yml step.
Also from review: clear `windowsVerbatimArguments` explicitly on the resolved
branch rather than inheriting it, since there is no caller-built command line
there; document the kill switch and the PTY/hook-wrapper scope limits in
docs/reference; and cover drive-relative, BOM, line-ending, casing and `%*`
tampering in the platform-independent half of the tests.
* docs(windows): justify the shim-path colon guard from the filesystem rule
The guard was argued empirically ("none of the 91 shims on this box has one"),
which invites a future reader to relax it for a shim we have not seen. Windows
reserves `:` within a path segment, so a relative path cannot carry one at all:
the only spellings that can are drive-qualified, an alternate data stream, or a
`\?\` device path, and the last is already refused as absolute. That makes a
false refusal impossible rather than unobserved.
* refactor(child-process): move resolveSpawn into its own module
The merge with main pushed run-process.ts one line past the 300-line cap:
both sides grew it. The spawn-argv decision is already a pure, separately
tested unit, so it moves out rather than the cap moving up. run-process.ts
re-exports it, so no caller changes.
* perf(child-process): cache the shim interpreter lookup
The parse cache spared the shim read but not the PATH walk, so a second
resolution of the same .cmd did 0 reads and one statSync per PATH entry --
30 on a 30-entry PATH, synchronous on resolveSpawn, where one dead network
mount blocks the calling thread on every spawn.
Keyed by shim directory AND PATH, since the shim's own rule is
%~dp0\node.exe first then PATH, and a PATH edit between spawns must miss.
Corrects the stat comment, which accounted only for the shim itself.
* fix(child-process): revalidate a cached shim interpreter before using it
The node cache was held for process life and never rechecked, so a cached
node.exe that was later uninstalled -- or dropped from PATH by a version
manager -- was still handed to resolveSpawn, failing the spawn with ENOENT.
An uncached process in the same state returns null and falls back to
cmd.exe successfully, so the cache was strictly worse than no cache.
One statSync on a non-null hit, not one per PATH entry, so the walk this
cache exists to skip is still skipped. The stale-null direction stays
uncorrected on purpose: it only keeps the working cmd.exe fallback. Both
directions are now stated in the comment, along with the known miss for
callers that vary PATH per spawn.
* fix(child-process): honour PATHEXT when resolving the shim interpreter
The doc claimed a node.com/.bat/.cmd on PATH returned null and fell back to
cmd.exe. The scan actually skipped those entries and kept looking for a
node.exe, so PATH=C:\A;C:\B with C:\A\node.com and C:\B\node.exe resolved to
B's node.exe while the shim runs A's node.com -- a different binary, chosen
silently, on the one axis this module must not get wrong.
The scan now follows cmd's rule: first PATH directory holding any PATHEXT
spelling wins, PATHEXT order decides within it, and only an .exe winner is
returned. Anything else gives up and keeps the cmd.exe path, which restores
the strict-subset-of-cmd property everywhere except the documented cwd case.
PATHEXT is read from the child's env and joined into the cache key, since it
now changes the answer. Costs one stat per PATHEXT entry per node-less
directory, paid once per process behind the cache.
---------
Co-authored-by: Orca Worker <orca-worker@localhost>
3.7 KiB
Resolving Windows .cmd shims past cmd.exe
Node refuses to spawn a .cmd/.bat target without a shell (the
CVE-2024-27980 mitigation), so resolveSpawn has to make cmd.exe the program
and hand it /d /v:off /s /c "<caret-escaped argv>". For an agent CLI that
means a long cmd.exe /c line whose caret-escaped payload is natural-language
prompt text — which Microsoft Defender for Endpoint's command-line model scores
as obfuscation. codex.cmd appeared in the spawn cluster of an MDE incident
against Orca for exactly this reason.
src/shared/child-process/windows-cmd-shim-resolution.ts sidesteps it. npm's
cmd-shim and pnpm's @zkochan/cmd-shim generate files whose entire body is
"find a Node interpreter and run this script". Reading one lets resolveSpawn
spawn node.exe <script> <args…> directly: no cmd.exe in the tree, and no
caret escaping at all.
What resolution changes
Only runProcess / spawnProcess callers. Two things people expect it to
cover, and it does not:
- The interactive terminal.
src/main/daemon/pty-subprocess/native-pty-spawn.tscallspty.spawndirectly, so typingcodexin an Orca terminal is completely unaffected. - Orca's own hook wrappers (
codex-hook.cmdand friends). These are batch files Orca writes, matching none of the generator shapes, so they keep the cmd.exe path. They are addressable — we generate them — but not by this module.
Adding a shape
Four shapes are recognised, each transcribed verbatim from a real install into
src/shared/child-process/__fixtures__/windows-cmd-shim-bodies.ts. If you add a
fifth, add its real body there too. A shape guessed from documentation is not
evidence.
The rule for the parser is all-or-nothing: the whole canonicalised body must match end to end, and anything unrecognised returns null and keeps the cmd.exe path. A mis-resolution silently runs the wrong program or drops arguments, which is far worse than an EDR alert — when in doubt, refuse.
Resolution also refuses a captured path that is absolute, drive-relative
(D:evil.js — win32.isAbsolute says false, but win32.resolve leaves the
shim directory), or contains % ^ & | < > " : or a line break; a script or
target that is not on disk; an interpreter-less target that is not .exe/.com;
and a program path that is not absolute.
Refusing every : cannot cause a false refusal. Windows reserves the character
within a path segment, so a relative path cannot contain one — the only
spellings that can are drive-qualified, an alternate data stream (a.js:zone),
or a \\?\ device path, and the last is already refused as absolute.
Kill switch
Set ORCA_DISABLE_CMD_SHIM_RESOLUTION to any non-empty value in the
environment a child is spawned with, and every .cmd goes back through
cmd.exe /c unchanged. It is read from the spawn's own environment, so
exporting it before launching Orca disables resolution process-wide.
Use it to confirm a suspected mis-resolution: run the failing operation with and without it. Identical behaviour means resolution is not the cause. If it is, report the shim's body — the parser is only allowed to recognise shapes we have seen for real.
Behaviour that changes, deliberately
A resolved shim is not merely a quieter spelling of the cmd.exe path. Two limits
of cmd.exe disappear with it:
- An argument containing
\r/\nwas rejected outright, because cmd ends its command at a raw line break whatever the quote state. Multi-line agent prompts now work. - A command line over 8191 characters returned
The command line is too long.Long prompts now work.
Both are improvements, but they are behaviour changes: an unresolved shim still
hits both limits, so a caller must not assume every .cmd accepts them.