3 ms·

I'm struggling to understand the process that went into this "feature" existing. It seems the most likely candidate is a developer's git started malfunctioning

I'm struggling to understand the process that went into this "feature" existing. It seems the most likely candidate is a developer's git started malfunctioning and an agent "fixed" it by dropping a `git.exe` in the repo and then conditionally calling it when it exists.

conartist6 3mo ago
and ever since, this approach has been a critical pathway for some billion dollar business probably. hooray
- pixl97 3mo ago
  I see you also work in enterprise software.
gruez 3mo ago
>It seems the most likely candidate is a developer's git started malfunctioning and an agent "fixed" it by dropping a `git.exe` in the repo and then conditionally calling it when it exists. It doesn't need to be that deliberate. The default shell on windows (cmd.exe) includes the current directory into PATH by default. In other words, you don't need to do `./program.exe`, `program.exe` would suffice. That's probably where the bug came from. This also means if you were using cmd.exe, ran `git clone`, went inside it, then executed any command (eg. dir or git) you could get pwned.
- drdexebtjl 3mo ago
  Windows doesn’t really have a default login shell like Unix. Windows Terminal defaults to PowerShell which does not suffer from this issue.
  - inigyou 3mo ago
    Windows has a default login shell which is explorer.exe. Windows also has a system(const char*) which certainly does something.
varenc 3mo ago
I doubt it. This is just normal Windows behavior. If you call out to a shell and have it run a `git` command the system has to decide where the git binary is. A quirk of Windows is that first it searches the current directory for a `git` executable, and then it searches directories defined in PATH. If there's an executable git.exe in the current dir, that gets ran. I assume Cursor's behavior is the same across platforms but this is only a Windows vuln because Windows picks binaries in the current directory before PATH. A Windows user purely using the CMD shell, not Cursor, that checked out a malicious repo, went to that repo, and then ran any `git` command in that repo could be hacked the same way.

conartist6 3mo ago

and ever since, this approach has been a critical pathway for some billion dollar business probably. hooray

pixl97 3mo ago
I see you also work in enterprise software.

gruez 3mo ago

>It seems the most likely candidate is a developer's git started malfunctioning and an agent "fixed" it by dropping a `git.exe` in the repo and then conditionally calling it when it exists. It doesn't need to be that deliberate. The default shell on windows (cmd.exe) includes the current directory into PATH by default. In other words, you don't need to do `./program.exe`, `program.exe` would suffice. That's probably where the bug came from. This also means if you were using cmd.exe, ran `git clone`, went inside it, then executed any command (eg. dir or git) you could get pwned.

drdexebtjl 3mo ago
Windows doesn’t really have a default login shell like Unix. Windows Terminal defaults to PowerShell which does not suffer from this issue.
- inigyou 3mo ago
  Windows has a default login shell which is explorer.exe. Windows also has a system(const char*) which certainly does something.

varenc 3mo ago

I doubt it. This is just normal Windows behavior. If you call out to a shell and have it run a `git` command the system has to decide where the git binary is. A quirk of Windows is that first it searches the current directory for a `git` executable, and then it searches directories defined in PATH. If there's an executable git.exe in the current dir, that gets ran. I assume Cursor's behavior is the same across platforms but this is only a Windows vuln because Windows picks binaries in the current directory before PATH. A Windows user purely using the CMD shell, not Cursor, that checked out a malicious repo, went to that repo, and then ran any `git` command in that repo could be hacked the same way.