TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Vulnerability #319816 – npm fails to restrict the actions of malicious packages

279 pointsby sebastianmckabout 9 years ago

17 comments

kibwenabout 9 years ago
<p><pre><code> &gt; npm encourages the use of semver, or semantic &gt; versioning. With semver, dependencies are not locked to &gt; a certain version by default. For any dependency of a &gt; package, the dependency author can push a new version of &gt; the package. </code></pre> I don&#x27;t see how this has anything to do with semver. Semver doesn&#x27;t say anything about not locking dependencies to a certain version (i.e., locking to a specific version is totally legal), nor does it have anything to do with allowing package authors to push new versions of their packages (I&#x27;m not even sure how to parse this sentence, really... should it be impossible to ever push new versions of a package? (EDIT: maybe it&#x27;s suggesting there should be a central review process, like the iOS App Store?)).<p>In fact, the semver spec doesn&#x27;t even advocate automatically upgrading when new patch versions are released:<p><i>&quot;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.&quot;</i><p><a href="http:&#x2F;&#x2F;semver.org&#x2F;#why-use-semantic-versioning" rel="nofollow">http:&#x2F;&#x2F;semver.org&#x2F;#why-use-semantic-versioning</a>
评论 #11365111 未加载
评论 #11365020 未加载
评论 #11365712 未加载
评论 #11366062 未加载
blaisioabout 9 years ago
Unless I&#x27;m not understanding this correctly, every package manager is vulnerable to this attack (along with many others). I&#x27;m not sure why someone bothered to write this down and make an official &quot;disclosure&quot;. Maybe someone more knowledgeable can explain?<p>I mean really the idea is just that if someone got somebody else&#x27;s password, they could use it to trick other people into installing a program. Even email has this problem. So really the only thing NPM could be accused of here is not doing more to make publishing secure (like using two-factor authentication).
评论 #11364586 未加载
评论 #11364702 未加载
评论 #11364776 未加载
评论 #11365491 未加载
评论 #11364815 未加载
评论 #11365064 未加载
评论 #11365606 未加载
评论 #11364934 未加载
评论 #11364567 未加载
评论 #11365158 未加载
评论 #11364587 未加载
userbinatorabout 9 years ago
I have a feeling that a lot of other systems also provide &quot;the capability for a self-replicating worm&quot;, as that&#x27;s just the nature of computers in general, and part of why they&#x27;re so very useful.<p>To me, the fact that this &quot;vulnerability&quot; requires explicit user action, akin to deliberately downloading and running malware, says that it&#x27;s really a property of all software ecosystems in which people can publish and disseminate freely.<p>In that respect, it&#x27;s nice to see a &quot;this is as intended&quot; response instead of the typical direction of coming up with a set of more draconian policies and processes merely to protect users from themselves.<p>But given what &quot;security research&quot; these days seems to involve, I can almost imagine in the future: &quot;Vulnerability #1048576 - computer allows users to perform potentially malicious actions.&quot;
评论 #11364485 未加载
pfootiabout 9 years ago
I feel like, with the left-pad fiasco, the node dev world (and the broader programmer community) is rediscovering the web of trust that makes open source feasible.<p>I mean, if I distributed a library through some other package manager system, like a .jar file or some code that you install via homebrew, pip, or .&#x2F;configure.sh &amp;&amp; make, I can embed malicious code in the source somewhere. Maybe not all automated package managers are quite as vulnerable to install hooks, but all open source code is vulnerable to trust attacks, at runtime if nowhere else. I ultimately trust the process that gives me nginx enough to let it serve up my code, hoping there&#x27;s not a backdoor somewhere that is shoving environment variables (and therefore API keys) out the window to a hacker.<p>You can&#x27;t assume people are going to review every line of source before they link against a library. You can&#x27;t assume people aren&#x27;t going to click that link that looks like a download link on a sourceforge page but is, in fact, a crapware link. People make mistakes all the time.<p>So, yeah, there&#x27;s probably room to make npm a little more robust and difficult to specifically target as a vector. But thousands of developers are still going to be writing sass, and using node-sass to build that, which needs to download, compile and execute a binary on the devbox. Making the installation process of libsass take an extra step or two is great and all (and annoying, and probably likely to degrade windows node development most of all, since windows libraries are harder to put in a &quot;standard&quot; place if you&#x27;re a non-windows dev writing a node library), but people are still going to be running libsass binaries on their local machine without auditing it, trusting that the developers there have good opsec and review everything well.<p>On the other hand, all this publicity means someone&#x27;s bound to actually try and build stuff that exploits trust here, either wormlike or just executing an rm -rf in an install hook. So, my trust levels are lowered and my productivity impaired because I&#x27;ll be auditing more closely all the updates to existing plugins I&#x27;m using. Win?
评论 #11366449 未加载
nickpsecurityabout 9 years ago
Here&#x27;s a reference work with links to key papers on build system security for anyone trying to improve them:<p><a href="http:&#x2F;&#x2F;www.dwheeler.com&#x2F;essays&#x2F;scm-security.html" rel="nofollow">http:&#x2F;&#x2F;www.dwheeler.com&#x2F;essays&#x2F;scm-security.html</a><p>Dig into archive.org for Shapiro&#x27;s OpenCM while you&#x27;re at it as it had a lot of nice properties. Aegis seemed to as well. Pulling good traits from Wheeler&#x27;s survey into modern ones would be a good idea. Also, one can re-develop OpenCM, Aegis, etc to have modern features like plugins for common languages&#x2F;apps or DVCS capabilities.<p>SCM security techniques date back to 80&#x27;s-early 90&#x27;s. No excuse for today&#x27;s solutions to still lack the basics.
raesene3about 9 years ago
Kind of amusing that this is considered to need a new vuln. report, I kind of assumed it was common knowledge.<p>Most of the programming language package repositories (e.g. npm, rubygems, PyPi, NuGet) have this kind of installation process and limited&#x2F;no checks for malicious content.<p>Also as there&#x27;s no consistent use of package signing by the developer (it&#x27;s either unsupported or not very used) there is also a risk of the repository itself being compromised.<p>I did a talk last year for OWASP AppSecEU that covers this kind of thing. <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Wn190b4EJWk" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Wn190b4EJWk</a>
评论 #11364917 未加载
评论 #11366160 未加载
ktRolsterabout 9 years ago
And no intention from NPM to fix (according to the article)
评论 #11364464 未加载
notdonspauldingabout 9 years ago
&quot;It rather involved being on the other side of this airtight hatchway&quot;<p><a href="https:&#x2F;&#x2F;blogs.msdn.microsoft.com&#x2F;oldnewthing&#x2F;20060508-22&#x2F;?p=31283" rel="nofollow">https:&#x2F;&#x2F;blogs.msdn.microsoft.com&#x2F;oldnewthing&#x2F;20060508-22&#x2F;?p=...</a>
评论 #11364804 未加载
chromakodeabout 9 years ago
In development, you should separate your npm publish credentials from your dev execution environment. Use some kind of sandbox where you `npm install` -- a VM is best.<p>In production, you should review the packages in your dependency tree and ensure that the exact version you reviewed is what you deploy. To that end, you should shrinkwrap your dependencies. Vendoring works well too. Shameless plug: for additional strictness in your shrinkwrap, you can use <a href="https:&#x2F;&#x2F;github.com&#x2F;chromakode&#x2F;exactly" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;chromakode&#x2F;exactly</a> to store content hashes.
评论 #11365458 未加载
msoadabout 9 years ago
&gt; 1. Socially engineer a npm module owner...<p>Social engineering is not accepted in many security bounties. Just saying...
评论 #11364686 未加载
mchahnabout 9 years ago
I am always surprised when I hear of developers letting new versions of dependencies go into production. I cannot imagine taking such a chance.<p>Even if every new version of the total app is tested heavily before production, you lose the inherent stability of shipping the same code that is known stable from the users over time.<p>Others have said it is important to use new versions of dependencies to get the bug fixes but I don&#x27;t see that as a good trade-off.
spankaleeabout 9 years ago
Automatically running pre and post scripts is absolutely insane.
评论 #11364703 未加载
评论 #11364676 未加载
评论 #11364788 未加载
评论 #11364796 未加载
评论 #11364795 未加载
footaabout 9 years ago
It does seem to me like it would be reasonable enough to not have npm stay logged in after running a command.
en4bzabout 9 years ago
Does npm require signing of packages?
评论 #11364944 未加载
fiboabout 9 years ago
Just to share, there is an issue about uglifyjs <a href="https:&#x2F;&#x2F;github.com&#x2F;mishoo&#x2F;UglifyJS2&#x2F;issues&#x2F;936" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mishoo&#x2F;UglifyJS2&#x2F;issues&#x2F;936</a>
评论 #11365620 未加载
评论 #11365147 未加载
diegorbaqueroabout 9 years ago
Now that things like GreenKeeper exists, the ^ should be removed from being a default thing.
评论 #11365627 未加载
inglorabout 9 years ago
It&#x27;s disappointing to see you post this Sebastian, sure - Babel was affected by the whole left-pad ordeal but is more drama what would really help right now?<p>You&#x27;re a doer - if you want to see something done about it at Facebook no one is stopping you from forking NPM or contributing code to it.