T09 · Insecure Skill Coding Practices
Warning
- Location
feishu_send_message.sh:116- Finding
Temporary Image Copies Are Not Removed After Processing
- Content
View full analysis
/dev/null || { TEMP_FILE="$FILE_PATH" } FILE_PATH="$TEMP_FILE" echo "✅ 压缩完成" ``` ### Technical Analysis When an image exceeds 10 MB, the script creates a temporary directory and writes a compressed copy of the image into it. No `trap`, cleanup function, or explicit `rm` operation removes this directory after the upload completes or after a later command fails. Although `mktemp -d` normally creates a directory with restrictive permissions, the sensitive image remains on disk after the process terminates. It can subsequently be accessed by processes running as the same operating-system account, privileged local users, backup or indexing software, or any process that later gains access to that account. Repeated executions can also accumulate abandoned files and consume storage. The problem affects successful execution and error paths because the script exits without cleaning up the generated directory. ### Attack Path 1. A user invokes the Skill with an image larger than 10 MB. 2. The script creates a directory under the system temporary-file location. 3. `sips` writes a compressed copy of the image into that directory. 4. The script uploads the copy to Feishu and then exits, or exits early because of an upload or message-delivery error. 5. The temporary directory and image remain on disk. 6. A later process running under the same account, or a privileged local process, enumerates the temporary directory and reads the retained image. ### Impact Assessment This does not provide remote code execution or privilege escalation by itself. Its primary impact is local confidentiality loss involving the conten ...[truncated 276 chars]- Remediation
View remediation
&2 exit 1 } chmod 700 "$TEMP_DIR" ``` Additional hardening measures: 1. Keep the temporary directory private with mode `0700`. 2. Use a fixed generated output name rather than retaining the user-controlled basename. 3. Verify that compression succeeded and that the generated file is within the required size before uploading it. 4. Do not report compression success when `sips` fails. 5. Preserve the cleanup trap for successful execution, command failures, and interruption signals. 6. Where supported, securely manage sensitive temporary data using an application-private runtime directory. ]]>