T07 · Tool Hijacking and Spoofing
Error
- Location
- SKILL.md:100
- Finding
- Default Auto Mode May Execute a Spoofed Local Scanner<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:100-102` **Supporting Locations**: `SKILL.md:41, 59, 110`; `INSTALL.md:27-32` **Vulnerability Type**: Local tool resolution and execution hijacking **Risk Level**: High ### Vulnerable Code Snippet ```markdown Default `auto` mode tries a locally resolved external scanner first and falls back to native when it is unavailable or fails. Use `--engine external` to require the external result, or `--engine native` to run only the built-in engine. CMIC passes the target path to a user-configured local tool. The tool runs with the current user's process permissions; trust the external tool and its configuration separately. CMIC only configures the external LLM endpoint when `--use-llm` is explicitly set; the tool may otherwise bootstrap dependencies or use its own network configuration. ``` The installation guide also recommends invoking the default behavior: ```markdown The default engine is `auto`: it prefers a locally resolved external scanner and falls back to the built-in native engine if the external scanner is unavailable or fails. Use `--engine native` to run only the built-in engine. ``` ### Technical Analysis The documented default engine is `auto`, which attempts to resolve and execute an external scanner before using the built-in native implementation. The external process inherits the current user's process permissions and receives the target path. If scanner resolution depends on `PATH`, local configuration, or another location that an attacker can influence, an attacker can place a malicious executable under the expected scanner name. The legitimate-looking review command would then execute attacker-controlled code. This violates secure tool-resolution principles because the package has a native engine capable of performing the task without invoking an independently trusted executable. The source code and claimed scanner binary are absent from the audited artifact, so the exact e ...[truncated 1564 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Make `native` the default engine. Require explicit user consent through `--engine external` before launching another executable. 2. Require an absolute external-scanner path rather than resolving a bare executable name through `PATH`. 3. Reject scanner binaries located in directories writable by untrusted users. 4. Verify the scanner's cryptographic digest or signature against trusted, pinned metadata before execution. 5. Validate file ownership and permissions and reject symlinks or unexpected file types where appropriate. 6. Launch the external process with a minimal environment and remove unrelated credentials and sensitive environment variables. 7. Apply process sandboxing where supported, including restricted filesystem access, network controls, resource limits, and reduced privileges. 8. Clearly display the resolved executable path and require confirmation before its first use. 9. Add tests covering malicious `PATH` entries, symlink substitution, configuration-path manipulation, and checksum mismatches. 10. Include the implementation source or a verifiable binary in the package so the resolution and execution controls can be independently audited. ]]>
