T07 · Tool Hijacking and Spoofing
- Location
scripts/install.sh:20- Finding
Installer Can Execute an Attacker-Controlled Local Python Script
- Content
View full analysis
/dev/null ``` ### Technical Analysis The installer itself resides in the `scripts` directory, but it attempts to change into another `scripts` directory beneath its own location. For a normal installation, this resolves to `scripts/scripts`, which does not exist. The script neither enables `set -e` nor checks whether `cd` succeeded. Consequently, after the directory change fails, execution continues in the caller's original working directory. The relative command `python3 monitor.py --help` then resolves `monitor.py` from that directory rather than from the trusted Skill directory. An attacker who can place a malicious `monitor.py` in the directory from which a victim launches the installer can cause arbitrary Python code to execute. ### Attack Path 1. The attacker creates a malicious file named `monitor.py` in a directory writable by the victim or otherwise controlled by the attacker. 2. The victim enters that directory and invokes the legitimate installer using an absolute or relative path. 3. The installer attempts to enter the nonexistent `scripts/scripts` directory. 4. The failed `cd` does not terminate execution. 5. `python3 monitor.py --help` loads and executes the attacker's local `monitor.py`. 6. The payload runs with all permissions available to the victim running the installer. This path requires the attacker to influence the launch directory or place a file there, but no further confirmation is requested before Python executes the file. ### Impact Assessment Successful exploitation provides arbitrary code execution with the privileges of the installing user. The attacker could rea ...[truncated 381 chars]- Remediation
View remediation
/dev/null 2>&1 ``` Additional hardening measures: 1. Check that `monitor.py` is a regular file before executing it. 2. Avoid continuing after any failed directory change. 3. Quote every filesystem path. 4. Run installation tests with the same explicit absolute-path convention. 5. Add an automated test that launches `install.sh` from an unrelated directory containing a decoy `monitor.py` and verifies that the decoy is never executed. ]]>
