TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

1107 点作者 Robadob超过 4 年前

71 条评论

ryukafalz超过 4 年前
I see a lot of people saying things like &quot;this is why package signing is important&quot; and &quot;we need to know who the developers are&quot; and &quot;we need to audit everything.&quot; Some of that is true to some degree, but let me ask you this: why do we consider it acceptable that code you install through a package manager implicitly gets to do <i>anything</i> to your system that you can do? That seems silly! Surely we can do better than that?<p>This article from Agoric is extremely relevant here, from a previous such incident (re: the event-stream package on npm): <a href="https:&#x2F;&#x2F;medium.com&#x2F;agoric&#x2F;pola-would-have-prevented-the-event-stream-incident-45653ecbda99" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;agoric&#x2F;pola-would-have-prevented-the-even...</a><p>Put simply: in many cases, the dependencies you install don&#x27;t need nearly as much authority as we give them right now. Maybe some of these packages need network access (I see a few named &quot;logger&quot; which might be shipping logs remotely) but do they need unrestricted filesystem access? Probably not! (They don&#x27;t necessarily even need unrestricted network access either; what they&#x27;re communicating with is likely pretty well-known.)
评论 #26090786 未加载
评论 #26090578 未加载
评论 #26091390 未加载
评论 #26090401 未加载
评论 #26095781 未加载
评论 #26090517 未加载
评论 #26141572 未加载
评论 #26093315 未加载
评论 #26091015 未加载
评论 #26093834 未加载
评论 #26096231 未加载
评论 #26090415 未加载
评论 #26096078 未加载
评论 #26091633 未加载
评论 #26096278 未加载
Communitivity超过 4 年前
This doesn&#x27;t surprise me. Horrify.. yes.<p>I&#x27;ve noticed more dev teams succumbing to the temptation of easiness that many modern package managers provide (NPM, Cargo, Ivy, etc.) - especially as someone who has to work with offline systems on a regular basis.<p>Because of that ease there are fewer tools and tutorials out there to support offline package management. There are more for using caches, though these are often along the lines of either &#x27;the package manager will do this for you and it just works (but in case it doesn&#x27;t, delete node_modules or cargo clean and re-try)&#x27;, or stand up a dependency server on your own machine with these proxy settings (which has it&#x27;s own security issues and is frequently disallowed by IT cybersecurity policies).<p>As an example, many blog articles I found a while back suggest using yumdownloader from the yum-utils package. This is unfortunately not reliable, as there are some packages that get skipped.<p>I have found I need to script reading a list of dependencies from a file; then for each dependency: create a directory for it, use repotrack to download its RPM and it&#x27;s transitive dependency RPMs in the dependency&#x27;s directory; then the script aggregates all the RPMs into one directory, removes the OS installed RPMs, uses createrepo to turn that directory into a RPM repository, and then makes an USF ISO image out of the directory for transfer onto offline system and installation.
评论 #26090054 未加载
kasperni超过 4 年前
I&#x27;m surprised the reverse fully-qualified domain name (FQDN) model used by Java isn&#x27;t more widely adopted. If you want to upload artifacts to the main repository (Maven Central) you first need to show ownership of a particular domain. For example, via a DNS TXT record (example [1]). Would make these kind of attacks a lot more difficult.<p>[1] <a href="https:&#x2F;&#x2F;issues.sonatype.org&#x2F;browse&#x2F;OSSRH-61509" rel="nofollow">https:&#x2F;&#x2F;issues.sonatype.org&#x2F;browse&#x2F;OSSRH-61509</a>
评论 #26087749 未加载
评论 #26087579 未加载
评论 #26087725 未加载
评论 #26089748 未加载
评论 #26087924 未加载
rachelbythebay超过 4 年前
I’m cackling at how great this is. This is what happens when you trust the internet forever and just scarf down any old thing at build time. Of course it’ll get exploited! That’s what evil people do.
评论 #26087487 未加载
评论 #26087395 未加载
评论 #26092019 未加载
评论 #26092452 未加载
评论 #26087534 未加载
评论 #26089994 未加载
评论 #26087406 未加载
评论 #26087470 未加载
nstart超过 4 年前
This post seems like a good time to note that by default, there&#x27;s no direct way to verify that what you are downloading from dockerhub is the exact same thing that exists on dockerhub [1].<p>Discovered after seeing a comment on HN about a bill of materials for software, i.e., a list of &quot;approved hashes&quot; to ensure one can audit exactly what software is being installed, which in turn led me to this issue.<p>[1] - <a href="https:&#x2F;&#x2F;github.com&#x2F;docker&#x2F;hub-feedback&#x2F;issues&#x2F;1925" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;docker&#x2F;hub-feedback&#x2F;issues&#x2F;1925</a>
评论 #26088522 未加载
评论 #26089966 未加载
DecoPerson超过 4 年前
Imagine we navigated the web using a command line tool called “goto” which works exactly like a package manager. If I want to open my bank’s site, I type “goto mybank” .<p>I could easily find myself in trouble, because:<p>- There’s no autocomplete or bookmarks, so typos are easy.<p>- If “mybank” is a name provided by my company’s name server, I could find myself redirected to the public “mybank” entry because Mr. Not-A-Hacker says his name entry is more up to date (or because I forgot to tell ‘goto’ to check the company name server.)<p>- There’s no “green padlock” to check while I’m actively using the destination site. (Though at this point it’s too late because a few moments after I hit enter the destination site had the same access to my machine &amp; network that I do from my current terminal.)<p>- A trusted site may later become malicious, which is bad due to the level of unrestricted and unmonitored access to my PC the site can have.<p>- Using scripting tricks, regular sandboxed browser websites can manipulate my clipboard so I paste something into ‘goto’ that I didn’t realize would be in my clipboard, making me navigate to some malicious site and giving it full access to my machine (if ‘sudo’ as added to the front).<p>This is just a few cases off the top of my head. If ‘goto’ was a real thing, we’d laugh it into being replaced by something more trustable.<p>How have current package managers not had these vulnerabilities fixed yet? I don’t understand.
mavhc超过 4 年前
<a href="https:&#x2F;&#x2F;security.googleblog.com&#x2F;2021&#x2F;02&#x2F;know-prevent-fix-framework-for-shifting.html" rel="nofollow">https:&#x2F;&#x2F;security.googleblog.com&#x2F;2021&#x2F;02&#x2F;know-prevent-fix-fra...</a><p>At Google, we have those resources and go to extraordinary lengths to manage the open source packages we use—including keeping a private repo of all open source packages we use internally
评论 #26090341 未加载
评论 #26090111 未加载
ex_amazon_sde超过 4 年前
Ex-Amazon SDE here.<p>&gt; a unique design flaw of the open-source ecosystems<p>This is a big generalization.<p>Inside Amazon, as well as in various Linux distributions, you cannot do network traffic at build time and you can only use dependencies from OS packages.<p>Each library has its own package and the code and licensing is reviewed. The only open source distribution that I know to have similar strict requirements is Debian.<p>[I&#x27;m referring to the internal build system, not Amazon Linux]<p>[Disclaimer: things might have changed after I left the company]
评论 #26089081 未加载
donaldihunter超过 4 年前
This was inevitable from the moment we let build systems and runtime systems fetch things automatically and unsupervised from public repos. This is the simplest and most blatant approach yet, but taking ownership of existing projects and adding malicious code is an ongoing problem. Even deleting a public project can have the effect of a DOS attack.<p>When I first used maven, I was appalled by how hard it was to prevent it from accessing maven central. And horrified to see karaf trying to resolve jars from maven central at run time. What a horrible set of defaults. This behaviour should be opt-in, disabled by default, not opt-out through hard to discover and harder to verify configuration settings.
评论 #26088080 未加载
keyle超过 4 年前
I&#x27;m flabbergasted by how silly this is. Bump the version and the package manager chooses yours online vs. the private one. Amazing. How silly and how expensive is this going to be as this blatant security issue is going ripple on for the next months to come.
评论 #26088656 未加载
评论 #26141688 未加载
评论 #26090467 未加载
ehnto超过 4 年前
Pulling packages down at build time seems ludicrous to me, I can understand it in a development environment, but I don&#x27;t understand how &quot;Pull packages from the public internet and put them into our production codebase&quot; past any kind of robustness scrutiny.<p>I guess it&#x27;s a case of the ease of use proving too great, so convenient in fact that we just kind of swept the implications under the rug.
评论 #26088512 未加载
评论 #26089420 未加载
评论 #26088548 未加载
评论 #26089705 未加载
评论 #26088875 未加载
评论 #26088430 未加载
jtsiskin超过 4 年前
That is insane that any company allowed this to happen.<p>&quot;&quot;That said, we consider the root cause of this issue to be a design flaw (rather than a bug) in package managers that can be addressed only through reconfiguration,&quot; a Microsoft spokesperson said in the email.&quot;<p>No, npm has scopes for a reason, why would that not fix this issue?
评论 #26087971 未加载
评论 #26087362 未加载
评论 #26087551 未加载
评论 #26088261 未加载
评论 #26087773 未加载
jbverschoor超过 4 年前
It won&#x27;t be just companies. It&#x27;ll be developers, sysops, etc who npm install a bazillion of packages, because the core language and libaries are not enough. Those people have keys, credentials and access to the internal networks.
评论 #26095854 未加载
nightpool超过 4 年前
The article mentions that RubyGems is vulnerable to this, and that Shopify in particular downloaded and ran a gem named &quot;shopify-cloud&quot;, but I&#x27;m curious as to how this is possible given a &quot;normal&quot; bundler pure-lockfile setup, or more generally the source-block directives I&#x27;ve seen in most Gemfiles.<p>That is, given a Gemfile.lock like, e.g.<p><pre><code> GIT remote: https:&#x2F;&#x2F;github.com&#x2F;thoughtbot&#x2F;appraisal revision: 5675d17a95cfe904cc4b19dfd3f1f4c6d54d3502 specs: appraisal (2.1.0) bundler rake thor (&gt;= 0.14.0) </code></pre> How would Bundler ever try and download the `appraisal` gem from RubyGems?<p>The Gemfile section is more explicable. While newer Gemfiles look like this:<p><pre><code> source &quot;http:&#x2F;&#x2F;our.own.gem.repo.com&#x2F;the&#x2F;path&#x2F;to&#x2F;it&quot; do gem &#x27;gemfromourrepo&#x27; end # or gem &#x27;gemfromourrepo&#x27;, source: &quot;http:&#x2F;&#x2F;our.own.gem.repo.com&#x2F;the&#x2F;path&#x2F;to&#x2F;it&quot; </code></pre> Older Gemfiles apparently looked like the following:<p><pre><code> source &#x27;https:&#x2F;&#x2F;rubygems.org&#x27; source &#x27;http:&#x2F;&#x2F;our.own.gem.repo.com&#x2F;the&#x2F;path&#x2F;to&#x2F;it&#x27; gem &#x27;gemfromrubygems1&#x27; gem &#x27;gemfromrubygems2&#x27; gem &#x27;gemfromourrepo&#x27; </code></pre> Which seems obviously vulnerable to the dependency confusion issue mentioned.<p>So is the understanding that Shopify&#x27;s CI systems were running `bundle upgrade` or another non-lockfile operation? (possibly as a greenkeeper-like cron job?) Or is `--pure-lockfile` itself more subtly vulerable?
评论 #26087379 未加载
评论 #26093077 未加载
siraben超过 4 年前
This attack demonstrates one of the problems outlined in the Nix thesis[0], that is the problem of nominal dependencies. That is, dependencies of the dependencies, build flags and so on are not taking into account, and in particular, the source of a package.<p>Nix makes it possible to query the <i>entire</i> build time and runtime dependency graph of a package, and because network access during build time is disabled, such a substitution attack would be harder to pull off.<p>The declarations for how the source is downloaded is specified declaratively and can be pinned to a specific commit of a specific Git repository, for instance.<p>[0] <a href="https:&#x2F;&#x2F;edolstra.github.io&#x2F;pubs&#x2F;phd-thesis.pdf" rel="nofollow">https:&#x2F;&#x2F;edolstra.github.io&#x2F;pubs&#x2F;phd-thesis.pdf</a>
andrejserafim超过 4 年前
Why would you want your CI to depend on an external source. Say a legit upgrade happened, but it has a breaking change. Now your build is broken.<p>Fixed versions for as many things as you can (including OS images, apt packages, Docker images, etc) lead to changes in your CI under your control.<p>Sure, you have to upgrade manually or by a script. But isn&#x27;t plain build stability worth it? Not even talking about security.
评论 #26096294 未加载
koolba超过 4 年前
&gt; The packages had preinstall scripts that automatically launched a script to exfiltrate identifying information from the machine as soon as the build process pulled the packages in.<p>Pre and post install scripts in NPM packages are such a terrible idea. Even when it’s not malware, it usually just a nagging donation request with a deliberate “sleep 5” to slow down your build and keep the text displayed.
评论 #26087944 未加载
评论 #26087914 未加载
heipei超过 4 年前
Previous discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26081149" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26081149</a>
评论 #26087225 未加载
jl6超过 4 年前
The real solution is to design and build software components that can be <i>finished</i>, so they can be ruthlessly vetted - rather than the endless churn of updates.
评论 #26087940 未加载
评论 #26087692 未加载
forty超过 4 年前
I don&#x27;t understand why there is this issue. We publish our internal npm packages in the @company namespace and we own this namespace on the public npm registry. Problem solved, isn&#x27;t it?
评论 #26094457 未加载
walrus01超过 4 年前
npm in particular has been problematic for a long time:<p><a href="https:&#x2F;&#x2F;naildrivin5.com&#x2F;blog&#x2F;2019&#x2F;07&#x2F;10&#x2F;the-frightening-state-security-around-npm-package-management.html" rel="nofollow">https:&#x2F;&#x2F;naildrivin5.com&#x2F;blog&#x2F;2019&#x2F;07&#x2F;10&#x2F;the-frightening-stat...</a><p><a href="https:&#x2F;&#x2F;techbeacon.com&#x2F;security&#x2F;check-your-dependencies-githubs-npm-finds-nasty-trojan-packages" rel="nofollow">https:&#x2F;&#x2F;techbeacon.com&#x2F;security&#x2F;check-your-dependencies-gith...</a><p><a href="https:&#x2F;&#x2F;thenewstack.io&#x2F;npm-password-resets-show-developers-need-better-security-practices&#x2F;" rel="nofollow">https:&#x2F;&#x2F;thenewstack.io&#x2F;npm-password-resets-show-developers-n...</a>
评论 #26087828 未加载
ipsum2超过 4 年前
Package management isn&#x27;t what I initially think of when I hear &quot;supply chain&quot;. Neat hack! It&#x27;s like left-pad but malicious.
评论 #26087623 未加载
nine_k超过 4 年前
Popularized 3 years ago: <a href="https:&#x2F;&#x2F;medium.com&#x2F;hackernoon&#x2F;im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;hackernoon&#x2F;im-harvesting-credit-card-numb...</a>
评论 #26092754 未加载
umvi超过 4 年前
&gt; I have been fascinated by the level of trust we put in a simple command like this one<p>sigh... am I the only one that <i>likes</i> environments where you can run simple commands to install stuff and you can generally trust your package managers? All the security folks love to act dumbfounded when people trust things, but post-trust environments have <i>terrible</i> UX in my experience. I hate 2FA, for example, because now I have to tote my phone around at all times in order to be able to access any of my accounts. If I lose my phone or my phone is stolen while travelling, I&#x27;m hosed until I can figure out how to get back in.<p>&gt; So can this blind trust be exploited by malicious actors?<p>Yes, it can. Trust can <i>always</i> be exploited by malicious actors, and no amount of software can change that. And it creates a world that sucks over time. Show me a post-trust, highly secure environment that isn&#x27;t a major PITA to use. And not just for computers. I&#x27;m sure you could use social engineering to abuse trust of customer service reps (or just people in general) and do bad things, and the end result will be a world where people are afraid do any favors for other people because of the risk of getting burned by a &quot;malicious actor&quot;.
vlovich123超过 4 年前
Does this work with AOT compiled languages? Surely the fake packages that get uploaded don&#x27;t know the structure of the internal libraries enough, so for something like Cargo this would just cause in your build suddenly failing mysteriously &amp; easy to spot. A build.rs could probably do some damage to your build systems temporarily for the 1 or 2 days (if not hours) it takes for engineers to track down what&#x27;s happening.
alkonaut超过 4 年前
What I don’t get from the article is the reasoning behind the design that the central repository “wins” over the local&#x2F;override repository.<p>How was that design chosen, not just once but in all 3 of those large package ecosystems. Did pypi&#x2F;gems&#x2F;node borrow their design from each other given their similarity in other aspects?<p>Are there any situations where this behavior is desired?<p>Does any of the other ecosystems have flaws like this (nuget, cargo..)?
评论 #26102111 未加载
xurukefi超过 4 年前
I never understood why these package repositories don&#x27;t include some (opt-in?) integrity checking option using digital signatures. If I download code that executes on my machine there should be at least the option to establish some level of trust. We have been doing that with linux distro package managers for decades. Seems like common sense to me.
评论 #26087726 未加载
评论 #26088774 未加载
评论 #26087732 未加载
robertlagrant超过 4 年前
I&#x27;ve often wondered about this, even in the accidental case of someone registering a package you use internally.<p>And I know it&#x27;s not perfect, but in Python if you use Poetry means you get a poetry.lock file with package hashes built in, so that&#x27;s something.
p0d超过 4 年前
I teach and one of my students, with little IT experience, asked me last week about the security of package management. I found myself using the many eyeballs argument. It only takes one set of bad eyeballs.<p>It seems to me that down through the years ease of deployment trumps security. npm, mongodb, redis, k8s.<p>Or maybe sysadmin has just become outdated? Maybe front of house still needs a grumpy caretaker rather than your friendly devops with a foot in both camps.<p>We can now even outsource our security to some impersonal third-party so they can &#x27;not&#x27; monitor our logs.<p>EOG # end of grump
snarfy超过 4 年前
Sadly I&#x27;ve had to fix this at more than one company.<p>It&#x27;s a bit of cognitive dissonance having to explain why downloading random shit from the internet during the build is a bad idea, yet here we are.
wyc超过 4 年前
Here&#x27;s the application called deptrust I submitted to the Mozilla Builders program (didn&#x27;t get in :P) to address this problem space before I had to focus more on my current job. Please let me know if there are any collaborators who would like to work on this together someday!<p><a href="https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1EW6uSZB0_D0qZuDSGuxujuVEBkCbpWznv7gRcbFvUZs&#x2F;edit" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1EW6uSZB0_D0qZuDSGuxujuVE...</a>
评论 #26136578 未加载
CGamesPlay超过 4 年前
I know that node has `package-lock.json` and `yarn.lock`, which include integrity checks. Are these checks decorative only? How could npm have been affected by this issue?
评论 #26087412 未加载
评论 #26087697 未加载
评论 #26087481 未加载
furstenheim超过 4 年前
Npm ecosystem already has the solution. Use namespaces @yelp&#x2F;infra-js where @yelp is the npm user.<p>It&#x27;s not possible for an attacker to publish on that name in the public npm
unilynx超过 4 年前
These install hooks... Why are they needed at all and why can&#x27;t package (de)installation be without side effects ?<p>I&#x27;m sure the hooks are needed for things NPM can&#x27;t do by itself, but they shouldn&#x27;t run by default. That puts pressure on developers to avoid them, and puts pressure on NPM to add whatever functionality is missing from package.json in a safe way.<p>(and have npmjs.com search rank packages without scripts above those that do)
评论 #26090770 未加载
jwr超过 4 年前
I have to build some CSS libraries that sadly use npm for building. The way I approach this is through rubber gloves: I create custom docker containers with npm and a specific set of dependencies, frozen in time. This way I can at least get reproducible and reliable builds.<p>This doesn&#x27;t mean I&#x27;m not vulnerable to dependency attacks, but it at least limits the window, because I update these dependencies very, very rarely.
pabs3超过 4 年前
For apt repositories you can do pinning by origin, which should prevent this issue.
评论 #26089517 未加载
mbag超过 4 年前
To mitigate this kind of supply chain attacks for python, we have created following tool [1], that will check python packages on Artifactory instance you specify and create packages with the same name on the PyPi.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;pan-net-security&#x2F;artifactory-pypi-scanner" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pan-net-security&#x2F;artifactory-pypi-scanner</a>
评论 #26087637 未加载
评论 #26088011 未加载
tantalor超过 4 年前
Like some other commenters, I too initially balked at the apparent misuse of &quot;supply chain attack&quot; but the linked paper provides a good definition,<p><i>A software supply chain attack is characterized by the injection of malicious code into a software package in order to compromise dependent systems further down the chain.</i><p>Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks<p><a href="https:&#x2F;&#x2F;link.springer.com&#x2F;chapter&#x2F;10.1007%2F978-3-030-52683-2_2" rel="nofollow">https:&#x2F;&#x2F;link.springer.com&#x2F;chapter&#x2F;10.1007%2F978-3-030-52683-...</a><p>To be clear, just calling this a &quot;supply chain attack&quot; and omitting &quot;software&quot; is going to cause confusion with traditional supply chains.<p>The analogy is not quite apt: in a software build system you have complete visibility into the dependency tree, so this attack is less useful, whereas with hardware suppliers you are relying on the security of your vendor.
评论 #26090389 未加载
fareesh超过 4 年前
This seems to be tending towards the generic problem of permissions that we have seen previously elsewhere.<p>For example in the case of Facebook, it used to be that users would accept permissions without considering them, and in-turn, various apps would access their data in bad faith.<p>Likewise for mobile apps.<p>Eventually Facebook removed many of the overtly powerful permissions entirely, likewise with the mobile operating systems.<p>In the case of mobile, the concept of &quot;runtime permissions&quot; was also introduced that required explicit approval to be granted at the time of authorization.<p>On Android, location access now prompts the user in the notification area informing the user of an app that accessed their location.<p>Can some of these ideas be borrowed to the package&#x2F;dependency management world? &quot;The package you are about to install requires access to your hard drive including the following folders: x&#x2F;y&#x2F;z&#x2F;all?
smilliken超过 4 年前
This is both a security bug and a reproducibility bug. If anyone outside your network can break your build, your build is broken! It&#x27;s mission critical to have a working build.<p>The way Nix handles this is that every external resource is cached and hashed, and every reference to an external resource must have a hash integrity check. If someone swaps out a package on a web server somewhere, rebuilds keep working because they don&#x27;t need to re-fetch (because the hash wasn&#x27;t changed by an operator), and fresh builds fail with an error indicating the hash is invalid, which should trigger an investigation (in practice, this is exceedingly rare, and IMO always deserves attention).<p>I dream for when build reproducibility is considered table stakes like version control.
adolph超过 4 年前
I think JFrog and Azure won the prize for product placement on this one. When the article listed “Azure Artifactory” I wondered if Azure was “sherlocking” JFrog, but no, they have a partnership. Given the SolarWinds vector I expect more investment in tooling security.
SideburnsOfDoom超过 4 年前
The upstream article was posted yesterday, here<p>&quot;Dependency Confusion: RCE via internal package name squatting &quot; <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26081149" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26081149</a><p>&quot;Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies, The Story of a Novel Supply Chain Attack, Alex Birsan&quot; <a href="https:&#x2F;&#x2F;medium.com&#x2F;@alex.birsan&#x2F;dependency-confusion-4a5d60fec610" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@alex.birsan&#x2F;dependency-confusion-4a5d60f...</a>
rectang超过 4 年前
PGP signing of packages should be table stakes for publishing to a public repository. If unsigned packages are accepted by a public repository to reduce friction for newbies, such packages should be hidden by default.<p>Then, build tools should be configurable such that they only pull in dependencies signed by PGP keys drawn from a whitelist.<p>Finally, companies need to maintain private repositories of vetted dependencies and avoid pulling from public repositories by default — and this requirement needs to be configurable from the project&#x27;s build spec and captured in version control.
评论 #26089106 未加载
konaraddi超过 4 年前
For npm enterprise, it looks like setting the scope (e.g. @acmecorp&#x2F;internal-pkg) would mitigate the public and private confusion. For Verdaccio, an open source light weight npm registry, it first checks if a private package is available before searching the public npm registry (however, their best practices say to use a prefix for private packages <a href="https:&#x2F;&#x2F;verdaccio.org&#x2F;docs&#x2F;en&#x2F;best" rel="nofollow">https:&#x2F;&#x2F;verdaccio.org&#x2F;docs&#x2F;en&#x2F;best</a> )
fortran77超过 4 年前
I don&#x27;t use npm much, but once I&#x27;m out of the initial development phase with any package manager and am &quot;feature complete&quot; we generally lock versions down so at least we&#x27;re always pulling a specific version in.<p>And, of course, on production build machines, all packages are local.<p>This isn&#x27;t just for &quot;security&quot; -- it&#x27;s to ensure we can always build the same bits we shipped, and to avoid any surprises when something has a legitimate update that breaks something else.
0xbadcafebee超过 4 年前
My favorite supply chain attack is still the chip vendors. Even if you come up with a hardware security module in your chip to verify the code that&#x27;s running on it, that can be (and has been) hacked too. Sleeping dragons could be lying in wait in billions of devices and nobody would know unless they went out of their way to do a low-level analysis.
angry_octet超过 4 年前
I&#x27;ve been wishing npm&#x2F;pypi&#x2F;apt etc would improve for ages, but it seems like infrastructure improves one disaster at a time, software one hack at a time. I&#x27;m only annoyed I didn&#x27;t do it myself.<p>The pypi maintainer is being ridiculous, it is much better to have this guy poke MSFT than have the Russians do it, he&#x27;s doing them a favour.
PhineasRex超过 4 年前
The only really shocking part of this is that Artifactory is vulnerable to this. I expect developers to be lazy about build security because I&#x27;ve seen it over and over again at multiple companies, but Artifactory&#x27;s whole purpose is to provide secure build dependency management.<p>I&#x27;ll be rethinking using Artifactory in my infrastructure.
评论 #26095934 未加载
NicoJuicy超过 4 年前
I used this version trick in nuget, but the other way around.<p>To update existing non-maintained public packages, mostly because they were on. Net framework and a lot moved to .net core.<p>In visual studio you can set the priority of where packages have to be checked. My own package repo has a higher priority.<p>I never thought about using it as an attack vector though.
评论 #26088545 未加载
wepple超过 4 年前
Does NPM offer cryptographic hash pinning of packages the way that PyPI does?* why is this not more widely used?<p>* <a href="https:&#x2F;&#x2F;flawed.net.nz&#x2F;2021&#x2F;02&#x2F;02&#x2F;PyPI-Security-State&#x2F;" rel="nofollow">https:&#x2F;&#x2F;flawed.net.nz&#x2F;2021&#x2F;02&#x2F;02&#x2F;PyPI-Security-State&#x2F;</a>
milo_im超过 4 年前
Diffend allows you to manage the risks that come with using open-source third party dependencies by providing malware detecting security scanning and a risk management platform for your Ruby dependencies.<p><a href="https:&#x2F;&#x2F;diffend.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;diffend.io&#x2F;</a>
soheil超过 4 年前
This brings a whole new level of awareness to package files where a simple typo can mean your machine can be rooted. From now on I&#x27;ll always be terrified whenever changing any of my <i>package.json</i>, <i>Gemfile</i> or <i>requirements.txt</i> files.
homakov超过 4 年前
Why didn&#x27;t npmjs&#x2F;rubygems just check failed lookup requests for &quot;shopify-cloud&quot; etc and block those for a while to prevent damage, and notify the companies (doing their best)? Seems like low hanging solution.
ddtaylor超过 4 年前
Does anyone else skip reading articles on Medium because of their login policies?
3np超过 4 年前
It surprises me a bit the way they refer to in-house dependencies purely by version number. When we have internal dependencies in e.g. package.json, it&#x27;s always referred to by an explicit url and git ref.
peteretep超过 4 年前
&gt; After spending an hour on taking down these packages, Ingram stressed that uploading illicit packages on PyPI puts an undue burden on the volunteers who maintain PyPI.<p>I dunno, feels like fair game to me
pinacarlos90超过 4 年前
Question for you guys here:<p>Is this kind of attack possible using Nuget-Package manager?
评论 #26091308 未加载
评论 #26091265 未加载
评论 #26090957 未加载
stephenr超过 4 年前
And still people won’t vendor their dependencies, so changes to dependencies are never reviewed.<p>To paraphrase family guy: you’re making this harder than it needs to be.
technics256超过 4 年前
Can&#x27;t there be a &quot;package signature&quot; of some sort that is specified and checked against in a package-lock.json or yarn.lock?
评论 #26088151 未加载
评论 #26089711 未加载
jcims超过 4 年前
Can anyone point me at a resource where I can download the full set of packages that are in the npm registry?
评论 #26103068 未加载
claw_howitzer超过 4 年前
Did this guy just make hundreds of thousands of dollars off this single bug (type)?
cooervo超过 4 年前
this shouldn&#x27;t be a problem with golang right? because it uses an id when go mod is used. I&#x27;m rusty on go since I haven&#x27;t used it in over 2 years but I believe this shouldn&#x27;t affect it?
malinens超过 4 年前
luckily I reserved my company&#x27;s namespace in packagist few months ago. each package manager works differently and it is hard to know inner workings of all package managers
tppiotrowski超过 4 年前
Dev 1: “npm -g package_name” doesn’t work.<p>Dev 2: try “sudo npm -g package_name”.
megous超过 4 年前
But will anything change in the minds and hearts of developers?
评论 #26087552 未加载
omega3超过 4 年前
Less than $4k average bounty for this.
Bannednad超过 4 年前
Bullshit you would be next to julian
seniorivn超过 4 年前
solution: use nix as your package manager
评论 #26087230 未加载
评论 #26088142 未加载
baybal2超过 4 年前
This is why end-developer signing is essential.<p>This is not as amendable to CI, but that&#x27;s the point.
评论 #26095985 未加载
评论 #26087662 未加载
trishankkarthik超过 4 年前
This is NOT a supply chain attack. Solarwinds was a supply chain attack. This is a typosquatting demonstration that happens every one or two years.
评论 #26088185 未加载
sitkack超过 4 年前
We need a blockchain for source. It is obvious and we just haven&#x27;t come to terms with it yet. Then anyone can run anything provided they have the right key.