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

Embedded malware in RC (NPM package)

github.com

Post reply on HN
Print view View original

51–60 of 117 posts

Re: Embedded malware in RC (NPM package)

#51

Post by tolmasky »

forty wrote: post #32
tolmasky wrote: post #10

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? :)

The fact that they don't need to be run is what makes them so hard to spot and easy to sneak in. This allows for some very hard to mitigate strategies. It's easier to sneak in packages into metadata files like package.jsons than create "excuses" to import files that aren't really needed. It can be abused in more complicated ways as well, like for example:

1. You add a totally "safe" dependency that you control, let's call it "shell-dependency", as an innocuous part of a PR to a "popular-package". Again, even if you inspect this package, it's totally fine. The current version of shell-dependency is 1.0.0, but it of course goes into the package.json as "1.x.x"

2. You now add malicious dependency to shell-dependency, and bump shell-dependency to 1.0.1, meaning every consumer of "popular-package" now gets your "malicious-package".

Notice that this was accomplished with zero traceable GitHub history. Unless every package up the line uses a package-lock.json (which is explicitly recommended against unless you are an end-user application), "malicious-package" is able to enter the dependency chain undetected. If it required some sort of code import, then it would have more opportunities to be spotted. There are of course ways to do this with attacks that require running code as well, but this makes it super easy, especially considering that people often install packages as root, even when they run their apps not as root.

Re: Embedded malware in RC (NPM package)

#52

Post by rndhouse »

yjftsjthsd-h wrote: post #46
rndhouse wrote: post #43

Earlier quoted context omitted.

That extra code will stand out as not having been reviewed.

Oh, you mean to have reviewers look at every line of every version (at least cumulatively). Yes, that would work, and while the effort is significant I appreciate that it's the effort you'd want regardless so this helps share the load.

That's right! The purpose of Vouch is to continually decrease the cost of the review process with each new review.

Re: Embedded malware in RC (NPM package)

#53

Post by morelisp »

afavour wrote: post #39
morelisp wrote: post #24

Earlier quoted context omitted.

> 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.

getopt is a higher-level API. process.argv is equivalent to, uh, argv.

Re: Embedded malware in RC (NPM package)

#54

Post by schemescape »

Ginden wrote: post #40
schemescape wrote: post #26

Earlier quoted context omitted.

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

Ah, sorry, I meant a way to automatically do that (both so I don't have to type as much and so that I can't accidentally forget to add that argument). Edited my comment to reflect this.

Re: Embedded malware in RC (NPM package)

#55

Post by Me1000 »

forty wrote: post #32
tolmasky wrote: post #10

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? :)

Many packages on npm are not run in a local node environment, they run in a browser which is sandboxed.

Regardless, just because there are additional vectors to exploit the user doesn't mean closing off one vector isn't worth doing.

Re: Embedded malware in RC (NPM package)

#56

Post by morelisp »

megumax wrote: post #28
morelisp wrote: post #24

Earlier quoted context omitted.

> 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.

POSIX is not ISO C or C++ standard. On Windows, what are you gonna do? Also, other languages are Rust, Kotlin, Swift (to name a few `modern` ones). Yes, Kotlin and Swift have `first class` CLI parsing libraries, but they are not part of standard library.

"First-party" is distinct from "first class". The difference between a first-party library and the standard library ranges from "slightly weaker compatibility guarantees" to "it's supported in all environments where it makes sense, but the language can run unhosted so that's not everywhere" to "no difference at all, we just didn't want to package it with the compiler".

You're also missing the forest for the "well actually" trees: Lots of languages have argument parsing in their stdlib.

Re: Embedded malware in RC (NPM package)

#57

Post by bluefox »

Is the advisory genuine?

It links to the github repo, where the latest commit is from 2018 for version 1.2.8.

It links to npmjs page, that shows 48 versions, where the latest version is 1.2.8 from "3 years ago".

Yet it has 1.2.9/1.3.9/2.3.9 for "Affected versions".

Did npmjs "revert" these versions and any clue of their existence? The npmjs page links to dominictarr's repository. The npmjs site doesn't seem to have a "who owns this package name" besides the repository/homepage links. Very confusing.

I remember some years ago there was some story involving the original author's handing maintainership rights to some shady dude. Is it about that time, or is it about something more current?

Re: Embedded malware in RC (NPM package)

#58

Post by schemescape »

rndhouse wrote: post #30

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…

> The check command generates an evaluation report of local project dependencies based on available reviews:

Is there an example of a generated report?

Re: Embedded malware in RC (NPM package)

#59

Post by ant6n »

madjam002 wrote: post #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.

If everybody waits two weeks, then nobody will notice it on the first two weeks.

Re: Embedded malware in RC (NPM package)

#60

Post by bluefox »

hjek wrote: post #2

More info: https://therecord.media/malware-found-in-coa-and-rc-two-npm-...

Thanks.

> Since then, the npm security team has removed all the compromised coa and rc versions to prevent developers from accidentally infecting themselves.

Removing all trace of evidence is not something "security teams" should do. Instead of sweeping security incidents under the rug (where twitterverse resides), they should at least mention the existence of these versions and that they contain malware on the package page.

Post reply on HN