T09 · Insecure Skill Coding Practices
Warning
- Location
- cobraclaw.sh:28
- Finding
- Path Traversal Permits Execution of Scripts Outside the Kata Directory<![CDATA[ ## Vulnerability Details **File Location**: `cobraclaw.sh:28-31` **Vulnerability Type**: Path traversal leading to unintended local code execution **Risk Level**: Medium ### Vulnerable Code ```bash cmd_kata() { kata="$1" if [ -x "$SCRIPT_DIR/katas/${kata}.sh" ]; then "$SCRIPT_DIR/katas/${kata}.sh" else echo "Kata not found: $kata" fi } ``` ### Technical Analysis The `kata` argument is controlled by the command-line caller and is interpolated directly into an executable file path. Although the path is quoted, which prevents ordinary shell metacharacter injection, the code does not reject directory separators or `..` traversal components. Consequently, a value such as `../../outside/payload` produces a path resembling: ```text $SCRIPT_DIR/katas/../../outside/payload.sh ``` The `[ -x ... ]` check only verifies that the resolved target exists and is executable. It does not verify that the resolved target remains inside the intended `katas` directory. If the target passes this check, line 31 executes it. The forced `.sh` suffix and executable-file requirement limit exploitation, but they do not eliminate the directory-boundary violation. ### Attack Path 1. An attacker places or identifies an executable file named `payload.sh` outside the project's `katas` directory. 2. The attacker gains control of the argument passed to the `kata` command. 3. The attacker supplies a traversal path, for example: ```bash ./cobraclaw.sh kata ../../outside/payload ``` 4. The constructed path resolves outside `katas`. 5. If the resulting file exists and has execute permission, the executable check succeeds. 6. The external script runs with the same operating-system identity and environment as the `cobraclaw.sh` process. ### Impact Assessment Successful exploitation permits execution of an unintended local `.sh` file with the privileges of the user or Agent invoking the Skill. The executed script could access, modify, or d ...[truncated 332 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions Use an explicit allowlist of supported kata identifiers rather than converting arbitrary input into an executable path: ```bash cmd_kata() { local kata="${1:-}" case "$kata" in strike-first|hard-shell|cobra-strike|no-mercy|evolve|wax-on-wax-off|sweep-the-leg) "$SCRIPT_DIR/katas/$kata.sh" ;; *) printf 'Invalid kata: %s\n' "$kata" >&2 return 1 ;; esac } ``` Additional hardening measures: 1. Reject empty values, absolute paths, directory separators, and traversal components. 2. If dynamic discovery is required, canonicalize both the `katas` directory and candidate target, then verify that the canonical target is a direct child of the canonical directory. 3. Account for symbolic links when performing containment validation; lexical prefix checks alone are insufficient. 4. Run kata scripts with the minimum required operating-system privileges. 5. Add regression tests covering values such as `../`, `../../outside/payload`, absolute paths, embedded slashes, and symlink-based escapes. ]]>