Live data from Hacker News

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

mindgard.ai

101–110 of 222 posts

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

#101
post #64

Earlier quoted context omitted.

The CVE process itself is broken. HackerOne and company VDPs are inundated with new reports of varying quality thanks to the advancements (I think) in agentic AI. It's allowed for both an increase in trash-tier low quality AND legitimately high quality reports. Since the same AI's are writing both, its almost impossible to distinguish between the two at a surface level. In response, companies just aren't responding l…

As someone on the company response side of the HackerOne brokenness, I can confirm that this effect is real but would also note that the difficulty of distinguishing is not as severe as all that, because the companies have access to the source code which the researchers do not typically have access to. This means that the token cost of verifying any given HackerOne report is dramatically lower than the token cost of…

[deleted]

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

#102
post #87
post #66

Earlier quoted context omitted.

This attack is exactly why IDE's have a concept of trusted and untrusted locations.

That is a very recent addition. The exact behavior they are describing was in VS Code for almost a decade.

Trusted locations were added to VSCode in 2021.

https://code.visualstudio.com/updates/v1_57

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

#103
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…

I agree, this isn't a vulnerability at all. Now that it's public, I'm not even sure I would do anything about it if I were them.

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

#104
post #94

Clone a repo and run "npm install" and the exact same thing will happen. You can say "oh I would never run npm install on a repo I don't trust"...but then why are you cloning it and opening it in an IDE in the first place? Especially an IDE whose entire purpose is to run autonomous coding agents?

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.

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

#105
post #102
post #87

Earlier quoted context omitted.

That is a very recent addition. The exact behavior they are describing was in VS Code for almost a decade.

Trusted locations were added to VSCode in 2021. https://code.visualstudio.com/updates/v1_57

And VS Code was released in 2015.

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

#106
post #73
post #44

Earlier quoted context omitted.

This doesn't require anyone placing anything deliberately on your machine (as in, needing to exploit it somehow ahead of time). It could be as simple as checking out a branch to review, where the author of the branch has added the .exe.

I'd say checking out a malicious branch is in the same category as downloading a malicious attachment. By which I mean, it's kinda on you.

Okay... but when "you" is a junior engineer on your team and now you are suddenly spending your entire weekend dealing with malware, it's kinda on you as well.

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

#107
post #76

Earlier quoted context omitted.

I’ve never got my head around how it’s apparently the done thing these days to just copy a bash command from a website and run it (sometimes with sudo! O.o ) to install software. I somewhat naively hope that this is because everyone is pushing single purpose VMs for that kind of install, but really I know better.

> to just copy a bash command from a website and run it (sometimes with sudo! O.o ) to install software. how is that different from the good old days of wget ftp://ftp.something.org/software-2.10.tar.gz tar zxfv ./configure make sudo make install ?

They’re both executing unknown code, but hopefully the ftp site here is at least a trusted one, and if you feel paranoid you can verify the archive’s hash to help verify it hasn’t been monkeyed with.

Also the archive probably won’t go and fetch a bunch of other scripts and run them (probably…) while doing so is usually the script’s primary purpose. So you’re not just trusting the people who published the script, at the time they published it. You’re trusting them and everyone they trust to still be good actors now.

That’s different to it being the standard way to install self-published bundles of scripts from all over the internet.

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

#108
post #64

Earlier quoted context omitted.

The CVE process itself is broken. HackerOne and company VDPs are inundated with new reports of varying quality thanks to the advancements (I think) in agentic AI. It's allowed for both an increase in trash-tier low quality AND legitimately high quality reports. Since the same AI's are writing both, its almost impossible to distinguish between the two at a surface level. In response, companies just aren't responding l…

As someone on the company response side of the HackerOne brokenness, I can confirm that this effect is real but would also note that the difficulty of distinguishing is not as severe as all that, because the companies have access to the source code which the researchers do not typically have access to. This means that the token cost of verifying any given HackerOne report is dramatically lower than the token cost of…

The token cost of a report is lower bounded by the number of tokens in the report * price per token of the cheapest model. The token cost of a good report is much higher, but sifting out the good reports is the entire problem.

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

#109
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…

I agree, this isn't a vulnerability at all. Now that it's public, I'm not even sure I would do anything about it if I were them.

You think opening a git repo I just cloned should execute code in that repo?

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

#110
post #94

Clone a repo and run "npm install" and the exact same thing will happen. You can say "oh I would never run npm install on a repo I don't trust"...but then why are you cloning it and opening it in an IDE in the first place? Especially an IDE whose entire purpose is to run autonomous coding agents?

Cursor is an editor. Why is it executing untrusted code when a folder is opened? Opening a folder is not equivalent to executing a script contained in the repo. How can you think that is ok?
Post reply on HN