T05 · Unauthorized Access and Privilege Escalation
Error
- Location
scripts/install_cron.sh:115- Finding
Root Cron Job Executes Mutable Code from the Original Project Directory
- Content
View full analysis
&2 exit 1 fi # ... { echo '#!/usr/bin/env bash' echo 'set -euo pipefail' echo 'export PATH="/root/.hermes/node/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"' printf 'source %s\n' "$(shell_quote "$ENV_FILE")" printf 'exec 9>%s\n' "$(shell_quote "/tmp/esa-acme-${WRAPPER_NAME}.lock")" echo 'flock -n 9 || exit 0' echo 'cd /root' printf 'python3 %s \\\n' "$(shell_quote "$SKILL_SCRIPT")" ``` ### Technical Analysis The installer must run as root and creates a root cron entry, but the generated root-owned wrapper continues to execute `esa_acme_issue.py` directly from the original project directory. The installer checks only that the file exists; it does not verify that the file and all parent directories are owned by root and are not writable by less-privileged users. Consequently, the security of the persistent root cron task depends on the ownership and permissions of the directory from which the installer was launched. If that directory is writable by a non-root account, that account can replace or modify the Python script after installation. The next scheduled invocation will execute the modified code as root. This persistence mechanism is explicitly documented and is legitimate for automatic certificate renewal. The vulnerability is not the presence of cron itself, but the failure to establish a trusted, immutable execution path across the privilege boundary. ### Attack Path 1. An administrator checks out or extracts the Skill into a directory owned ...[truncated 915 chars]- Remediation
View remediation