T06 · System Persistence
Error
- Location
- SKILL.md:37
- Finding
- Privileged Cross-Session Rollback Task Creates System Persistence<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 37-60 **Vulnerability Type**: System-level scheduled-task persistence **Risk Level**: High ### Vulnerable Code ```bash # Backup + set 5-min restore timer cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak echo "cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf && systemctl reload nginx" | at now + 5 minutes # Make your changes... vim /etc/nginx/nginx.conf systemctl reload nginx # If everything works, cancel the timer: atrm <job-id> ``` The Skill further specifies: ```text The restore timer is a system-level scheduled task (`at` / `crontab`). It does NOT depend on your shell session, SSH connection, or any application. Even if you brick the service, the timer still fires. ``` ### Technical Analysis The Skill explicitly instructs the Agent to register an `at` job that continues executing after the initiating shell, application, or SSH session ends. The scheduled command later overwrites an active service configuration and reloads the affected service. A delayed rollback is relevant to the declared recovery functionality, but the instructions apply broadly to nginx, SSH, firewall, DNS, proxy, and arbitrary service configurations. They do not require: - Validation or canonicalization of the target path. - An allowlist of permitted files or services. - Confirmation of the exact delayed command before registration. - Verification of the account under which the task will execute. - Reliable capture and storage of the scheduled job ID. - Verification that cancellation succeeded. - Secure backup permissions and cleanup. - Restrictions against substituting a persistent `crontab` entry. The mechanism does not independently obtain elevated privileges; it executes with the permissions of the account that registers the job. However, modifying files under `/etc` and reloading system services will commonly require root or equivalent administrative authority. When invoked with those privileges, ...[truncated 1952 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require explicit user confirmation before scheduling the task. Display the exact target file, backup path, service name, delayed command, execution account, and expiration time. 2. Restrict operation to an explicit allowlist of configuration paths and service units. Resolve canonical paths and reject symlinks, traversal, shell metacharacters, and unrecognized service names. 3. Use least privilege. Grant only narrowly scoped permission to copy the approved file and reload the corresponding service instead of running the entire workflow as unrestricted root. 4. Use a securely created backup file or directory with restrictive permissions, preserved ownership and mode, collision prevention, and deterministic cleanup. 5. Capture the `at` job ID programmatically, verify that the queued command matches the intended rollback, and return a reliable cancellation command. 6. After cancellation, verify through `atq` that the job no longer exists. Report failure prominently rather than assuming cancellation succeeded. 7. Avoid `crontab` for one-shot rollback. If it must be supported, require a bounded self-removing entry and verify its removal. 8. Validate the backup before restoration and test the configuration syntax before reloading the service. 9. Prefer service-specific rollback facilities or a narrowly scoped transient service with an explicit timeout, audit trail, and cleanup behavior. 10. Warn the user that losing the job ID or failing to cancel the task can revert valid changes and interrupt service. ]]>