[flagged]
Cursor 0day: When Full Disclosure Becomes the Only Protection Left
191–200 of 222 posts
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#192As 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 art…
> 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.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#193First grok cli and now this
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#194Earlier quoted context omitted.
The difference is that I expect "npm install" to execute code, where I do not expect merely opening a repo to look at the files in Cursor to execute anything.
IDEs do syntax highlighting, typechecking, linting, automatic git refreshes. All of this happens in the background without you executing any code. If you open a Typescript project in VS Code and it automatically shows you a list of errors where do you think it got them from? It ran the tsc executable in your node_modules folder.
Visual Studio Code asks you if you trust the files in the folder you open, or at least it always has done for me. Presumably this stuff stops working if you don't?
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#195Earlier quoted context omitted.
Maybe the bug report got ignored because they posted another 1000 slop reports, who knows.
The disclosure seems pretty straight-forward, definitely some LLM assisted writing here, but not nearly as bad as most of the other stuff on this site.
Yes, the question is whether it drowned in a myriad of other LLM "assisted" reports, because that would be a way in which a simple straightforward report could be missed.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#196As 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 art…
Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.
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.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#197I'm not sure I fully agree with this being a major vuln. There's a lot of up front scary text which was raising a lot of red flags until it actually discussed the "what". An actor has to place a malicious .exe in the user's code folder, named git.exe, for this to take place. I see this akin to something like saying "replacing their .bashrc with an alias that says `ls` instead executes `/tmp/mega-big-virus.sh` is a vu…
I clone some repo from github, open it with default code editor which happens to be Cursor. I am cooked. That is it.
It is the same as autorun.exe on some CD - I put some CD in my CD-ROM and my Windows are compromised.
You can argue that I should not clone unknown repos, I should inspect each and any file in the repo, look for git.exe or any other suspicious binary and etc. I should not put untrusted CDs or USB sticks into my computer.
However the reality of it is that it will not be the user who inspects USB stick in some contained environment, it will be security policy which disables autorun. Same as Cursor should disable this.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#198[flagged]
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#199[dead]
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#200Earlier quoted context omitted.
Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.
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 sinc…
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.