T09 · Insecure Skill Coding Practices
- Location
scripts/check-reboot.sh:4- Finding
Unrestricted State Paths and Symbolic-Link Following Permit File Deletion or Clobbering
- Content
View full analysis
"$STATE_FILE" echo "$CURRENT_BOOT | first_recorded" >> "$HISTORY_FILE" ``` ```bash echo "$CURRENT_BOOT_TS" > "$STATE_FILE" echo "$CURRENT_BOOT | reboot_detected" >> "$HISTORY_FILE" ``` ### Technical Analysis The script accepts an unrestricted state-file path through the `STATE_FILE` environment variable or the `--state` option. It subsequently passes that path to `rm -f` during reset and uses shell redirection to overwrite it during initialization or reboot detection. The history-file path is similarly controllable through `HISTORY_FILE` and is opened in append mode. Neither path is validated for ownership, file type, symbolic-link status, or containment within a trusted directory. Shell redirection and `rm` follow or operate on the supplied filesystem path without these safeguards. Consequently: - `--reset` can delete any file that the executing account is permitted to remove. - State updates can truncate and replace the contents of an existing target. - State or history files pre-created as symbolic links can redirect writes to another file. - If the script runs from cron or another privileged context while an attacker can influence its environment, arguments, home directory, or configured state directory, the operation occurs with that context's filesystem privileges. The script also does not set a restrictive `umask`, use atomic file replacement, or protect state updates against concurrent invocations. ### Attack Path A symbolic-l ...[truncated 2286 chars]- Remediation
View remediation
