Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mindgard.ai

Post reply on HN
Print view View original

211–220 of 222 posts

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

#211

Post by hnfong »

cute_boi wrote: post #136
shitter wrote: post #100

Earlier quoted context omitted.

? Doesn’t the code exec happen upon merely launching Cursor against a repository, without giving an agent any tasks? That’s clearly an issue at the Cursor application level, not some inevitable risk caused by the non-deterministic nature of LLMs. You can’t use the latter fact to excuse the former mistake Not to mention that Cursor has an agent permissions model that this presumably sidesteps!

I agree cursor can fix the issue, but the main issue is downloading anything from untrusted source. The repo may have AGENTS.md which can tell please install npm package from random repo and run pnpm start etc... We should never ever download any pdf or excel macros etc.. from untrusted source.

If we take your logic to the extreme, then there are never any legitimate code execution vulnerabilities in web browsers since the user is not supposed to visit untrusted websites.

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

#212

Post by undecisive »

orphereus wrote: post #37
firer wrote: post #28

All too common... It's sad yet understandable how a company would not prioritize security. At the same time, it's also understandable how a security start-up, upon (rightly) getting fed up waiting, decide to publicly disclose, as a way to scrape some PR out of the sunk cost. Public disclosure has a place. But if you truly care about helping, you could do more than bumping on HackerOne and messaging the CISO once on L…

This comment is so weird. It is so vague to me and feels so off, like an alien from Men in Black trying to pass as a human. How do they not truly care about helping? Also what sunk cost? What does that mean?

We're in the worst of all worlds. Sometimes it feels like you only know it's a human because the AI would have over-explained.

But yeah, this security company only prodded, what, once or twice a month for 7 months? I mean, if they really truly cared, they would have found the CISO's home address, broken into their house, painted the reproduction steps on the inside of their front door (to avoid accidental disclosure), created a few "beginner friendly" repos with a git.exe that DDoS's their auth servers, got a job as a night cleaner in their offices, waited for one of the developers to leave their machine unlocked then fixed the vuln themselves.

It's just another capitalistic money grab, them posting their security concerns. Ugh.

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

#213

Post by hnfong »

melodyogonna wrote: post #176
jjcm wrote: 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…

People are offloading a lot of responsibilities to tools. If you pull a repository from Github without doing due diligence then you can't blame Cursor for getting compromised

So I clone a repo from Github and try to do due diligence before compiling and executing the code. I open the project with my IDE/text editor, and boom, I get pwned while doing the due diligence.

Unless it's Cursor's stance that people should use Emacs or whatever to check the repo before opening it, this is "you're holding it wrong" level stupid gaslighting.

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

#214

Post by psd1 »

physix wrote: post #114

Wouldn't this be something a virus scanner would detect and quarantine? Not an active Windows user, but I can't imagine any sane person working on Windows OS without malware protection.

The reason you need AV on windows is because you are a granny who gets an "FBI" warning on a dodgy webpage and clicks the "pwn my shiz" button.

If you don't install trojans, you don't need AV. If you do install trojans, switching OS won't help.

I'm not sure which is the trojan in TFA - the mooted malicious git binary, or the agent. I can't imagine any sane person letting an agent near anything they care about. All your keys are belong to us.

I guess you fell into a coma before Heartbleed, so here's what you missed: desktop OS security became irrelevant when otherwise-sane people started installing npm and buying smart TVs. And, latterly, giving shells to actors that have no ethics and no consequences.

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

#216

Post by [deleted] »

frabera wrote: post #184
lyu07282 wrote: post #86

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`

[deleted]

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

#217

Post by hack1312 »

himata4113 wrote: post #181
hack1312 wrote: post #168

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.

There’s no trust system by default in Cursor because they ship that feature disabled.

https://cursor.com/docs/agent/security#workspace-trust

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

#218

Post by hack1312 »

dclowd9901 wrote: post #31

This draws to mind the dialog that opens when you open a new project in Cursor (and VSCode too, I think), where the IDE asks the user if they trust the project they're opening. Is Cursor under the impression that this is sufficient security apparatus?

Cursor, being based on VSCode, does have the Workspace Trust feature.

They ship it disabled.

https://cursor.com/docs/agent/security#workspace-trust

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

#219

Post by preg_match »

shitter wrote: post #42
jjcm wrote: 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…

The user's code folder? You mean the code I frequently pull from untrusted sources, unlike my .bashrc? Opening a GitHub project for review should not mean arbitrary code execution. Of course, that ship has long sailed, for all major IDEs. Heck, VSCode SSH and devcontainer remotes allow RCE by design.

These days I run absolutely everything dev related inside of podman containers, no node or anything on my host. But even that's not enough, because the IDE support for that is lacking and those tools expect host binaries to be available. I can largely get around it with ro mounts and such but it's very annoying.

Containers are really good now, there's zero reason why every extension and LSP isn't containerized.

Also agents inside a container. It's very nice because I have zero trust for harness permission systems. But again, why aren't the tools designed from the ground up to be containerized?

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

#220

Post by varenc »

psd1 wrote: post #190
varenc wrote: 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.

great point! Though what about the default windows APIs for 'calling out to shell'. Like using `subprocess.run(...)` in Python. My suspicion is that works like cmd.exe?

edit: answered myself. Seems like subprocess.run works like PowerShell, unless you pass in 'shell=True', then it passes it directly to CMD.exe. And I'm guessing that's what Cursor is doing.

Post reply on HN