T09 · Insecure Skill Coding Practices
Warning
- Location
scripts/generate_episode.sh:37- Finding
Predictable Shared Temporary File Allows Local File Overwrite and Feed Corruption
- Content
View full analysis
/dev/null # 3. Build new item PUBDATE=$(date -d "${DATE}" -u '+%a, %d %b %Y 08:00:00 +0800') BUILDDATE=$(date -u '+%a, %d %b %Y %H:%M:%S +0000') NEW_ITEM="\n ${TITLE}\n ${DESC}\n \n ${PUBDATE}\n ${DURATION}\n ${DESC}\n \n podcast-${DATE}-${EP_LOWER}\n " # 4. Insert new item after line and update build date sed -i "s|.*|${BUILDDATE}\n\n ${NEW_ITEM}|" /tmp/feed_current.xml # 5. Upload updated RSS aws s3 cp /tmp/feed_current.xml "s3://${BUCKET}/feed.xml" --content-type "application/rss+xml" ``` ### Technical Analysis The script uses the fixed, globally predictable path `/tmp/feed_current.xml` without securely creating the file, checking its ownership, or verifying that it is a regular file rather than a symbolic link. On a multi-user system, another local user can create this path before the script runs. Depending on the behavior and permissions of the invoked tools, the subsequent S3 download or in-place `sed` operation may follow or otherwise interact unsafely with an attacker-created symbolic link. The effect is influenced by operating-system and tool-level symlink protections, but the code itself does not establish a safe invariant. The same fixed path is also shared by every invocation. Concurrent cron jobs or manual runs c ...[truncated 1666 chars]- Remediation
View remediation
&2 exit 1 } trap 'rm -rf -- "$TMPDIR_PATH"' EXIT FEED_FILE="$TMPDIR_PATH/feed.xml" aws s3 cp "s3://${BUCKET}/feed.xml" "$FEED_FILE" ``` Additional hardening should include: 1. Use the unique `$FEED_FILE` path for all subsequent processing and uploads. 2. Set a restrictive process umask, such as `umask 077`, before creating temporary files. 3. Verify that the downloaded object is a regular file before modifying it. 4. Avoid globally writable shared paths for security-sensitive intermediate data. 5. Add locking around feed updates so concurrent executions cannot overwrite each other. 6. Consider an S3-side concurrency control strategy, such as validating the previous object version or ETag before uploading the modified feed. 7. Run the publishing job under a dedicated, unprivileged service account with access only to the required podcast objects. ]]>