T06 · System Persistence
- Location
install.sh:52- Finding
Installer creates privileged and recurring persistence without explicit opt-in
- Content
View full analysis
/dev/null; then sudo systemctl enable syncthing@claw sudo systemctl start syncthing@claw fi ``` ```bash if ! crontab -l 2>/dev/null | grep -q "auto-commit-memory.sh"; then (crontab -l 2>/dev/null; echo "*/30 * * * * $SKILL_DIR/scripts/auto-commit-memory.sh >> $LOG_FILE 2>&1") | crontab - fi ``` Related startup behavior: ```bash if systemctl is-active --quiet syncthing@claw 2>/dev/null; then echo "Syncthing is already running" else sudo systemctl start syncthing@claw sleep 2 fi ``` ### Technical Analysis The installer enables a system-level Syncthing service and adds a user cron entry that runs every 30 minutes. These changes survive the installation process and future interactive sessions. Enabling a service with `sudo` crosses a privilege boundary and affects system startup behavior. Continuous synchronization is related to an advertised optional feature, but it is not required for local memory indexing, searching, tagging, or graph generation. The installer does not request explicit consent for either persistence mechanism, offer a local-only installation mode, validate the service configuration, or provide an uninstall routine. The cron entry invokes a script from a writable workspace path. If that script or any parent path becomes attacker-controlled, the persistent scheduler becomes a recurring code-execution mechanism under the affected user account. ### Attack Path 1. A user runs `install.sh` expecting the memory Skill to be installed. 2. The script invokes `sudo systemctl enable syncthing@claw`, causing Syncthing to start automatically in future boots. 3. The script adds `auto-commit-memory.sh` to the user's ...[truncated 663 chars]- Remediation
View remediation
