RUSTSEC-2021-0071

Dashboard / Vulnerabilities / RUSTSEC-2021-0071

RUSTSEC-2021-0071

Summary: `grep-cli` may run arbitrary executables on Windows

Details: 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`](https://docs.rs/grep-cli/0.1.6/grep_cli/fn.resolve_binary.html) helper function. To be clear, `grep-cli 0.1.6` mitigates this issue in two ways: * A `DecompressionReader` will resolve decompression programs to absolute paths automatically using the `PATH` environment variable, instead of relying on Windows APIs to do it (which would result in the undesirable behavior of checking the CWD for a program first). * A new function, `resolve_binary`, was added to help users of this crate mitigate this behavior when they need to create their own `std::process::Command`. For example, [ripgrep uses `grep_cli::resolve_binary`](https://github.com/BurntSushi/ripgrep/blob/7ce66f73cf7e76e9f2557922ac8e650eb02cf4ed/crates/core/search.rs#L119-L122) on the argument given to its `--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.

References: https://crates.io/crates/grep-cli, https://rustsec.org/advisories/RUSTSEC-2021-0071.html, https://github.com/BurntSushi/ripgrep/issues/1773