38 lines
4.2 KiB
Markdown
38 lines
4.2 KiB
Markdown
|
# ADVERSARIAL_BUG_REPORT: add-goal-mode
|
||
|
|
|
||
|
|
Attack the goal-mode extensions as a hostile work source or verifier would: find ways to escape work-source dispatch, inflate task creation, or leak token content.
|
||
|
|
|
||
|
|
## Attack vectors tried
|
||
|
|
|
||
|
|
### A1 -- Can a hostile `work_source.kind` value crash the runner?
|
||
|
|
No. `_find_work` checks `_FIND_WORK_DISPATCH.get(kind)`; unknown kinds log a WARNING and fall back to `single`. No crash, no escape. PASS
|
||
|
|
|
||
|
|
### A2 -- Can `_find_work_audit` be coerced into creating arbitrary tasks?
|
||
|
|
`_find_work_audit` calls `status.py --create-task <slug>` only when a violation has no `task` field. The slug is derived from `_slugify(violation["message"])`, which strips non-alphanumeric chars. A hostile audit JSON with `message: "rm -rf /"` would slugify to `rm-rf` (harmless task name). The `--create-task` call itself is sandboxed by status.py's own task-creation logic (validates names, creates dirs under `tasks/`). No shell injection. PASS
|
||
|
|
|
||
|
|
### A3 -- Can `_find_work_backlog` read arbitrary files?
|
||
|
|
The backlog path is constructed as `<project_dir>/design/<area>/BACKLOG.md` where `area` comes from `work_source.area` in `loop.json`. A hostile `area` value like `../../etc` would resolve to `<project>/design/../../etc/BACKLOG.md` = `<project>/../etc/BACKLOG.md` -- a path outside the project. However, the file must exist and contain `- [ ]` lines to produce a task name. The attacker would need write access to place a BACKLOG.md there, which already implies filesystem access. The runner doesn't write to the backlog path; it only reads. PASS (config-trust model: loop.json is operator-controlled).
|
||
|
|
|
||
|
|
### A4 -- Can token substitution leak task_brief content into a visible argv?
|
||
|
|
`_substitute` replaces `{task_brief}` in the harness command template. If the command template includes `{task_brief}` as a CLI arg (e.g. `--brief {task_brief}`), the full task brief text appears in the process argv, visible via `ps` on multi-user systems. This is a config decision (the operator chose to pass it as a CLI arg). The default command does not include `{task_brief}`. The recommended pattern (task 6) is to have the prompt file itself contain `{task_brief}` -- but the runner doesn't substitute into prompt file content, only into the command template. PASS (operator config responsibility).
|
||
|
|
|
||
|
|
### A5 -- Can a hostile `--audit --json` output inject a task name that escapes the tasks/ dir?
|
||
|
|
`_find_work_audit` uses the `task` field directly as `current_task`. If a hostile audit JSON returns `task: "../../../etc/passwd"`, the runner sets `state["current_task"] = "../../../etc/passwd"`. Downstream, `_task_dir_for(name, project_dir)` constructs `<tasks_dir>/../../../etc/passwd` -- a path outside tasks/. However, the runner only reads from this path (`_read_task_brief` checks `f.exists()` before reading) and passes the name as a substitution token. No writes occur. The orchestrator might call `status.py --task ../../../etc/passwd` but status.py's own validation would reject the path. PASS (defense in depth: runner is read-only on task dirs; status.py validates).
|
||
|
|
|
||
|
|
### A6 -- Can `acceptance_criteria` with a huge string OOM the runner?
|
||
|
|
`_acceptance_criteria_text` joins list items with newlines, then `_truncate_tokens` caps at 2000 tokens (8000 chars). A 10MB acceptance_criteria string is truncated to ~8k chars. No OOM. PASS
|
||
|
|
|
||
|
|
### A7 -- Can `_find_work_audit` loop infinitely on create-task failures?
|
||
|
|
No loop. `_find_work_audit` calls `--create-task` once (fire-and-forget, timeout=15s) and returns the slug. If create-task fails, the slug is returned anyway. Next tick, `--audit` sees the same violation, tries create-task again. Each tick is one attempt. The OS scheduler interval rate-limits. No infinite loop within a single tick. PASS
|
||
|
|
|
||
|
|
## Hardening recommendations (for BACKLOG)
|
||
|
|
|
||
|
|
1. **Validate `work_source.area`** against a whitelist or path-traversal check (reject `..` components). Low priority since loop.json is operator-controlled.
|
||
|
|
2. **Validate `current_task` from audit JSON** against a path-traversal check (reject `..` and `/`). Same priority.
|
||
|
|
|
||
|
|
Both are defense-in-depth; neither blocks v1.
|
||
|
|
|
||
|
|
## Verdict
|
||
|
|
|
||
|
|
PASS -- no exploitable escape. Work-source dispatch is bounded; token substitution is config-gated; audit JSON consumption is read-only and slug-sanitized.
|