T09 · Insecure Skill Coding Practices
Warning
- Location
SKILL.md:16- Finding
Executable Credential File Enables Persistent Shell Command Injection
- Content
View full analysis
" > "$HOME/.config/placed/credentials" export PLACED_API_KEY= ``` ### Technical Analysis The Skill stores an API key as executable shell syntax and subsequently loads it using `source`. The `source` command does not parse the file as passive credential data; it executes every command in the file with the privileges of the Agent's operating-system user. This design creates two related injection paths: 1. Any local process or actor capable of modifying `~/.config/placed/credentials` can place arbitrary shell commands in it. 2. A user-provided value is interpolated into an unquoted shell assignment. If the supplied value contains shell syntax, such as command substitution, separators, redirections, or line breaks, the generated credential file can become executable attacker-controlled code. For example, a malicious value that results in the following stored content would execute its command whenever the file is sourced: ```bash export PLACED_API_KEY=$(attacker_controlled_command) ``` The creation procedure also relies on the ambient `umask` and does not explicitly set restrictive permissions on either the directory or credential file. Consequently, the plaintext bearer token may be readable by other local users or processes in some environments. Reading a credential is necessary for the declared API functionality, but executing a credential file and storing it without explicit access controls exceed the minimum privileges and behavior required. A non-executable d ...[truncated 1463 chars]- Remediation
View remediation
"$credential_file" chmod 600 "$credential_file" ``` 3. **Never interpolate an untrusted token into shell program text.** Accept the key as data, validate its expected length and character set, and write it using `printf '%s\n' "$value"`. 4. **Prefer an operating-system credential manager** over a plaintext file, such as Secret Service, Keychain, or an equivalent secure token store. 5. **Require explicit user consent before persistence.** Keep the key only in the current process environment unless the user affirmatively requests storage. 6. **Validate existing credential files before reading them.** Reject symbolic links, unexpected owners, and files with group or world permissions. Where supported, verify that the file is a regular file owned by the current user. 7. **Rotate any API key previously stored using the vulnerable procedure** if there is reason to believe the file was accessible or modified by an untrusted party. ]]>