T09 · Insecure Skill Coding Practices
- Location
scripts/install-cron.sh:16- Finding
Persistent command injection through an unvalidated cron schedule
- Content
View full analysis
/dev/null | grep -v "github-backup.sh") | crontab - # Add the new entry (crontab -l 2>/dev/null; echo "$SCHEDULE $BACKUP_SCRIPT >> $LOG_FILE 2>&1") | crontab - echo "cron task installed: $SCHEDULE" ``` ### Technical Analysis The `schedule` property is read from `.backup-config.json` using `grep` and `sed`, then inserted directly at the beginning of a crontab entry. The installer does not verify that the value contains exactly five valid cron timing fields. A crontab entry treats everything after the five schedule fields as the command to execute. Consequently, a value containing five timing fields followed by an attacker-selected command changes the effective command registered by the installer. For example, a schedule conceptually equivalent to the following would cause the injected command to become the cron command: ```text * * * * * attacker-command # ``` The fixed backup script path appended by the installer would be commented out. This is not shell evaluation during installation; it is injection into the syntax of the generated crontab, which cron subsequently interprets and executes. Exploitation requires an attacker to modify the configuration file or induce the user or Agent to create a malicious `schedule` value and then run the documented installer. ### Attack Path 1. The attacker gains influence over `~/.openclaw/workspace/.backup-config.json`, such as through a malicious workspace file, repository content, or deceptive setup instructions. 2. The attacker sets `schedule` to five valid cron fields followed by an arbitrary shell command and a comment marker. 3. The user invokes `scrip ...[truncated 819 chars]- Remediation
View remediation
