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

71–80 of 117 posts

Re: Embedded malware in RC (NPM package)

#71

Post by matheusmoreira »

thrashh wrote: post #23
schemescape wrote: post #21

Earlier quoted context omitted.

Given that these attacks are becoming increasingly common, package registries could at least install each package (prior to publishing) in some isolated container or VM and then run some similar malware detection on the resulting file system. Honestly, I'm strongly considering moving away from the NPM ecosystem because it's clearly become a target for malware.

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.

> Nothing you will think of will evade defeat.

Trust. Why is it that random people can submit packages? Make it so they can't. Only trustworthy people should be able to do that. People who care, so that we don't have to. People we can trust. This is how Linux distributions work and you just don't see malware randomly making its way into official repositories.

Re: Embedded malware in RC (NPM package)

#73

Post by schemescape »

jffry wrote: post #62
schemescape wrote: post #54

Earlier quoted context omitted.

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.

You can run this npm config set ignore-scripts true which will update ~/.npmrc (you can also create project-specific .npmrc files if you prefer) You can see how NPM has been configured by running npm config list

That breaks “npm run” (violating the second part of my request).

Re: Embedded malware in RC (NPM package)

#74

Post by dane-pgp »

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

The registry could send an email to the account which uploaded the package saying "Thank you for uploading version 1.2.3 of your-package." which would give them two weeks to think "Wait, I didn't upload a new version."

Of course, if the attacker has access to their npm account, they can probably change the email address associated with the account too, so change-of-email requests should send a "Thank you for changing your email address" to the original address.

The developer might have difficulty regaining control of the account, but hopefully they could inform the npm security team who could quite quickly confirm that a malicious package had been uploaded, which would be enough to get the malicious package taken down and the account locked.

Re: Embedded malware in RC (NPM package)

#75

Post by jffry »

schemescape wrote: post #73
jffry wrote: post #62

Earlier quoted context omitted.

You can run this npm config set ignore-scripts true which will update ~/.npmrc (you can also create project-specific .npmrc files if you prefer) You can see how NPM has been configured by running npm config list

That breaks “npm run” (violating the second part of my request).

The manpage says that directly invoking a script from package.json with `npm run X` aka `npm run-script X` will still work with this preference set to true, but that it will not run pre/post scripts. Perhaps that is good enough for your use-case?

  npm help run-script
  
   [...]
   ignore-scripts
       o Default: false
       o Type: Boolean
       If true, npm does not run scripts specified in package.json files.

       Note  that  commands  explicitly  intended to run a particular script, such as npm
       start, npm stop, npm restart, npm test, and npm run-script will  still  run  their
       intended  script  if  ignore-scripts  is  set,  but  they will not run any pre- or
       post-scripts.

Re: Embedded malware in RC (NPM package)

#76

Post by dane-pgp »

hn_throwaway_99 wrote: post #25

One of the thing I wish was really much easier to do with NPM is, when running `npm update`, to only pick up the most recent compatible versions from X days ago . That is, for sensitive apps, I don't want to use versions that are less than, say, a month or so old unless I specifically override it. I want to stay up-to-date but not too bleeding edge, specifically to avoid situations like this.

That would be a big improvement, but I assume that people would override this check whenever they were updating a package to fix a minor accidental vulnerability that had been found in it (detected by an "npm audit").

An attacker who had control over an account would wait until just such a moment to add their own version which includes a much worse payload, and people would rush to download it, thinking they were just installing a fix for the minor vulnerability.

Re: Embedded malware in RC (NPM package)

#77

Post by rndhouse »

throwaway984393 wrote: post #69
rndhouse wrote: post #45

Earlier quoted context omitted.

Reviews in Vouch refer to a particular version of a software package. If a new release is issued by a malicious actor, the new release would require a new review. But the review process does not need to re-start from scratch. Reviews from other versions can be used to lessen the workload. On the subject of automatically updating packages: the Vouch dependency analysis can be included in CI. Un-reviewed or review fail…

Who's reviewing the software package's dependencies?

Each dependency of a software package would have its own separate set of reviews.

Anyone can produce a review using Vouch. Official reviews will also be published in the future.

Re: Embedded malware in RC (NPM package)

#78

Post by cxr »

binarynate wrote: post #47

This is why JS runtimes should add the ability to set permissions on a per-module basis. Deno is a step in the right direction by requiring permissions for a script to be specified (e.g. deno run --allow-read --allow-net myscript.ts), but the permissions are global for the entire script and can't (yet?) be configured differently for each module / dependency.

Alternatively, JS programmers should exhibit less contempt for the standardized, sandboxed runtime that JS was originally created to target: the Web browser.

What's nuts is that any of these projects (whether they be single components, larger utilities, or full-blown apps) require a build step that involves anything more complicated[1] than a single machine-readable document in the web browser's native file format and that sits alongside (or in place of[2]) the project README. With so many programmers writing code for the express purpose of making digital documents with behavior dynamic enough to trick you into thinking that the page you have open is really an app, no one in the community with any clout ever stops and says, "Gee, since we're at it, maybe we ought to take this tech that enables us to securely run code on demand and focus it on the goal of allowing other programmers to configure all these modules that we're sharing with one another, or to handle the finishing step of a collection of modules that make up a given app."

Then again, that would presume that any of the stuff that this industry engages in is actually meant to solve any problem, rather than creating a neverending supply of them in order to justify the paychecks being written and the egos they're feeding. If stuff's not laughably overengineered to the point of constantly breaking for no good reason[3], does it even count as "real"[4] programming?

1. https://www.colbyrussell.com/2019/03/06/how-to-displace-java...

2. https://news.ycombinator.com/item?id=28407936

3. https://news.ycombinator.com/item?id=24494434

4. https://news.ycombinator.com/item?id=17165784

Re: Embedded malware in RC (NPM package)

#79

Post by peteatphylum »

matheusmoreira wrote: post #71
thrashh wrote: 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.

> Nothing you will think of will evade defeat. Trust. Why is it that random people can submit packages? Make it so they can't. Only trustworthy people should be able to do that. People who care, so that we don't have to. People we can trust. This is how Linux distributions work and you just don't see malware randomly making its way into official repositories.

I wish it worked that way. I just peeked into how python packages in debian-based distros work. They are most frequently PyPI packages with some debian wrapping, so we're back at the same problem.

Re: Embedded malware in RC (NPM package)

#80

Post by beart »

hn_throwaway_99 wrote: post #25

One of the thing I wish was really much easier to do with NPM is, when running `npm update`, to only pick up the most recent compatible versions from X days ago . That is, for sensitive apps, I don't want to use versions that are less than, say, a month or so old unless I specifically override it. I want to stay up-to-date but not too bleeding edge, specifically to avoid situations like this.

renovate bot can do this. set it to wait for x days before accepting a merge, and pin your versions so there's no chance to update by mistake.
Post reply on HN