Live data from Hacker News

Malicious crossenv package on npm

twitter.com

21–30 of 237 posts

Re: Malicious crossenv package on npm

#21
post #11

nodejs lack-of-QA comes back to bite them in the ass yet again. wasn't the first time nor will it be the last time, ditch this bullshit.

Explain to me how "QA" prevents a malicious package from transitively including another one and taking advantage of typo squatting.

Last time I wrote a Firefox extension, the code was manually reviewed before being officially published on addons.mozilla.org (it's there as experimental release with big warning bars while it sits in queue for code review).

To publish an Android app, I need to verify my name by paying Google some money ($25?) and my code has to pass some automated checks.

It seems like anyone can publish just about anything anonymously on npm. That model has upsides, but it's not exactly state-of-the art in terms of QA (though you could argue whether QA is the right term here).

Re: Malicious crossenv package on npm

#22
post #18

Earlier quoted context omitted.

QA prevents someone from adding a typo to the repository.

Your QA teams are looking up every entry in your package.json files, your Maven poms, your Gemfiles, your requirements.txt files? They're making sure that something that builds completely cleanly and shows no external errors doesn't have a typo in it? Of course they're not.

That's a pretty big straw man you wrote there, to imply that getting rid of not-all errors is no better than not getting rid of any errors at all.

In fact, GNU/Linux distros with even minimal QA will disallow network access during builds. Also we do in fact manually audit quite a lot of stuff to make sure this sort of bullshit doesn't get uploaded to the archives.

Re: Malicious crossenv package on npm

#23
This attack has been previously described in the paper "Typosquatting package managers":

Paper: http://incolumitas.com/data/thesis.pdf

Blog post: http://incolumitas.com/2016/06/08/typosquatting-package-mana...

Discussion: https://news.ycombinator.com/item?id=11862217 https://www.reddit.com/r/netsec/comments/4n4w2h/

The paper also discusses possible mitigation measures, including prohibiting registering new packages within a certain Levenshtein distance of existing packages and using additional namespacing.

Re: Malicious crossenv package on npm

#24
post #2

This is important. It looks like the organization is submerging; they've deleted their NPM account and the package and emptied their GitHub repo. This should be signal boosted as hard as it can be managed, because this is rough stuff.

What can be done to help sort problems like this?

Integrating something like https://nodesecurity.io/opensource or https://snyk.io into you're CI process will help flag issues you may want to know about if they are disclosed / discovered.

And yes, I get the irony of adding another dependency to help with the security mess caused by the node ecosystem's bent towards external untrusted / unverified dependencies.

Re: Malicious crossenv package on npm

#25
NPM themselves recently launched a new package called npx [0] which will download and execute packages directly from the registry if you don't already have them installed. So if you make a simple typo like this:

    npx crossenv foo
instead of

    npx cross-env foo
you'd have got the malicious version.

[0] https://www.npmjs.com/package/npx

Re: Malicious crossenv package on npm

#26

Earlier quoted context omitted.

The `left-pad` debacle a year ago[0] should've served as a wake up call to people writing projects with hundreds of dependencies. [0]: http://left-pad.io

It's next to impossible for the average team to avoid hundreds of dependencies as their project grows though. You could write your own everything, but then what's the benefit of the node ecosystem? Edit: spelling

How many of those dependancies are trivial though? It's one thing to rewrite express, but something different to rewrite a package that just contains a function that capitalizes the first letter of a string or something similarly contrived, yet plausibly already a package.

Re: Malicious crossenv package on npm

#27

Earlier quoted context omitted.

The `left-pad` debacle a year ago[0] should've served as a wake up call to people writing projects with hundreds of dependencies. [0]: http://left-pad.io

It's next to impossible for the average team to avoid hundreds of dependencies as their project grows though. You could write your own everything, but then what's the benefit of the node ecosystem? Edit: spelling

[deleted]

Re: Malicious crossenv package on npm

#29
post #25

NPM themselves recently launched a new package called npx [0] which will download and execute packages directly from the registry if you don't already have them installed. So if you make a simple typo like this: npx crossenv foo instead of npx cross-env foo you'd have got the malicious version. [0] https://www.npmjs.com/package/npx

crossenv was already running the script on post install, which means it was run on "npm i crossenv" anyway.

Re: Malicious crossenv package on npm

#30

Earlier quoted context omitted.

The `left-pad` debacle a year ago[0] should've served as a wake up call to people writing projects with hundreds of dependencies. [0]: http://left-pad.io

It's next to impossible for the average team to avoid hundreds of dependencies as their project grows though. You could write your own everything, but then what's the benefit of the node ecosystem? Edit: spelling

I wish the node ecosystem would learn from more mature ones.

I would like to see a curated set of popular libraries that are stabilized and blessed, and a core group that handles security updates and upgrading packages in the blessed set.

Post reply on HN