T06 · System Persistence
- Location
install.sh:64- Finding
Cross-Session Execution Through Scheduled Tasks and System Services
- Content
View full analysis
> logs/cron.log 2>&1" # Add the job to the current user's crontab (crontab -l 2>/dev/null | grep -v "news-brief.js"; echo "$CRON_JOB") | crontab - ``` The installer also generates the following optional systemd service: ```ini [Service] Type=simple User=$USER WorkingDirectory=$(pwd) ExecStart=/usr/bin/node $(pwd)/news-brief.js --setup-cron Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target ``` ### Technical Analysis The installer modifies the current user's crontab to execute the Skill every day. It can also generate a systemd unit that the documentation instructs the user to copy into `/etc/systemd/system`, enable, and start with elevated privileges. Daily scheduling is consistent with the declared news-brief functionality, and the installer asks for confirmation before configuring it. Nevertheless, these mechanisms survive the current Skill run and cause code and dependencies from the project directory to execute later without renewed approval. The systemd option is especially excessive because it creates boot-level persistence while internally starting another scheduler through `--setup-cron`. The crontab replacement logic removes every existing crontab line containing `news-brief.js`, rather than identifying only a uniquely marked job owned by this installation. It may consequently alter unrelated scheduled tasks. ### Attack Path 1. A user runs `install.sh`. 2. The user accepts the scheduling prompt. 3. The installer rewrites the user's crontab and adds a daily command that executes `news-brief.js`. 4. Alternatively, the user follows the provided privileged systemd comman ...[truncated 1008 chars]- Remediation
View remediation
