T07 · Tool Hijacking and Spoofing
Error
- Location
linux_command_guard/checker.py:132- Finding
Allowlisted command names can resolve to attacker-controlled executables
- Content
View full analysis
ParsedCommand: tokens = tokenize(command) base = next((token for token in tokens if token.strip()), None) return ParsedCommand(raw=command, tokens=tokens, base_command=base) ``` ```python # linux_command_guard/checker.py:132-139 if policy.allowlist and base not in policy.allowlist: return Decision( False, "Not in allowlist", matched_rule=base, base_command=base, details=(READ_ONLY_ALLOWLIST_GUIDANCE,), ) ``` ### Technical Analysis The allowlist validates only the textual value of the first command token, such as `ls`, `cat`, or `grep`. It does not resolve that name to an executable, constrain resolution to trusted system directories, or verify the resolved file's ownership and permissions. If a caller executes an approved command through a shell or a PATH-searching API such as `execvp`, the operating system may resolve the command to an attacker-controlled executable located earlier in `PATH`. Consequently, a malicious program named `ls` can satisfy the guard's allowlist even though it is unrelated to the trusted system utility. This is a trust-boundary problem: the checker authenticates a command name but not the executable that will actually receive control. The vulnerability becomes exploitable when an attacker can influence `PATH`, the working environment, or a directory appearing in `PATH`. ### Attack Path 1. The attacker obtains write access to a directory that is or can be placed before trusted directories in `PATH`. 2. The attacker creates an executable named after an allowlisted command, for example: ```bash mkdir -p /tmp/attacker-bin printf '#!/bi ...[truncated 1212 chars]- Remediation
View remediation