T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:20
- Finding
- Insecure Temporary Files Expose Authentication Data and Permit Symlink-Based File Overwrites<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 20–29 **Vulnerability Type**: Unsafe temporary-file creation and incomplete cleanup **Risk Level**: Medium ### Vulnerable Code ```bash pup_login() { local jar; jar=$(mktemp -t pupjar) curl -sS -c "$jar" -X POST "$PUP/Authenticate" \ -H 'Content-Type: application/json' \ -d "$(jq -nc --arg u "$PUP_USER" --arg p "$PUP_PASS" \ '{provider:"credentials",UserName:$u,Password:$p,RememberMe:true}')" \ -o /tmp/pup_auth.json -w '%{http_code}' >/tmp/pup_code [ "$(cat /tmp/pup_code)" = 200 ] || { jq -r '.ResponseStatus.Message' /tmp/pup_auth.json >&2; return 1; } export PUP_JAR="$jar" ``` ### Technical Analysis Although the cookie jar is created using `mktemp`, the authentication response and HTTP status are written to predictable, shared paths: `/tmp/pup_auth.json` and `/tmp/pup_code`. Shell redirection and `curl -o` follow symbolic links. A local attacker can therefore pre-create either path as a symbolic link and cause the authenticated user to overwrite another file that the user is permitted to modify. The permissions assigned to the generated files also depend on the user's current `umask`. Under an insufficiently restrictive configuration, another local user may be able to read authentication response data. The response is documented as containing account and session-related fields such as `UserId`, `SessionId`, `UserName`, roles, permissions, and potentially bearer or refresh tokens if the deployment begins issuing them. The securely generated cookie jar is not deleted when the session ends or when login processing fails. It contains active session cookies and consequently remains sensitive for as long as those cookies are valid. ### Attack Path 1. An attacker with local access predicts the documented fixed paths `/tmp/pup_auth.json` and `/tmp/pup_code`. 2. The attacker creates a symbolic link from one of those paths to a file writable by the victim, or moni ...[truncated 1102 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions Create a private temporary directory, enforce restrictive permissions, and place every temporary artifact inside it: ```bash pup_login() { local tmp jar auth_file code_file umask 077 tmp=$(mktemp -d -t pup.XXXXXX) || return 1 jar="$tmp/cookies" auth_file="$tmp/auth.json" code_file="$tmp/status" trap 'rm -rf "$tmp"' RETURN curl -sS -c "$jar" -X POST "$PUP/Authenticate" \ -H 'Content-Type: application/json' \ -d "$(jq -nc --arg u "$PUP_USER" --arg p "$PUP_PASS" \ '{provider:"credentials",UserName:$u,Password:$p,RememberMe:true}')" \ -o "$auth_file" -w '%{http_code}' >"$code_file" || return 1 } ``` Because the cookie jar must survive the function when cookie authentication is used, manage it through an explicit session lifecycle rather than deleting it on function return. Recommended controls include: - Create the session directory with `mktemp -d` and mode `0700`. - Set `umask 077` before creating authentication artifacts. - Avoid predictable names directly under `/tmp`. - Add a `pup_logout` or cleanup function that removes the cookie jar and unsets `PUP_JAR`, `PUP_TOKEN`, and `PUP_PASS`. - Install appropriate `EXIT`, `HUP`, `INT`, and `TERM` traps for cleanup. - Delete authentication response and status files immediately after parsing. - Reject any temporary path that is not a regular file owned by the current user. ]]>