T09 · Insecure Skill Coding Practices
Warning
- Location
- cli-wrapper.sh:56
- Finding
- Undisclosed and Unsafe Persistent Logging of User Search Terms## Vulnerability Details **File Location**: `cli-wrapper.sh`, lines 56-58 **Related Documentation**: `SKILL.md`, lines 13-16 **Vulnerability Type**: Unsafe local logging, plaintext retention, and relative-path file write **Risk Level**: Medium ### Vulnerable Code ```bash # Log search to file (read-only, no side effects) LOG_FILE="logs/clawhub-search.log" echo "$(date -u): SEARCH: $SEARCH_TERM" >> "$LOG_FILE" ``` The accompanying documentation claims that the skill runs without filesystem write capability: ```markdown - Runs in sandboxed session with no filesystem write or exec capability — only read-only clawhub search and install via CLI **Uses only**: , , (for CLI), (for log only) ``` ### Technical Analysis The script appends the complete user-supplied search term to a persistent file despite describing its operation as read-only and without side effects. The implementation provides no consent mechanism, redaction, retention limit, access-control setup, path validation, or symbolic-link protection. `LOG_FILE` is a relative path, so its destination depends on the process's current working directory rather than a trusted application-owned directory. Shell append redirection follows symbolic links. If an attacker can prepare the working directory, the attacker can create `logs/clawhub-search.log` as a symbolic link to another file writable by the user running the script. Subsequent searches will then be appended to that target. The script also does not create the `logs` directory or fail safely when logging is unsuccessful. The comment that the operation is “read-only” is technically incorrect because `>>` opens or creates a file for writing. ### Attack Path 1. An attacker obtains control over, or write access to, the directory from which the wrapper will be executed. 2. The attacker creates a `logs` directory and makes `logs/clawhub-search.log` a symbolic link to another file writable by the victim ...[truncated 1386 chars]
- Remediation
- ## Remediation Suggestions 1. Disable persistent query logging by default. If logging is necessary, obtain explicit user consent and accurately document the filesystem side effect. 2. Avoid retaining raw search terms. Redact sensitive values or record only non-sensitive operational metadata. 3. Use a fixed, application-owned logging directory rather than a path relative to the current working directory. 4. Create the directory and log with restrictive permissions, such as `0700` for the directory and `0600` for the file, while applying an appropriate restrictive `umask`. 5. Reject symbolic links and non-regular files. Open the destination using a mechanism that supports no-follow and exclusive safety checks rather than ordinary shell redirection. 6. Define log rotation and retention limits and provide a method for users to inspect and delete stored records. 7. Check and report logging failures explicitly instead of silently continuing. 8. Update `SKILL.md` so its claims match actual behavior. Do not characterize the implementation as read-only while it writes a log.
