T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:59
- Finding
- User-Controlled Location Values Can Trigger Shell Command Injection<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 59–60 **Vulnerability Type**: Shell command injection through inadequate quoting guidance **Risk Level**: High ### Vulnerable Code Snippet ```markdown 1. Always pass `--llm`. 2. **Quote all user-provided values** in shell commands: `--city="New York"`, `--city="St. Petersburg"`. Only known-safe tokens (numbers, single ASCII words) may be unquoted. ``` ### Technical Analysis The Skill instructs the agent to place user-provided values inside double-quoted shell arguments. Double quotes prevent word splitting and pathname expansion, but they do not prevent shell command substitution through `$(...)` or backticks. For example, directly interpolating a user-provided city into the documented template could produce: ```sh openmeteo weather --current --city="$(id)" --llm ``` A shell evaluates `$(id)` before invoking `openmeteo`. Merely placing the input inside double quotes therefore does not safely isolate it as data. The same issue applies to other user-controlled options if they are interpolated into shell command strings. The Skill does not require arbitrary shell execution for its weather functionality. It only needs to pass location and weather parameters to the `openmeteo` executable, so allowing shell interpretation exceeds the minimum execution capability necessary for the declared task. ### Attack Path 1. An attacker submits a weather request containing shell syntax in a location value, such as a city named `$(id)` or a more harmful command-substitution payload. 2. The agent follows the documented command template and inserts that value between double quotes. 3. The command is passed to a shell rather than to a process API as a structured argument array. 4. The shell evaluates the embedded command substitution. 5. The injected command executes before `openmeteo` receives the resulting argument. Successful exploitation depends on the agent or runtime constructing a shell command ...[truncated 793 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Invoke `openmeteo` directly through an execution API that accepts an argument array, without using a shell. For example, pass the city as one discrete argument equivalent to: ```text ["openmeteo", "weather", "--current", "--city=New York", "--llm"] ``` 2. Explicitly prohibit constructing shell command strings from user input. State that double quoting alone is not sufficient protection. 3. Validate every user-controlled parameter against a narrow allowlist: - Latitude and longitude must parse as bounded numeric values. - Country codes should match the supported fixed format. - Forecast lengths and offsets should be bounded integers. - Parameter lists should be selected from the documented weather-variable allowlist. - City values should be subject to reasonable length and character restrictions. 4. If shell execution is unavoidable, apply a proven shell-escaping routine independently to every argument, such as Bash `printf '%q'`. Do not implement escaping through ad hoc character replacement. 5. Run the weather command under a minimally privileged account with restricted filesystem access, a sanitized environment, and outbound network access limited to the required Open-Meteo endpoints. ]]>