T06 · System Persistence
Warning
- Location
- SKILL.md:229
- Finding
- Persistent Cron Jobs Execute Mutable Project Code Without Hardening<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 229–234 **Vulnerability Type**: Persistent scheduled execution **Risk Level**: Medium ### Vulnerable Code ```bash crontab -e # Add: */30 * * * * cd /path/to/my-ai-company && python main.py --task discover_opportunities 0 9 * * * cd /path/to/my-ai-company && python main.py --task daily_optimization */15 * * * * cd /path/to/my-ai-company && python main.py --task health_check ``` ### Technical Analysis The Skill instructs users to install three cron entries that survive completion of the current Skill session and repeatedly execute `main.py` from a potentially user-writable project directory. Scheduled execution is related to the declared 24/7 automation objective, but it is not required for project initialization or demonstration. It materially expands the execution lifetime and risk boundary of the Skill. The commands use the generic `python` executable resolved through the cron environment and do not pin the script or interpreter to integrity-controlled absolute paths. The supplied generated `main.py` does not implement the documented `--task` interface. Consequently, the cron configuration is not functional with the provided scaffold and introduces persistence before a complete, reviewed scheduler implementation exists. ### Attack Path 1. A user follows the instructions and installs the three cron entries. 2. The entries remain active across terminal sessions and system restarts where cron is enabled. 3. The project directory, `main.py`, an imported local module, or an executable selected through environment resolution is subsequently modified or compromised. 4. Cron invokes the modified code without an interactive approval step. 5. The substituted code executes repeatedly with the permissions and environment available to the account that owns the crontab. ### Impact Assessment Successful exploitation could provide repeated code execution under the affected user account. The acc ...[truncated 421 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not install cron entries during initialization or demonstration. Make scheduling a separate, explicit opt-in production step. 2. Implement and test the documented `--task` interface before recommending scheduled execution. 3. Use absolute paths for both the virtual-environment interpreter and the script: ```bash /opt/my-ai-company/.venv/bin/python /opt/my-ai-company/main.py --task health_check ``` 4. Run scheduled jobs through a dedicated, least-privileged service account without interactive login or unrelated file access. 5. Store executable project files in a deployment directory that is not writable by untrusted processes. 6. Provide a restricted environment file containing only the credentials required by each task. 7. Add concurrency locks, timeouts, resource limits, rate limits, structured logging, and failure notifications. 8. Require human approval for external posting, code deployment, financial operations, and other high-impact actions. 9. Document exact removal commands, such as deleting the installed crontab entries, and provide a scheduler-disable procedure. 10. Consider a hardened service manager with explicit sandboxing instead of raw crontab entries. ]]>