T06 · System Persistence
- Location
SKILL.md:59- Finding
Persistent Daily Execution Through User Crontab Modification
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 59–63
Vulnerability Type: Persistent scheduled task installation
Risk Level: HighVulnerable Code
bash ### 3. Set up Cron # Run daily at 23:00 crontab -l | { cat; echo "0 23 * * * /path/to/send_lyrics.py >> /path/to/log.txt 2>&1"; } | crontab -Technical Analysis
The setup instructions append a scheduled task to the current user's crontab. The task survives the initiating session and executes
send_lyrics.pyautomatically every day at 23:00 without requiring further confirmation.Scheduling is related to the declared daily-reminder functionality. Nevertheless, direct modification of persistent system state carries elevated risk and must be explicitly authorized, reversible, and idempotent. The supplied command does not check whether the entry already exists, so running it repeatedly can create duplicate tasks and duplicate outbound messages.
The scheduled command also relies on unspecified absolute paths. If the script path or its parent directory is writable by another account or process, later replacement of the script could cause cron to execute attacker-controlled code with the privileges of the user who installed the task.
Attack Path
- A user follows the setup instructions and runs the supplied
crontabcommand. - The command copies the existing crontab and appends the new daily entry.
- The cron service executes the referenced script every day under the installing user's account.
- The script performs browser and SMTP network operations without interactive approval.
- If the referenced script is subsequently modified or replaced, the modified code is executed automatically at the next scheduled interval.
- Repeating the setup command creates additional entries, potentially causing repeated emails and excess network activity.
Impact Assessment
This establishes cross-session persistence unde ...[truncated 330 chars]
- A user follows the setup instructions and runs the supplied
- Remediation
View remediation
Remediation Suggestions
- Make scheduling an explicit, separate opt-in step rather than a default installation action.
- Display the exact command, execution identity, network behavior, and destination before requesting approval.
- Use an idempotent installer that checks for an existing uniquely marked entry before adding one.
- Provide documented status and uninstall commands that remove only this Skill's entry.
- Use an absolute script path in a user-owned directory that is not writable by other users.
- Use a dedicated least-privileged account where practical.
- Restrict permissions on the script, configuration, and log files.
- Avoid logging secrets or full message contents, and configure log rotation.
- Consider an application-level scheduler that requires explicit user activation and exposes a visible disable control.
