T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/script.sh:284
- Finding
- Plaintext History Log Injection and Terminal Escape Replay<![CDATA[ ## Vulnerability Details **File Location**: `scripts/script.sh:5-6`, `scripts/script.sh:72`, `scripts/script.sh:89`, `scripts/script.sh:284`, and `scripts/script.sh:290` **Vulnerability Type**: Unsanitized persistent logging of user-controlled input **Risk Level**: Medium ### Vulnerable Code ```bash DATA_DIR="${EXCEL_DIR:-${XDG_DATA_HOME:-$HOME/.local/share}/excel-formula}" mkdir -p "$DATA_DIR" ``` ```bash _log "find" "$kw ($found results)" ``` ```bash _log "explain" "${formula:0:30}" ``` ```bash _log() { echo "$(date '+%m-%d %H:%M') $1: $2" >> "$DATA_DIR/history.log"; } ``` ```bash history) [ -f "$DATA_DIR/history.log" ] && tail -20 "$DATA_DIR/history.log" || echo "No history" ;; ``` ### Technical Analysis The `find` keyword and the first 30 characters of an `explain` formula are passed directly to `_log`. The logging function writes these user-controlled values to `history.log` without removing newlines, carriage returns, ANSI terminal escape sequences, or other control characters. An input containing newline characters can create forged history entries. An input containing ANSI control sequences remains in the persistent log and is later emitted unchanged by `tail` when the `history` command is invoked. A compatible terminal may interpret those bytes as display-control instructions. The history file also stores formula fragments in plaintext. The data directory and file are created using permissions determined by the process umask rather than explicit restrictive modes. Under a permissive or common shared-host configuration, another local account may be able to read logged spreadsheet formulas or business-related search terms. This issue does not provide shell command execution because the logged data is not evaluated as shell syntax. Its practical effects are persistent log corruption, terminal-output manipulation, and potential local information disclosure. ### Attack Path 1. An attacker or untrusted automation supplies a crafted arg ...[truncated 1380 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Create the application directory and history file with explicit restrictive permissions: ```bash umask 077 mkdir -p -- "$DATA_DIR" chmod 700 -- "$DATA_DIR" touch -- "$DATA_DIR/history.log" chmod 600 -- "$DATA_DIR/history.log" ``` 2. Sanitize logged values by rejecting or escaping carriage returns, newlines, ANSI escape bytes, and non-printable control characters. 3. Store each event using an unambiguous structured format, such as JSON Lines, with a serializer that safely escapes control characters. 4. Escape values before rendering them to a terminal. For a shell-oriented representation, `printf '%q'` can prevent raw control bytes from being replayed: ```bash _log() { local action="$1" local value="$2" printf '%s %q: %q\n' \ "$(date '+%m-%d %H:%M')" \ "$action" \ "$value" >> "$DATA_DIR/history.log" } ``` 5. Avoid storing complete user formulas where possible. Store only non-sensitive metadata, redact cell values, or make history logging opt-in. 6. Use `printf` instead of `echo` for predictable behavior across shell implementations. 7. Add tests covering embedded newlines, carriage returns, ANSI escape sequences, Unicode control characters, and permissive umask configurations. ]]>