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'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.
Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
181–190 of 412 posts
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#182Earlier quoted context omitted.
I was thinking the same thing. Surely PayPal's packages should be signed by a certificate only PayPal has, and they would want to verify that before using their packages?
If the signature reqt is attached to the package metadata, the new package just removed it. If it's part of their custom build system, what signs third party packages? Would it just sign the new one anyway, because how does it know which ones should have PayPal internal signing? Or are you proposing manual controls? shudder Channels and priorities embedded in the package tools are a better approach, combined with som…
> Or are you proposing manual controls?
That's what we do. Dependencies are committed to our repository, so changes show up as diffs which are looked through then.
Then again we don't use libraries for padding strings and such...
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#183Earlier quoted context omitted.
apples and oranges, the name conflict was perfectly disambiguated by the use of the mandatory group identifier. npm design was so bad that you could at the beginning upload over an existing version of your package name and break dependencies retroactively even to people that pinned versions. if you want to try some good old whataboutism, at least try to be in the same ballpark.
Nobody in this thread argues that npm is not bad (it is), the current topic is: “is maven's design[1] better” and there is little evidence on this front. Maven was (yes, I'm using the past on purpose) not a panacea that later system failed to equal: it has the usability of an IRS form and never gained as much popularity in the Java world than npm in the JavaScript one for that reason. In 2014, last time I did Java fo…
Maven is/was huge in the Java world. For years it was pretty much the only way to resolve dependencies, until people got fed up with its many idiosyncrasies.
> “we are getting .jar files individually and not using maven because it's a fucking mess”
That seems odd and a bizarre edge case. Nobody worked like that with Java projects, and I bet nobody does today either.
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#184Earlier quoted context omitted.
"Years of maturity" or, just thinking about the problem for a bit. How long did it take npm to have scoped packages. Sure, let me create a "paypal" project, they only need one js project no? If Java suffers from excessive bureaucracy, the newer package developers/repos suffer from too much eagerness to ship something without thinking Not to mention dependency and version craziness. If you want your software to be rep…
It drives me crazy that "official" sounding package names like yaml are seemingly given basically first-come first serve, with no oversight. Publish anything you want, but call it Mark's awesome yaml library, or companyName-yaml or something like that so that people are aware that's not an officially supported project
What would you imagine that oversight looking like, who decides who gets the name `yaml`, and how do they verify it, and who pays for that time?
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#185Ex-Amazon SDE here. > a unique design flaw of the open-source ecosystems This is a big generalization. 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. 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 Debia…
I work in this area. This is not a supply chain attack. This is a typosquatting "attack" people keep rediscovering every year or two. I know, because I wrote an as yet unpublished paper on safely pulling packages from private and public repos.
There's no typos in this attack.
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#186Ex-Amazon SDE here. > a unique design flaw of the open-source ecosystems This is a big generalization. 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. 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 Debia…
I work in this area. This is not a supply chain attack. This is a typosquatting "attack" people keep rediscovering every year or two. I know, because I wrote an as yet unpublished paper on safely pulling packages from private and public repos.
This is not correct.
Installing packages only from a trusted (and signed) source protects against typosquatting, misread or confusing package names and many other risks.
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#187https://security.googleblog.com/2021/02/know-prevent-fix-fra... 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
That's more for availability than security. Assuming you keep the crypto checksums / author signatures of all the source code and packages, you don't need to keep a copy of the source / packages. Just verify them at download time. Many Linux distros don't even have a copy of all those binaries, they rely on HTTP mirrors of random organizations.
It's also useful for your organization to rebuild all of the source code from scratch (for reproducible packages anyway) and compare the new ones to the old ones, looking for things like compiler or hardware injection attacks. Secure build systems are definitely non-trivial.
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#188Ex-Amazon SDE here. > a unique design flaw of the open-source ecosystems This is a big generalization. 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. 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 Debia…
I work in this area. This is not a supply chain attack. This is a typosquatting "attack" people keep rediscovering every year or two. I know, because I wrote an as yet unpublished paper on safely pulling packages from private and public repos.
There are no typos here, the root issue is package manager preferring public packages of the same name over private ones
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#189Does this work with AOT compiled languages? Surely the fake packages that get uploaded don't know the structure of the internal libraries enough, so for something like Cargo this would just cause in your build suddenly failing mysteriously & 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's happening.
Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies
#190Pulling packages down at build time seems ludicrous to me, I can understand it in a development environment, but I don't understand how "Pull packages from the public internet and put them into our production codebase" past any kind of robustness scrutiny. I guess it'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.
> I can understand it in a development environment I can't. It's incredibly wasteful time and resource-wise, and ties your development process to third-party providers (and your ISP), which fall over often enough in practice. It's a good practice to have a local cache of all the third-party dependencies you use, available to both developers and CI infrastructure.
Well I agree, I don't personally do it either. My stack is comprised of tools that are pretty comprehensive on their own, so they get committed to the repository. A backend framework, a SASS compiler binary and a frontend framework if needed. It all gets put in the repo and any tasks are run by a makefile.