-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
globally-installed package overwrites an existing binary in the target install location #7761
Comments
tldr: The vulnerabilities are fixed. What remains (both in Yarn and npm) is the consequence of the typical Node package management security policies, and closing that the way you intend it would require to simply rethink part of how both package managers and Node security policies are designed. On the bright side, Yarn 2 is doing precisely that (for the package manager part), with the hope that once Node catches up we'll be able to switch painlessly. So ... what happened? There are three reports (pinging their author, @DanielRuf): 1. Binary plantingThis means that, by using a specially crafted {
"bin": {
"../../../../../../../../../../../../home/arcanis/foo": "foo"
}
} This is a very weird behaviour, not a single chance that it would be legit, so we now prevent it. It's still possible to do it using a postinstall script, of course, but at least just running To be clear: it's safe to call this behavior a vulnerability, and it's now fixed. 2. Out-of-tree executionThis means that, by using an absolute (or deep relative) path as {
"bin": {
"foo": "/home/arcanis/foo"
}
} Yarn 1.21.1 fixes that by making sure that the target is neither an absolute path nor a back-relative path. So Now - does it entirely solve the problem? Meh. Let's assume two cases:
As you can see, fixing the initial report does little to protect you against a malicious package, as they have many tools at their disposal to mess with your system if you dare execute them. For this reason, I'd class the fix we've done (both Yarn and npm) as a bugfix rather than a vulnerability fix. The only true fix can come from having true per-package security policies, which can only be implemented on the Node side. 3. Binary overlapThis means that a malicious package can "pose" as another by exposing an overlapping binary name. So for example: {
"name": "malicious-package",
"bin": {
"my-tool": "./script.js"
}
} In this case, if you have both packages Let's ignore postinstall scripts for a second - you'll have understood by then that you're in a bad place if they're executed. So what should we do here? It seems likely indeed that we shouldn't allow such conflicts to happen. At the same time:
Changing that would make you feel safer, maybe, but you wouldn't really be. And it could trigger compatibility problems for some projects that would then be unable to keep upgrading Yarn and profit from future security updates. Conclusion - What to do?
|
@arcanis
I agree with you. But I feel that printing a warning for binary overlap is helpful to detect the case because printing a warning won't break anything and developers sometimes install npm packages without confirming what the package does by copy-paste from blog posts.
I sometimes concern about the risk of postinstall scripts. I don't actually recognize how many postinstall scripts are executed while |
I've created an npm package to disclose I think it would be nice if |
@koba04 it seems your package reads the local files and checks if they contain It has to be done after the tarballs are unpacked but before description. Yarn v2 might support this through plugins / hooks. |
@DanielRuf Yeah, in this case, we should run |
Does yarn have a plan to support |
Yes, although new features will be implemented in the v2 trunk (we may backport them on a case-by-case basis, but this will only be once the v2 is stable). |
@arcanis Thank you!!! That sounds amazing!!馃槏 |
if you can --ignore-scripts ... also there should be a way, from yarn to so yarn install --scripts-only. If only because there are many situations where "yarn's" link behavior doesn't bring in the whole-state of the module. For example: a postinstall hook that checks the o/s version and maybe some configuration, and then installs an o/s and config-specific package. Yarn should keep these postinstall files in the cache, and link them in... but it seems to ignore them? Can't tell why. I always have to run --force to fix stuff |
npm has announced vulnerabilities that npm has been fixed.
https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli
One of the vulnerabilities has been fixed at yarn v1.12.1. Thank you! 馃憦馃憦馃憦
But yarn hasn't fixed the other yet.
Do you have any plans to fix this?
Do you want to request a feature or report a bug?
bug?
What is the current behavior?
globally-installed package overwrites an existing binary in the target install location.
If the current behavior is a bug, please provide the steps to reproduce.
What is the expected behavior?
Do not overwrite the symlink.
Please mention your node.js, yarn and operating system version.
The text was updated successfully, but these errors were encountered: