T09 · Insecure Skill Coding Practices
Warning
- Location
- references/cli-examples.md:10
- Finding
- Secret Disclosure Through Plaintext CLI Output and Insecure File Export Examples<![CDATA[ ## Vulnerability Details **File Location**: `references/cli-examples.md:10-24`; related pane-capture workflow in `SKILL.md:42-57` **Vulnerability Type**: Plaintext sensitive-data exposure **Risk Level**: Medium ### Vulnerable Code ```bash ## Read - `op read op://app-prod/db/password` - `op read "op://app-prod/db/one-time password?attribute=otp"` - `op read "op://app-prod/ssh key/private key?ssh-format=openssh"` - `op read --out-file ./key.pem op://app-prod/server/ssh/key.pem` ## Run - `export DB_PASSWORD="op://app-prod/db/password"` - `op run --no-masking -- printenv DB_PASSWORD` - `op run --env-file="./.env" -- printenv DB_PASSWORD` ## Inject - `echo "db_password: {{ op://app-prod/db/password }}" | op inject` - `op inject -i config.yml.tpl -o config.yml` ``` The related workflow captures terminal contents: ```bash tmux -S "$SOCKET" capture-pane -p -J -t "$SESSION":0.0 -S -200 ``` ### Technical Analysis The examples instruct users or agents to retrieve passwords, one-time passwords, private keys, and rendered configuration directly into terminal output. The `--no-masking` option explicitly disables 1Password's output masking before `printenv` prints the resolved database password. This is especially unsafe in the context of the mandatory tmux workflow. A secret-producing command can place plaintext credentials in the tmux scrollback buffer, after which `capture-pane` can copy that content into tool output, an agent transcript, logs, or chat context. The file-output examples create `key.pem` and `config.yml` without requiring a private directory, a restrictive `umask`, explicit file permissions, or secure cleanup. Consequently, sensitive files may inherit permissions that are broader than intended. These examples conflict with the guardrails in `SKILL.md`, which state that secrets must not be pasted into logs, chat, or code and that `op run` or `op inject` should be preferred over writing secrets to disk. ### Attack Path 1. A user or age ...[truncated 1610 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the `--no-masking` option and all examples that print resolved secrets through `printenv`, `echo`, or direct `op read` output. 2. Demonstrate `op run` with a consumer process that uses the secret without displaying it, and explicitly warn against debug output that exposes environment variables. 3. Do not execute `tmux capture-pane` after any command that may emit secret material. Capture only authentication status or non-sensitive metadata, and clear tmux history before terminating the session. 4. Replace secret-bearing examples with non-executing placeholders or commands that verify success without returning secret values. 5. Prefer in-memory secret delivery through `op run` over file creation. 6. If disk output is unavoidable: - Create a private directory owned by the current user. - Set `umask 077` before creating files. - Require permissions such as `chmod 600`. - Avoid predictable shared paths. - Delete the file securely as soon as it is no longer needed. 7. Add an explicit warning that OTPs, private keys, passwords, rendered templates, and secret-bearing environment variables must never be included in terminal captures, logs, transcripts, or chat output. ]]>