Fix CVE-2023-40590

[EliahKagan]

Fixes #1635

This fixes the path search bug where the current directory is included on Windows, by setting NoDefaultCurrentDirectoryInExePath for the caller. (Setting for the callee env would not work.)

This sets it only on Windows, only for the duration of the Popen call, and then automatically unsets it or restores its old value.

NoDefaultCurrentDirectoryInExePath is documented in NeedCurrentDirectoryForExePathW function (processenv.h). See also this SO post by Mofi.

It automatically affects the behavior of subprocess.Popen on Windows, due to the way Popen uses the Windows API. (In contrast, it does not, at least currently on CPython, affect the behavior of shutil.which. But shutil.which is not being used to find git.exe. [Edit: To avoid misleading people who find this by searching, I should mention that, starting in Python 3.12, shutil.which now checks this as well.])

I have tested this by naming a hello world program git.exe and placing it in the current directory, verifying that import git produces an expected error (my hello world program does not provide Git operations), then applying this change and verifying that import git works as it should.

[Byron]

Thanks a lot!

Could we also have a test for this?

I could imagine that a test could be as simple as dropping a git.exe file into a freshly initialized git repository. When invoking any repo.git(…) command, this should fail on windows as it picks up and tries to execute the dummy file. With the fix, it should not fail. For good measure, on linux one can probably create an executable file called git instead, which shouldn't be picked up by default.

What do you think?

[EliahKagan]

@Byron Yes, I will add a test.

I think the test could be even simpler. The existing test test_it_executes_git_to_shell_and_returns_result calls git.execute directly, and does not have to be run in a git repository. I wouldn't change that test, but a new one like it could be added that temporarily changes directory into a temporary directory with a dummy git.exe (or executable git on non-Windows systems).

Would that be reasonable, or would you prefer a higher level repo.git test?

The other thing that occurs to me is that the test might be considered slightly more robust if it uses a binary file as git.exe that is actually executable. I'm not sure if this is worthwhile or not. (On Windows, hostname.exe could be copied from the System32 directory as git.exe to serve this purpose.)

[EliahKagan]

I've added a test, which I've verified locally fails before the fix and passes afterwards, on Windows. I have not yet run it on other operating systems, so there may be bugs in my test on that code path that I will have to fix. I have also run it on Ubuntu, where it passes.

I've taken the approach I suggested above. But I'm willing to make any requested changes, including to the specific way you have suggested if you would prefer that.

[Byron]

Thanks for the test!

Even though I am a bit uneasy about changing the directory of the test-process, I understand that tests aren't run in parallel so it should be fine for the foreseeable future.

Besides one small nit that hopefully prevents this test to fail with unexpected git versions, this PR is ready to be merged.

Thanks again for your help with this.

[xesf]

Any idea when a patch release can be made with this fix?

[EliahKagan]

@Byron Is this ready to go?

[xesf]

Thanks guys, I appreciate the promptness.

[xesf]

Looks like this issue is still present in the 3.1.34 version and has been reported overnight
GHSA-cwvm-v4w8-q58c

[EliahKagan]

@xesf That's a separate vulnerability, CVE-2023-41040 (#1638, #1644). This PR only fixed CVE-2023-40590 (#1635).

[xesf]

Thanks @EliahKagan for the details.