Files
automaton/tasks/complete/add-goal-mode/ADVERSARIAL_BUG_REPORT.md
T
Lap Tran 4a2301b077
CI / build (push) Has been cancelled
Archive completed tasks, add cleanup commands, self-documenting dashboard UI
- Archive 79 completed framework-dev tasks from tasks/ -> tasks/complete/
- status.py: add --cleanup-done and --install-cleanup-schedule commands
- Add scripts/automaton-cleanup.sh for periodic task archiving
- Dashboard: rename 'Background' tab -> 'Agent', 'Cleanup' agent -> 'Completed Task Archiver', remove redundant group headers and pill badges, dim inactive agent placeholders
- .rules.md: add Self-Documenting UI Names rule
- New tests: test_cleanup_done.py, expanded test_app.py and test_task.py
2026-06-24 22:43:33 -04:00

4.2 KiB

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.