4 ms·

I'm not a JS dev, but would it be possible for a malicious actor to create a pre/post install script that looks for packages published by the current user and "

by jwcrux 11y ago

I'm not a JS dev, but would it be possible for a malicious actor to create a pre/post install script that looks for packages published by the current user and "worms" its way into those pre/post install scripts? If this were possible, something like this could have the potential to infect quite a few npm modules.

istoica 11y ago
yes, it basically means this and it is not about npm in itself, it can also be gem, a pod, a jar ... basically what he highlights is that there is a lot of trust in these days in the open source repositories towards non-certified/verified contributors. There are others that already found the secure ways, such as the Linux kernel developers. I as a non developer, compared to them, in the web world, I put a lot of trust in the other, with almost no idea what/who he is, mostly a basic read of his username/github profile. And npm architecture, the "ultimate" code reuse repository, due to "there's an npm for sum(a,b)" that they so madly promote, it is extremely sensitive to exactly these types of maliciousness. Maybe npm will start to introduce policies, boards, advisers, commissions, really start to act professionally as it should, maybe this will work, but up to a point, in the end, it is the dev's problem to use the proper shit, and have some basic "wash your hands before you eat" type of rules: - use as little dependencies as possible, it will byte you later, it has been proven, don't head this road, fuck it! - ensure a back-up for that stuff, use a FTP account if you still are in that era, put them on S3 or even Dropbox, it is modern times, you have the means. - when you finally decide on one, check a little bit its usage rate, its latest commit date, its main, contributors, its image, yes, be shallow, look at the clothes, it must look good to the eye too. Ensure at least the dev tried its best in his available time there, get involved, read the number of users, the magic stars, the votes, the ratings, the songs, the novels, the books. Have a problem, not in the github issues, a functionality change, well, don't just beg for it opening a new bloody issue, fork the stuff, fork it hard and add your new magic trick and then create PR for yourself to shin and let others handle it from where you left. Be wise, improve yourself, be polite, be nice, look at the dependency's dependencies too, if they are shady, fuck it! roll your own! - most of the programmers these days, especially web ones, tend to rush to solution with their new agile/kanban/shalmban methodologies, their golden paths to success and ideologies, without taking time to do some housekeeping, I also do not blame, sometimes it really is without actually HAVING any time at all because the Scrum Master 5000 expect deliveries, solutions, not problems - I am a human, I live, I eat, I sleep - I do not have time for your shit, if you want it fast like that and don't accept my own timeline after presenting it to you 100 times in every daily stand-up shit, then fuck-it - no housekeeping, I go shady I start a dance with the wolves! - there is something rotten in Denmark with this "there's a start-up for every shit" mentality from which everything flows Enjoy life!
ENTP 11y ago
The post install script can be like any other script the user can run. There's no sandboxing so it can access anything the running user can access. So essentially, yes, it could infect any other module in there. I believe it could even run an "npm publish", which is pretty scary.
- gry 11y ago
  Even worse, `scp` the `~/.ssh/id_rsa` private key and known hosts file. The attack vector went tenfold.
- dineshp2 11y ago
  The recent NPM situation was a real eye opener for me. I never gave much thought to the attack vectors involoving package managers. > The post install script can be like any other script the user can run. There's no sandboxing so it can access anything the running user can access. Wow. This just seems wrong that the script has such far reaching privileges.
  - nmjohn 11y ago
    Considering node.js is able to spawn subshells and execute whatever code it wants when running, install scripts pose no additional threat to just running the javascript.
    - rdancer 11y ago
      The changes a package install makes ought to be limited to the source files within its subdirectory (and perhaps some precompiled binaries). I don't quite expect it to be installing rootkits, and the principle of least privilege dictates that it should not be allowed to. Once the package is installed, it is already too late for a code review, or any mitigation. A well-written worm will never be detected. It is unexpectedly bad design (or, in case of the JavaScript community, an expectedly bad design).
deleted 11y ago
[deleted]
jtuchsen 11y ago
I've not tried this, but a similar but easier exploit would be to register packages with names that are close to existing popular package names, and then have a post install script inject a modified version of the actual package into the node_modules directory that also does something malicious. So you register the "lodasj" package instead of "lodash" and than create a post install script to inject the malicious "lodash" package that re-exports all of the lodash API + does something nasty. If someone has a typo with "npm i lodasj" and doesn't notice the mistake, the machine that installs it and anyone that depends on the package is infected. I wonder how well policed NPM is against these kinds of malware attacks.
- troygoode 11y ago
  they'd notice as soon as they tried to run their program as "import * from 'lodash'" would fail (unless they were consistent with their typos...)
  - jtuchsen 11y ago
    You can inject a version of whatever you want into the node_modules folder in the post install script though can't you? So you just copy your own malicious lodash into node_modules. I haven't tried it but I think it'd work.
  - goldbeck 11y ago
    what if it ran "npm install -g lodash"?
- tyingq 11y ago
  This one isn't doing anything scary at the moment, but shows the potential: https://www.npmjs.com/package/uglifyjs https://www.npmjs.com/package/uglifyjs It's getting 30k+ downloads a month. The actual package people are looking for is here: https://www.npmjs.com/package/uglify-js https://www.npmjs.com/package/uglify-js
dclowd9901 11y ago
Scripts of dependencies don't run. Period. You'd have to fork someone else's repo and run npm install on that fork. If you're doing that, you ostensibly trust their code enough to inspect and work on it. If not, wtf are you doing? If you run `npm install` on a project, you're simply installing its dependencies (and actually running any pre-publish hooks too, for some stupid reason).
- deleted 11y ago
  [deleted]
JdeBP 11y ago
This idea appears to be the subject of https://news.ycombinator.com/item?id=11364347 https://news.ycombinator.com/item?id=11364347 .

by jwcrux 11y ago

istoica 11y ago

yes, it basically means this and it is not about npm in itself, it can also be gem, a pod, a jar ... basically what he highlights is that there is a lot of trust in these days in the open source repositories towards non-certified/verified contributors. There are others that already found the secure ways, such as the Linux kernel developers. I as a non developer, compared to them, in the web world, I put a lot of trust in the other, with almost no idea what/who he is, mostly a basic read of his username/github profile. And npm architecture, the "ultimate" code reuse repository, due to "there's an npm for sum(a,b)" that they so madly promote, it is extremely sensitive to exactly these types of maliciousness. Maybe npm will start to introduce policies, boards, advisers, commissions, really start to act professionally as it should, maybe this will work, but up to a point, in the end, it is the dev's problem to use the proper shit, and have some basic "wash your hands before you eat" type of rules: - use as little dependencies as possible, it will byte you later, it has been proven, don't head this road, fuck it! - ensure a back-up for that stuff, use a FTP account if you still are in that era, put them on S3 or even Dropbox, it is modern times, you have the means. - when you finally decide on one, check a little bit its usage rate, its latest commit date, its main, contributors, its image, yes, be shallow, look at the clothes, it must look good to the eye too. Ensure at least the dev tried its best in his available time there, get involved, read the number of users, the magic stars, the votes, the ratings, the songs, the novels, the books. Have a problem, not in the github issues, a functionality change, well, don't just beg for it opening a new bloody issue, fork the stuff, fork it hard and add your new magic trick and then create PR for yourself to shin and let others handle it from where you left. Be wise, improve yourself, be polite, be nice, look at the dependency's dependencies too, if they are shady, fuck it! roll your own! - most of the programmers these days, especially web ones, tend to rush to solution with their new agile/kanban/shalmban methodologies, their golden paths to success and ideologies, without taking time to do some housekeeping, I also do not blame, sometimes it really is without actually HAVING any time at all because the Scrum Master 5000 expect deliveries, solutions, not problems - I am a human, I live, I eat, I sleep - I do not have time for your shit, if you want it fast like that and don't accept my own timeline after presenting it to you 100 times in every daily stand-up shit, then fuck-it - no housekeeping, I go shady I start a dance with the wolves! - there is something rotten in Denmark with this "there's a start-up for every shit" mentality from which everything flows Enjoy life!

ENTP 11y ago

The post install script can be like any other script the user can run. There's no sandboxing so it can access anything the running user can access. So essentially, yes, it could infect any other module in there. I believe it could even run an "npm publish", which is pretty scary.

gry 11y ago
Even worse, `scp` the `~/.ssh/id_rsa` private key and known hosts file. The attack vector went tenfold.
dineshp2 11y ago
The recent NPM situation was a real eye opener for me. I never gave much thought to the attack vectors involoving package managers. > The post install script can be like any other script the user can run. There's no sandboxing so it can access anything the running user can access. Wow. This just seems wrong that the script has such far reaching privileges.
- nmjohn 11y ago
  Considering node.js is able to spawn subshells and execute whatever code it wants when running, install scripts pose no additional threat to just running the javascript.
  - rdancer 11y ago
    The changes a package install makes ought to be limited to the source files within its subdirectory (and perhaps some precompiled binaries). I don't quite expect it to be installing rootkits, and the principle of least privilege dictates that it should not be allowed to. Once the package is installed, it is already too late for a code review, or any mitigation. A well-written worm will never be detected. It is unexpectedly bad design (or, in case of the JavaScript community, an expectedly bad design).

deleted 11y ago

[deleted]

jtuchsen 11y ago

I've not tried this, but a similar but easier exploit would be to register packages with names that are close to existing popular package names, and then have a post install script inject a modified version of the actual package into the node_modules directory that also does something malicious. So you register the "lodasj" package instead of "lodash" and than create a post install script to inject the malicious "lodash" package that re-exports all of the lodash API + does something nasty. If someone has a typo with "npm i lodasj" and doesn't notice the mistake, the machine that installs it and anyone that depends on the package is infected. I wonder how well policed NPM is against these kinds of malware attacks.

troygoode 11y ago
they'd notice as soon as they tried to run their program as "import * from 'lodash'" would fail (unless they were consistent with their typos...)
- jtuchsen 11y ago
  You can inject a version of whatever you want into the node_modules folder in the post install script though can't you? So you just copy your own malicious lodash into node_modules. I haven't tried it but I think it'd work.
- goldbeck 11y ago
  what if it ran "npm install -g lodash"?
tyingq 11y ago
This one isn't doing anything scary at the moment, but shows the potential: https://www.npmjs.com/package/uglifyjs https://www.npmjs.com/package/uglifyjs It's getting 30k+ downloads a month. The actual package people are looking for is here: https://www.npmjs.com/package/uglify-js https://www.npmjs.com/package/uglify-js

dclowd9901 11y ago

Scripts of dependencies don't run. Period. You'd have to fork someone else's repo and run npm install on that fork. If you're doing that, you ostensibly trust their code enough to inspect and work on it. If not, wtf are you doing? If you run `npm install` on a project, you're simply installing its dependencies (and actually running any pre-publish hooks too, for some stupid reason).

deleted 11y ago
[deleted]

JdeBP 11y ago

This idea appears to be the subject of https://news.ycombinator.com/item?id=11364347 https://news.ycombinator.com/item?id=11364347 .