T06 · System Persistence
- Location
SKILL.md:57- Finding
Persistent User-Level Execution Through Recurring Cron Jobs
- Content
View full analysis
> /tmp/tech-weekly-cron.log 2>&1 ``` ```bash # Every Saturday at 09:00 Beijing Time 0 9 * * 6 cd ~/.openclaw/workspace-group/skills/tech-weekly-briefing && python3 scripts/generate-briefing.py weekly >> /tmp/tech-weekly-cron.log 2>&1 ``` ### Technical Analysis The documentation instructs the user to modify their crontab and install two recurring tasks. These jobs survive the original Skill session and execute the Python script daily and weekly without requiring further interaction. Scheduled collection is consistent with the Skill's advertised automation feature, and the cron entries do not request root privileges. Nevertheless, persistent scheduling exceeds the minimum lifetime and privileges required to generate an on-demand briefing. The documentation does not clearly present persistence as an optional security-sensitive action, obtain explicit informed consent, provide an uninstall procedure, or offer a nonpersistent default. The jobs execute code from a mutable workspace path. If another process or future package update can replace `scripts/generate-briefing.py` or files imported by it, the changed code will subsequently run automatically under the account that owns the crontab. The current audited script does not contain such a malicious payload, but the persistent execution mechanism expands the impact of later file compromise. ### Attack Path 1. A user follows the Skill documentation and opens `crontab -e`. 2. The user installs the documented daily and weekly cron entries. 3. The entries remain active after the initiating session ends. 4. Cron periodically runs cod ...[truncated 1343 chars]- Remediation
View remediation
