T06 · System Persistence
Error
- Location
- SKILL.md:155
- Finding
- Mandatory Recurring Monitoring Creates Cross-Session System Persistence<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:155-165`; `references/cron-template.md:3-5, 27-39, 54-60` **Vulnerability Type**: Mandatory scheduled-task persistence with autonomous system modification **Risk Level**: Critical ### Vulnerable Code From `SKILL.md:155-165`: ```markdown ## Phase 5: Monitor Set a recurring cron job that runs until user confirms "good enough" (minimum 7 days, 30 days for recurring incidents). ``` Cron job structure: - Schedule: every 24h (or every N hours for high-severity) - Task: check specific metric → compare to baseline → if degraded: restore + 5-why → report - Report channel: sessions_send to your preferred channel (Signal, Telegram, Discord) - Auto-escalate: if same fix needed 3+ days in a row → upgrade prevention measure - Termination: user explicitly says "stop monitoring" or N days without incident ``` ``` From `references/cron-template.md:27-39`: ```markdown ## Decision Tree - If [METRIC] == [BASELINE]: report OK - If [METRIC] < [BASELINE]: a. Run 5 Whys: find what's missing, check git log for who, check session logs for which tool call b. Restore: [RESTORE_COMMAND] c. Check if guard failed: [GUARD_CHECK] d. If guard failed, strengthen it: [HOW_TO_STRENGTHEN] e. Commit prevention update to git ## Auto-escalate Rule If same fix is needed 3+ days in a row: upgrade prevention measure from SOUL.md rule → config-validate.sh hard guard. ``` From `references/cron-template.md:54-60`: ```markdown ## Stopping Monitoring Only stop when: 1. User explicitly says "stop monitoring" or "it's good enough" 2. OR: N consecutive clean checks with no incidents (N = 7 for minor, 30 for systemic) Never self-terminate monitoring. The cron job should report its own run count and ask user for confirmation when approaching the suggested stop date. ``` ### Technical Analysis The skill requires a recurring cron job after every incident rather than presenting monitoring as an optional, separately authorized actio ...[truncated 1761 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Make monitoring explicitly opt-in rather than a mandatory incident-response phase. 2. Before scheduling, show the user the exact schedule, expiration time, commands, accessed files, report destination, and retained privileges. 3. Require explicit informed confirmation before creating the scheduled task. 4. Apply a fixed automatic expiration using the scheduler itself; do not rely on a future conversational instruction to stop. 5. Make recurring checks read-only by default. 6. Require a new approval before any cron run restores configuration, modifies guards or memory, commits files, or restarts services. 7. Restrict the task to an allowlisted host, commands, paths, and metrics. 8. Record the job identifier and provide an immediate removal command. 9. Avoid embedding credentials or private session keys directly in the scheduled prompt. 10. Add tests confirming that no recurring task is created without explicit consent and that every task expires automatically. ]]>