Live data from Hacker News

Embedded malware in RC (NPM package)

github.com

31–40 of 117 posts

Re: Embedded malware in RC (NPM package)

#31

See also the ongoing discussion about malware in "Coa", another NPM package: https://news.ycombinator.com/item?id=29116878

Also recent:

NPM package ‘ua-parser-JS’ with more than 7M weekly download is compromised - https://news.ycombinator.com/item?id=28962168 - Oct 2021 (141 comments)

Re: Embedded malware in RC (NPM package)

#32

If you're interested in preventing this sort of thing, I'd appreciate comments on this [RFC]( https://github.com/npm/rfcs/pull/488 ) I just submitted to npm to make install scripts opt-in instead of default behavior . While of course not perfect, this simple change would certainly go a long way in increasing the difficulty in creating these sorts of attacks, as right now as long as a computer even installs the packag…

Isn't that only useful for the very rare minority of people that install packages then don't run the code right after? :)

Re: Embedded malware in RC (NPM package)

#33

I've created Vouch in an attempt to address this problem: https://github.com/vouch-dev/vouch Vouch lets users create and share reviews for NPM packages. Project dependencies can then be checked against those reviews. Vouch uses extensions to interface with package ecosystems. It's simple to create a new extension. Extensions currently exist for NPM, PyPi, and Ansible Galaxy. I'm currently working on a website to inde…

Sounds really interesting. I'm kinda scared to use npm right now to be honest. What dangers may be hidden deep in the dependency trees? But is a review of every update then done, because rc used to be a legit package?

Re: Embedded malware in RC (NPM package)

#34

I've created Vouch in an attempt to address this problem: https://github.com/vouch-dev/vouch Vouch lets users create and share reviews for NPM packages. Project dependencies can then be checked against those reviews. Vouch uses extensions to interface with package ecosystems. It's simple to create a new extension. Extensions currently exist for NPM, PyPi, and Ansible Galaxy. I'm currently working on a website to inde…

I'd like this to work, but it seems like it relies on packages being statically "good" or "bad" - what happens if a package is legitimately well trusted but then the main dev gets backdoored and a bit of extra code is injected?

Re: Embedded malware in RC (NPM package)

#35
This is like the third one this week right?

I know people keep saying about post-install should be opt out but then malware will just wait for first run instead.

How about an option to refuse to install any packages that have been published in the past week/2 weeks? That way hopefully malware like this would have been spotted before you end up running it locally.

Re: Embedded malware in RC (NPM package)

#36

I've created Vouch in an attempt to address this problem: https://github.com/vouch-dev/vouch Vouch lets users create and share reviews for NPM packages. Project dependencies can then be checked against those reviews. Vouch uses extensions to interface with package ecosystems. It's simple to create a new extension. Extensions currently exist for NPM, PyPi, and Ansible Galaxy. I'm currently working on a website to inde…

That's not really the solution for this problem, though, which is very specifically when a project maintainer's account gets compromised, so then the bad guys publish a new malicious version of that library that gets picked up by anyone using non-pinned NPM versions (i.e. most everyone).

There are a couple more straightforward ways to do this:

1. Require 2FA, ideally hardware key 2FA, for anyone publishing a package with any sizable following.

2. Make running of preinstall/install scripts opt-in.

3. Make the semantic versioning syntax optionally more restrictive. If I specify I want version ^2.2.1, I'd like to be able to specify that I DON'T want to pull 2.2.2 the moment it becomes available, but perhaps want some amount of latency before pulling that.

Re: Embedded malware in RC (NPM package)

#37
post #32

If you're interested in preventing this sort of thing, I'd appreciate comments on this [RFC]( https://github.com/npm/rfcs/pull/488 ) I just submitted to npm to make install scripts opt-in instead of default behavior . While of course not perfect, this simple change would certainly go a long way in increasing the difficulty in creating these sorts of attacks, as right now as long as a computer even installs the packag…

Isn't that only useful for the very rare minority of people that install packages then don't run the code right after? :)

I initially had the same thought, but I came to a different conclusion because the presence of an install script is not a given for most packages.

For example, if I installed a command line arguments parser and it claimed to require running a setup script, I would immediately be very suspicious.

For a huge package like TypeScript, I'd probably just immediately let the script run and trust Microsoft to not publish malware (and NPM to not change the package contents).

Re: Embedded malware in RC (NPM package)

#39
post #18

Earlier quoted context omitted.

Ok, now, what languages beside Python and Go provide Command line argument parsing? And Go doesn't do that in a `professional` way. You either write your own, which can easily turn into a clusterfuck or use a third party library. Even in Go, people use cobra[1]. Also embedding a lot of functionality in a standard library isn't great as well, because if some vulnerability is found, it's really hard to patch it, becaus…

> what languages beside Python and Go provide Command line argument parsing? Even POSIX gives you getopt(1) and getopt(3). What other language doesn't? I can only think of Java.

Sure, and Node gives you the process.argv array. The point is having higher level APIs than that.

Re: Embedded malware in RC (NPM package)

#40
post #23

Earlier quoted context omitted.

But attackers are not dumb. They would circumvent whether loose checks the package manager may have. Just considering your suggestion, the obvious immediate exploit is to not deploy the attack payload right away. Nothing you will think of will evade defeat.

I agree that it is an unending arms race, but if NPM doesn't even plug obvious holes (like running install scripts by default), then they've lost my trust. Edit: if anyone knows of a way to disable NPM from running install scripts automatically (without having to remember to specify --ignore-scripts on each invocation), while still allowing me to use "npm run" to manually run scripts (e.g. test scripts for my own pac…

npm ci --ignore-scripts
Post reply on HN