As someone who is on the other side, the amount of familiar, LLM generated reports are overwhelming and usually falls under "not familiar with product design/security scope" category. But there are also really good ones - so I can't afford to not take actual look at each, but it gets tiring and we need a solution. Spamming the former category with LLM generated "rationale" isn't that solution (yes I can tell this article is mostly LLM generated).
Unfortunately, this looks like the former case. If the software can execute arbitrary code/binary, and you place a malicious binary, that's up to you to secure/sandbox the workspace, not the software. Unless cursor commit themselves to securing the user environment, which I don't think they are in the business of.
If you are generating a CVE report with LLM, please use LLM responsibly in helping you reproduce deterministically. Then please do the write up yourself, keep it as concise as possible and strip most adjectives in any LLM generated sections as they cannot help themselves to write without mostly useless exaggerations.
It isn't "a binary", it's git.exe (which has a very specific purpose). We are talking about an AI tool which wants to know the current state of the folder it is indexing, that's a reasonable thing for an AI to want to do.
You then take the default of Windows execution order of: look for the executable in the current folder otherwise check the PATHs in order. This is a Windows security issue which has been around since day one.
To me the App is preparing to do some work so it is more responsive to my requests. This is a classic trade off between security and performance, where the odds of a malicious virus being in the root of your project are very small if you are already taking best practices.
Perhaps what we really need is Microsoft to change the execution order and that the maintainers of Git add a new feature where we can block executables being in the root of a repo (or in the whole of a repo). That would prevent every app having to make the same workaround, fix the issue upstream and you'll never have to think about it again.
git.exe is just a name. Cursor has no reason what so ever to assume that a random binary in a random repo is a legitimate git binary just because its name happens to be git.exe.
The trivial fix is to execute not "git.exe" but "C:\Program Files\Git\bin\git.exe". With a configurable git binary
Of course that then leads you down the rabbit hole of whether the llm should exectute a known-good ripgrep, tree, etc. instead of depending on PATH resolution
> If the software can execute arbitrary code/binary, and you place a malicious binary, that's up to you to secure/sandbox the workspace, not the software.
What do you think PATH variables are for? Cursor just immediately adds the repo to your PATH, iiuc, without user approval.
> But there are also really good ones - so I can't afford to not take actual look at each, but it gets tiring and we need a solution.
There is not easy solution, the landscape has changed and if care about security, you just need to allocate more human resources. Another layer of LLM checks won't help.
Unfortunately, this looks like the former case. If the software can execute arbitrary code/binary, and you place a malicious binary, that's up to you to secure/sandbox the workspace, not the software. Unless cursor commit themselves to securing the user environment, which I don't think they are in the business of.
If you are generating a CVE report with LLM, please use LLM responsibly in helping you reproduce deterministically. Then please do the write up yourself, keep it as concise as possible and strip most adjectives in any LLM generated sections as they cannot help themselves to write without mostly useless exaggerations.