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

111–117 of 117 posts

Re: Embedded malware in RC (NPM package)

#111

Post by jffry »

schemescape wrote: post #88
jffry wrote: post #75

Earlier quoted context omitted.

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 in…

Edit: That doesn't work as described on NPM 6.14.14 (the version I had), but it does work on NPM 8.1.0 (the version I just upgraded to). Thanks!

Ah, looks like it was introduced in v7.0 - https://github.com/npm/rfcs/pull/185

Re: Embedded malware in RC (NPM package)

#112

Post by tolmasky »

forty wrote: post #95
tolmasky wrote: post #51

Earlier quoted context omitted.

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…

I understand the attack but my point is that the next step after installing the popular package is probably to import/require it in my code, then run my unit tests, which will allow the evil package to run whatever code they intended to run.

Interestingly enough, this actually isn't always the case! For example, install scripts provide the unique ability to affect build machines, which often don't run the code, but do run install scripts. Build machines can still have sensitive keys though, and will often automatically start building in response to a PR being submitted. So in these cases, the attack targets a part of the system that is inaccessible to attacks that require importing or actually running code, and only requires submitting a pull request, not even having it accepted!

Another example is when npm is used for front-end code (which is a lot!). It's true here that the code will eventually be imported or required, but in the browser sandbox. Install scripts in this instance do meaningfully change the attack surface to not just be whatever cookies you have set up or whatever, but the entire contents of your filesystem.

Re: Embedded malware in RC (NPM package)

#113

Post by forty »

tolmasky wrote: post #112
forty wrote: post #95

Earlier quoted context omitted.

I understand the attack but my point is that the next step after installing the popular package is probably to import/require it in my code, then run my unit tests, which will allow the evil package to run whatever code they intended to run.

Interestingly enough, this actually isn't always the case! For example, install scripts provide the unique ability to affect build machines, which often don't run the code, but do run install scripts. Build machines can still have sensitive keys though, and will often automatically start building in response to a PR being submitted. So in these cases, the attack targets a part of the system that is inaccessible to at…

Yes I answered a sibling comment on front end code, I'll ask here again: doesn't browser code have tests that are run with nodejs?

And my build / CI machines generally run the tests too (though it's possible to separate the test runners from the build runners, I would not bet it's a very common thing).

Re: Embedded malware in RC (NPM package)

#114

Post by tolmasky »

forty wrote: post #113
tolmasky wrote: post #112

Earlier quoted context omitted.

Interestingly enough, this actually isn't always the case! For example, install scripts provide the unique ability to affect build machines, which often don't run the code, but do run install scripts. Build machines can still have sensitive keys though, and will often automatically start building in response to a PR being submitted. So in these cases, the attack targets a part of the system that is inaccessible to at…

Yes I answered a sibling comment on front end code, I'll ask here again: doesn't browser code have tests that are run with nodejs? And my build / CI machines generally run the tests too (though it's possible to separate the test runners from the build runners, I would not bet it's a very common thing).

1. With regard to build / CI, I certainly don't know the percentages worldwide, but this example actually comes from my own experience as a company I used to work at I believe had this setup of separate build and CI machines (for a variety of reasons, including the resource requirements being quite different).

2. At least with our frontend tests, no, we don't run them "in" node-js. Well, to clarify, the "tests" are run in node-js, but the frontend code in question is run in Puppeteer. Hence those libraries do not usually have any chance of touching our filesystem (except for their install scripts). This is a less complicated answer for non-"isomorphic" companies -- for example if your backend is Ruby and you use puppeteer-ruby, then I think we can agree that your npm packages should never run on your machine outside of a browser.

Just to give you a third case, again from my own experience, install scripts are also a good vector for typo attacks. If you type `npm install lodsah` instead of `npm install lodash`, and you don't notice and hit control-C fast enough, that mere installation can be sufficient to compromise your system.

Re: Embedded malware in RC (NPM package)

#115

Post by SpaceManiac »

jiggawatts wrote: post #110
SpaceManiac wrote: post #102

Earlier quoted context omitted.

I think I remember discussing this briefly in #rust with you. It's clearly not the case that "everyone understands" how these package managers actually work, but I'd rather see the reality become more obvious than give up and shackle these package ecosystems to Microsoft even harder than they already are.

NPM, Cargo, and the like are basically like the people saving a link to a random Wikipedia article, and then making the shocked Pikachu face when their presentation in front of the boss shows a defaced article with the Goatse picture in the middle of it. There's a solution to this problem, of course. The Wikipedia team provides the tools you need! You can link to a specific revision of an article so there are no surp…

> require that the crate content match the [commit] hash.

If you want to audit a crate, you don't need to require that it "matches" anything else, you can just audit the crate. Download the source tarball from the same URL that Cargo would and audit it. I think the problem with crates.io is that it just gives you the GitHub link (possibly misleading - bad!) and doesn't just give you a button to download or browse the tarball that Cargo actually uses (what you see is what you get).

Defining "matches" and enforcing it against a remote Git repository is non-trivial. It gets worse with NPM because those packages are sometimes the output of the Typescript compiler or Webpack, so now you need reproducible builds (a huge task) and a CI infrastructure to validate them. Nuget distributes .dll files, which often aren't even open source. There's no hope to enforce a correspondence with a Git repository there. A developer who wants to audit a Nuget package has no choice but to decompile it.

NPM clearly has a malware problem, and Cargo will eventually have one because it really wants to be like NPM. I'm not convinced that what you propose is the solution.

Re: Embedded malware in RC (NPM package)

#116

Post by jiggawatts »

SpaceManiac wrote: post #115
jiggawatts wrote: post #110

Earlier quoted context omitted.

NPM, Cargo, and the like are basically like the people saving a link to a random Wikipedia article, and then making the shocked Pikachu face when their presentation in front of the boss shows a defaced article with the Goatse picture in the middle of it. There's a solution to this problem, of course. The Wikipedia team provides the tools you need! You can link to a specific revision of an article so there are no surp…

> require that the crate content match the [commit] hash. If you want to audit a crate, you don't need to require that it "matches" anything else, you can just audit the crate . Download the source tarball from the same URL that Cargo would and audit it. I think the problem with crates.io is that it just gives you the GitHub link (possibly misleading - bad!) and doesn't just give you a button to download or browse th…

I get it. My mistake. Page 537 paragraph 7. I must have just missed it on the first reading of the contract.

I won't make that particular mistake again.

But just like the thousands (and thousands!) of people that are befuddled as to why Rust's console output is slower than Python, it's a pit of failure that others fill fall into.

Over and over. And over.

Re: Embedded malware in RC (NPM package)

#117

Post by forty »

tolmasky wrote: post #114
forty wrote: post #113

Earlier quoted context omitted.

Yes I answered a sibling comment on front end code, I'll ask here again: doesn't browser code have tests that are run with nodejs? And my build / CI machines generally run the tests too (though it's possible to separate the test runners from the build runners, I would not bet it's a very common thing).

1. With regard to build / CI, I certainly don't know the percentages worldwide, but this example actually comes from my own experience as a company I used to work at I believe had this setup of separate build and CI machines (for a variety of reasons, including the resource requirements being quite different). 2. At least with our frontend tests, no, we don't run them "in" node-js. Well, to clarify, the "tests" are r…

Just an extra thought: as soon as you are running anything from an npm "script" it's also lost, because any package is free to add anything in node_modules/.bin which then gets added to the PATH of those npm "script". So I guess you will want to fix that next :)
Post reply on HN