4 ms·
> Also, because the instructions included an "npm install" command for the dependency, the attacker's code would achieve arbitrary code execution on the devices
by sublinear 3y ago
> Also, because the instructions included an "npm install" command for the dependency, the attacker's code would achieve arbitrary code execution on the devices of unsuspecting users.
This is debatable. If the owner unpublishes their old releases, then the npm install would simply fail and the package reference string is burned forever. I don't like the implication this post makes that other package managers don't require code execution to install, or that npm is somehow more vulnerable.
> Registry data is immutable, meaning once published, a package cannot change. We do this for reasons of security and stability of the users who depend on those packages. So if you've ever published a package called "bob" at version 1.1.0, no other package can ever be published with that name at that version. This is true even if that package is unpublished.
https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish
https://docs.npmjs.com/cli/v9/commands/npm-unpublish https://docs.npmjs.com/cli/v9/commands/npm-unpublish
To hijack an npm package is to exploit sloppy code review somewhere in the dependency tree. The registry has nothing to do with this.
Being aware of this policy, requiring maintainers to review all changes to "package-lock.json", and keeping this lock file in your repo ("npm-shrinkwrap.json" for releases) entirely mitigates this.
https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-j...
It's also important to regularly run npm audit on all releases and unpublish if vulnerabilities are found in the dependency tree of that lock file. It's better to break someone's build and leave a note that they need to upgrade than be part of the problem. Even further, npm audit reports are shown to the end user after an npm install so they can decide for themselves in the event the maintainers haven't unpublished yet (or ever).
https://docs.npmjs.com/cli/v9/commands/npm-audit https://docs.npmjs.com/cli/v9/commands/npm-audit
- EdwardDiego 3y ago> that other package managers don't require code execution to install But that's more or less true. Arbitrary code execution isn't a feature needed when installing packages for other languages that don't use C bindings so heavily. You're spot on that Node.js isn't alone, Python packages are very much the same in that packages can require code execution to install. But not all packaging systems require the ability to execute package provided code in order to install some packages. But then, in those languages, binding to C libs is far far less common.