28 lines
3.2 KiB
Markdown
28 lines
3.2 KiB
Markdown
# ADVERSARIAL_BUG_REPORT: add-blast-radius-scheduler
|
|||
|
|
|
||
|
|
Attack the worktree creation as a hostile environment would: escape blast radius, inject branch names, or corrupt state.
|
||
|
|
|
||
|
|
## Attack vectors tried
|
||
|
|
|
||
|
|
### A1 -- Can a hostile `loop.json` set `worktree_path` to an arbitrary location?
|
||
|
|
`_ensure_worktree` reads `state["worktree_path"]`, not `loop.json`. The state file is controlled by the framework (written via `_write_state_loop`). A hostile `loop.json` cannot set `worktree_path` directly. The worktree path is always constructed as `<loop_path>/worktree` by the runner. PASS
|
||
|
|
|
||
|
|
### A2 -- Can a hostile loop name create a branch outside the `loop/` namespace?
|
||
|
|
The branch name is `f"loop/{loop_name}"` where `loop_name` comes from `state.get("name")` or `loop_path.name`. The loop name is validated by `_is_kebab_case` in `status.py --create-loop` (rejects non-kebab-case names, including slashes). So the branch name is always `loop/<kebab-case-name>`. A hostile state file could set `name` to `../evil`, but `_write_state_loop` is only called by the framework. If the state file is manually edited, the attacker already has filesystem access. PASS (config-trust model).
|
||
|
|
|
||
|
|
### A3 -- Can `git worktree add` be coerced into writing outside the loop dir?
|
||
|
|
The worktree path is `<loop_path>/worktree` which is under `.automaton/loops/<name>/`. The `git worktree add` command receives this as an absolute path. Git creates the worktree at exactly that path. No path traversal possible because the path is constructed from `Path` objects, not string concatenation. PASS
|
||
|
|
|
||
|
|
### A4 -- Can a concurrent tick create two worktrees?
|
||
|
|
TOCTOU: two ticks both see `worktree_path is null`, both call `git worktree add <same-path>`. The second call fails because the path exists. The second tick falls back to project root. The first tick succeeds and records the worktree. No state corruption (atomic write; last-writer-wins, but the second write doesn't happen because the fallback path doesn't write state). Next tick: both see the worktree exists and reuse it. PASS (bounded by scheduler interval).
|
||
|
|
|
||
|
|
### A5 -- Can `git worktree add` execute arbitrary commands via the branch name?
|
||
|
|
The branch name is `loop/<kebab-case-name>`. It's passed as a separate argv element to `subprocess.run(["git", "worktree", "add", path, "-b", branch])`. No shell invocation (`shell=False` by default in `subprocess.run` with list args). A branch name starting with `-` would be interpreted as a git flag, but `_is_kebab_case` requires alphanumeric + hyphens + dots + underscores, and the `loop/` prefix ensures the branch never starts with `-`. PASS
|
||
|
|
|
||
|
|
### A6 -- Can a symlink at `<loop_path>/worktree` redirect file writes?
|
||
|
|
If an attacker creates a symlink from `<loop_path>/worktree` to `/etc`, `git worktree add` would fail (git refuses to use existing paths). If the attacker creates the symlink AFTER worktree creation but BEFORE the harness runs, the harness would write to the symlink target. But the attacker needs filesystem access to create the symlink, which already implies compromise. PASS (filesystem-trust model).
|
||
|
|
|
||
|
|
## Verdict
|
||
|
|
|
||
|
|
PASS -- no exploitable escape. Worktree creation is path-safe, branch-name-safe, and shell-injection-safe. TOCTOU is bounded by scheduler interval.
|