os/exec: on Windows use NeedCurrentDirectoryForExePathW for LookPath behavior

[dolmen]

In os/exec.LookPath use Windows function NeedCurrentDirectoryForExePathW to check if the environment is hardened to protect against resolution of command path in the current directory.

Note that this proposal is different from just looking at the existence of a NoDefaultCurrentDirectoryInExePath environment variable because the function doesn't just look in the process environment variables but might also look in registry settings.

This is related to:

• os/exec: return error when PATH lookup would use current directory #43724: return error when PATH lookup would use current directory
• proposal: os/exec: use LookPathAbs by default  #42950: use LookPathAbs by default

Credit goes to @KalleOlaviNiemitalo for his/her comment in #38736.

[dolmen]

Side note: Windows has multiple ways of resolving application paths. The one that os/exec had implemented before 1.15.7 is the one implemented by cmd.exe (and most CLI tools), not the one recommended for GUI tools which involves more than PATH. Just to say that os/exec has never been the only right way to launch commands on Windows.

[rsc]

Sounds reasonable.
/cc @alexbrainman @zx2c4

[zx2c4]

Huh, interesting rabbit hole here. One thing I noticed is that CreateProcess itself will handle path resolution if you pass it a non-absolute executable name as argv[0] and NULL as the actual executable path name:

from https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa

As an aside from the specific proposal here, this makes me wonder if instead of having exec.Command use LookPath, it should instead use that behavior of CreateProcess, and then we always do what windows does.

---

With regards to NeedCurrentDirectoryForExePath, here's what kernelbase.dll is doing on Windows 10, translated from the x86 into Go:

if strings.Index(exePath, `\`) != -1 { return true }
_, ok := os.Environ()["NoDefaultCurrentDirectoryInExePath"]
return !ok

So when you write:

Note that this proposal is different from just looking at the existence of a NoDefaultCurrentDirectoryInExePath environment variable because the function doesn't just look in the process environment variables but might also look in registry settings.

I'm not sure that this is actually true. Are there other versions of Windows you think I should look at?

[antichris]

use [the] behavior of CreateProcess and ... always do what windows does

Is it just me or does this sound really reckless? This entire proposal arose exactly from the necessity to mitigate the risk of malicious code execution that may lurk in a current working directory (#38736, #42420, #42950 and #43724). The fact that Microsoft did stupid sh...tuff (and still does, and have been doing for ages), really does not mean we or anyone else should ape them in that, ever (again). Convenience should not take precedence over security.

[zx2c4]

I hadn't seen #43724. I was thinking that Go wouldn't want a behavior change, and would want to keep os/exec using the defaults of whatever operating system and environment it's using. But it looks like #43724 changes that. So this issue here, I suppose, becomes one of "how can we tell when Windows is going to do something bad?" And I take it that @dolmen's suggestion is to use NeedCurrentDirectoryForExePath() instead of checking the NoDefaultCurrentDirectoryInExePath environment variable. But in reversing the former, I saw that it's basically the same as the latter.

[rsc]

In summary:

Except for the error in #43724, LookPath aims to match Windows cmd.exe.
If Windows has been configured to not add "." to the PATH implicitly,
then this proposal is for LookPath to respect that configuration setting
(which turns out to be an environment variable).

This seems unobjectionable. There was some discussion above arising from confusion about what exactly is being proposed, but that seems to have been resolved.

Does anyone object to this proposal?

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group