On Windows in versions of grep-cli
prior to 0.1.6
, it’s possible for some
of the routines to execute arbitrary executables. In particular, a quirk of
the Windows process execution API is that it will automatically consider the
current directory before other directories when resolving relative binary
names. Therefore, if you use grep-cli
to read decompressed files in an
untrusted directory with that directory as the CWD, a malicious actor to could
put, e.g., a gz.exe
binary in that directory and grep-cli
will use the
malicious actor’s version of gz.exe
instead of the system’s.
This is also technically possible on Unix as well, but only if the PATH
variable contains .
. Conventionally, they do not.
A DecompressionReader
has been fixed to automatically resolve binary names
using PATH
, instead of relying on the Windows API to do it.
If you use grep-cli
’s CommandReader
with a std::process::Command
value
on Windows, then it is recommended to either construct the Command
with an
absolute binary name, or use grep-cli
’s new
resolve_binary
helper function.
To be clear, grep-cli 0.1.6
mitigates this issue in two ways:
DecompressionReader
will resolve decompression programs to absolutePATH
environment variable, instead of relyingresolve_binary
, was added to help users of this cratestd::process::Command
. For example,grep_cli::resolve_binary
--pre
flag.While the first mitigation fixes this issue for sensible values of PATH
when doing decompression search, the second mitigation is imperfect. The more
fundamental issue is that std::process::Command
is itself vulnerable to this.