"It rather involved being on the other side of this airtight hatchway" https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...
This is not the first time I've seen that argument used to justify ignoring persistence attacks.
Vulnerability #319816 – npm fails to restrict the actions of malicious packages
31–40 of 138 posts
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#32Unless I'm not understanding this correctly, every package manager is vulnerable to this attack (along with many others). I'm not sure why someone bothered to write this down and make an official "disclosure". Maybe someone more knowledgeable can explain? I mean really the idea is just that if someone got somebody else's password, they could use it to trick other people into installing a program. Even email has this…
Not every package manager, for example the Solaris 11 package manager explicitly does not support install time scripting for this reason among many others:
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#33Earlier quoted context omitted.
What solution can we propose?
The article suggests this: > >As a user who owns modules you should not stay logged into npm. (Easily enough, npm logout and npmlogin) >Use npm shrinkwrap to lock down your dependencies >Use npminstall someModule --ignore-scripts > I would add to toss a glance at the libraries you import every once in a while. Just to make sure they look sane.
--ignore-scripts won't help much. The act of using any npm module means you implicitly trust all the javascript code in the module and any of its dependencies. Has anyone taken the time to inspect every line of the dozens of modules that many common packages pull in? Not likely.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#34 > npm encourages the use of semver, or semantic
> versioning. With semver, dependencies are not locked to
> a certain version by default. For any dependency of a
> package, the dependency author can push a new version of
> the package.
In fact, the semver spec doesn't even advocate automatically upgrading when new patch versions are released:
"As a responsible developer you will, of course, want to verify that any package upgrades function as advertised. The real world is a messy place; there’s nothing we can do about that but be vigilant."
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#35It does seem to me like it would be reasonable enough to not have npm stay logged in after running a command.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#36Earlier quoted context omitted.
All package managers (that I know of) for dynamic languages offer a mechanism for compiling native code for packages that include bindings to C libraries. That mechanism could easily be used to achieve the same goal, even if there was no explicit "post-script" mechanism.
Debian solved this particular problem a long time ago, with pbuilder(1): packages that are installed "from source" simply get compiled in a chroot. Strangely, nobody has ever copied the idea. The modern hipster-language equivalent would probably be to make the package manager depend on the presence of Docker/rkt/systemd, and use it to pull down a dev-env container and build the native bindings in that.
Don't give them ideas!
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#37Unless I'm not understanding this correctly, every package manager is vulnerable to this attack (along with many others). I'm not sure why someone bothered to write this down and make an official "disclosure". Maybe someone more knowledgeable can explain? I mean really the idea is just that if someone got somebody else's password, they could use it to trick other people into installing a program. Even email has this…
Similar problems exist in most package management systems. registries that have a manual review process mitigate this danger, but there's still always a risk of malicious code getting into the world. Having said this, we'd like to make exploits such as those discussed in #319816 as difficult as possible. We're exploring supporting new authentication strategies: such as 2-factor authentication, SAML, and asymmetric ke…
Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware...
Linux package managers are a different story of course.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#38Kind of amusing that this is considered to need a new vuln. report, I kind of assumed it was common knowledge.
Most of the programming language package repositories (e.g. npm, rubygems, PyPi, NuGet) have this kind of installation process and limited/no checks for malicious content.
Also as there's no consistent use of package signing by the developer (it's either unsupported or not very used) there is also a risk of the repository itself being compromised.
I did a talk last year for OWASP AppSecEU that covers this kind of thing. https://www.youtube.com/watch?v=Wn190b4EJWk
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#39Unless I'm not understanding this correctly, every package manager is vulnerable to this attack (along with many others). I'm not sure why someone bothered to write this down and make an official "disclosure". Maybe someone more knowledgeable can explain? I mean really the idea is just that if someone got somebody else's password, they could use it to trick other people into installing a program. Even email has this…
Well, isn't proper authentication a solution in and of itself? Using keys with pass phrases or requiring sudo to publish would theoretically mitigate this issue.
No, because it can just sit in the background and wait until you type your passphrase at some point. As soon as you run malicious code, it’s all over; no workarounds.
It would be nice if npm didn’t run arbitrary install scripts by default…
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#40Kind of amusing that this is considered to need a new vuln. report, I kind of assumed it was common knowledge. Most of the programming language package repositories (e.g. npm, rubygems, PyPi, NuGet) have this kind of installation process and limited/no checks for malicious content. Also as there's no consistent use of package signing by the developer (it's either unsupported or not very used) there is also a risk of…
A very insightful look at package signing, and why it wouldn't actually improve security for PyPI, by Python packaging guru Donald Stufft:
https://caremad.io/2013/07/packaging-signing-not-holy-grail/