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

41–50 of 222 posts

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

#41

Post by beart »

827a wrote: post #34

Frankly, if you git clone a compromised repository, I'm not sure that a vulnerability of the class "compromised code in that repository will be executed" is all that major a concern. There are plenty of IDEs that will go autonomously run npm installs (with post-install scripts) for you when they detect a package.json. This isn't all that different than that. They could throw up a warning like "do you trust this repos…

A lot of malware was delivered back in the day via Windows AutoPlay feature. Someone plugs a USB drive in and bam, they are immediately exploited. You could say it's always a problem if the USB drive is already full of malware. However, Microsoft disabled AutoPlay in Windows 7 (and backported this fix) specifically to address this vulnerability.

This exploit feels very similar to me. I don't know if there's a specific name for this classification of AutoPlay issues.

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

#42

Post by shitter »

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.

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

#43

Post by arcticfox »

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…

I am not at all a security expert, but isn't this akin to giving a repo-owner RCE if you just clone their repository and open it? I feel like that's not an implied contract for opening a folder in your IDE.

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

#44

Post by beart »

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…

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.

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

#46

Post by zeroq »

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…

This is very similar to 30yo exploit in which you placed an alternative, infected dll inside a folder with mp3s (winamp), or photos (windows picture viewer).

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

#47

Post by awongh »

beart wrote: post #38
awongh wrote: post #35

I guess this is only specific to a file in the root of the repo, so it doesn't allow for an NPM supply chain attack?

It has nothing to do with npm. However, a binary could be configured to extract your git/npm secrets using this exploit, which could then lead to a npm supply chain attack (or pip, etc. etc.).

I meant the attack would be the other way around- if an infected package had the git.exe file in their root.

Or, the infected package could also copy that file into the parent project's root.

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

#48

Post by shitter »

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?

Since there are no approval dialogs, it sounds like that doesn't even come into play here. That is the "gate" (to use the AI parlance) that Microsoft places on code execution in workspaces, though, and I would expect Cursor to at minimum fix this to only execute git.exe in trusted workspaces.

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

#50

Post by beart »

awongh wrote: post #47
beart wrote: post #38

Earlier quoted context omitted.

It has nothing to do with npm. However, a binary could be configured to extract your git/npm secrets using this exploit, which could then lead to a npm supply chain attack (or pip, etc. etc.).

I meant the attack would be the other way around- if an infected package had the git.exe file in their root. Or, the infected package could also copy that file into the parent project's root.

Oh yeah that's a good point - two layers of auto executing scripts/binaries.
Post reply on HN