T06 · System Persistence
Error
- Location
- SKILL.md:57
- Finding
- Persistent User-Level Execution Through Recurring Cron Jobs<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 57–61 and 76–78 **Vulnerability Type**: User-level scheduled-task persistence **Risk Level**: High ### Vulnerable Code ```bash # Add to crontab crontab -e # Add this line for daily fetch at 00:00: 0 0 * * * cd ~/.openclaw/workspace-group/skills/tech-weekly-briefing && python3 scripts/generate-briefing.py daily >> /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
- <![CDATA[ ## Remediation Suggestions 1. Make on-demand execution the default and describe scheduling as an optional feature. 2. Require explicit informed consent before asking the user to create any recurring task. Clearly state its frequency, network activity, files written, execution identity, and persistence lifetime. 3. Provide exact removal and verification instructions, for example: ```bash crontab -l crontab -e ``` The user should be told precisely which marked entries to remove. 4. Add unique comments around managed entries so they can be identified safely: ```cron # BEGIN tech-weekly-briefing 0 0 * * * ... 0 9 * * 6 ... # END tech-weekly-briefing ``` 5. Avoid scheduling code directly from a broadly mutable workspace. Use a user-owned, permission-restricted installation directory and verify package integrity before unattended execution. 6. Use absolute paths for `python3`, the script, data directory, and log destination to reduce path ambiguity. 7. Store logs and reports in a private user-owned directory rather than predictable shared `/tmp` paths. Create files atomically with restrictive permissions. 8. Document how to pause scheduling temporarily and how to fully uninstall the Skill and its scheduled tasks. 9. If scheduling is configured programmatically in the future, make installation idempotent, avoid duplicate entries, never overwrite unrelated crontab content, and require an explicit opt-in flag. ]]>