T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/script.sh:35
- Finding
- Plaintext Logging and Disclosure of Sensitive Command Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/script.sh:5-7`, `scripts/script.sh:35`, and `scripts/script.sh:59-69` **Vulnerability Type**: Sensitive data exposure through plaintext logging **Risk Level**: Medium ### Vulnerable Code ```bash DATA_DIR="${PRIVACY_POLICY_DIR:-${XDG_DATA_HOME:-$HOME/.local/share}/privacy-policy}" DB="$DATA_DIR/data.log" mkdir -p "$DATA_DIR" ``` ```bash _log() { echo "$(date '+%m-%d %H:%M') $1: $2" >> "$DATA_DIR/history.log"; } ``` ```bash cmd_encrypt() { echo " Encrypting: $1" _log "encrypt" "${1:-}" } cmd_hash() { echo "$1" | sha256sum | cut -d" " -f1 _log "hash" "${1:-}" } ``` ### Technical Analysis The `encrypt` and `hash` commands accept values that users may reasonably expect to be confidential, such as passwords, tokens, personal information, or encryption plaintext. Both commands pass the complete raw argument to `_log`, which appends it to the persistent `history.log` file without redaction. The `encrypt` command also prints the supplied value to standard output and does not perform encryption. Consequently, sensitive input can be exposed through both terminal output and persistent command history. The script creates the data directory without explicitly applying restrictive permissions. Its effective permissions depend on the invoking user's `umask` and any pre-existing directory or file permissions. The behavior is also not disclosed in the skill documentation. ### Attack Path 1. A user invokes a command with sensitive content, such as: ```bash privacy-policy hash "SensitivePassword" ``` or: ```bash privacy-policy encrypt "ConfidentialText" ``` 2. The command forwards the original argument to `_log`. 3. `_log` appends the unredacted value to: ```text $DATA_DIR/history.log ``` 4. For `encrypt`, the plaintext is additionally printed to the terminal. 5. A local process, user, backup system, diagnostic bundle, or support workflow capable of reading the ...[truncated 650 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Never log raw arguments supplied to cryptographic or security-related commands. 2. Restrict audit entries to non-sensitive metadata, such as the command name, timestamp, and success status: ```bash _log() { printf '%s %s\n' "$(date '+%m-%d %H:%M')" "$1" >> "$DATA_DIR/history.log" } ``` 3. Remove plaintext output from `cmd_encrypt`. 4. Remove the `encrypt` command unless genuine, authenticated encryption can be implemented using a reviewed cryptographic tool and an appropriate key-management design. 5. Apply restrictive permissions before creating storage: ```bash umask 077 mkdir -p -m 700 "$DATA_DIR" touch "$DATA_DIR/history.log" chmod 600 "$DATA_DIR/history.log" ``` 6. Prefer reading secrets from standard input without echoing rather than accepting them as command-line arguments, because command-line arguments may be visible in process listings or shell history. 7. Document all persistent logging behavior and provide a mechanism to disable or securely delete logs. 8. Add regression tests confirming that sensitive inputs never appear in standard output or `history.log`. ]]>
