Windows: Resolve `process::Command` program without using the current directory...

ChrisDenton commented on Aug 2 •

Currently std::process::Command searches many directories for the executable to run, including the current directory. This has lead to a CVE for ripgrep but presumably other command line utilities could be similarly vulnerable if they run commands. This was discussed on the internals forum. Also discussed was which directories should be searched.

EDIT: This PR originally removed all implicit paths. They've now been added back as laid out in the rest of this comment.

Old Search Strategy

The old search strategy is documented here. Additionally Rust adds searching the child's paths (see also #37519). So the full list of paths that were searched was:

1. The directories that are listed in the child's PATH environment variable.
2. The directory from which the application loaded.
3. The current directory for the parent process.
4. The 32-bit Windows system directory.
5. The 16-bit Windows system directory.
6. The Windows directory.
7. The directories that are listed in the PATH environment variable.

New Search Strategy

The new strategy removes the current directory from the searched paths.

1. The directories that are listed in the child's PATH environment variable.
2. The directory from which the application loaded.
3. The 32-bit Windows system directory.
4. The Windows directory.
5. The directories that are listed in the parent's PATH environment variable.

Note that it also removes the 16-bit system directory, mostly because there isn't a function to get it. I do not anticipate this being an issue in modern Windows.

Impact

Removing the current directory should fix CVE's like the one linked above. However, it's possible some Windows users of affected Rust CLI applications have come to expect the old behaviour.

This change could also affect small Windows-only script-like programs that assumed the current directory would be used. The user would need to use .\file.exe instead of the bare application name.

This PR could break tests, especially those that test the exact output of error messages (e.g. Cargo) as this does change the error messages is some cases.