node-ipc used by vue.js (and others) compromised

[wbmnfktr]

So... just a short heads-up... a node.js module that's widely used - even in vue.js and well known software - was compromised by its developer.

It seems that the repository was already cleaned-up again, yet in case you installed the module itself or something with it the last couple of days. Take a closer look, clean it up, fork a clean version whatsoever.

https://snyk.io/blog/peacenotwar-malicious-npm-node-ipc-package-vulnerability/

node-ipc-dependencies-list
https://github.com/zlw9991/node-ipc-dependencies-list

Video with some more details about the whole issue.

 

[kongondo]

Where does this leave us with tools like composer?

[wbmnfktr]

I don't get what you are asking. 

Could be that's because I don't know that much about composer.

[kongondo]

I meant composer as a package / dependency manager. It would also be vulnerable to a similar attack.

[kongondo]

Here's a conversation on reddit whether Composer could be susceptible to a similar attack

 

[wbmnfktr]

Oh...kay... now I get it. Sure this could happen in some way in or with Composer as well.
The r/thread is a nice read. 

This whole scenario was always the reason why I rarely used and use NPM or Composer - it's so often a big blackbox.

[teppo]

22 hours ago, kongondo said:

Where does this leave us with tools like composer?

Same place where we've always been, and where we're ultimately going to be with any dependency management solution, automated or manual: risk assessment.

Any time we depend on third party dependencies we're making a choice to trust the vendors of said dependencies (and by extension anyone they trust, and also anyone who might have access to the "pipeline" in between us and those vendors). Whether the benefit is greater than the risk is what matters.

(Sorry for going a bit philosophical with this ?)

As for Composer vs. npm, my opinion is that the situation with Composer is slightly less problematic, simply due to the ecosystem. I don't have numbers to back this, so please take it with a grain of salt, but in my experience relying on numerous interconnected dependencies is more common for npm projects. ProcessWire modules, for an example, tend to have relatively few dependencies, which can be a good thing (in this particular context).

One solution, mentioned in that Reddit discussion as well, is roave/security-advisories. I would recommend adding it to your setups, just in case. It's a super simple package that defines a list of "conflicts", each of those being a package + version with known vulnerabilities. When running composer install or composer update, these conflicts crash the process. This may well be the only "positive use case" for conflicts I've come across ?

It's not a fool proof solution, but a good start — and pretty much a no-brainer, in my opinion.

Another thing that can help is private packagist, which provides automated security audits, alerts, and more. Private packagist is not free, but for commercial users it's definitely something to consider (and not just for the security features).