[security][medium] Avoid trusting PATH/which for locating/launching external programs (trojan binary risk)

[upupwrite]

Summary

Path Keeper relies on external programs discovered via PATH using which or environment PATH checks to determine available tools (e.g., fzf, editors). This allows an attacker who controls PATH (or places trojan binaries earlier in the PATH) to influence which binaries are executed. Additionally, Editor::findInPath uses popen("which ...") which also interprets the program name through a shell.

Reproduction / evidence

• src/search.cpp: checks system("which fzf > /dev/null 2>&1") and later invokes fzf via popen with a constructed shell command.
• src/loadfile.cpp: Editor::findInPath constructs which + prog and calls popen().

Risks

• If PATH is set by an untrusted environment (e.g., a compromised shell profile, malicious container), an attacker can cause the application to use malicious binaries.
• popen/which invocation with untrusted program names can lead to command injection if program name is attacker-controlled.

Suggested fixes

1. Resolve executables securely:

   • Instead of using a shell which, implement direct PATH traversal by reading PATH and checking each directory for an executable file with the expected name (use stat/access to validate X_OK). Construct absolute paths and execute those directly.
   • Prefer to require absolute paths for critical external tools or provide a configuration option for explicit paths.

2. Avoid shell-based which calls; if invoking external lookup, ensure inputs are validated/whitelisted and use non-shell APIs.

3. Validate PATH in hostile environments: if running in elevated or multi-user contexts, either sanitize PATH or ignore it and use a known-safe set of binaries.

Files/places to review first

• src/search.cpp
• src/loadfile.cpp (Editor::findInPath)

Severity: medium