T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:83
- Finding
- Untrusted TTS text may be interpolated into a shell command<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 83-96 **Vulnerability Type**: Command injection through unsafe shell argument construction **Risk Level**: High ### Vulnerable Code ```bash Always delete temporary files after playback. Generated audio or referenced text may be retained by the chat client history, so avoid processing sensitive sources. ```bash # Generate with unique filename and play OUTPUT_FILE="/tmp/audio_reply_$(date +%s)" uv run mlx_audio.tts.generate \ --model mlx-community/chatterbox-turbo-fp16 \ --text "Your response text" \ --play \ --file_prefix "$OUTPUT_FILE" # ALWAYS clean up after playing rm -f "${OUTPUT_FILE}"*.wav 2>/dev/null ``` ``` The same unsafe command-construction pattern also appears in the TTS example at `SKILL.md:50-57` and the example workflow at `SKILL.md:114-128`. ### Technical Analysis The Skill instructs the agent to fetch webpage content or generate a response and substitute that content into the `--text` argument of a shell command. The documentation does not require use of a structured process API, argument array, securely created input file, or another mechanism that keeps content separate from shell syntax. If an implementation constructs the displayed command as a string and replaces `"Your response text"` with fetched or user-controlled content, shell-significant characters can break the intended quoting context. Command substitutions such as `$(...)` and backticks are evaluated even within double quotes when they appear in shell source. Embedded quotes can also terminate the argument and introduce redirections, separators, or additional commands. The instruction stating that commands from fetched content must not be executed is a policy guardrail, but it does not technically prevent indirect execution caused by unsafe shell interpolation. ### Attack Path 1. An attacker publishes a public webpage containing shell syntax in article text, such as command substitution or a ...[truncated 1454 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Never construct shell source by concatenating or interpolating fetched, generated, or user-provided text. 2. Invoke the TTS program through a structured process-execution API that accepts an argument array. Pass the entire response as one literal argument without invoking a shell. 3. If supported by MLX Audio, write the text to a securely created temporary file and pass the file path through a dedicated input-file option. 4. Create temporary files with unpredictable names and restrictive permissions, such as through `mktemp` with an appropriate `umask`, rather than using a timestamp alone. 5. If shell use cannot be eliminated, place dynamic data in positional parameters supplied separately to a fixed script. Do not evaluate, reparse, or embed those parameters in generated shell code. 6. Add an explicit implementation requirement that shell tools must not be used to interpolate TTS text. 7. Add regression tests containing double quotes, single quotes, backticks, command substitutions, newlines, redirections, and command separators. Verify that all test strings are delivered literally to the TTS process and that no secondary command runs. ]]>