Hacker News Reader

Comment by samrus | Hacker News Reader

The title does make it sound like the AI itself lead to the vulnerability, which is false

But cursor isnt off the hook. It wasnt a malicious copy, it was a legit copy of the cursor IDE distirbuting a package they allowed on the extension store. This is on them.

The lesson here is to not make a vscode fork if you arent able to maintian it the way microsoft does. Move fast and break (the user's) things i guess

View on HN

The article says they use open-vsx, which is managed by the Eclipse foundation. It's not really anything to do with cursor, other than the fact they're allowing you access to the only other vscode marketplace that all the forks use.

The biggest "reveal" here is that open-vsx has far less effective anti-fraud measures than the end users of Cursor, Windsurf, etc. expect.

It seems that an attacker was able to easily manipulate download counts, placing their malicious extension high in search results.

And this is far from the first open-vsx vulnerability in the past month. See: https://blog.koi.security/marketplace-takeover-how-we-couldv... which describes how open-vsx was installing arbitrary packages and running their build scripts in a privileged environment.

And the instructions to report malicious extensions, even now, are practically nonexistent: https://github.com/EclipseFdn/open-vsx.org/wiki/Guidelines-o...

With billions of dollars being poured into this ecosystem, it's mind-boggling that security is being treated as such an afterthought. Consider this when choosing tools.

Yes, let's blame the guys working on something for free, instead of the company which raised nearly a billion in VC money but couldn't be bothered to check.

If you run part of the software supply chain ecosystem, put it on the web without any kind of "alpha" or "insecure" language that's highly visible to end users on every package, and even distribute professional white papers and marketing-style landing pages to promote it (e.g. https://outreach.eclipse.foundation/openvsx), but create a deployment architecture that executes arbitrary third party code during every deploy (as was the case before https://github.com/EclipseFdn/publish-extensions/pull/881/fi... landed to fix the issue in the link above) - I do indeed think that the Eclipse Foundation bears some responsibility here.

And for sure, Cursor and others should have funded security hardening of their extension marketplace. The lion's share of the blame lies on that. But the Eclipse Foundation is in a position to incentivize that investment by making it clear to end users that open-vsx is still at an experimental level of stability and security, rather than promoting it as an enterprise-ready product with white papers and all.

There are companies that will provide quality guarantees and product liability insurance for open source software (I work for one in fact), so maybe Cursor should have used one of those.

@rwmj The Eclipse foundation is actually backed by some really big companies. Check out the sponsors page.

(And a fun but irrelevant bonus fact: Eclipse was originally made by IBM)

For sure, but the membership fees these companies pay are really quite small (bottom of this page https://www.eclipse.org/membership/prospectus/), and they mainly go towards infrastructure, running the working groups, and conferences. The projects get some benefits, but they don't get a lot of full time developers (in fact, I'd be surprised if they get even a fraction of 1 FTE), and are largely run either by volunteers or by people doing this in their 20% time in regular day jobs.

In any case, Cursor didn't pay any money here, so they get to keep all the pieces when the code they used for free breaks.

Ah, I see.

I blame my tool, Cursor. They blame their tool, open-vsx. We're either both right about that logic, or both wrong. Either way, I expect consistency in how the product I pay for assigns/accepts blame. Cursor's response will be interesting.

I am not so sure. They don’t own the registry for extension. Even in VSCode I always thought one should be cautious.

Cursor does bear significant responsibility in the sense that OpenVSX transformed from a niche service used by free software nerds into a major component of many developers’ process. There were a few months were Cursor were the scrappy upstarts, but now they’re a $200M/year company and they have $200M/year responsibilities. They can’t just wash their hands of it and pretend OpenVSX is a public service.

I sense a settlement agreement with strong non-disparagement terms is in the works here.

Why in the open source world do goal posts always move? It’s a public open source service. Speaking purely on this vulnerability, it’s an extension listed in the OpenVSX ecosystem. Regardless if Cursor vetted all of these extensions or not I would still be incredibly hesitant like everyone should be.

Now do we need better solutions? Definitely and I do hope cursor will contribute towards it but I won’t hold them to it. They switched to OpenVSX less than a month ago, too soon to really say much at this point.

I didn’t move any goalposts. Cursor set up the goalposts themselves by making a small volunteer-run service a critical component of their massive for-profit product. It’s greedy and irresponsible.

“Open VSX is an open-source registry for VS Code extensions. It can be used by any development environment that supports such extensions.”

Sure sounds like you are moving goalposts around. Of course I hope Cursor contribute back but it’s been 20days and I am not an insider I have no idea what the plan is.

Cursor is off the hook in my system of ethics.

If you're running code without reading it, that's on you.

The exploiter is evil. Cursor has no culpability here.

Yah no that's not how it works. It's the system designer's responsibility to make sure you can run correct code without you reading it.

If you have to read it, then your system has already failed.

Yeah no that is how it works.

I want people to release cool software without the insane burden you describe. If they want to delegate that burden to users or ask them to pay for someone else to assume the burden, great.

I love Cursor. They haven't failed me. I'm not running arbitrary code and I suffer none of the consequences.

Furthermore, it probably literally says you're running random 3rd party code when you use extensions and Cursor is not liable. This is basic human responsibility 101. You are responsible for your own actions.

You've audited the Cursor codebase then? Along with every other tool you use?

No.

I trust Cursor isn't trying to screw me.

I don't trust random 3rd party extensions. They might be trying to screw me. This is the exact reason why I don't touch npm.

I'm not prescribing a formal set of rules by which you should or shouldn't trust things. I'm just a reasonable person.

Cursor is an unrelated 3rd party to this situation, which is probably clearly described in their Terms of Service. Blaming them reeks of denying responsibility for your own actions. If you want Cursor to audit every 3rd party extension, they'd probably want you to pay them for it. Just like every commercially licensed Linux distro.

You understand that the extension was a copy of a genuine extension?

It was a mistake that he installed the duplicate fraudulent extension. For all we know he could have checked the intended extension code line by line, and then went on to install the trojan horse extension by accident.

I mean yeah I see what you're saying and that does add important nuance. It makes me more sympathetic to the user that got screwed.

This seems like a bad faith argument - the risky tools, yes, actually. I do audit them. Or at least poke around for someone who has.

It is easier than ever to do a DIY malware analysis on the tools you use.

“Hi Claude - you are a security researcher and malware analyst. Analyze the FooBar Chrome Browser extension / git repository I just downloaded for security threats and provide me a report on whether this is OK to use”

I know browser / IDE extensions are not usually audited and approved by the tool owner unless specifically noted otherwise. Even phone apps can sneak stuff in. So I am careful to only install things I trust or will audit myself or am willing to take the risk on.

You have to audit the risky tools because the system you are using was terribly designed.

Again, it's the system's responsibility to make sure you don't fail, not your responsibility.

It really is not.

You can dig in your heels on ideals and principles, but it is simply not realistic to expect a 3rd party extension marketplace from a closed source IDE startup run by 24 year olds in the Valley to protect you from all risk. (By the way, nor is it their goal - they are optimizing for breadth of the ecosystem and adoption and growth, not security and guardrails. That would likely cost you a lot more than $20/month.)

If you can figure out how to moderate a system of 3rd party software (or content, really) to protect the user from all bad things while maintaining global-scale content throughput, I suggest you start a company - I’m sure people will pay a lot of money for your capabilities.

most of us haven't read the Linux kernel. Some of us even use closed operating systems like Mac OS, Windows or iOS. So this can't possibly be the right standard.

But it is true that certain types of developers will just download anything and integrate it into their development process. And it's also true that this would have been avoided by executing in a sandbox.

> And it's also true that this would have been avoided by executing in a sandbox.

Until someone runs `cursor ~/.where_i_store_a_bunch_of_secrets` or maybe even `cursor ~/.bashrc`

It's not black and white.

It's reasonable to assume Cursor isn't trying to screw you over and you don't need to audit their code.

It's also reasonable to assume some of the arbitrary 3rd party extensions are trying to screw you over.

You don't have to be so rigid and extreme in your thinking. You can take the reasonable middle ground and make good guesses yourself.

It's not their extension store.

Reply on news.ycombinator.com