41–50 of 117 posts
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…
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…
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?
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?
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…
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 failing dependency updates can be flagged for attention.
Earlier quoted context omitted.
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?
That extra code will stand out as not having been reviewed.
Earlier quoted context omitted.
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…
2. Make running of preinstall/install scripts opt-in. They already are, npm install --ignore-scripts
Earlier quoted context omitted.
Command line argument parsing and config loading both seem like very sensible library abstractions to me. This isn’t leftpad.
>Command line argument parsing 20-30 LoC maybe. `process.argv.slice(2).forEach(str => ... )`. there is no access to the raw command-line invocation, sadly, so you really can't really do anything fancier than that. >config loading that thing "RC" package does - looking up the config file in random locations - is really strange to me. aren't you the one in control of where it is stored?
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.