Complete tasks 3-7: harden verdict parsing, outputs retention, base branch, linux schedule parity, claim loop task
CI / build (push) Has been cancelled
CI / build (push) Has been cancelled
This commit is contained in:
@@ -0,0 +1,48 @@
|
||||
# ADVERSARIAL_BUG_REPORT: add-self-improvement-loop
|
||||
|
||||
## Methodology
|
||||
|
||||
Targeted attack on:
|
||||
1. Shell injection via `$FRAMEWORK_DIR`
|
||||
2. Race condition between install.sh and update.sh
|
||||
3. Loop creation failure cascading to install failure
|
||||
4. Schedule installation on unsupported platforms
|
||||
5. Template path traversal
|
||||
|
||||
## Findings
|
||||
|
||||
### Attack 1: Shell injection via `$FRAMEWORK_DIR` -- NOT VULNERABLE
|
||||
|
||||
`$FRAMEWORK_DIR` is set to `$HOME/.automaton` at the top of both scripts. It is not derived from user input. The `--project "$FRAMEWORK_DIR"` argument is passed as a single quoted argument to `python3`, so no shell expansion occurs inside the Python process. No injection vector.
|
||||
|
||||
**Verdict:** NOT VULNERABLE
|
||||
|
||||
### Attack 2: Race condition between install.sh and update.sh -- NOT EXPLOITABLE
|
||||
|
||||
If a user runs `install.sh` and `update.sh` concurrently (which would be unusual), both might try to create the loop simultaneously. `--create-loop` checks `if loop_path.exists()` and returns rc=2 if it exists. The `mkdir(parents=True)` in `cmd_create_loop` is not atomic, but the `.state.loop` write is atomic (tmp+rename). Worst case: one script gets rc=2 and `|| true` swallows it. No data corruption.
|
||||
|
||||
**Verdict:** NOT EXPLOITABLE
|
||||
|
||||
### Attack 3: Loop creation failure cascading -- NOT VULNERABLE
|
||||
|
||||
Both `--create-loop` and `--install-schedule` are followed by `|| true`. If either fails, the script continues. The `.venv` setup and pip install at the end of `install.sh` are outside the `else` block and run regardless. The framework works without the loop.
|
||||
|
||||
**Verdict:** NOT VULNERABLE
|
||||
|
||||
### Attack 4: Schedule installation on unsupported platforms -- HANDLED
|
||||
|
||||
`--install-schedule` handles platform dispatch internally (Darwin -> launchd, Linux -> cron, Windows -> schtasks). On an unknown platform, it prints an error and returns non-zero, which `|| true` swallows. The loop is created but not scheduled; the user can manually run `--mode tick` or `--mode daemon`.
|
||||
|
||||
**Verdict:** HANDLED
|
||||
|
||||
### Attack 5: Template path traversal -- NOT VULNERABLE
|
||||
|
||||
`--from-template self-improvement` is a fixed string in both scripts. `cmd_create_loop` constructs the template path as `AUTOMATON_DIR / "templates" / "loops" / template`. The template name is not user-supplied in this context.
|
||||
|
||||
**Verdict:** NOT VULNERABLE
|
||||
|
||||
## Summary
|
||||
|
||||
No exploitable vulnerabilities found. All attack surfaces are mitigated by trusted input, `|| true` non-fatal behavior, and atomic state writes.
|
||||
|
||||
**Verdict: CLEAN**
|
||||
Reference in New Issue
Block a user