T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/launch_claude_code.sh:90
- Finding
- Shell Command Injection Through Crafted Project Paths<![CDATA[ ## Vulnerability Details **File Location**: `scripts/launch_claude_code.sh`, lines 90-106 and 130-137 **Vulnerability Type**: OS command injection through unsafe shell-input construction **Risk Level**: High ### Vulnerable Code ```bash validate_project() { local project="$1" # Expand ~ to home directory project="${project/#\~/$HOME}" if [[ ! -d "$project" ]]; then error "Project path does not exist: $project" error "Did you mean one of these?" ls -d ~/dev/* 2>/dev/null | head -5 || true exit 1 fi if [[ ! -w "$project" ]]; then error "No write permission for: $project" exit 1 fi success "Project validated: $(basename "$project")" echo "$project" } ``` ```bash navigate_to_project() { local project="$1" info "Navigating to project: $project" if peekaboo type "cd \"$project\"" --app Terminal --return 2>/dev/null; then success "Navigated to project" sleep 1 else error "Failed to navigate to project" return 1 fi } ``` The returned value is captured and subsequently passed to the vulnerable function: ```bash PROJECT_PATH=$(validate_project "$PROJECT_PATH") open_terminal navigate_to_project "$PROJECT_PATH" ``` ### Technical Analysis The launcher validates only that the supplied project path identifies an existing writable directory. It does not encode the path safely before inserting it into a command that is typed into an interactive shell. The construction below is not sufficient shell escaping: ```bash peekaboo type "cd \"$project\"" --app Terminal --return ``` A directory name can legally contain characters such as double quotes, semicolons, backticks, dollar signs, command substitutions, and newline characters. An embedded double quote can terminate the intended quoted path, after which shell syntax in the directory name can introduce additional commands. Peekaboo's `--return` opti ...[truncated 1734 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Avoid constructing commands for an interactive shell. Prefer a process-launching interface that accepts an executable and arguments separately. 2. If UI automation is unavoidable, convert the path to an absolute canonical path and encode it as one shell argument before typing it: ```bash canonical_project="$(cd -- "$project" && pwd -P)" printf -v escaped_project '%q' "$canonical_project" peekaboo type "cd -- $escaped_project" --app Terminal --return ``` 3. Ensure `validate_project` emits only the validated path on standard output. Send informational output to standard error: ```bash success "Project validated: $(basename -- "$project")" >&2 printf '%s\n' "$project" ``` 4. Use `realpath` or an equivalent canonicalization mechanism and reject paths containing newline or carriage-return characters as defense in depth. 5. Add automated tests using directory names containing spaces, quotes, semicolons, command substitutions, backticks, leading hyphens, and newlines. 6. Do not treat existence and writability checks as input sanitization; retain shell-safe argument handling at the command-execution boundary. ]]>
