T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:29
- Finding
- Potential Shell Command Injection Through User-Controlled Query Text<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 29–36 **Vulnerability Type**: Shell command injection caused by unsafe interpolation guidance **Risk Level**: High ### Vulnerable Code ```bash **If `workiq` is on PATH:** ```bash workiq ask -q "<natural language question>" ``` **If only `npx` is available (Node.js required):** ```bash npx -y @microsoft/workiq ask -q "<natural language question>" ``` ``` ### Technical Analysis The skill instructs the agent to execute WorkIQ through an `exec` tool and place natural-language query text directly inside a shell command. It does not require argument-array execution, validation, or shell-safe escaping. If the agent constructs the command by replacing the placeholder with user-controlled text, a malicious query containing a closing quotation mark and shell metacharacters could terminate the intended argument and introduce another command. Quoting the placeholder with double quotation marks does not make arbitrary input safe when the command itself is assembled as a string. The instruction on line 47 not to pipe or combine WorkIQ output with other commands discourages normal command composition, but it does not prevent injection inside the query argument. ### Attack Path 1. An attacker submits a Microsoft 365 query containing shell syntax designed to close the `-q` argument. 2. The agent substitutes that text into the documented command template. 3. The `exec` tool passes the resulting command string to a shell. 4. The shell interprets the injected metacharacters as executable syntax. 5. The injected command runs with the operating-system privileges and environment access of the agent process. Successful exploitation depends on the execution tool using a shell and the agent performing direct string interpolation. The skill does not mandate the safer non-shell execution model needed to eliminate this path. ### Impact Assessment An attacker could potentially execute arbitrary local commands ...[truncated 581 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Execute WorkIQ without invoking a shell. Pass each component as a separate process argument, for example: ```text ["workiq", "ask", "-q", userQuestion] ``` - Apply the same argument-array approach to the `npx` fallback. - Explicitly prohibit concatenating user-controlled text into shell command strings. - If the execution interface cannot avoid a shell, use a well-tested platform-specific escaping routine rather than manual quote replacement. - Reject control characters such as null bytes and line breaks when they are not required. - Keep WorkIQ output separate from shell evaluation and never pass it to `eval`, command substitution, or another interpreter. - Add adversarial tests covering quotation marks, semicolons, command substitution, redirection operators, pipes, and line breaks. ]]>