T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/backup.sh:4
- Finding
- Sensitive credential backups are created without enforced access controls## Vulnerability Details **File Location**: `scripts/backup.sh`, lines 4–11 **Vulnerability Type**: Sensitive data exposure through insecure file permissions **Risk Level**: High ```bash BACKUP_DIR="${1:-$HOME/openclaw-backups}" DATE=$(date +%Y-%m-%d_%H%M) BACKUP_FILE="$BACKUP_DIR/openclaw-$DATE.tar.gz" mkdir -p "$BACKUP_DIR" # Create backup (exclude completions cache and logs) tar -czf "$BACKUP_FILE" \ --exclude='completions' \ ``` ### Technical Analysis The script archives the user's complete `.openclaw` directory. According to `SKILL.md`, this includes API keys, tokens, authentication profiles, Telegram session data, agent state, user files, and scheduled tasks. Neither the backup directory nor the generated archive is assigned an explicit restrictive permission mode. The script does not set a secure `umask`, use `mkdir` with mode `700`, or apply mode `600` to the archive. Consequently, actual permissions depend on the caller's inherited environment and the permissions of an existing destination directory. If the script runs with a permissive `umask`, or if the caller supplies a shared or inadequately protected backup directory, another local user may be able to list or read the unencrypted archive. The archive itself is compressed but not encrypted, so compression provides no confidentiality. ### Attack Path 1. A user or automated task invokes `backup.sh` under a permissive `umask`, or specifies an inadequately protected shared directory as `backup_dir`. 2. The script creates the directory and archive without enforcing owner-only permissions. 3. Another local account discovers the generated `openclaw-*.tar.gz` file. 4. That account reads and extracts the archive. 5. The attacker obtains credentials, API tokens, Telegram session material, configuration, agent state, and user workspace data. Exploitation requires local access and effective read permission to the generated archive; the script does not ...[truncated 611 chars]
- Remediation
- ## Remediation Suggestions - Set `umask 077` at the beginning of the script, before creating the destination directory or archive. - Create the destination with `mkdir -p -m 700 -- "$BACKUP_DIR"` and explicitly enforce `chmod 700 -- "$BACKUP_DIR"` when appropriate. - Create the archive with owner-only access and run `chmod 600 -- "$BACKUP_FILE"` after successful creation. - Validate that the destination is a directory owned by the current effective user and is not a symbolic link or an unexpectedly shared location. - Refuse destinations that are group-writable or world-writable unless an explicit secure-use policy supports them. - Consider authenticated encryption for archives because they contain long-lived credentials and session data. Encryption keys should be stored separately from the backups. - Write to a securely created temporary file in the destination, verify successful archive creation, apply permissions, and then atomically rename it to the final filename.