mirror of https://github.com/stablyai/orca.git synced 2026-09-24 16:02:41 +00:00

Files

T

OrcaWinandOrca Worker fba90e017c fix(windows): copy the daemon host exe verbatim instead of renaming it (MDE T1036) (#17865 )

* docs(windows): document the EDR signal surface

Six Microsoft Defender for Endpoint incidents fired against Orca 1.4.192 in
eight days on one enterprise Windows 11 / Intune tenant. All six were
behavioural process-tree scoring, not signature hits; two escalated to
multi-stage incidents mapped to ATT&CK Execution and Collection.

Add a reference doc mapping each attack-technique-shaped behaviour to the code
that produces it and to why it exists: the renamed daemon image (T1036), the
per-process PEB read, encoded policy-bypassed PowerShell (T1049), caret-escaped
cmd.exe lines, and computer-use screen capture plus runtime-compiled MSIL
(T1113). Records that signing is not the gate -- reputation is signer plus
hash-keyed prevalence -- and carries the two evidence gaps the report noted.

Adds an engineer checklist, deployment guidance for admins (AV path exclusions
do not suppress EDR behavioural alerts; an MDE alert suppression rule does), and
an explicit pre-deployment warning about computer use.

* docs(windows): correct the PowerShell flag inventory and admin paths

Review corrections to the EDR posture doc.

The "encoded, policy-bypassing PowerShell" list conflated three different
shapes and was incomplete. Split it into the three tiers an EDR actually scores
differently -- bypass plus encoding, encoding alone, and bypass alone -- and add
the sites it missed, including windows-mobile-firewall.ts, which encodes a
script and launches it elevated through Start-Process -Verb RunAs. system-fonts.ts
(-Command) and desktop-script-provider-bridge.ts (-File) were listed as encoded
and are not. Notes that a raw grep under-reports, because the hook sites reach
-EncodedCommand through wrapWindowsPowerShellEncodedCommand.

Attribute the in-payload Set-ExecutionPolicy move to #16576 rather than to
#16003's measurement, which keyed on -WindowStyle Hidden + -EncodedCommand, and
record that the launcher's own tradeoff is unverified on a real box.

Admin guidance was missing two ways a suppression rule pinned to one full path
misses real activity: the .staging-<hex> sibling that exists mid-update, which
is when the update-cluster incidents fire, and the userData fallback when
LOCALAPPDATA is unset.

Also: state the measurement conditions on the process-table timings, note that
Hermes has surface even though we have no telemetry for it, note that the
uninstaller names are electron-builder-generated and in no repo file, drop a
volatile line count, and mark the per-operation computer-use shape as being
addressed by an unmerged change. Drops the duplicated AGENTS.md section, keeping
the indexed bullet.

* docs(windows): reconcile the EDR posture doc with the shipped remediation

Three claims in this doc became false once the rest of the Windows EDR set
landed, and two told engineers the opposite of what the release does.

The process-table section still described one shared snapshot taken with
`Memory | CommandLine | CreationTime`, argued that splitting the cache per
field set "would restore exactly the fan-out it exists to prevent", and
concluded the shape was unfixable because "the information is only in the
PEB". The split shipped (identity opens no handle at all), `Memory` is
retired, and the command line now comes from the kernel through
`ProcessCommandLineInformation` -- `ReadProcessMemory` is absent from the
compiled addon and a ratchet asserts it against the import table. An engineer
reading the old text would have concluded both fixes were dead ends.

The PowerShell site inventories were stale in three of four lists: the port
scan went native, every `-ExecutionPolicy Bypass` + `-EncodedCommand` pair
was dropped as a measured no-op, and of the unencoded-bypass list only
`wsl-cli-scripts.ts` survives. Regenerated against the merged tree, including
the sites that reach the flag through `wrapWindowsPowerShellEncodedCommand`
and never spell it, which a raw `rg` misses.

Incident-evidence sections are left alone: they record what the tenant observed
on 1.4.192, not what the code does now.

* fix(windows): copy the daemon host exe verbatim instead of renaming it

Microsoft Defender for Endpoint flagged `orca-terminal-daemon.exe` as MITRE
T1036 (Masquerading): Orca copied its own `Orca.exe` into %LOCALAPPDATA% under a
different name, specifically so the NSIS updater's `taskkill /IM Orca.exe` could
not match, then ran it detached. Because that process is what every other flagged
action was attributed to, the name mismatch acted as a reputation multiplier on
unrelated findings.

The rename was never what made the daemon survive. In app-builder-lib 26.15.3 the
installer's FIND_PROCESS/KILL_PROCESS select processes whose image path is under
$INSTDIR; `taskkill /IM` is only the fallback for hosts where PowerShell is
missing or blocked. Survival is a property of the path, and
%LOCALAPPDATA%\Orca\daemon-host is outside $INSTDIR whatever the file is called.

Derive the host exe name from process.execPath so the copy is byte-for-byte,
name included — it keeps its Authenticode signature and carries no renamed-image
signal. On the no-PowerShell fallback the daemon is now killed with the app and
terminals cold-restore, which is the documented pre-relocation outcome the update
harness already asserts, not a regression.

The uninstall macro no longer needs a distinct name to find the daemon; it kills
the app's own image name (plus the legacy name, for hosts left by older builds).

Adds docs/reference/windows-daemon-host-relocation.md with the survival contract,
the rejected alternatives and their measured costs, and the invariants to keep.

* fix(windows): apply daemon-host relocation review corrections

Scope the uninstall taskkill to the current user with `/FI "USERNAME eq
%USERNAME%"` via cmd.exe, matching upstream's per-user KILL_PROCESS — without it
an elevated machine-wide uninstall reaches another logged-on user's session, so
the "no collateral" claim in the comment was overstated.

Comment the rmSync-before-publish: Windows refuses to delete a running image, so
a live daemon already hosted in this version's dir (same-version reinstall, or a
dev channel reusing a version) throws and materialization fails open.

Doc corrections:
- The fallback selector is the full per-user `taskkill /F /IM "<app>.exe" /FI
  "PID ne $pid" /FI "USERNAME eq %USERNAME%"`, not a bare `taskkill /IM`.
- The probe reads `Get-ExecutionPolicy -Scope Process`, not the effective policy,
  and GPO writes MachinePolicy/UserPolicy — so GPO-managed hosts take the primary
  path-scoped branch. Narrow the fallback triggers accordingly.
- Drop the Authenticode sentence: the old name was equally byte-identical and
  equally signed, so a filename has no bearing on signature validity.
- Name the new update-abort path: the daemon now matches FIND_PROCESS, so on the
  fallback branch an unkillable host reaches the retry loop's MessageBox /SD
  IDCANCEL and Quits, aborting a silent update.
- Correct the customCheckAppRunning rejection. It is ~6 lines, not a rewrite; it
  is wrong because forcing the PowerShell branch where PowerShell is absent makes
  FIND/KILL silently no-op and leaves the real app running with files in use.
- Bound the win honestly: OriginalFilename is empty on the shipped binary, so the
  strongest T1036 indicator never fired, and the residual copy-and-run-detached
  shape still maps to T1036.005.

Reconcile docs/reference/windows-edr-posture.md, which documents the rename as a
live finding and would otherwise contradict this change. Content-only edit:
markdown under docs/reference/ is not oxfmt-formatted as a matter of practice and
nothing in CI gates it, so the file is left consistent with its neighbours.

* fix(windows): expand USERNAME in NSIS instead of spawning cmd.exe

The uninstall macro routed both taskkills through `"$SYSDIR\cmd.exe" /C` purely
so `%USERNAME%` would expand — two extra interpreter spawns on the uninstall
path, in a change whose whole point is not adding scored behaviour, and the
exact `cmd.exe /c` shape the new AGENTS.md EDR bullet warns about. NSIS reads
the variable itself with ReadEnvStr, so the spawns buy nothing.

Verified on Windows 11 that the generated command line does what the filter is
there for: a copy of cmd.exe running as orca-nonexistent-probe.exe (pid 34244)
was terminated by `taskkill /F /IM "orca-nonexistent-probe.exe" /FI "USERNAME eq
<user>"` — SUCCESS, exit 0, process gone.

Guarded on an empty USERNAME because the degenerate case is silent: taskkill
rejects an empty filter value outright ("The search filter cannot be
recognized") and kills nothing, which would leave exactly the orphaned daemon
this macro exists to reap. `*` is rejected as a filter value too, so there is no
branchless spelling. With no USERNAME to scope by it kills unfiltered, as the
macro did before the filter was added. Stack stays balanced: three pushes, two
nsExec pops, three restores.

Also strike the last stale row in windows-edr-posture.md's remediation table.
"Copying our own image under a different name" read as outstanding work; it is
done by this change, so the row now points at the relocation doc. Same class of
staleness as the section reconciled in the previous commit, and git would not
have flagged it either.

* fix(windows): port the daemon-host uninstall sweep into the live NSIS include

The uninstall macro this branch rewrote lived in config/nsis/daemon-host-uninstall.nsh,
which main no longer includes: #17906 consolidated every Windows installer hook into
config/nsis/orca-installer-hooks.nsh because electron-builder accepts exactly one
`nsis.include`. Merged as-is, the rewritten macro would have been dead code while the
shipped uninstaller kept running main's stale sweep — `taskkill /F /IM
orca-terminal-daemon.exe`, which matches nothing now that the relocated host is a
verbatim Orca.exe copy. The RMDir that follows then cannot delete the running image, so
a live orphaned daemon and its ~224 MB tree would survive every uninstall.

Ported into the live include: the ${APP_EXECUTABLE_FILENAME} kill, the USERNAME filter
that keeps an elevated machine-wide uninstall out of another logged-on user's session,
and the register save/restore around both. The legacy orca-terminal-daemon.exe kill
stays so hosts left by older builds are still reaped.

The ratchet that was meant to catch exactly this pinned only the legacy image name,
which main's stale macro already satisfied, so it passed both ways. It now asserts the
app-exe kill and the USERNAME filter, against comment-stripped script — the prose above
the macro names both image names, so a toContain over the raw file proves nothing.

---------

Co-authored-by: Orca Worker <orca-worker@localhost>

2026-09-05 21:11:28 -07:00

6.7 KiB

Raw Permalink Blame History

win-crash-survival-e2e — packaged crash-survival proof harness

Windows only. Proves that a crash of Orca's main process does not orphan open terminal PTYs — the regression behind GitHub #7742 — with machine-checkable assertions against an already-installed, packaged Orca.exe.

Why this exists

On Windows, when Orca's main/renderer process crashed, open terminal PTYs were orphaned and PowerShell hard-crashed with a 0xE9 "No process is on the other end of the pipe" FailFast. Root cause: the terminal daemon (which hosts the ConPTYs) died together with the main process, severing the console pipe.

The fix re-architected the daemon into a standalone daemon host relocated out of the install dir (see src/main/daemon/daemon-host-relocation.ts) that is spawned detached and survives main-process death.

There is already a harness proving the daemon survives a Windows update (tests/tools/win-update-e2e). This harness proves the daemon survives a crash of the main process, so that guarantee can't silently regress. It reuses win-update-e2e's shared modules (app driver, daemon discovery, onboarding seed, PowerShell runner, platform guard, table renderer) and adds only the crash step + its assertions.

What it does

Launch the installed Orca.exe under an isolated userData dir (ORCA_E2E_USER_DATA_DIR), seeded with a fresh profile (onboarding dismissed plus one throwaway git repo), then open a plain terminal tab (the seeded workspace opens an agent tab, not a bare shell).
Stamp the interactive shell — typing DIRECTLY into it (not a nested powershell), set a per-shell env sentinel ORCA_CRASH_SENTINEL=<canary> and record the shell's own $PID. The command finishes fast, leaving the shell idle at a live PSReadLine prompt — the exact state that FailFasts with 0xE9 on a broken build.
Record the daemon PID and the real Electron main PID (resolved via app.evaluate(() => process.pid) — the launched instance's own main, not the launcher stub app.process() returns, and not a machine-wide scan).
Crash — taskkill /F /PID <real-main-pid> with no /T and no graceful close. This kills ONLY the real main of the instance this harness launched, never a scanned or image-named process, and never the process tree — a real crash does not tree-kill the detached daemon. Then prove the crash landed (poll the main PID until dead).
Assert survival: the daemon PID and the same interactive shell PID are still alive after the crash soak.
Relaunch (same userData, no reseed) and assert the daemon PID is unchanged (the new main adopts the surviving daemon instead of forking a new one) and that the reattached UI is bound to the same survivor shell — a bounded, readiness-aware command on the exact restored tab reads back both ORCA_CRASH_SENTINEL and the shell's $PID, which a freshly re-spawned shell would not carry.
Scan the full crash-to-input window and require the Windows Application event log to contain zero pwsh FailFast / 0xE9 events (matched by crash-reporter provider+id, not fragile Message text). Scanning after the reattach keystroke catches shells that fail only on their next console read.
Teardown — close the relaunched app, then kill this run's scoped daemon tree (re-discovered fresh via findDaemonProcesses(userData), which the surviving shell is a descendant of) and remove the temp profile. It never kills a PID captured earlier in the run (a recycled PID could hit an innocent process), never installs/uninstalls, and never touches any other Orca on the box.

Exit code is 0 when every non-informational assertion passes, else 1 (2 for a CLI usage error).

Usage

pnpm win-crash-survival-e2e --expect survival
# or explicitly point at an installed exe:
node tests/tools/win-crash-survival-e2e/run.mjs --expect survival --exe-path "C:\Users\<you>\AppData\Local\Programs\orca\Orca.exe"

Flags

Flag	Meaning
`--expect <profile>`	Assertion profile (required): `survival` or `orphaned` (see below)
`--exe-path <path>`	Installed `Orca.exe` to drive (default: per-user install under `%LOCALAPPDATA%\Programs\Orca`)
`--soak-seconds <n>`	Post-crash observation window before relaunch (default `8`)
`--keep-profile`	Skip temp-profile cleanup (debugging)

Profiles

survival — the fixed behavior and the baseline that must keep passing: the main crash actually lands, yet the daemon + the same interactive shell PID survive, zero pwsh FailFast events fire, a relaunch adopts the same daemon PID, and the reattached UI reads back the survivor shell's env sentinel.
orphaned — the directional inverse describing the old broken #7742 behavior. Daemon death is the primary signal (deterministic); pwsh FailFast / 0xE9 is secondary — faithful only because the shell is left idle at a live PSReadLine prompt (which queries the severed console). On a fixed build this profile is expected to fail, proving the survival assertions are not vacuous. It is not exercised in CI (workflow_dispatch is unavailable on a non-default branch) and the 0xE9 only reproduces on a genuinely broken build.

Safety

Never installs, updates, or uninstalls anything — it only launches an existing exe against an isolated userData dir.
The crash kills only the real Electron main of the instance this harness launched — resolved via app.evaluate(() => process.pid) (not the launcher stub app.process() returns) — /F with no /T. It never taskkills by image name or a scanned pid, so a developer's live Orca (a different userData, out of scope) is untouched.
Teardown never kills a PID captured earlier in the run (a recycled PID could hit an innocent process): daemon cleanup re-discovers this run's daemon fresh via a userData-scoped findDaemonProcesses, and the surviving shell is torn down as a descendant of that daemon tree.
Daemon discovery is scoped to this run's userData path, so it never matches the many other daemons a dev box or CI runner can host.
Windows-only (assertWin32); it no-ops with a clear error off win32.

6.7 KiB Raw Permalink Blame History