T06 · System Persistence
Warning
- Location
- setup_cron.sh:20
- Finding
- User-Level Persistence Through a Recurring Cron Job<![CDATA[ ## Vulnerability Details **File Location**: `setup_cron.sh:20-49` **Vulnerability Type**: Scheduled-task persistence **Risk Level**: Medium ### Vulnerable Code ```bash SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" CRON_JOB="0 7 * * * $SCRIPT_DIR/daily_update.sh >> $HOME/.cache/runstr-analytics/cron.log 2>&1" # Check if cron job already exists if crontab -l 2>/dev/null | grep -q "runstr-analytics/daily_update.sh"; then echo "⚠️ Cron job already exists." echo "" echo "Current crontab entry:" crontab -l | grep "runstr-analytics" echo "" read -p "Replace existing job? (y/N): " REPLACE if [[ $REPLACE =~ ^[Yy]$ ]]; then # Remove old entry crontab -l 2>/dev/null | grep -v "runstr-analytics/daily_update.sh" | crontab - echo "Old job removed." else echo "Setup cancelled." exit 0 fi fi # Add new cron job (crontab -l 2>/dev/null; echo "$CRON_JOB") | crontab - ``` ### Technical Analysis The setup script modifies the current user's crontab and registers `daily_update.sh` to execute every day at 07:00. This creates execution that survives the current Skill invocation and user session, meeting the definition of system persistence. The behavior is disclosed, supports the declared optional automated-update feature, and requires interactive confirmation before installation. It is therefore not covert. Nevertheless, scheduled execution exceeds the privileges needed for one-shot fitness analysis and expands the security boundary from an explicitly invoked program to persistent background execution. The cron entry references the project script by path rather than an immutable, integrity-checked installed artifact. Any future modification or replacement of `daily_update.sh` at that path will affect what cron executes. The command also does not quote the script and log paths for cron, which may cause incorrect interpretation when installation paths contain spaces or shell meta ...[truncated 1102 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Keep scheduling strictly optional and separate it from the core analytics installation. 2. Display the exact cron expression and command before requesting consent. 3. Install the executable into a user-owned directory with restrictive permissions rather than referencing a mutable project checkout. 4. Quote or safely escape all paths used in the cron command. 5. Verify ownership and permissions of the target script before registration and before each execution. 6. Provide a dedicated uninstall command that removes only the exact entry created by the Skill. 7. Prefer a user-level service manager with explicit enable, disable, status, and logging controls where supported. 8. Consider generating reports only on explicit invocation, which is the minimum-privilege design for the core analytics functionality. ]]>