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

Snyk security researcher deploys malicious NPM packages targeting cursor.com

sourcecodered.com

Post reply on HN
Print view View original

261–270 of 331 posts

Re: Snyk security researcher deploys malicious NPM packages targeting cursor.com

#261

Post by nightpool »

krainboltgreene wrote: post #249
ziddoap wrote: post #237

Earlier quoted context omitted.

> If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area? This would be where different security advice would apply: don't pull in a package that has 400 dependencies.

Given the nature of software development and software developers, especially given American companies decide to value shareholder profits over programmer productivity, this might as well be effectively "You don't need to get vaccines, simply don't get sick from other people."

Out of curiosity, I've always meant to ask, are you related to the famous Geoguesser content creator in any way? It's a pretty distinctive last name.

Re: Snyk security researcher deploys malicious NPM packages targeting cursor.com

#262

Post by tristor »

chamomeal wrote: post #250
gortok wrote: post #235

The only part of the article I disagree with is this line: > But in general, it’s a good idea not to install NPM packages blindly. If you know what to look for, there are definite signals that these packages are dodgy. All of these packages have just two files: package.json and index.js (or main.js). This is one of several flags that you can use to determine if a package is legit or not. This works -- maybe OK for to…

Wait how in the world does a React carousel component have over 400 deps…

Because Javascript is a drug that makes developers stupid.

It's almost trite at this point to comment on the obsession that Node has created with developers to reduce functionality to the smallest possible reusable parts, even trivial things, and publish them as packages, then to import and use those dependencies. The idea, in and of itself, is not terrible, but it's been taken to a logical extreme which is very much the definition of terrible.

Re: Snyk security researcher deploys malicious NPM packages targeting cursor.com

#263

Post by austinkhale »

dannyallan wrote: post #222

Snyk Research Labs regularly contributes back to the community with testing and research of common software packages. This particular research into Cursor was not intended to be malicious and included Snyk Research Labs and the contact information of the researcher. We were very specifically looking at dependency confusion in some VS Code extensions. The packages would not be installed directly by a developer. Snyk d…

Upvoting this since presumably you're actually the CTO at Snyk and people should see your official response, but wow this feels wildly irresponsible. You could have proved the PoC without actually stealing innocent developer credentials. Furthermore, additional caution should have been taken given the conflict of interest with the competitor product to Cursor. Terrible decision making and terrible response.

Re: Snyk security researcher deploys malicious NPM packages targeting cursor.com

#264

Post by woodruffw »

manquer wrote: post #117
woodruffw wrote: post #54

Earlier quoted context omitted.

Conspiracies and politics aside, the reasons for the prominence of 8200 are somewhat boring: it's the largest unit in the IDF, in a relatively small country. Teenagers who demonstrate just about any degree of technical savviness get funneled into it for their mandatory service. It's the equivalent of observing that SFBA startups tend to have a lot of Stanford grads at the helm. (I don't have any particular love for S…

Talent or skills is essential but alone is not enough. while the size and quality of the talent pool helps it is not sufficient to explain the success rate, considering that there are similar or better quality talent pools which are larger in many countries around the world, but they don't have the success rates Israeli startups and 8200 ones specifically have compared to their home market and talent pool size. It is…

Right, it's not about talent. It's the fact that it's an extremely strong network with a flywheel between defense spending and startup tech. The same things that make the US's startup industry indefatigable.

Re: Snyk security researcher deploys malicious NPM packages targeting cursor.com

#265

Post by krainboltgreene »

nightpool wrote: post #261
krainboltgreene wrote: post #249

Earlier quoted context omitted.

Given the nature of software development and software developers, especially given American companies decide to value shareholder profits over programmer productivity, this might as well be effectively "You don't need to get vaccines, simply don't get sick from other people."

Out of curiosity, I've always meant to ask, are you related to the famous Geoguesser content creator in any way? It's a pretty distinctive last name.

I believe he might be a distant cousin. I've done some family tree searching myself and haven't found many things, since the Rainbolt side has mostly been scoundrels and vagabonds there aren't many details, but we do have a mountain that we named after ourselves after we stole it from natives.

Re: Snyk security researcher deploys malicious NPM packages targeting cursor.com

#266

Post by LtWorf »

dagw wrote: post #170
mcherm wrote: post #169

Earlier quoted context omitted.

> The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month. I don't actually think that is a bad thing. The TSA screening at airports would be vastly better if TSA maintained a "red team" that regularly tried smuggling guns (or water bottles or whatever) into airports. The agents would be more attentive if the number of incidents they dealt with was…

The TSA screening at airports would be vastly better if TSA maintained a "red team" that regularly tried smuggling guns They actually do have this. TSA seem to still suck at their job: https://www.forbes.com/sites/michaelgoldstein/2017/11/09/tsa... https://www.gao.gov/products/gao-19-374

You'd also suck if you knew your job is useless busywork.

Re: Snyk security researcher deploys malicious NPM packages targeting cursor.com

#267

Post by LtWorf »

nomilk wrote: post #30
n2d4 wrote: post #15

[EDIT: See the response by a Cursor dev below — looks like it was not authorized by them] Sounds to me like Cursor internally has a private NPM registry with those packages. Because of how NPM works, it's quite easy to trick it to fetch the packages from the public registry instead, which could be used by an attacker [0]. Assumably, this Snyk employee either found or suspected that some part of Cursor's build is misc…

> If that's the case, then there's not much to see here. Allowing someone full access to the contents of your environment (i.e. output of env command) is a big deal to most, I suspect.

If /proc is mounted you can read all of that.

Re: Snyk security researcher deploys malicious NPM packages targeting cursor.com

#268

Post by cloverich »

chamomeal wrote: post #250
gortok wrote: post #235

The only part of the article I disagree with is this line: > But in general, it’s a good idea not to install NPM packages blindly. If you know what to look for, there are definite signals that these packages are dodgy. All of these packages have just two files: package.json and index.js (or main.js). This is one of several flags that you can use to determine if a package is legit or not. This works -- maybe OK for to…

Wait how in the world does a React carousel component have over 400 deps…

History of "micro dependencies" where many flexible utilities are split up into separate packages, such that many npm dependencies are a single function (ie rather than a package exporting ten methods, its ten separate dependencies).

Then because there is no standard library, many reinventions of similar but incompatible utilities. etc.

Re: Snyk security researcher deploys malicious NPM packages targeting cursor.com

#269

Post by wyldberry »

krainboltgreene wrote: post #249
ziddoap wrote: post #237

Earlier quoted context omitted.

> If you're pulling in a package that has 400 dependencies, how the heck would you even competently check 10% of that surface area? This would be where different security advice would apply: don't pull in a package that has 400 dependencies.

Given the nature of software development and software developers, especially given American companies decide to value shareholder profits over programmer productivity, this might as well be effectively "You don't need to get vaccines, simply don't get sick from other people."

Things like this are suppose to be provenance of an organizations security engineering teams. Helping to ensure you don't ship something like this. It's also hard for them too because no one wants to force developers to re-implement already solved functionality.

Re: Snyk security researcher deploys malicious NPM packages targeting cursor.com

#270

Post by __MatrixMan__ »

beardedwizard wrote: post #257
XorNot wrote: post #253

Earlier quoted context omitted.

This is really where SELinux had the right idea overall: preclassifying files with data about their sensitivity, and denying access based on that, does adequately solve this problem (i.e. keeping npm installations away from id_rsa).

The issue with SElinux is usability. A company called intrinsic tried a similar "allowlist" approach to javascript based on the assumption that you could never control this sprawl and had to assume every package was malicious. I never saw the technology take off because generating the allowlist was of course error prone. im not sure what has to change in UX to make these approaches more palatable, but if you have to…

I think we need to to focus on empirical consensus rather than taking as authoritative some file which makes claims about what a particular piece of software will or won't do.

So before running any code you'd hash it and ask your peers: "what do we think this does?"

If it does something surprising, you roll back its effects (or maybe it was in a sandbox in the first place) and you update your peers so that next time they're not surprised.

I keep saying "you" but this would just be part of calling a function, handled by a tool and only surfaced to the user when they ask or when the surprising thing happens.

It could be a useful dataset both for maintainers and for people who want to better understand how to use the thing.

Post reply on HN