Live data from Hacker News

Cursor 0day: When Full Disclosure Becomes the Only Protection Left

mindgard.ai

181–190 of 222 posts

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#181

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 art…

Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.

Let me introduce you to jetbrains, vscode and nearly every other IDE that relies on an LSP.

Edit: yes I get that there's a trust system, but I know a lot of people just trust everything in a directory.

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#182
post #82
post #40

I'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…

Cloning a repo owns your computer. Is that something you expected?

That's not what's happening.

Using AI tool over that repo does, but you have to launch it before the AV kicks in.

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#183

Earlier quoted context omitted.

Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.

Let me introduce you to jetbrains, vscode and nearly every other IDE that relies on an LSP. Edit: yes I get that there's a trust system, but I know a lot of people just trust everything in a directory.

Both jetbrains and vscode ask you if you trust the project

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#184
post #55

Earlier quoted context omitted.

If bash placed the current directory in your PATH by default, then yes.

Could file a CVE with Microsoft then, cause thats kinda what cmd.exe is doing: > git clone git://evil evil > cd evil\ > git status The last line would execute git.exe from the cloned repo, wouldn't it?

No, `git` uses the binary in path, to use the repo file it should be `./git.exe`

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#185

Earlier quoted context omitted.

Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.

Let me introduce you to jetbrains, vscode and nearly every other IDE that relies on an LSP. Edit: yes I get that there's a trust system, but I know a lot of people just trust everything in a directory.

What repo-binary is executed for the LSP?

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#186

Earlier quoted context omitted.

Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.

Let me introduce you to jetbrains, vscode and nearly every other IDE that relies on an LSP. Edit: yes I get that there's a trust system, but I know a lot of people just trust everything in a directory.

VSCode at least prompts you to trust the project folder before running anything, otherwise it will use a globally installed LSP.

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#187

Earlier quoted context omitted.

Could file a CVE with Microsoft then, cause thats kinda what cmd.exe is doing: > git clone git://evil evil > cd evil\ > git status The last line would execute git.exe from the cloned repo, wouldn't it?

No, `git` uses the binary in path, to use the repo file it should be `./git.exe`

On Linux.

Look for `NoDefaultCurrentDirectoryInExePath` if you want to learn about Windows.

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#188

Uh, you're already beyond fucked if git.exe (or equivalent in *nix) is a hacked one and on your system. And similarly the same doomsday article does not exist for VSCode, Zed, GitKraken, and a billion other tools that run git without caring to ask..

In this case, simply cloning a repository containing such an executable is enough. This isn’t a common bug or a gotcha.

Although on Windows, the current directory is checked before PATH, unlike UNIX-based systems that require the current directory to be explicitly included in the PATH if that's the behaviour you want.

So for any repository with git.exe in the root, if you then ran another git command from a DOS prompt with the repo as your current directory then it would give the same bad outcome of running the git.exe from the repo.

I'm not saying that it's good that it's happening, but it doesn't seem like it's their bug to solve per se, it's just a feature of using Windows. Of course, they probably could work round it by parsing the PATH themselves and locating a git.exe that isn't in the current directory.

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#189

Earlier quoted context omitted.

Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.

We're back to autorun.exe times

but it is just a agents.md file lol

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#190
post #140

On Windows, if your shell was in a malicious repo's directory and you ran any "git" command, wouldn't the behavior be the same? Binaries in the current directory are considered before PATH. This seems like a broader issue. That said, Cursor should at least have some "trust this directory?" dialogue.

Not in powershell, no, because . is not in PATH (unless you put it there).

If you tab-complete `git` it will resolve to `.\git.exe` but it you merely hit enter then it will search PATH and not the CD.

Post reply on HN